プログラマの思索

プロジェクトの失敗とは見積もりが失敗しているのだ、という下記Blogを読んで考えたことをメモ。
＃以下はラフなメモ書き。

【元ネタ】
Agileが根付かないもう一つの理由 - masayangの日記（ピスト通勤他

【1】SW開発のプロジェクトは規模が大きくなるほど、失敗する確率も高くなる。

SIerならば、成功の基準は、黒字だ。
そして、IT業界にいる人なら誰でも、「黒字＝納期に間に合う＝品質が良い」という等価な式が成り立つことを経験的に知っている。
失敗に至るプロジェクトのパターンはいつもワンパターン。

要件定義、設計と進みながらも、システムのスコープや細部を詰め切れず、裏ではRailsやSeasarなどの新技術を取り入れて実装を並行開発する。
そして、殆どの画面を作った後も仕様変更が五月雨式に落ちてきては手直しし、結合テストやシステムテストで初めて稼動させた時に、大きな穴に気付く。
いくらテストしてもバグが落ち着く傾向も無く、延々と残業と休日出勤が続く。
品質が安定しない状態のまま、最後は納期も遅れてしまい、投入した人員では足りず、火消しやヘルプの人員をどんどん投入して、何とか鎮火させる。

WF型開発による失敗はいつもパターンが決まっている。

【2】上記の記事では、見積もりが失敗しているのだ、と指摘する。
つまり、上記のような失敗パターンに陥るなら、成功する確率の高い見積もりを提示すればよいだけだ、と。

しかし、見積もり工数を120％とか150％の水増しで顧客へ出したとしても、いつも遅れてしまう。
その理由は、TOCを由来とするクリティカルチェーンの話にある、学生症候群や遅延の伝播が優先されるなどがあるだろう。
いつも、バッファをすぐに使い切ってしまう。
また、技術上の難点を正確に見積もることは正直難しい。特にリファクタリングの作業も必要になるような技術的負債がある場合は尚更だ。

【3】僕はまだTOCの理屈が何となく分かる気はするけど、体ではまだ分からない。
でも、チケット駆動開発でアジャイル開発を実践してみて、見積とはそもそも何なのか、という疑問を感じるようになった。

XPを代表とするアジャイル開発は、２～４週間のイテレーションで小刻みにリリースしていく。
そのイテレーションで何を開発して、どんな機能を顧客へリリースするのか、イテレーション計画をまず立てる。
その時に、見積もりをする。

アジャイル開発の最大の利点は、早期のリリースで重大な問題に気付くことだ。
つまり、早く失敗することで、リスクを早く検知し、早期に是正対策を取ることができる。

最初の数回のイテレーションがどれもリリースに失敗したならば、そのプロジェクトは大きな赤字になるまでに却下されるだろう。
WF型開発のように最後の1回のリリースまでに、メンバー全員が疲弊しきってしまうこともなくなる。

【4】アジャイル開発の見積では、工数による見積よりも、機能の大きさや機能の難しさなどをまず考える。
特によく考えることは、1プロジェクトを数回のイテレーションで分割リリースするならば、どの順番に機能を作ったらよいのか、という機能の優先順位付けとその関係図(概念モデル)だ。
例えば、Amazonのような小売系Webシステムを請け負ったならば、下記のような順番で実装するようにイテレーションに分割していくだろう。

１・会員登録、商品検索などのユーザ向けの基本機能
２・会員保守、商品保守などの管理者向けの基本機能
３・注文フローを保守する管理者向けの重要な機能
４・カート画面、注文画面などのユーザ向けの重要な機能
５・帳票出力や会計システムと連動する機能

上記は、データのCRUDの観点から、システムをいくつかのサブシステムへ分割し、そのサブシステムを少しずつ開発していく考えだ。
つまり、アジャイルに開発するには、高度な設計技法、モデリング技術を必要とする。

システムをサブシステムへ分割し、更に機能分割していくと、精度の高い見積を行うことができる。
この時に、ファンクションポイントやユースケースポイントなど昔から知られている技法を使えば、より精度の高い見積もりができるだろう。

【5】１イテレーションには、設計、開発、単体テストだけでなく、結合テスト、受入テストもある。
アジャイル開発といえども、受入テストは当然あるし、その工程が最も大変であることは変わりない。
設計書をいくら書いたとしても、単体テスト済みのプログラムであっても、結合テストで初めて判明するバグはたくさんある。
ユーザに使ってもらって、初めて理解できる要件や仕様もある。
だから、そういうリスクを早めに出しておけば、残りのバッファで対処することもできる。

数回のイテレーションを実施してみて気付いたことがある。
それは、プロジェクト特有、あるいは開発チーム特有の開発速度(ベロシティ)がある。
１イテレーションで実装できる機能の数、あるいは機能規模は、ある程度平均している。

開発速度と言う場合、それは工数ではないと思う。
開発速度は、生産性そのものだと直感している。

工数は、同じ機能の実装であっても、開発者ごとに大きく違う。
でも、チーム全体で開発できるサイズは上限があり、ある一定の幅の中に納まる。

実際は、チームでもメンバーの入れ替えは時々あり、入れ替えた直後は開発速度は落ちる。
とはいえ、チームのルールや技術に慣れれば、チーム全体の開発速度は平均の前後で落ち着く。

「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」では、ベロシティによる見積もりとコミットメントによる見積もりの2種類のうち、後者を推奨している。

前者は、平均の開発速度(ベロシティ)から、そのイテレーションに入れられるサイズを決めて、そのサイズに入るようにストーリーを取捨選択する方法。
後者は、イテレーションに入れるストーリーをチームメンバー全員に「コミット(契約・約束)できるか？」と尋ねて、ストーリーを優先順位付けして取捨選択する方法。

後者を推奨する理由は、開発速度という概念を見積もりに使うにはあまりにも曖昧だからだ。
確かに、開発速度に当てはまるようにストーリーの数を制御しても、開発速度はそもそも最小値と最大値の範囲内にある平均だから、多少の誤差が発生する。
ソフトウェア開発がビジネスである以上、多少の誤差も命取りになりうる可能性はあるから。

でも、開発速度という概念は僕は上手に言えないけれど重要だと考える。
見積もりは多分、開発速度の概念と密接に絡んでいるから。
つまり、見積もりは絶対的な数値ではなく、ある一定の範囲内の平均の数値。
だから、実際にやってみないとどれだけ工数がかかるか分からない。

もう少しまとめてみる。