Redmine Lychee Enterpriseシリーズの解剖part2～RedmineでEVMを実現 Lychee EVM

Redmineのアドオン製品 Lychee EVMのデモ画面を触ってみた。
感想をラフなメモ書き。

【参考】
Lychee Enterprise～マネージャのためのRedmine

【1】EVM Plugin | Lychee Enterpriseは、Redmine上でEVMを表示してくれるアドオン製品。
「Redmineによるタスクマネジメント実践技法」の第8.1節「PMBOKのEVM」に、Redmine上でEVMを実現できるはずだ、と書いたけれど、まさにその機能を実現してくれた製品になる。
だから、僕にとって一番気になる製品。

【1－1】EVMはなぜ必要なのか？

SI案件でも、工事進行基準が適用されたために、プロジェクトの進捗状況に応じて、プロジェクトの売上を確定する必要が出てきたからだ。
かつてのように、システムの検収後に売上を一括計上するやり方は、大規模案件になるほど不可能。
そんな丼勘定をしていると、会計監査でツッコミが入ってくる。

これから始める進ちょく管理（1）：工事進行基準が進ちょく管理に変化をもたらす (1/2) - ITmedia エンタープライズ

EVM を活用したIT サービス調達の進化モデル～情報処理振興事業協会

しかし、ITプロジェクトの進捗は、土建業界のようなビルの構築のように明確に判断できない弱点がある。
WF型開発ならまさにそうだ。

要件定義書、設計書が納品されたとしても、プログラムはないから、肝心のシステムは稼働されていない。
ユーザにシステムを納品できていないのに、その状況では果たして、売上が確定できると言えるのか？

設計書が完成したとしても、レビューによる手戻り作業があれば、100％完成とは言えないのでは？
完了基準の定義はいったい何なのか？

EVMでは、当初の計画工数に対して、今どれだけのコストが発生し、今の出来高(アウトプット)がどこまであるのか、を把握できる。
EVMはPMBOKできちんと理論化されているので、運用できれば、かなり強力なツールだ。

Redmine Lychee EVMは、Redmine上でEVMを実現してくれる画期的な製品。
なお、MSProjectには、EVMの機能がすでに実現されている。

その意味でも、Lychee製品シリーズは、MSProjectの機能をRedmineで実現しようとしている意図が込められているように思える。

これから始める進ちょく管理（4）：Microsoft ProjectでEVMに挑戦！ (1/2) - ITmedia エンタープライズ

【1－2】しかし、EVMの運用は至難の業だ。
運用上の課題はいくつかある。

一つ目は、タスクの完了基準をどのように決めるのか、という点。
進捗率がステータスと連動していなければ、計算された出来高の正当性が失われてしまう。
その完了基準をメンバーに徹底させるにもそれなりのコストがかかる。

2つ目は、工数入力と工数集計にかなりの手間がかかること。

プロジェクト計画時にWBSを作る最大の理由は、見積りしたいためだ。
そのWBSの見積り工数が予定工数になり、その総額が予算になる。
そして、タスクの実績工数と進捗率がWBSに反映されて、EVMが確定する。

しかし、日々の工数入力を徹底できなければ、EVMは得られない。
しかも、日々の工数をExcelで集計し直すのはかなりの手間だ。

ちょっとした案件でさえ、WBSは数百～数千にものぼるからだ。
1億円以上の案件なら、WBSは数万レベルになるだろう。
そうなると、もはやExcelでEVMを運用するのは事実上不可能に近い。

3つ目は、リスケが発生した場合、EVMをどのように再計算し直すのか？
仕様変更、スコープ増大、要員増加などが途中で発生したら、WBSもその予定工数も全て更新し直さなければならない。
炎上プロジェクトほど、要員が大量に増えるので、スケジュール変更もままならず、EVMの運用まで手が回らない。

【1－3】EVMをRedmineで実現する基本的アイデアは、WBSをチケットで表現すれば、PV・AC・EVがチケットの属性で表現できること。
チケット管理の運用さえ徹底できれば、工数データはチケットとして蓄積されているから、EVMの仕掛けは事実上整っている。

