Ship It!

Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック

Jared Richardson, William Gwaltney Jr. 著
でびあんぐる 訳

オーム社

ソフトウェア開発に起こる問題を解決し、スケジュール通りに出荷(Ship It)するための様々な方法について書かれている。開発メンバ、技術主任(開発リーダとかAPリーダとか呼ばれている人)、マネージャの観点から書かれている。

内容は、大きく分けると、ツールを使って自動化(XPとかアジャイルでよく使われれている)、作業リスト(トヨタの見える化みたいなものかな)、曳光弾開発(TBD; Tracer Bullet Development)について。

ツールについては、知ってはいるし使っているものもあるけど、効能や利点、ツールの選定方法について書いてあると改めて重要だと感じた。

CIツールとは初めて聞いたけど、これは便利そうだ。あるトリガー(例えばコード管理ツールにコミットされたや一定時間経過など)でビルドや自動テストが起動して、結果に不備があるとメールやRSSフィード、さらにはLavaLampの点灯などを行ってくれる。1回使用したら、このツールなしではやっていけなくなるな。

作業リスト、コードレビュー、毎日のミーティングは、アナログだけど効果が高く、全メンバが共通意識の元に開発を進められるすばらしい方法だと思う。ある意味当たり前だけど。ここでは技術主任が重要な役割を担うと思うし、自分はこのポジションで今後活動していかなくてはならないと強く思った。

曳光弾開発も初めて聞く開発プロセスだが、早い話がメソッドや関数で各機能の中身は書かずに固定値を返すだけのものを全部作って、そこから中身を足していくやり方のようだ。
この開発方法では、最初にシステムオブジェクトを抽出して、各層(DB層とかAP層とか)ごとにメソッドや関数の枠だけ作る。層と層でデータのやり取りが発生する部分は関係者間でのミーティングでパラメータや戻り値を確定する。各メソッドや関数は、別の層のメソッドや関数を呼ぶコードを追加する。そうするとある操作を行うとすべての層を通して何らかの応答がある。中身のコーディングはほぼやっていないにも関わらず、デモらしいことができる。パラメータや戻り値を変えなければ、メソッドや関数の中身は他のコードに影響を与えないので各作業者が個別に作業できることになる点が大きな利点だ。しかも、いつでも顧客にこれを見せれば簡単なデモを行って、適切なフィードバックをもらえる。早い段階でフィードバック(変更依頼)をもらえれば、それに対応するのは楽だ(全部できあがってからの変更は無駄が多いし、スケジュールにも大きな影響がある)。この開発方法は、一種のプロトタイプ開発みたいなものだね。

ソフトウェア開発に関わる人は、どんな立場であっても一度は読んだ方が良い本だと思う。