経験の浅い人はEVMの「出来高」という概念を理解しにくい

「経験の浅い人はEVMの「出来高」という概念を理解しにくい」という話を聞いて、心当たりがあったのでメモ。
ラフなメモ書き。

EVMで重要な概念は、計画と実績の予実管理だけでなく、出来高管理にある。
今、実際に労働コストを費やして、どれだけの出来高をアウトプットに出したのか、という状況を見える化するためにある。

しかし、新人やマネジメント経験の少ない開発者は、出来高という概念が理解しにくいらしい。
そういう人に限って、作業の進捗率が曖昧で、90％シンドロームに陥りがち。

出来高という概念を理解しにくい原因を辿ると、作業の完了基準を明確に理解していない事実が判明する。
「未着手」「作業に着手した」「設計書は完成したがレビュー未完了」「レビューが終わった」「リーダーが承認した」というフローを理解していないのだ。
あるいは、それぞれのチケットの状態と成果物が対応付けられておらず、進捗率を自分の感覚だけで適当に付けてしまう。

その意味では、WF型開発では、出来高＝計画工数 * 進捗率で計算されるため、出来高を理解しにくい弱点があると思う。
レビュー未完了の設計書の出来高は、本当に80％なのか？
設計工程が完了しても、システムは何一つ作られておらず、リリースされていないのに、出来高を計上してもいいのか？

アジャイル開発を経験している人なら、出来高は理解しやすいはずだ。
完成したモノが出来高と等価であり、未完了のモノは出来高としてはゼロだから。
つまり、アジャイル開発の領域では、出来高は現物と同じ。

また、この話は、アジャイル開発ならDoneの基準に相当する。
製品をリリースできる基準、作業が完了した基準、成果物が完成した基準が、チーム内で認識が不統一なのだ。
Scrumでは、スプリント計画を立てる時点で、Doneの基準もチームで決める。
それによって、メンバー全員が、作業を完了する基準を理解し、共有する。

Scrumが優れている点は、Doneの基準がチームの成長に従って変化していくことを許容していることだ。
初期のスプリントでは、メンバーも新しいフレームワークや仕様に慣れていないし、チームも有機的に動けないので、アウトプットの量は少ない。
だから、Doneの基準の範囲も狭い。

しかし、スプリントを経ていくうちに、メンバーもチームも成長し、生産性が上がり、成果物の品質も向上するようになるだろう。
だから、リリース後ないしスプリント計画時に、Doneの基準を見直して、Doneの基準の範囲を広げていく。
そうすれば、より品質の良い作業や成果物をメンバーに期待することにもつながる。

出来高という概念には、現物主義、Doneの基準という概念と密接に関連する。
アジャイル開発で考える方が厳密で分かりやすいと思う。