Joel on Software

概要

Fog Creek Software(後のStack Overflow, Trello創業母体)の創業者であるジョエル・スポルスキーが、2000年から自身のブログ"Joel on Software"に断続的に発表してきたエッセイ群を選りすぐり、書籍としてまとめた一冊。Apress社より2004年に原著が刊行され、日本語版は青木靖の翻訳でオーム社より刊行されている。特定の開発手法やフレームワークを体系的に解説する技術書ではなく、採用・見積もり・仕様書作成・オフィス環境・ビジネス戦略といったソフトウェア開発現場の実務的な悩みに対して、著者自身がマイクロソフトでのExcel開発経験やFog Creek経営の実体験を踏まえて論じるエッセイ集としての性格が強い。著者はイェール大学でコンピュータサイエンスを優等で修めた後、1991年にマイクロソフトに入社しExcelチームのプログラムマネージャとしてExcel Basicの設計やVisual Basic for Applications戦略の策定に携わった経歴を持つ。平易でユーモアを交えた文体でありながら、後年「ジョエルテスト」のように業界内で広く定着する概念を数多く生み出したことで知られる。

本の構成

全5部構成。 - PART1 プログラミングのプラクティス: プログラミング言語選択、Unicode/文字コード、機能仕様書の書き方、デイリービルド、バグ管理、クラフトマンシップなど、日々の開発実務に関わる19章。 - PART2 開発者のマネジメント: 採用面接の技法、テスターの雇用、人員配置、開発者を守るマネジメントのあり方を扱う9章。 - PART3 Being Joel: 経営戦略、オープンソースの経済学など、より広い視点からのビジネス論を扱う14章。 - PART4 .NETについての論評: マイクロソフトの.NET戦略への批評を扱う3章。 - PART5 ジョエルに聞け選集: 読者からの質問に答える「ジョエルに聞け」コラムからの抜粋。

主要な内容

ジョエルテスト(PART1)

開発チームのプロセス品質を素早く自己診断するための12個のYes/No形式の質問(ソースコード管理を使っているか、1ステップでビルドできるか、デイリービルドを行っているか、バグデータベースを持っているか、新しいコードを書く前にバグを直すか、更新されたスケジュールを持っているか、仕様書があるか、開発者が静かな環境で作業できるか、購入できる最高のツールを使っているか、テスターがいるか、採用選考で候補者にコードを書かせているか、廊下で捕まえたユーザーにテストしてもらっているか)からなり、12点満点中10点以下であれば深刻な問題を抱えているとされる。特定の開発手法に依存せず、どのようなチームにも適用できる簡便な自己診断ツールとして提示されている。

「決してやってはいけないこと」――全面書き直し批判(PART1)

本書に収録された代表的なエッセイの一つは、動いている既存のコードベースをゼロから全面的に書き直すという判断が、ソフトウェア企業にとって最も危険な経営判断の一つであると論じる。著者は「コードは書くより読むほうが難しい」ため、既存コードが汚く見えても実際には長年の不具合修正と実運用による検証の蓄積が詰まっていると指摘し、アーキテクチャ上の問題・非効率・見た目の悪さといった不満は、全面書き直しではなく漸進的なリファクタリングによって解決すべきだと主張する。全面的な書き直しは、蓄積された知見を失わせ、競合に対する市場での優位性を何年分も失わせるうえ、新しいチームが同じ過ちを繰り返さない保証もないとされる。

採用面接論(PART2)

「スマートで物事をやり遂げる(Smart, and Gets Things Done)」人材のみを採用すべきだという方針を軸に据えた「ゲリラ式面接術」を展開する。妥協して平凡な人材を採用することは、優れた候補者を見送ることよりもはるかに組織にとって有害であるという「悪い採用は良い候補者の見送りより高くつく」という考え方が中心に据えられ、面接では候補者に実際にホワイトボード上でコードを書かせることで、経歴書だけでは判断できない実務能力を確認すべきだと説く。

機能仕様書とUnicodeのエッセイ(PART1)