過去にもたくさんのアイデアを書いてきた。

【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索

EVMはアジャイル開発に適用できるか: プログラマの思索

EVMとバーンダウンチャートは本質的に違う: プログラマの思索

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

RedmineにおけるEVMの考え方: プログラマの思索

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

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

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

運用上の課題は、Redmineでは下記で解消される。

1・タスクの完了基準は、チケットの進捗率を作業ステータスと連動させる。
2・工数入力と工数集計は、チケットの工数管理のI/Fを使う。
3・EVMの再計算は、チケット集計機能をバッチ処理で実行し、EVMの履歴を残す。

【2】EVM Plugin | Lychee Enterpriseを見ると、主に3つの機能がある。

【2－1】EVMの表示

Lychee Enterprise - Redmineを見るとよい。

【2－1－1】EVMにフォーカスを当てると、PV・AC・EVがポップアップ表示される。
履歴や測定日で、今どれだけのコストがかかっているのか、どれだけのアウトプットが出ているのか、がすぐに分かるのは便利。

チケットの情報を見ると、EV＝PV * 進捗率　で計算しているようだ。
つまり、アジャイル開発ではなくWF型開発を想定しているようで、進捗率をステータスと連動する運用を想定しているのだろう。
アジャイル開発ならば、Doneの基準が厳格なので、進捗率は0％か100％の2つしかないからだ。

また、PVは、チケットの開始日・終了日で補正計算されている。
そのため、当日時点の正確な予定工数を把握できるので、当初の計画通りに進んでいるかどうかを判別できる。
EVMの計算で面倒な点の一つは、EVの計算だけでなく、日付を考慮したPVの計算もあるからだ。

PV・AC・EVの配置によって、プロジェクトの進捗度合いやコスト増加傾向が一目で分かる。

ITレポート（動向／解説） - EVMによる進ちょく管理の基本と勘どころ（2）：ITpro

但し、PV・AC・EVの単位は、時間単位であるのに注意。
人日や人月で把握するには、再計算する必要がある。
SIerによって、1人日＝8時間だったり、7時間だったりバラつきがあるので、人月の計算は大きく違ってくる。

【2－1－2】過去の履歴だけでなく、測定日以後の将来に向けて、実績工数が点線で表示されている。
チケットの情報を見ると、点線の実績工数はEACの傾向を表している。

下側のメニューにある「EAC」にフォーカスを当てると、
EAC＝AC＋(BACーEV)/CPI
という計算式が表示される。
この計算式は、EAC＝BAC/CPIと同じ。

つまり、現在の開発ペースをCPIとみなして、現在の開発ペースなら、これくらいのコストが予測されることを意味している。

マネージャなら、EACは常に把握しておきたい数値だ。
なぜなら、現在の開発ペースなら、プロジェクトが赤字で終わるのか、黒字で終わるのか、を早めに予測したいからだ。
普通は、開発ペースが計画時点よりも悪い場合が多いので、赤字にならないための対策を早めに作り、上司の報告する必要が出てくる。

【2－1－3】ユーザインターフェイスを見ると、タイプ＝EVMを選択後、バージョン・プルダウンで、全てのバージョンや各バージョン、子プロジェクトのバージョンを選択することができる。
また、各バージョンを複数選択することもできるようだ。

マネージャの使い方としては、プロジェクト全体を見たい時は、全バージョンを選択して、予算と総コスト見積り(EAC)を把握する。
WF型開発なら、バージョンを工程で区切ることが多いから、設計バージョンや開発バージョンごとに、計画工数と実績工数を細かく比較分析する運用になる。

また、子プロジェクトは各チームのタスク管理に対応していれば、例えば、設計チームや開発チーム、画面チームやバッチチームごとの開発ペースを分析できる。

基準日や単位＝月毎・週毎・日毎を選択できるので、見たいメッシュを変えれば良いので便利。

但し、注意点としては、サマリされたEVMの結果が表示されているだけで、EVMの値からドリルダウンできないこと。
つまり、過去の履歴のPV・AC・EVの値では、チケットがどんな状況だったのか、を調べることはできない。
あくまでも、現時点のチケットの状況しかドリルダウンできない点は注意。

