工数見積もりで陥りやすい罠

「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。
理解できたことをメモ。
間違っていたら後で直す。
※追記：一部修正した。
※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。

【元ネタ】
Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。

アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索

ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索

チームは加速するのか～Velocityの使い方 #agilesamurai: プログラマの思索

ソフトウェア開発の工数見積もりが混乱しやすい理由: プログラマの思索

以下、工数見積もりで陥りやすい罠を3つあげる。

【1】顧客へ提示した工数(規模)と開発チームの実績工数(コスト)は等価でない

RedmineやTracチケットには予定工数と実績工数を入力する欄がある。
実績工数は、チケットを完了させるまでにかかった時間ないし日数を書く。つまり、コスト(AC)に相当する。

予定工数は、チケットを完了させるまでにかかる最短の時間ないし日数を書く。つまり、Scrumなら理想時間・理想日に相当する。
予定工数はシステム規模を開発完了させる工数(PV)に相当するから、システム規模と見なしていい。

そして、予定工数は「ソフトウェア見積り」で言えば楽観的な見積りに相当する。
楽観的な見積りの意味は、前回の失敗の教訓を生かして今回のプロジェクトの方が生産性が高いだろう、とか、学習曲線を期待して前回のタスクの経験が今回のタスクの経験に生きるだろう、などのように、見積り時点では予測できないリスクや課題を排除して、最短で完成できる見積りをしてしまうこと。

実際、見積り時点では、開発者は管理者や顧客へ説明できない工数バッファを積むと、詳細まで突っ込まれたら説明責任を果たせないので、予測できないリスクやトラブルに対する予備工数(コンティジェンシー予備)は積まない。
マネジメント予備工数は、管理者がタスク全部の工数見積もり後、一括して積むのが普通だから。

すると、予定工数は最短で完成できる工数ゆえに、普通はコストオーバーになる。
「ソフトウェア見積り」に書かれている即興の見積りで予定工数を見積もれば、見積りの誤差が大きくなるから、プロジェクト全体の実績工数は予定工数よりも大幅に超過する場合が多くなるだろう。

予定工数の1.0MDと実績工数の1.0MDは、単位は同じでも、システム規模とコストでは意味合いは全く異なる。

【2】私の見積り工数とあなたの見積り工数は等価でない

まず、理想日とは実際の工数のうち、打合せやメール問合せ、社内の雑務などを除いた純粋にタスクに専念できる時間を表す。
「アジャイルな見積りと計画づくり」では、アメフトを例に持ち出し、理想時間は60分だが現実時間は2～3時間になると分かりやすく説明している。
ソフトウェア開発における理想日・理想時間は、次の三つが前提条件としてある。

・ストーリーに必要な作業だけに専念できる
・割込みタスクがない
・作業開始前に、作業に必要な情報や環境などは全て用意されている

理想日はまさに、タスクだけに集中できる時間を指すわけだ。

そして「アジャイルな見積りと計画づくり」では「僕の理想日と君の理想日は違う」という節で説明されている。
実際、経験者の工数1.0MDで出来上がるシステム規模と、新人プログラマの工数1.0MDで出来上がるシステム規模はかなり違う。
プログラマの生産性の比較は10倍以上にも達するから、見積った予定工数1.0MDはそもそも等価ではないのだ。

だから、理想日でシステム規模を工数見積もりする場合、各開発者の生産性が無視されがちなため、予定工数の純度は低い可能性がある。
特に昨今の受託開発は、3～6ヶ月間という短期間に新規の開発者をかき集めて開発チームを形成するから、実際のプロジェクトでは、開発者の過去の生産性があまり当てにならない。だから、見積りの誤差のリスクも大きい。

理想日が問題にならないようにするには例えば、常にペアプログラミングしていてチームメンバーのスキルが平均化されている状況があるだろう。

理想日による見積りは開発者同士の生産性を無視している。

【3】生産性が増えているのにVelocityが変わらない

「アジャイルな見積りと計画づくり」では「ストーリーポイントによる見積りは長持ちする」という節で説明している。

例えば、プロジェクト初期の頃は、1.0MDという工数で開発できるシステム規模はかなり小さいだろうが、プロジェクト後半では、同じ1.0MDで以前よりもかなりのシステム規模を作れるだろう。
あるいは、CobolとRubyなどの開発言語の違い、業務システムやSNSなどのシステムの種類、新規開発と運用保守では、見積り工数1.0MDの中身は大きく異なるだろう。

また、Velocityを計測しても生産性の問題は解決しないと「アジャイルな見積りと計画づくり」では「ストーリーポイントによる見積りは長持ちする」という節で指摘している。
例えば、プロジェクト初期では、予定工数5.0MDで一つの機能を作れるとする。すると、1週間5日間のスプリント1のVelocityは1機能×5理想日＝5.0MDになる。
次に、プロジェクト中盤では、一つの機能を予定工数1.0MDで作れるように生産性が上がったとしよう。すると、1週間5日間のスプリントでは、5.0MDかけて5つの機能を作ったにも関わらず、Velocityは5機能×1理想日＝5.0MDになる。

