プログラマの思索

見積りや生産性を突き詰めていくと、どうしてもアジャイル開発に向いている契約は何か、という話になる。
ラフなメモ書き。

【元ネタ】
InfoQ: VelocityによってAgileは死んでしまうのか？

Martin Fowler's Bliki in Japanese - 生産性は計測不能

【1】WF型開発では、見積りのタイミングは2回ある。
1回目はシステム提案、2回目は外部設計終了時点。

システム提案時は、不確実な情報の中で大まかな概算見積を行い、外部設計終了まで委任契約で作業し、内部設計や開発以降は請負契約にするのが普通だろう。
何故なら、システム提案時の見積りはあまりにも不確定であり、SIにとっても顧客にとっても合意しづらいから。
だから、外部設計終了時点で、開発対象のスコープが確定後に再見積を実施して、開発の金額を確定して、請負契約にする。

委任契約は成果物責任がないので、外部設計終了時点まではシステム営業に近い。
作業にかかった工数だけ顧客からお金をもらう。
とはいえ、顧客も無駄にお金を払いたくないから、元請けのSIで優秀なSEが少人数で設計して、あまり時間をかけずに要件を固めるのが普通だろう。
そして、要件が確定後に請負契約に切り替えて、SIへ成果物責任を課して、システムを製造してもらう流れになる。

請負契約ゆえに支払い金額の上限があるから、仕様変更が積み重なって当初の要件スコープよりも増加すればコストが増えて赤字なってしまう。
だから、再見積もりの数字はとても重要であり、ベースラインとして保持し、その後の仕様変更で再見積もりするたびにベースラインを変更管理していくことになる。

【2】アジャイル開発でも見積もりは当然行う。
アジャイル開発で再見積りのタイミングは、ストーリーの相対規模に変化があるとチームが判断した時だ。
「アジャイルな見積りと計画づくり」では再見積もりのタイミングについて説明がある。

例えば、あるイテレーションで開発中に、グラフ化の処理実装が実はとても難しく、当初の見積の2倍以上かかると分かったとする。
つまり、該当ストーリーの規模が実は大きかったと判明した時、ストーリーポイントを変更する。

但し再見積りの注意点は幾つかある。
一つは、全てのストーリーの規模(ストーリーポイント)と整合性を取ること。
ストーリーポイントは相対規模の見積りなので、一つのストーリーポイントを変更すれば、他のストーリーの規模見積りにも影響がある。
例えば、3ポイントを6ポイントに変えたストーリーがあったら、他の3ポイントのストーリーは変更したストーリーと同様に2倍すべきなのか、それとも別の値にすべきか判断する必要がある。
そうしなければ、相対規模の見積りというストーリーポイントの見積りに一貫性が無くなってしまい、Velocityの計算が狂ってしまう。

もう一つは、部分完了したストーリーの扱い。
基本は、All or Nothing。
つまり、完了したらVelocityに含めるし、未完了ならば0ポイントと見なしてVelocityに含めない。
何故ならアジャイル開発における完了条件とは、顧客へ動くシステムを納品すること。
だから、仕掛り中の機能は顧客から見ればコンパイルエラーのソースと同じく、まともに動かないから価値がない。
この意味では、アジャイル開発の完了条件はWF型開発のそれよりも厳しい。

但し、イテレーション終了時点で部分完了したストーリーポイントをVelocityに含めたい場合もある。
部分完了したストーリーポイントは現在のVelocityに加算されず、次のVelocityに反映される可能性が大きい。
つまり、現在のVelocityは予想よりも少し下がり、次のVelocityは予想よりも少し高くなるだろう。
すると、Velocityがあくまでも開発の平均速度であり、特定のイテレーションのVelocityに特別な意味がないことを分かっているチームならば、特に問題はないだろう。

だが、部分完了したストーリーを次のイテレーションで継続開発しない場合、現在のVelocityに入れたくなる。
この時、部分完了したストーリーを完了部分と未着手の部分で分割する方法を「アジャイルな見積りと計画づくり」では勧めている。
つまり、分割したストーリーのうち、部分完了したストーリーポイントを現在のVelocityへ反映し、未着手のストーリーは次回以降に回す。
分割対象のストーリーは再見積もりを実施するので、前回のストーリーポイントよりも値が上回っても構わないと「アジャイルな見積りと計画づくり」と説明している。

但し、注意点は、未完了のストーリーポイントをVelocityに含めないようにするのが大前提。
更に、部分的にストーリーポイントを加算してもVelocityに大きなブレが発生しないように、ストーリーを細かい粒度で見積もりしておくのが大事。
そうすれば、Velocityの値に一喜一憂することも無い。

「アジャイルな見積りと計画づくり」を今頃になって何度も読み直して、とても奥が深いと改めて感じている。
WF型開発でプロジェクトマネジメントの経験がある人でも、「アジャイルな見積りと計画づくり」はお薦めだと思う。

【3】InfoQ: VelocityによってAgileは死んでしまうのか？の記事では、Velocityを開発チームの生産性と拡大解釈した場合の短所を説明している。
この議論の結論は、Martin Fowler's Bliki in Japanese - 生産性は計測不能で既に書かれている。

僕の理解では、Velocityとは特定のチームが特定の期間で開発した時の生産性に過ぎない。
つまり、時間と場所がかなり限られた場合でしか、Velocityの数値は意味をなさない。
他チームの開発や将来のシステム開発にVelocityを適用しても、あまり有意義な結果は得られないだろう。

でも、Velocityという値を他チームにも流用したくなるのは人間の性なのだろう。
そのアンチパターン「メトリクスの罠」については下記で書いた。

メトリクスの威力: プログラマの思索

チケット駆動開発のアンチパターンpart2: プログラマの思索

この考え方は、哲学における認識論や真理の考え方と同じだと思う。
哲学者が考えぬいた真理も、所詮は特定の時代で特定の場所でしか有効でない。

ずる賢い人ならば、その概念を自分にとって都合の良い状況へ当てはめて、歪曲させるだろう。
生産性の概念は諸刃の剣だと思う。

【4】再見積もりにも関わるソフトウェア開発の契約については、色々議論がある。
現状のソフトウェア開発の契約は委任契約か請負契約しかなく、アジャイル開発に向いた契約スタイルではない。
顧客に価値があるシステムを早く定期的に納品することを信条とするアジャイル開発では、成果物責任が発生しない委任契約は無意味だし、スコープを調整できない請負契約は要件やリスクの変化を制御しにくい。

PMBOKの調達管理でも、何種類もの契約スタイルがあり、発注者と受注者のどちらが有利なのか、という観点で整理されて説明されている。

とはいえ、IPAの委員会で平鍋さんがアジャイル開発に向いた契約スタイルについて、議論するだけでなく、提案している内容はとても価値があると思う。

アジャイル開発の契約スタイルに関するIPAの報告書: プログラマの思索

・非ウォーターフォール型開発WG活動報告書（概要資料） (PDF形式)[858KB]

・非ウォーターフォール型開発WG活動報告書 (PDF形式)[5.05MB]

個人的な考えとしては、日本の製造業を真似た契約スタイルは、WF型開発と多重下請構造にとてもマッチしているのだろうが、欧米だけでなく日本でも最先端を走るソフトウェア企業がアジャイル開発へ舵を切っている現在、時代に合わなくなっているのだろうと思う。