開発現場の掟

山本大さん@クロノスが書かれた「開発現場の掟」を買った。（「開発現場の掟」出版！！ - レベルエンター山本大のブログ）

最後の１ヶ月は波乱万丈ありまして、
ラスト３週間で９０ページの原稿を追加しなくてはならないという怒涛の要請がありました。
ちなみに、それまで１年半かけて書き終えた原稿を編集してみると
１１０ページ分にしかならなかったのです。
そこを３週間で９０ページ追加。
３０代に必要な「なんとかやり遂げる能力」 - レベルエンター山本大のブログ

という山本さんのブログのエントリを読んでいたので、「3週間で90ページ追加した本って内容は大丈夫かなあ？」って疑ってた。土曜日にふらっと本屋に入った時に「あ、山本さんの本だ」と思ってパラパラっと見て、即買うことに。今日、電車で読んでたら、思わず「うんうん」ってうなずきながら読んでしまった。教科書的な本じゃなくて「現場で培われた生の知恵」がぎっしり詰まっている。

P. 10

法則1 人間は情報でなく物語を理解するようにできている

って書かれてるけど、この本がわかりやすくて共感できるのは鉄則と一緒に物語が書かれているからだと思う。

自分もなんとなく鉄則というかパターンみたいなものがあるけど、整理されて明文化したものを読むとなんか頭の中がガリガリとデフラグされるような感じがした。

この本に書かれている「テストケースファースト」なんかは自分も以前からやってるけど、すごく効果がある。テストケースって「具体的な仕様」であり、「具体的で詳細化されたゴール」なのでこれを先に作って頭に入った状態でプログラムを作ると自然にバグが減る。
以前にテストケースファーストでちょっとした20、30本のプログラムを作った時に、後輩とペアプログラミングしたんだけど、テストしてもしてもバグが出なくて結局1つもバグが出てこなくて後輩がびっくりしてたことがあった。あれは自分でも驚いた。自分の場合、ちょっと書いて動かしてみながらコーディングする（ひがやすおさんはこれをステップバイステッププログラミングと呼ばれていた）ので、コーディングが終了した時点で実際にはほとんどテストが終わっているような感じだった。かといって、コーディングに普段より時間がかかったわけでもない。テストケースを先に書いて頭に入っているので、なんか「テスト脳」になっていて、コーディングの時にバグが出そうなところは思いついて先につぶしてしまっている感じだった。
その後、上京して金融系の大規模プロジェクトでリーダーやったときに「テストケースファースト」を提案した時は却下されちゃったけど。

設計書よりもユーザーマニュアルを書こう！ - レベルエンター山本大のブログもすごく共感したけど、共通しているのは、「ゴールから逆算」していることではないかと思う。
システムは人間が使うものなので、まず人とのインターフェース、次に他のシステムとのインターフェース、サブシステム間のインタフェース、とゴールからの逆算発想で進めると、最短ルートを通ることができると思う。

プロジェクトによって状況が違うので、一概にどのやり方がいいというのはないから、ゴールに最短ルートで到達するために最適なやり方を選択すれば良いと思う。現実では、ゴールを見極めてないのに、ルールだけはしっかり守って進めているという本末転倒な状況をよく目にする。「赤信号だと車が来ていなくても横断歩道を渡らない。青信号なら車が来ているのに渡って事故になる。」という感じ。

う〜ん、このエントリは書いてるうちに脇道にそれて、当初のゴールと全然違うところに到達してしまったw

この本を「テストケースファースト」的に読むなら、最後に書かれている