付録ジョ工ルテスト これが意味するのは、残存バグがたくさんある 場合には、スケジュールは当てにならないというこ とだ。しかし既知のバグがすべて修正されていて、 残っているのは新たに書く部分だけという場合に は、スケジュールははるかに正確なものとなる。 もう 1 つバグ数を 0 に保つことの良いところを挙 げると、競合に素早く対応できるということがあ る。プログラマたちはこれを、製品をいつでもリ リースできる状態に保つことだと考えている。そ うすれば競合が何か魅力的な新機能を追加して自 分たちの顧客を奪いつつあるという時に、たまり にたまったバグの修正で足止めされることなく、 ただその機能だけ追加して即座にリリースするこ それがスケジュールの話につながってくる。そ がある ? 6. アップデートされているスケジュール とができる。 に向かって怒鳴る。 そりや出来上がったときさ ! 」とビジネスの連中 のを嫌がるものだ。彼らは「いつ出来るかって、 る。プログラマというのはスケジュールを立てる る時期を知ることが重要になる理由はたくさんあ るなら、ビジネスの連中がプログラムの出来上が のプログラムがビジネスにとって重要なものであ 159

1 60 ソフトウェア開発者採用カイド あいにくとそう言って済ますわけにはいかない のだ。デモに、展示会に、広告その他、ソフトウ ェアのリリースに先立ってビジネス側でしなけれ ばならない計画上の決断がたくさんある。そして それができるためには、スケジュールを立てて、 アップデートし続ける以外にないのだ。 スケジュールを持っことのもうひとつ重要な点 は、それがどの機能を作るか決めるよう強いると いうことだ。それによりつまらない機能をしのび こませて機能過多 ( 別名 : スコープクリープ ) に陥 る代わりに、重要度の低い機能を選んでカットす ることになる。 入仕様書はある ? 仕様書を書くのはデンタルフロスみたいなもの だ。みんな良いことだとは思っているが、誰もや ろうとしない。 これがなぜなのかはっきりとはしないが、たぶ ん多くのプログラマがドキュメントを書くのが嫌 いなのが原因じゃないかと思う。結果として、プ ログラマばかりのチームが問題に取り組む場合、 彼らはドキュメントではなくコードで解を表現し たがる。最初に仕様書を書いたりしないで、コー ディングに飛びつくのだ。 設計の時点で問題が見つかった場合、文章を数

1 5 6 ソフトウェア開発者採用ガイド 5- 新しいコードを書く前にバグを直して Windows 版 Microsoft Word の最初のバーション は「デスマーチ」プロジェクトだったと考えられ ている。それは延々と時間がかかった。スケジュ ールは変更され続けた。開発チーム全員がばかげ ているくらい長時間働き、プロジェクトは何度も 何度も遅延し、ストレスは尋常でなかった。何年 も遅れてついにソフトウェアが出荷されたとき、 Microsoft はチーム全員をカンクンへと休暇に送り 出し、それから腰を据えて真剣に自己分析を行っ 0 彼らにわかったのはこういうことだ。プロジェ クトマネージャたちは「スケジュール」を守るこ とにあまりにこだわり、しかもバグ修正フェーズ が公式のスケジュールには載っていなかったた め、プログラマたちは駆け足でコーディングし、 極めてますいコードを書いた。バグ数を低く抑え ようとする試みは何もなされなかった。むしろま ったく逆だった。テキスト行の高さを計算するコ ードを書かなければならないプログラマが、単に 「 return12; 」と書いておいて、その関数の値がい つも正しいとは限らないというバグレポートが来 るのをただ待っていたという話さえあった。スケ ジュールはバグへと変わるのを待っている機能の チェックリストでしかなかった。事後分析でこれ

