ソフトウェア開発の工数見積もりが混乱しやすい理由

工数見積もりしていると、同じ人月で数えているのに、コストだったり、システム規模だったり、出来高だったり意味が違っているのに気付いた。
考えたことをメモ。
間違っていたら後で直す。

【1】運用保守では、顧客に毎月の実績工数を報告して保守料金をもらう。
マネージャの仕事の一つが、月次報告のための工数集計がある。
だが、この工数集計が結構面倒だ。

普通はメンバーに毎日の日報で、どのタスクにどれだけの時間をかけたのか、報告してもらう。
しかし、普通はタスクは顧客の改善要望をWBSレベルで詳細化したタスクのため、まず要望別に集計し直さないといけない。
更に、顧客からの改善要望のステータスが未着手なのか、進行中・完了なのか、逐一記録して、追跡しないといけない。
また、それら要望は、問合せ調査だったり、定常的な運用作業だったり、障害対応や改善対応などの種類に分けて、それぞれで集計し直したい。
特に、本番障害は原因報告とかかったコスト、更には抜本対策まで報告する必要がある時が多い。

メールで日報を収集して、集計作業をExcelでやっていると、管理作業だけでマネージャの作業が浪費されてしまう。

【2】マネージャは毎月集計した実績工数を元に、来月や次四半期の保守作業でどれだけの工数がかかるか見積もって、提案したい。
直近の実績は開発チームのペースを表しているから、見積もりの精度も高いと推定できる。
だが、見積もった工数を提案時にきちんと説明できなければ、顧客から保守金額の値下げ交渉をくらう。
実際は、見積もった工数の正当性を説明するのは、見積管理システムの仕様を説明するのと同じぐらいの煩雑さになるだろう。

月末に工数を締めて集計する場合、各タスクのステータスによって見積もる工数が変わってくる。
例えば、タスクがA～Cの3個あり、どのタスクの種類も改善対応とする。

タスクA：予定＝0.9MD, 実績＝0.0MD、ステータス＝未着手
タスクB：予定＝0.9MD, 実績＝1.0MD、ステータス＝担当中
タスクC：予定＝0.9MD, 実績＝1.0MD、ステータス＝完了

これらデータから、単価(MD/件)を計算して、次月の件数がどれくらいか推定して、工数を見積もりたい。
その場合、改善対応のタスクの単価はどう計算されるか？
単純に考えると、3件のタスクで2.0MDかかったので、0.67MD/件という単価のように思える。
しかし、深く考えるとこの計算方法は正当性がない。

タスクAはそもそも未着手なので、アウトプットはゼロだ。
つまり、タスクBやCとは出来高が異なるから、同じ1件として件数にカウントするのはおかしい。
同様に、タスクBは未完了だから、完了タスクCの1件に対し、0.5件ぐらいの重みを与える方が正しいように思える。

また、タスクBとCは、予定されていた工数1.8MDの成果物を作るために、2.0MDのコストをかけて作った事実だから、実績はコストだ。
本来のタスクの規模は、タスクBとCの予定工数である1.8MDであるべきだ。

更に、タスクBのアウトプットは仕掛り中であり、予定工数0.9Mで作れる成果物を1.0MDをかけても未完成だから、出来高はタスクCの半分以下のようにも思える。

このように、本来の単価を計算するには、予定工数や実績工数、ステータスをパラメータとして計算せねばならず、Excel上ではひたすらマクロを使いまくる。
Excelで頑張って作り込むほど、それは見積り管理システムを作っているに等しい。

【3】上記のタスクA～Cにおける工数の考え方では、PMBOKのEVMの概念を入れると分かりやすい。
タスクをチケット化して、RedmineやTracに放り込んでおけば、SQLを叩くだけで工数集計できるだけでなく、近い将来のコストの予測や工数見積もりも可能だ。
アイデアは下記に書いた。

RedmineプラグインRodmapsにEVMの機能を追加する: プログラマの思索

RedmineからPMBOKのEVMを計測する方法: プログラマの思索

チケット駆動開発におけるソフトウェア見積り: プログラマの思索

すなわち、予定工数はPV、実績工数はAC、出来高工数はEVに相当する。
つまり、PVは顧客へ納品する本来の成果物の規模、ACはコスト、EVは開発者がコストをかけて作った成果物の規模に相当する。
そもそもシステム規模や成果物の規模、そしてかかったコストをひとつの単位で表現してしまっているため、同じ1.0MDでも意味合いが異なってくる。
同じ人月の単位を三つの意味で表現しようとしているので、混乱するわけだ。
しかも規模と時間を混同している。

EVMを導入すれば、下記のように整理できる。

タスクA：PV＝0.9MD、AC=0.0MD、EV＝0.0MD
タスクB：PV＝0.9MD、AC=1.0MD、EV＝？
タスクC：PV＝0.9MD、AC=1.0MD、EV＝0.9MD