このような仕様になった理由は、過去の履歴のEVMの指標はバッチ処理でサマリされているため、過去のチケットの状況を表示する機能が現状のRedmineでは実現できないことがあるのだろう。

【2－1－4】また、細かいUIがとても使いやすい。

下側にあるメニュー項目(PV～EAC)をクリックすると、EVMからクリックした項目の線が消える
例えば、過去の履歴だけ見たい場合は、EACをクリックして非表示にすればいい。

エクスポート機能を見ると、CSVだけでなく、PNG・JPG・PDF・SVGで出力できる。
特にマネージャ会議では、印刷物としてEVMを配布する時が多いだろうから、PDF出力されるのは便利。

また、特定の期間をドラッグして拡大表示もできる。
つまり、EVM上で、細かな値を見たい時に便利。

【2－2】SPI・CPIの表示

スケジュールやコストのペースを表示してくれる。
SPI、CPIの理解は下記を参考。

[ThinkIT] 第3回：データの推移からつかめる傾向とベースラインの作成・出来高計上基準 (3/4)

LycheeEVMでは、背景色に赤色・黄色・青色がある。
背景色の意味は、赤色が危険ゾーン、青色が正常ゾーン、黄色が要注意ゾーンに相当する。

つまり、SPIやCPIが赤色ゾーンに入っていたら、すぐに対策を打つ必要がある。
既に進捗遅れ、コスト増が発生しているのだから。

黄色ゾーンになるなら、SPIやCPIが増えないように監視していくことになる。

EVMの理論では、CPIが一番重要だと思う。
CPIはチームの開発ペース、または、生産性を表しており、アジャイル開発のVelocityの傾向に近い概念だからだ。
CPIが大きいほど、作業実績以上にアウトプットが出ていて、効率が良いことを意味する。
だから、CPIの過去の履歴を見れば、チームの生産性がよく分かる。

普通のプロジェクトでは、前半はチームとして有機的に機能していないためにCPIが赤色ゾーンにある。
その後、メンバーの特徴を把握できて技術や仕様に慣れてくると、チームが機能し始めてアウトプットが安定して出せるようになり、CPIが上昇していく傾向にあると思う。

【2－3】ベースライン比較

タイプ＝ベースライン比較　を選択し、基準日を2つ設定する。
ベースライン比較とは、バージョン・プルダウンでEVM計測対象のチケットを絞り込んでおき、2つの基準日でEVMを比較する機能だ。

使い道としては2つあると思う。

1つ目は、工程の最初の日と最後の日を設定して、EVMの傾向を分析すること。
WF型開発なら、バージョン＝工程で区切っているので、バージョンの最初の日と最後の日を設定して、EVMの傾向を分析できるだろう。
あるいは、要件定義、設計、開発、単体テスト、結合テストなどの工程ごとの進捗・コスト、生産性を比較する時に使える。

また、上流工程は元請け、下流工程は下請け、あるいは、設計チームと開発チームのように工程ごとにチームが違う場合、ベースライン比較で進捗・コスト、生産性を比較分析できる。
生産性の低いチームには、メンバーを増員したり、配置換えしたりする対策もあるだろう。

2つ目は、仕様変更でスコープが変わってリスケした時、開発・テスト工程からメンバーが増員された時などで、変化の前後で比較する場合に使う。

顧客要望で仕様が追加されて、設計を大幅に書き直して、開発工数が増えた場合もあるだろう。
その時、変更前と変更後でベースライン比較して、現在のチームの生産性ならば、どれくらいのコスト増になるのかを予測することができるだろう。

あるいは、当初の計画通り、開発・テスト工程からメンバーが増員された場合、普通は生産性が落ちる。
人月の神話で知られている通り、人数が増えるほど無駄なコミュニケーションパスが発生し、新規メンバーに説明したり教育するコストが発生するので、既存メンバーの生産性も落ちる。
もちろん新規メンバーも、計画通りの生産性で作業してくれるとは限らない。