訳者序文 れた良書に、ジョハンナ・ロスマンの『ザ・ベス ト有能な人材をいかに確保するか』 ( 翔泳社、 2005 年 ) がある。興味のある方はこちらもご覧いただけ ればと思う。 翻訳にあたっては多くの人に助けていただいた。 本書の刊行に先立って来日して素晴らしいデモを 見せてくれたジョ工ル、いつもお世話になってい て今回も無理なスケジュールの中レビューしてく れた角征典さん、荻野淳也さん、渡部亮太さん、 arton さん、直さなきやと思っていたところがいつ の間にか直っている小人の靴屋さんのような編集 者の野口理香さんに感謝したい。 青木靖 XIII

索引 ■す 『数学入門』 ( アルフレッド・ホワイトヘッド著、 1911 年 ) から .. 1 57 ~ 1 59 .055 ~ 057 .. 1 59 ~ 160 1 / 6 の引用 . スケジュール、アップデートされていることの重要性 ストッセル、ジョン著 "How to Fire an lncompetent . 1 06 . 1 29 Teacher ■せ 政治、機能不全な . ゼロ欠陥法 . 冫小、尻状 ソース管理 . .065 , 068 ~ 069 , 075 測定と評価がチームのモチベーションに与える悪影響 .. 1 22 ~ 1 2 5 ソフトウェア会社、 Fog Creek Software の創業 . ソフトウェア会社運営のバイブル .. ソフトウェア開発者 面白いプロジェクトの重要性 . 社会生活 . ソフトウェア開発者つ開発者を参照 『第 1 感「最初の 2 秒」の「なんとなく」が正しい』 ( マ丿レコム・グラッドウェル著 ) . ダンツィーク、ジョージ・ B のインタビュー 002 042 . 082 . 023 .. 051 ~ 057 .. 057 ~ 058

1 48 ソフトウェア開発者採用ガイド ているプレットは、それにより 6.0 にもっと機能を 付け加えられると考えるかもしれない。情報を共 有することの要点は、状況が変わった場合でもプ レットが Fog Creek にとって正しいことができる ようにするということだ。リリースが 4 月より何日 前になるかに応じて金を払うと提示することでプ レットを動かそうとしたなら、彼のインセンティ プは既存のバグだらけの開発ビルドを今晩リリー スする、ということになるだろう。指揮統制を使い、 言ったとおりのスケジュールでバグなしのコード を出荷しろと命じたなら、彼はやってのけるかも しれないが、仕事が嫌になって辞めてしまうだろ マネージャの数だけマネジメントのスタイルが 存在する。私は主要な 3 つのスタイルを示した。簡 単で機能不全なスタイルを 2 っと、難しいが機能的 なスタイルを 1 つだ。しかし本当のことを言えば、 多くの開発現場では、どちらかというと場当たり 的な、日により人により変わる「何でもあり」の 方法でマネジメントされている。

付録ジョ工ルテスト 行編集するだけで容易に修正できる。しかしひと たびコードが書かれたなら、問題を修正するコス トは、心理的にも ( 自分で書いたコードは捨てたが らないものだ ) 時間的にも劇的に高くなる。そして 実際に問題を修正することに対する抵抗が生じる ことになる。仕様書から作られていないソフトウ ェアというのは、設計はますくスケジュールは制 御不能という結果に陥りがちだ。これは Netscape で起きた問題のように思える。最初の 4 つのバージ ョンがあまりにひどい状態になったため、マネジ メントは愚かにもコードを捨てて初めからやり直 すという決断をした。そして彼らは同じ間違いを M 。 zi Ⅱ a で再び繰り返して制御不能な怪物を作りだ し、アルフア版に至るまでに何年もかかった。 プログラマをライティングの集中コースに送り 込んで文章嫌いを直すことでこの問題は解消でき るというのが私の持論だ。別な解決策として、優 秀なプログラムマネージャを雇って仕様書を書か せるという手もある。どちらの場合でも、「仕様書 なしにはコードを書かない」というシンプルなル ールを徹底する必要がある。 161