ここで、WF型開発とAgile開発では、EVの定義の仕方が違う。
WF型開発ならば、タスクに進捗率を記載しておき、EV＝PV×進捗率で導出する。
だから、メンバーに毎日の進捗率を記入させる運用を試みるが、90％で停滞する症状に陥りやすいため、進捗率はあまり当てにならない。
普通は、ステータス＝作業中、レビュー中など細かく切って、ステータスに進捗率を対応付けて運用する方が正確さが増すだろう。

Agile開発ならば、未完了チケットはアウトプットがゼロと見なすため、完了ステータス以外はEV＝0になる。
開発タスクでソースを修正中だったり、単体テストが未完了ならば、それは顧客から見れば、コンパイルエラーのソースと同じだ。
何故なら、顧客から見れば、まともに動くソースでないからだ。

【4】EVMを使って単価を求める場合、下記のような計算方法になると思う。
WF型で開発しているとして、進捗率から下記の値になると想定しよう。

タスクA：PV＝0.9MD、AC=0.0MD、EV＝0.0MD
タスクB：PV＝0.9MD、AC=1.0MD、EV＝0.7MD
タスクC：PV＝0.9MD、AC=1.0MD、EV＝0.9MD

まず、CPI(コストパフォーマンス)を求める。

CPI = EV/AC = (0.7 + 0.9)/(1.0 + 1.0)=0.8

次に、完了時の想定コストを求める。

ETC = AC + (BAC-EV)/CPI
= 2.0 + (3 * 0.9 - (0.9 + 0.7))/0.8
= 3.375 MD

従って、単価は、3.375MD/3件＝1.125MD/件で導出される。
つまり、単純にPVやACを合計して件数で割り算するだけでは単価は出ないと思う。

ここでは、顧客が本来想定している成果物を作るのにかかる単価0.9MD/件に対し、1.125MD/件かかっているわけだから能率が悪い。
２５％もコストオーバーで作っているのだから、赤字になりやすいし、メンバーの作業負荷も高くて大変だろうと思う。

Agile開発ならば、タスクBのEV＝0なので、CPI＝0.45となり、単価はもっと高くなる。
単価が高いと言う意味は、一つの成果物(アウトプット)を出すのにたくさんのコストが掛かっているわけだから、生産性はもっと悪い。

例えば、顧客に工数見積を提案する時は、顧客が本来想定している90MDかかるシステム規模を作るには、我々は112.5MDかかるので、提案工数は90MDとさせてください、という流れになるのだろうと思う。
もし、112.5MDで提案したとすれば、顧客は112.5MDかかるシステム規模を想定しているのに、実際は90MD相当のシステムしか作れない訳だから、多分もめると思う。

この人月単価の計算方法は、工業簿記の総合原価計算に似ている気がする。
総合原価計算では、生産データから完成品総合原価を求めるのだが、そのロジックが上記の考え方に近い。
特に、加工費の計算方法は、まさにEVで考えているのと同じような気がする。

とはいえ、工数見積もりをするのに、ここまで複雑な計算を考える必要があるのだろうか？
顧客に工数見積もりの正当性を説明しようとしたら、上記のような工数見積もり管理システムの仕様書で説明しようとするわけだから非現実的な気がする。

【5】Scrumの見積り技法が優れている点の一つは、規模見積りと工数見積りを区別していること。
Scrumではストーリーポイントで規模見積りして、スプリント実施後に工数を測定して、規模と工数の係数を求めることで、後どれくらいの時間をかければシステムが完成するのか、という見積りに使う。

この時の係数がVelocityという概念であり、1スプリントに対する開発規模を表す。
Velocityをスプリントごとに計測して、将来の予測とリリース計画の精度を上げるために使っている。
その時に使われるのがバーンダウンチャート。
バーンダウンチャートをEVMの言葉で変換すれば、右肩下がりの予定が残PV、右肩下がりの実績が残EVに相当する。
バーンダウンチャートは残作業量を表示することで、顧客や開発者に後どれくらいのタスクが残っているからどれくらいの時間がかかるのか、を説明しやすくしてくれる。

Scrumのストーリーポイントによる見積りは、EVMやCOCOMO2のような複雑な仕様による工数見積りをバッサリ切り捨てて、簡易な手法で見積もって素早いフィードバックを活かしながら、計画作りの精度を上げていく。
工数見積りそのものに工数がかかりすぎると、管理工数が増えすぎてアウトプットの量が減る。
そんなことを考えると、Agileな開発における工数見積もりの技法は色々考える余地があるように思う。

チケット駆動開発を実践してみて、PMBOKのEVMやScrumのVelocityの考え方がとても理解しやすくなった。
見積り、コストの予測、開発ペースに関する考察が可能なのも、Redmineに元ネタとなる工数データがあるから。
チケットに予定・実績工数を入力しておけば、いわゆるTimeTracking機能もRedmineは実装されているから、強力なチケット集計機能によって、工数の変化も追跡できる。

色々考えてみたい。