だから、特にメンバー増員の場合は、チームの生産性を日々監視していく必要があるだろう。

【3】OSSのEVMプラグインとの違い

LycheeEVM以外にも、OSSで既にEVMプラグインが公開されている。
その内容は以前書いた。

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

imaginary-cloud/redmine_evm ・ GitHub

【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索

EVMプラグインでは、チケットの予定・実績工数と進捗率を元に、EVMをリアルタイムに表示している。
だから、「Redmineによるタスクマネジメント実践技法」に書いたEVMの実現方法をそのまま提供していると思っていい。
実際にソースを見れば、どのように計算しているのか、よく分かるだろう。

但し、EVMプラグインの弱点は、ACやEVの履歴を保持していないので、EVMの履歴を表示してくれない。
EVMをリアルタイムに表示する機能しか持っていないので、プロジェクト完了時に、PV＝EVになってしまうのだ。
だから、EVMを本当に運用する場合には、残念ながら適用できないだろう。

一方、LycheeEVMでは、AC・EVの履歴をバッチ処理で保持しているようだ。
だから、EVMの履歴がきちんと残るので、本格的な運用に適用できる。

【4】LycheeEVMのリリースノートを見ると、こんな表記がある。

EVM Plugin リリースノート| Lychee Enterprise

(引用開始)
・当日のEVMを即時計算・描画
・スナップショットがない日付のEVMを描画可能に(描画時点での計算値)
・EV計算に使用する進捗率の履歴を広義単調増加するように補正計算
・EVの増加を日割り加算(設定休業日考慮)
・日割りの範囲に、Lychee Actual Dateの実開始日・実終了日を考慮
(引用終了)

ここから類推すると、LycheeEVMには下記の機能が実現されていると考えられる。

【4-1】バッチ処理で前日のEVMをサマリする前に、当日中のチケット情報を元に、当日のEVMも即時計算・描画している。
　つまり、リアルタイムにEVMを表示する機能がある。
　例えば、EVMのリアルタイム表示の利用場面としては、結合テストや総合テスト工程で、障害の発生と修正が頻繁に発生している時、日々のコストやアウトプットを把握したい時に使いたいだろう。
　あるいは、既にコスト超過の案件で、これ以上の工数増加が許されない場合、リアルタイムに工数をチェックして、残業を禁止する運用もあるかもしれない。

【4-2】バッチ処理でEVMのサマリをスナップショットで保持する時、チケットが更新されない日はEVMがサマリされないので、EVMが確定しない。
　だが、LycheeEVMでは、チケットの最新更新日時点のEVMで補正表示してる。

【4-3】EV＝PV*進捗率で計算されるが、進捗率が減少した場合、EVも減少する症状が発生する。
　EVMの理論では、PV・AC・EVが減少することはありえない。
　PVは計画時点で確定してベースラインになるし、ACやEVは日々の作業結果の積み重ねだからだ。
　
　しかし、チケット管理の運用では、リスケしたり、適宜補正したり、差し戻される時に、PV・AC・EVが減少する場合が発生すると考えられる。
　例えば、リスケして予定工数を減らしたり、月末に実績工数を減らして修正したり、進捗率を差し戻しステータスで減らしたり、とか。
　そんな症状が発生しないように、LycheeEVMでは、「EV計算に使用する進捗率の履歴を広義単調増加するように補正計算」していると思われる。

【4-4】SIerでも、日祝日以外にも非営業日でお休みの時もある。
　例えば、創立記念日とかメーデーとか。
　LycheeEVMでは、EVの計算に「設定休業日も考慮」しているらしい。
　
【4-4】別製品Lychee Actual Dateを入れておくと、EVの計算に実開始日・実終了日も考慮しているようだ。
　つまり、チケットの予定日と実績日を厳密に管理している場合、実績日を元にEVを計算してくれているようだ。
　この機能は、OSSのEVMプラグインでは実現できていない。

以上を見ると、LycheeEVMは、OSSのEVMプラグインの単なる焼き直しではなく、SIerにおける実際のEVMの運用ノウハウを相当埋め込んでいると思われる。