コーディングに着手する前に詳細な機能仕様書を作成することで、後工程での手戻りを減らし、開発チーム全体でプロダクトの意図を共有すべきだと主張し、仕様書作成の具体的なテンプレートを提示する。また文字コードの歴史と仕組みを解説する有名なエッセイでは、Unicodeと文字集合についての最低限の知識を持たずにテキスト処理を実装すると文字化けなどの深刻なバグを生みやすいとし、すべての開発者が身につけるべき基礎知識として文字コードの理解を位置づけている。

「開発者の抽象化レイヤー」論(PART2)

良いマネジメントの役割とは、営業・総務・ハードウェア調達といった「面倒な雑務」から開発チームを遮断し、開発者がコーディングという本質的な作業だけに集中できる環境を用意することだとし、これをソフトウェアにおける抽象化レイヤーの概念になぞらえて論じる。

戦略論(PART3)

補完財(complement)の価格を引き下げることで自社の中核製品・サービスへの需要を押し上げるという「補完財のコモディティ化」戦略など、著者独自の視点によるソフトウェアビジネス論が展開される。

.NET批評(PART4)

マイクロソフトがVisual Basic 6などの旧来の開発者資産との後方互換性を軽視して.NETへの移行を強く推し進めたことに対する批判的な考察が展開される。

具体例

ジョエルテストの12項目そのものが具体的なチェックリストとして提示されるほか、面接での質問例(候補者に文字列を反転させる関数をその場で書かせるなど)、Fog Creekが採用していた個室中心のオフィスレイアウトの事例、自社製品FogBugz開発における「ドッグフーディング(自社製品を自ら使う)」の実践例などが挙げられている。全面書き直し批判のエッセイでは、ネットスケープ社がブラウザのバージョン6.0を旧コードベースから完全に書き直すという判断を下した結果、3年近く大型リリースを出せずにブラウザ市場での主導権を競合に奪われてしまった事例が、具体的な反面教師として詳しく取り上げられている。同様の全面書き直しの失敗例として、ボーランド社のdBaseやQuattro Proのプロジェクトについても言及されている。著者自身のマイクロソフトでの経験に基づく具体例としては、Excel Basicの設計やVisual Basic for Applicationsの策定に携わった際のプログラム言語設計上の判断についても随所で語られている。

実践への応用

開発チームの現状を手早く自己診断する手段としてジョエルテストのチェックリストを用いること、採用基準を「スマートで物事をやり遂げる」人材に絞り妥協しないこと、コーディング開始前に機能仕様書を作成してから着手すること、開発者に静かで集中できる作業環境と十分なツールを与えること、マネジメントが開発チームを雑務から遮断する「抽象化レイヤー」として機能すること、自社製品・サービスの価格戦略を検討する際に補完財との関係を意識することなどが、実務への応用として挙げられる。また、既存システムの刷新を検討する際には、ネットスケープの事例を教訓として、全面書き直しではなくまず漸進的なリファクタリングで対応できないかを検討するという判断基準としても応用できる。

位置づけ・評価

2000年代のソフトウェア業界において最も広く読まれたブログ発の書籍の一つであり、「ジョエルテスト」という語を業界内の共通言語として定着させたことで知られる。著者は本書刊行後の2008年にジェフ・アトウッドと共同でQ&Aサイトのスタック・オーバーフローを創業し、2019年までCEOを務めた(同社は2021年に18億ドルで売却された)。また2011年にはカンバン方式のプロジェクト管理ツールTrelloを立ち上げ、2017年にアトラシアン社に4億2500万ドルで買収されている。本書で示された採用観・開発文化論はその後のFog Creek/Stack Overflowの企業文化にも反映されている。フレデリック・ブルックスの『人月の神話』やトム・デマルコ、ティモシー・リスターの『ピープルウエア』と並んでエンジニアリングマネジメント層の定番の読み物として挙げられることが多いが、体系立った方法論書ではなく個々のエッセイの集合であるという性格上、特定の技法を深く学ぶための書というよりは、開発現場の実務感覚を養うための読み物として位置づけられている。