RedmineにおけるEVMの考え方
Redmine.JP Blogで>Redmine 2.2の新機能が紹介されていたのでメモ。
Redmine 2.2新機能紹介: 休業日の設定 | Redmine.JP Blog
Redmine 2.2新機能紹介: プロジェクトをまたいで子チケットを作成 | Redmine.JP Blog
Redmine 2.2のCHANGELOG (新機能のみ・日本語訳付き) | Redmine.JP Blog
【1】「休業日の設定。休業日は後続するチケットの開始日の再計算とガントチャートの表示で使われる」「先行するチケットの期日を前倒しした際に後続するチケットの開始日・期日も前倒し」などの機能改善を見ると、最近のVerUpが進捗管理の機能改善に力を入れているように思える。
【2】チケットの属性には開始日・期日・進捗率があるので、ガントチャートというビューをすぐに表示できるし、EVMプラグインを入れれば、EVMでコスト管理も可能。
imaginary-cloud/redmine_evm ・ GitHub
EVMプラグインでは、PV・AV・EVは以下のように定義されているらしい。
PV=チケットの予定工数
AC=チケットの実績工数の和
EV=チケットの予定工数 * 進捗率(%)
EVの解釈は、例えば、現時点のチケットが次のように考えると分かりやすい。
チケットの予定工数=10人日
チケットの実績工数の和=8人日
チケットの進捗率=60%
この例では、以下の計算になる。
PV=10人日
AC=8人日
EV=6人日(=10MD * 60%)
つまり、本来の予定(PV)では、10人かかるタスクに8人分のコスト(AC)が既に消費されているのに、成果物(出来高:EV)は6人分のタスクの量でしか達成されていない。
本来は、8人分のコストが計上されているなら、成果物も8人分の分量ができて然るべきなのに、6人分しかできていないから、効率が悪い。
この時の「効率」という概念がCPIであり、CPI=EV/AC で計算される。
つまり、CPI=6/8=0.75ゆえに、1よりも小さいからコストパフォーマンスが悪い。
CPIは開発能率、生産能力に相当するので、定義は違うけれどもアジャイル開発のVelocityに似ている。
【3】EVMプラグインのスクリーンショットにあるように、EVMプラグインはSPIやCPIもデフォルト表示されるので、プロジェクトの進捗でどれだけ工数を浪費しているのか、リアルタイムに観察することができる。
できれば、Redmine metrics pluginのようにEVMをマイルストーン単位にバッチ処理で集計できれば、マネージャの意に沿うようになるだろう。
redmine_evm/screenshot.png at master · imaginary-cloud/redmine_evm · GitHub
スクリーンショットの例では3つある。
Test_Redmine_Evmバージョンでは、PVがかなり大きく、EVがACを上回っているものの、PVよりもはるかに小さい。
CPI=1.2なので、1人投入して1.2人分の仕事はしているが、SPI=0.33なので、スケジュールはかなり遅れている。
普通は、他のプロジェクトに人員が取られて、予定通りにメンバーをアサインできず、少ない人数で進めている状況と思われる。
計画通りにメンバーをアサインできていないのだから、マネージャは組織上の上司に訴えかけてプロジェクトを打破する必要がある。
test_version_1バージョンでは、当初はPV=0の時期にACが発生していて、その後、ACは増えていないのにEVが増えている。
色々解釈できるが、当初の計画よりも先にメンバーがタスクを消化しようとしていたが、途中で実績工数を更新せずに進捗率だけ更新していると思われる。
マネージャはチーム状況をヒヤリングし、正しく実績入力するように指導するだろうと思う。
test_version_2バージョンでは、ACが一時期PVを追い越すほど高止まりしていて、EVが停滞している。
CPIもSPIも1よりもはるかに小さい。
普通は、メンバーが残業や休日出勤でリカバリーしようとしたが、本来想定している出来高(アウトプット)が出せていない状況に相当する。
多分デスマーチプロジェクトになっているのだろう。
【3】RedmineからPMBOKのEVMを計測する方法: プログラマの思索にも書いたけれども、EVの考え方には、WF型開発とアジャイル開発の2種類がある。
EVを進捗率で考える方法がWF型開発、EVをチケットが完了したかどうかで決める考え方がアジャイル開発。
つまり、仕掛中の成果物をEVという出来高に含めるかどうかで、EVの考え方が変わってくる。
マネージャの仕事の殆どは予算管理やコスト管理なので、EVの基準を定めることはまさにプロジェクトの成功基準を定めることと同じ。
EVMに限らず、先行・後行、クリティカルパスの計算なども、チケットの属性という入力さえあれば実装可能。
RedmineはRailsで作られているのだから、Rubyでアジャイルに開発してしまえばいいだけのことだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 掃き溜めの鶴を活かすマネジメント、それは強みSと環境Oを組み合わせたクロスSWOT分析と同じだ(2026.10.01)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
- Redmine利用成熟度モデルによる運用戦略(2026.07.12)
「Redmine」カテゴリの記事
- Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア(2026.09.21)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論(2026.08.04)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
「ソフトウェア工学」カテゴリの記事
- AIが思考を代行する時代に人間が「知識を繋ぐ」固有の価値とは何なのか?(2026.10.12)
- Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア(2026.09.21)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- AI時代のソフトウェア開発者とはアーキテクトの役割として再定義される(2026.08.30)
- AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi(2026.08.22)
「チケット駆動開発」カテゴリの記事
- Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア(2026.09.21)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- 人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる(2026.08.16)
- チケット駆動でAIを制御する仕組みのアイデア(2026.08.13)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
「Agile」カテゴリの記事
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi(2026.08.22)
- チケット駆動でAIを制御する仕組みのアイデア(2026.08.13)
- アジャイル開発を強化するキルチェーン進化の歴史~VUCA時代におけるモノづくりの新アーキテクチャ(2026.08.11)
- 脱PDCA!DXを加速する超高速戦略「KillChain」(2026.08.10)
「Ruby」カテゴリの記事
- 「コーディングを支える技術」は良い本だ(2022.05.26)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- JRubyの終焉(2020.06.09)



コメント