RedmineからPMBOKのEVMを計測する方法

RedmineからPMBOKのEVMを計測する方法についてアイデアをメモ。

【元ネタ】
チケット駆動開発にEVMの概念を導入してみる: プログラマの思索

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

チケット駆動開発にPMBOKの概念を導入してみる: プログラマの思索

【1】PMBOKのEVM(Earned Value Management)とは、工事進行基準による進捗管理と実質的に同義だ。
昨今のITプロジェクトでは、大規模案件ほど、成果物の進捗ベースで売上が計上される仕組みが多いだろう。
すると、メンバーに毎日の進捗報告を義務付けて、マネージャが週1回集計して、売上を計上して会社に報告する流れになるだろう。
以前は、工事終了基準だったから、システムの検収後に一括して売上を計上すれば良かったが、J-SOXがあるために実質的に不可能。

実際に工事進行基準でプロジェクト管理を始めると、実績工数を含めた進捗報告と集計作業がとても大変で、実際の仕事に関係ない所でロスが発生する。
運用ルールが決められていないと、進捗率が90％のまま1週間以上も未完了だったり、各メンバーの進捗報告のレイアウトがバラバラで集計しにくかったりする。
そもそも、実プロジェクトの進捗管理そのものがルーズだったりすれば、すぐにデスマーチに陥る。

【2】PMBOKのEVMは、成果物の進捗ベースからスケジュールやコストを予測できる優れた仕組みだが、正直分かりづらい。
僕は、Redmineによるチケット駆動開発でEVMの概念が腑に落ちた。
EVMの概念は下記でRedmineへマッピングできる。

(1) PV＝sum(該当期間のチケットの予定工数)
(2) AC＝sum(該当期間のチケットの実績工数)

(3) EV＝sum(該当期間の終了チケットの予定工数)
又は
EV＝sum(該当期間のチケットの予定工数×進捗率)

ここで、EVの概念がAgile開発と従来のWF型開発の場合、2通りの定義が出ることに注意して欲しい。
EVは獲得価値(出来高)であるから、実際の成果物(出来高)に相当する。

Agile開発では、作業の終了条件(Done)がリリースできることだから、進捗率は0％か100％のどちらかしかない。
ソースをコミットしてビルドして動くのが確認できるまで、未着手でも作業中でも０％だ。
何故なら、Doneの条件が動くシステム＝リリース完了だからだ。
Agile開発が定義するEVはとても厳格で、うまくプロジェクト管理できなければ、顧客から見れば、殆ど作業がはかどっていないように見えるだろう。

従来のWF型開発では、メンバーが自分の判断で進捗率を入れる場合が多いだろう。
すると、進捗率の基準があいまいなため、９０％シンドローム（進捗率が９０％のまま停滞する）が起きやすく、EVの値が正しくないケースが出てきがちだ。

だから、普通は作業ステータスごとに進捗率が設定されるだろう。
未着手＝０％、作業中＝５０％、レビュー中＝９０％、完了＝１００％みたいになるだろう。
Redmineの場合、管理画面でステータスごとに進捗率を設定できるので、この機能を使えばいいだろう。

又、実績工数の入力ではWorkTimeプラグインがとても使いやすいのでお勧めだ。
プラグイン作者は、このプラグインから出力された前日の実績データを朝会で使っていると聞いたことがある。

RedmineのWorkTimeプラグイン: プログラマの思索

【3】PV、AC、EVの値は、Redmineからすぐに取り出せる仕組みはないようだ。
直接MySQLにアクセスして、SQLでデータをダウンロードしなくてはいけないようだ。

その場合、下記のようなデータのフォーマットがあれば、EVMは計算可能。

チケットNo,開始日,終了日,予定工数,実績工数,進捗率

現在日付から該当の期間を初期設定しておけば、ExcelマクロでPV、AC、EVの値は集計可能。
Excelの集計のアイデアは下記に書いた。

WindowsのキラーアプリExcel: プログラマの思索

本来は、Redmineの画面上でEVMをグラフ化してくれるのが良いのだが、今の所、そういうプラグインは存在しないようだ。

【4】EVMを使う場合、ベースラインが重要で、最初に決めた計画のベースラインを修正することはない。
修正してしまったら、予定と実績の差がなくなるので、差異分析ができなくなるからだ。
だが、実プロジェクトでは、マイルストーンごとに見直し作業や作業漏れのタスクを反映してリスケする時がとても多い。
そうしなければ、ベースラインは実プロジェクトからかけ離れた与太話に過ぎなくなり、差異分析する意味もなくなる。

EVMのグラフを見ると、Agile開発で出てくるバーンダウンチャートに似ているように見える。
バーンダウンチャートは、PVとEVを右肩下がりで描いたグラフと言える。
実際、バーンダウンチャートの残作業の予定量はBAC-PV、残作業の実績量はBAC-EVから求められる。

ベースラインを使うEVMよりもバーンダウンチャートの方が開発チームにとって有効である理由の一つは、ゴールが見えやすいことだろう。
無理な予定に実作業を合わせるのではなく、顧客に価値あるソフトウェアを作るために、決められた納期までに作業を進める方が現実的だからだ。

PMBOKのEVMをITプロジェクトへ適用する場合、建設業やプラント業界とは違ったノウハウが必要とされるように思う。
もう少し考えてみる。