1 50 ソフトウェア開発者採用ガイド 12. ユーザビリティテストはしてる ? 11. 採用面接のときにコードを書かせてる ? 10. テスタはいる ? 9. 手に入る最高のツールを使ってる ? 8. プログラマは静かな環境で作業してる ? 7. 仕様書はある ? 6. アップデートされているスケジュールがある ? 5. 新しいコードを書く前にバグを直してる ? 4. バグデータベースはある ? 3. ディリービルドしてる ? 2. ワンステップでビルドできる ? 1. ソース管理してる ? ジョ工ルテスト 多くのソフトウェア開発組織は 2 ポイントとか 3 抱えていることになる。本当のところを言うと、 きるけど、 10 ポイント以下だったら深刻な問題を 12 ポイントなら完璧で、 11 ポイントなら許容で 全かどうかのチェックには使えないってことだ。 の欠点は、原子力発電所向けのソフトウェアが安 つき 1 ポイントをチームに与える。ジョ工ルテスト 数だとかを求める必要はない。そして 1 個の yes に たりのステップ数だとか変曲点あたりの平均不良 に yes / no で答えていくのが簡単なことだ。 1 日あ ジョ工ルテストの良いところはそれぞれの質問

096 ソフトウェア開発者採用ガイド しばしば博士号を持っていて大企業で働いている が、まったく実用的でない彼らの言うことなんか 誰も聞いてはいない。彼らはスケジュールどおり に出荷することよりも、何かアカデミックなこと についてあれこれと考える。そういう種類の人は 概念的に大きく隔たったものの間にある理論的な 類似性を指摘したりするのを好むことで識別でき る。たとえば、彼らは「スプレッドシートという のは、実際のところ、プログラミング言語の特殊 なケースにすぎない」みたいなことを言い、そ うして一週間ほど休みを取って、プログラミング ロ語としてのスプレッドシートの理論計算言語面 的属性についての見事でスリリングな論文を書く のだ。頭は良いが役には立たない。そういう人を 見分けることのできるもうひとつの場合は、彼ら があなたのオフィスにコーヒーマグ片手に現れ、 Java のイントロスペクションと COM タイプライプ ラリの相対的優位性についての長い議論を、べー タ版をリリースしようとしているその日にやろう とするようなときだ。 頭は悪いが物事を成し遂げる人というのは、考 えもなしにバカなことをやり、誰か他の人がその 後始末をする羽目になる。彼らは貢献できないば かりか、優れた人々の時間さえ奪ってしまうの で、会社にとってはお荷物になる。彼らは製品の コアのアルゴリズムを前の晩に読んだばかりのビ ジターパターンを使ってリファクタリングしよう

ⅱ 4 ソフトウェア開発者採用ガイド ないのだが、頭の良い候補者はあきらめすに、も っともらしい数字を推定しようと嬉々として取り 組む。ちょっと考えてみましよう。シアトルの人 ロは・・・・・ 100 万人くらいでしたつけ ? ピアノを持 っているのは 1 % くらいかな ? ピアノを調律する のは年に 2 回くらいでしようか ? 1 台調律するの にかかるのは 35 分とか ? もちろん全部間違ってい る。しかし少なくとも彼らは問題に挑戦している。 こんな質問をしている理由は、それで候補者と話 ができるからだ。「 OK 、 35 分としておこう。でもピ アノの間の移動時間はどう ? 」 「いい指摘ですね。ピアノ調律師があらかじめう まく予約を取っておけるなら、移動時間が最少に なるようにスケジュールを調整するでしよう。 520 号線を日に三度も行ったり来たりするよりは、月 曜にレドモンドのピアノを全部やってしまおうと するでしよう」 良い封筒裏の問題は、候補者と話ができるよう にしてくれ、彼らが頭が良いかについて考えをま とめる助けになる。悪い "Aha ! " 海賊問題の場 合は、通常候補者がしばらくの間ただこちらを見 つめていて、それから降参と言って終わりになる。 面接の終わりに、その人が頭が良く物事を成し 遂げる人だと納得させてくれ、 4 人か 5 人の他の面 接者も同じ意見なら、その人を雇ってもたぶんま ずいことにはならないだろう。しかしもし何であ れ疑念があるなら、誰かもっと良い人が現れるの