このトリックは、開発者がアウトプットして作り出す出来高とコストの単位を混同していることから発生する。

生産性が上がってもVelocityが変化しないという指摘は、チームが新しい技術や未経験の業務分野に挑戦するプロジェクトでは、この問題が深刻な影響を与えることになる。
つまり、チームが経験を積んでも学習曲線の期待による生産性がVelocityに反映されないために、見積もり工数が狂ってしまうのだ。

開発の生産性に関する問題は、結局、開発者が作った出来高と実際のコストを混同しているために発生するのだ。

【4】上記の3つの問題の根本原因は、PMBOKのEVMで現れるPV(システム規模)・AC(実績工数)・EV(出来高)を混同していることから発生すると思う。
1.0MDという同じ単位で、システム規模・実績コスト・開発者が作る出来高を測定しているのだから、混乱しやすいのだ。

Scrumで、理想日よりもストーリーポイントによる見積りの優位性を強調しているのは、工数という単位が混同しやすいために、規模見積りと工数見積りを区別できるからだ。
つまり、システム規模や開発者が作る出来高はストーリーポイント、実際のコストは工数で使い分けることによって、どれだけの開発規模をつくっているのかを明確にしてくれる。

実際のストーリーポイント見積りは概算見積りゆえに、タスクカードによる詳細見積りではもっと工数が増えるリスクもあるが、初期の段階で開発規模をメンバー全員で共有できる利点は大きい。
そして、まず1スプリントをすぐに実施すれば、規模見積りを工数見積りへ変換できる利点がある。
WF型開発なら、1年後の本番リリースまで実際に納品出来るシステムを作れないから、規模見積りをいくら頑張っても、肝心の工数や期間がどれくらいかかるのか、1年後にならないと分からない。

初期のスプリントを実施した後、次のスプリントでVelocityを計算する方法は下記になる。

【追記】Velocityの計算方法は「塹壕よりScrumとXP」を参照して下さい。

まず、初期のスプリントを実施した場合、実績のVelocityは実際に納品できたストーリーポイントの合計値ゆえにすぐに計算できる。
初期スプリントの稼働人日を計算して、Focus Factorという係数を求めて、人日当たりのストーリーポイントを求める。

Focus Factor = 直近スプリントの実績Velocity/直近スプリントの実績の稼働人日

すると、次のスプリントで予測されるVelocityは下記で計算できる。

予測Velocity(次回) = 実施スプリントの稼働人日 * Focus Factor

Focus Factorをわざわざ乗算するのは、前回スプリントの見積もり工数と実績工数の差異を反映することによって、チームの直近の生産性を加味するからだ。
@daipresentsさんが説明してくれているFocus Factorは、本来はこういう意味があったのだろうとようやく理解できた。

計画プロセスそのものもAgile化することによって、計画の精度を上げていくことが可能になる。
つまり、Agileな計画プロセスとは、作った計画をすぐに直近のスプリントで実施して検証し、その結果を反映することで計画をどんどんブラッシュアップしていくプロセスなのだ。

上記のことを考えると、見積もりは計画作りでとても重要な要素であることが分かるし、見積もりの本質に迫っているScrumは非常によく考えられていると思う。

チケット駆動開発でVelocityや工数見積もりに関する考察ができるのも、RedmineやTracに元ネタとなるチケットの予定・実績工数があるから。
チケット駆動開発はもっと色んな可能性を秘めていると思う。

【追記1】@wkoichiさんの指摘を受けて【2】を修正した。
@wkoichiさん、ありがとうございます。

Twitter / @wkoichi: 理想日による見積もりだと生産性が上がった場合に、1理想日×5機能になるので、Velocityが相変わらず5になるということであって、Velocityの計算を25/5としているのは誤りではないかな？ / “工数見積もりで陥りやすい罠: …” .

「アジャイルな見積りと計画づくり」の「ストーリーポイントによる見積りは長持ちする」という節を読み直すと、下記のような意味で解釈できる。
最初は、1機能を5日かけて開発した場合、Velocityは1機能×5理想日＝5MD。
生産性が上がって、1機能を1日で開発できるようになった場合、Velocityは5機能×1理想日＝5MD。

【追記2】
規模・コスト・出来高の単位が一緒であることから発生する混乱の症状をまとめると下記になると思う。

【1】顧客へ提示した工数(規模)と開発チームの実績工数(コスト)は等価でない
→規模(顧客へ提示した予定工数)とコスト(開発チームの実績工数)を混同している。

【2】私の見積り工数とあなたの見積り工数は等価でない
→出来高(開発者が作ったアウトプットの規模)とコスト(開発者の実績工数)を混同している。

【3】生産性が増えているのにVelocityが変わらない
→出来高(開発チームが作ったアウトプットの規模)とコスト(開発チームの実績工数)を混同している。

【追記3】
@daipresentsさんから、「塹壕よりScrumとXP」にFocus Factorの定義があることを教えて頂きました。ありがとうございます。