プロジェクトの進捗管理：進捗率を信用できる数字にし、遅延を早期に検知する

「80%」「85%」「90%」と報告され、それでも終わらない

進捗管理で困るのは、数字が出てこないことではありません。出てきた数字が信用できないことです。週次会議で「80%です」と報告された作業が、翌週は「85%」、その翌週は「90%」。そして完了予定日を過ぎても終わらない。報告する側が怠けているのではなく、進捗率という指標の測り方そのものが、この動きを生みます。

前提を1つ置きます。作業がWBSのような形ですでに分解されていること。分解が済んでいない段階では、以下に挙げるどの測定方式も使えません。逆に分解さえ済んでいれば、打てる手は4つに絞られます。完了基準を定義する。作業の長さに合わせて計上方式を選ぶ。EVMを入れるか入れないかを決める。そして、悪い数字が正直に上がってくる場を作る。

「進捗90%」が動かない構造

この現象には90パーセント完了シンドローム（90-Percent-Done Syndrome）という名前が付いています。担当者が作業の90%は終わったと認識しているにもかかわらず、実際に残っている工数が見積もった10%よりはるかに大きい状態を指します。進捗報告が最後まで問題なしのまま推移し、スケジュールの大半を消化した段階で突然遅延が表面化する、という形で現れます。

原因は複数あります。第1に、見積もりが楽観的で、主要な問題はもう解決したという思い込みが働くこと。第2に、最後に残る作業を些末なものとして過小評価すること。実際には統合、例外処理、性能調整、他システムとの接続確認、ドキュメント整備といった終盤の作業が想定外の困難を含みます。第3に、進めるなかで新しい要件や制約が判明すること。第4に、完璧主義から手直しが繰り返されることです。

測り方そのものに起因する原因もあります。5日間の予定の作業が3日経過したから60%完了、という数え方は、作業量ではなく経過時間を測っています。この方法では着手すらしていない作業でも時間の経過とともに進捗率が上がります。さらに構造的な問題として、EVMの研究では、上層部が現場の作業内容を理解しないまま実行不可能な要求を課す環境では見せかけの進捗報告が発生しうることが指摘されています。「90%です」は担当者個人の問題ではなく、正直に報告すると不利益を被る環境が作り出している場合があります。

完了基準（Definition of Done）で測る

対処の核心はシンプルです。「何パーセント終わりましたか」と人に聞くのをやめ、「終わったか、終わっていないか」を客観的に判定できる単位まで作業を割ってから、完了した単位の数を数えることです。この判定基準が完了基準、いわゆるDefinition of Done（DoD）です。スクラムでは「作業が完了したという意味についてのチームの共通理解」と説明され、受入基準を1か所に集約するものとされています。スプリントの終わりに作られる増分は、このDefinition of Doneを満たし使える状態でなければなりません。

この考え方はアジャイル固有のものではありません。ウォーターフォール型でも、WBS辞書に各ワークパッケージの完了条件を書けば同じことができます。「基本設計を実施する」ではなく「基本設計書がレビューを通過し、指摘事項がすべてクローズされている」と書けば判定は割れません。「テストをする」ではなく「該当機能のテストケースが全件実行され、未クローズの重大不具合がゼロである」と書きます。粒度も同時に決めます。完了か未完了かの二値で測るなら、作業の単位は報告サイクル内で終わるサイズでなければ意味がありません。週次で進捗を見るのに1つの作業が3か月かかるなら、13週間ずっと0%と報告されることになります。

進捗の測定方式：0/100法、50/50法、加重マイルストーン法、出来高法

EVMの実務では、作業ごとにどう進捗を計上するかの方式（アーンドバリュー・テクニック）を選びます。EVMを本格導入しない現場でも、この分類はそのまま使えます。第1は0/100法です。作業が完了して受入が済むまで一切の進捗を計上せず、完了した瞬間に100%とします。1つの報告期間内で終わる短期の作業に適しており、「ほぼ終わっています」という曖昧な申告が入り込む余地がないため、90パーセント完了シンドロームに最も強い方式です。第2は50/50法です。着手時点で50%、完了時点で残り50%を計上します。25/75法や40/60法といった配分違いもあり、2つの報告期間にまたがる程度の作業に向いた折衷案です。

第3は加重マイルストーン法です。作業の途中に中間マイルストーンを設定し、それぞれに重みを配分して、通過した時点でその重み分を計上します。最初のマイルストーンに25%の重みを与えたなら、それを達成したときにはじめて25%が計上されます。2つの報告期間を超える長い作業に適します。決定的なのは、中間マイルストーンを客観的に判定できるものにすることです。「詳細設計が半分終わった」ではなく「対象30画面のうち15画面の設計書がレビュー済み」と置きます。

第4は出来高法（ユニット完了法）です。同種の作業が反復的に発生する場合に、完了した個数の比率をそのまま進捗率にします。10個作る予定のうち7個できていれば70%です。画面本数、テストケース消化数、移行対象テーブル数など数えられる対象がある工程では、最も納得感のある方式になります。選び方の原則は作業の長さと数え方で決まります。なお、進捗会議の運営や課題管理のように成果物が離散的でない継続作業（レベル・オブ・エフォート）はEVMの想定外であり、この比率が高いと計算結果が実態を反映しなくなることが指摘されています。

EVMの土台：PV、EV、ACという3つの値

EVM（Earned Value Management、アーンドバリューマネジメント）は、スコープ、スケジュール、コストを1つの指標系に統合して進捗と実績を測る手法です。基礎になるのは3つの値です。1つ目はPV（Planned Value、計画価値）で、旧称はBCWS、その時点までに完了しているはずの作業に割り当てられていた予算額を指します。計画上のカーブと考えるとわかりやすいです。

2つ目はEV（Earned Value、出来高）です。旧称はBCWPで、実際に完了した作業に割り当てられていた予算額を指します。計算としては、BAC（Budget at Completion、完成時総予算、全作業の予算合計）に実績の完了率を掛けた値、あるいは完了した作業のPVを足し合わせた値になります。最大のポイントはEVの性格です。EVは使った金額ではなく、経過した時間でもなく、終わった作業の計画上の価値です。前節の測定方式は、まさにこのEVをどう計上するかを決めるためのものです。3つ目はAC（Actual Cost、実コスト）で、旧称はACWP、その作業に実際に投じたコストを指します。3つが同じ通貨単位あるいは工数単位で表されているからこそ、引き算で差異を、割り算で効率を出せます。

差異と指数：SV、CV、SPI、CPIの意味と落とし穴

3つの値から指標が導かれます。まず差異です。SV（Schedule Variance、スケジュール差異）はEVからPVを引いた値です。負であれば計画より遅れており、ゼロなら計画どおり、正なら先行しています。CV（Cost Variance、コスト差異）はEVからACを引いた値です。負であれば予算超過、ゼロなら予算どおり、正なら予算内です。どちらも金額で表現されるため、影響の大きさが直感的にわかります。

次に指数です。SPI（Schedule Performance Index、スケジュール効率指数）はEVをPVで割った値です。1未満なら遅れ、1なら計画どおり、1を超えていれば先行を意味します。CPI（Cost Performance Index、コスト効率指数）はEVをACで割った値です。1未満ならコスト超過、1なら予算どおり、1を超えていれば予算内です。差異は絶対額で影響の大きさを、指数は比率で効率の良し悪しを見る、と使い分けます。

必ず知っておくべき落とし穴が2つあります。1つ目は、SPIとSVが終盤で必ず健全な値に収束することです。プロジェクトが完了した時点ではEVとPVが必ず一致するため、SPIは最終的に1.0に、SVは0に収束します。これは実際に納期どおり終わったかとは無関係に起こり、数か月遅れて終わったプロジェクトでも終わってしまえばSPIは1.0です。この性質のため終盤のSPIは遅延の指標として信頼できません。対処として、金額ではなく時間軸で進捗を測るアーンド・スケジュール法が提唱されています。

2つ目は、SPIがクリティカルパスを区別しないことです。SPIは金額の重みで計算されるため、予算規模の大きい作業が順調なら、クリティカルパス上の小さな作業が遅れていてもSPIは良好に見えます。EVMの限界として、クリティカルパス上にない大型作業の影響が小型の重要作業の影響を覆い隠しうることが指摘されています。SPIが1.0だから納期は大丈夫、という読み方は誤りで、必ずクリティカルパス上の遅延状況とセットで読みます。

完成時予測：EAC、ETC、VAC、TCPI

EVMの実務的な価値はむしろ予測にあります。中心となるのがEAC（Estimate at Completion、完成時総コスト見積り）で、代表的な考え方が3つあります。第1の方式は、ACにBACからEVを引いた値を足す方法です。すでに使ったコストに残作業の予算額をそのまま足すもので、今後は当初計画どおりの効率で進むという前提に立ちます。コスト超過の原因が特定済みで、すでに解消されている場合に使います。

第2の方式は、BACをCPIで割る方法です。現在のコスト効率が最後まで続くという前提であり、最も標準的に使われます。CPIが0.8なら当初予算の1.25倍かかるという計算です。第3の方式は、ACに、BACからEVを引いた値をCPIとSPIの積で割ったものを足す方法です。コストの非効率とスケジュールの遅れの双方が続く前提で、両方が悪化している状況では最も悲観的な数字になります。

関連指標も押さえます。ETC（Estimate to Complete、残作業コスト見積り）はEACからACを引いた値、つまり今後追加で必要になるコストです。VAC（Variance at Completion、完成時差異）はBACからEACを引いた値で、負であれば追加予算が必要という意味です。TCPI（To-Complete Performance Index）はBACからEVを引いた値をBACからACを引いた値で割ったもので、当初予算内で完了させるために今後必要となるコスト効率を示します。

TCPIは経営への説明に効きます。現在のCPIが0.8なのにTCPIが1.4であれば、残り期間で今の1.75倍の効率を出さなければ予算内に収まらないという意味です。それが現実的でないなら、予算増額かスコープ削減かの判断を今すべきだ、という話になります。実務ではEACを1つの数字で出すより、3方式の値を併記して幅で示すほうが意思決定の材料として有用です。

EVMを入れるべき現場と、オーバーヘッドが見合わない現場

EVMは強力ですが無償ではありません。成立させるには前提条件があります。第1に、スコープが事前に定量化されWBSのような形で作業に分解されていること。第2に、個々の作業に予算が配分されていること。第3に、実コストを作業単位で集計できること。第3が実は最大の壁で、経理システムから出るコストが部門単位や月単位でしか取れない場合、ACを作業ごとに割り付けられず、CPIもEACも計算できません。EVMの導入は、会計側の集計単位を変える話を含みます。

したがってEVMが見合うのは、長期かつ大規模で、並行する作業が多く、コスト超過の説明責任が問われる現場です。多くの組織は規模の閾値を設け、一定規模を超えるプロジェクトにEVMを必須とし、下回るものは対象外とする運用を取っています。ただし、いくら以上という一律の基準が標準として定められているわけではなく、閾値は組織ごとに設定されるものです。

逆に見合わないのは、数人が数か月動く程度の規模、実コストを作業単位で取れない体制、継続作業の比率が高い現場です。形式的に導入すると、毎週の実績入力に相当な工数を割いた末に実態を反映しない指標が出力されます。この場合はバーンダウンやバーンアップ、マイルストーンの達成状況、未完了作業の残件数と推移で十分です。

中間解もあります。金額ではなく工数（人日）を単位にした簡易EVMなら、予定工数と実績工数は多くの現場ですでに取れているため追加コストが小さく済みます。さらに軽い方法として、0/100法で完了基準を満たした作業だけを数えて進捗率を出すやり方があります。EVMの指標を一切計算しなくても、自己申告の進捗率を完了ベースの進捗率に置き換えるだけで、90パーセント完了シンドロームの大部分は解消します。

アジャイル・ハイブリッドでの進捗の見方

EVMは事前に計画を定量化することを前提とするため、探索的な開発やアジャイル開発には適用しにくいと一般に考えられています。代わりに見るものの1つ目はベロシティです。1回のスプリントでチームが完了させた作業量を表し、通常はストーリーポイントで測ります。決定的なのは、チーム自身のDefinition of Doneを満たしたものだけを数える点です。作りかけを数え始めた瞬間、ベロシティは自己申告の進捗率と同じものに退化します。

2つ目はバーンダウンチャートです。残作業量が時間とともにどう減るかを可視化したもので、ベロシティが「どれだけできるか」を示すのに対し、バーンダウンは「あとどれだけ残っているか」を示します。ここでも完了はDefinition of Doneへの到達を意味します。ただし残作業しか見えないため、スコープ増加による停滞と生産性低下による停滞が区別できません。総量と完了量の両方を描くバーンアップチャートを併用すると、スコープの増加が視覚的に分離できます。3つ目は完了した価値です。リリース済みの機能が実際に使われたか、狙った成果指標が動いたかを見ます。作業量の消化は進捗の代理指標にすぎず、予定どおりポイントを消化していても誰にも使われない機能を積み上げているなら前進していません。

ハイブリッド、つまり全体は計画駆動でマイルストーンが決まっているが開発チームはスプリントで回している構成では、報告の階層を分けるのが実務的です。上位にはマイルストーンの達成状況とEVM指標で報告し、開発チームの運用はベロシティとバーンダウンで回します。必要なのは両者を対応づける翻訳ルールを1つ決めることです。あるマイルストーンに紐づくバックログ項目群を定義し、そのうち完了した項目の比率を上位に上げる形が典型です。翻訳ルールがないと二重管理になり、どちらも精度が落ちます。

週次報告で見る指標と、悪い数字を隠されないための運用

週次報告で見るべきものを整理します。第1に、完了基準を満たした作業の数と比率です。自己申告の進捗率ではなく、判定可能な完了の積み上げを見ます。第2に、クリティカルパス上の作業の状況です。第3に、マイルストーン日付の履歴です。当初計画、前回報告時、今回報告時の3つを並べると、日付がじりじり後ろにずれる動きが可視化されます。第4に、未完了作業の残件数と推移です。第5に、課題とリスクの新規発生件数と滞留件数です。第6に、EVMを導入しているならCPI、SPI、EACの推移です。いずれも単発の値ではなく傾向として読みます。CPIが0.95であること自体より、3週連続で下がり続けていることのほうが重要です。

そのうえで、悪い数字が隠されない運用を作る必要があります。第1に、報告様式から主観的な進捗率の入力欄をなくし、完了基準ベースの記入に固定します。書く欄がなければ90%という数字は生まれません。第2に、悪い報告をした人を責めないことです。実行不可能な要求が課される環境では見せかけの進捗報告が生じうると指摘されており、悪い数字を上げた瞬間に詰問される場では報告は必ず楽観方向に歪みます。第3に、遅延の報告を受けたときはまず「いつ分かったか」を確認し、分かってすぐ報告されたならその行動自体を評価します。第4に、報告書とは別に、デモやコードレビュー、成果物の現物確認といった実物を見る場を持つことです。

進捗率は、測り方を決めない限り数字になりません。完了基準を定義し、判定できる単位まで作業を割る。そのうえで作業の長さと性質から計上方式を選びます。1期間で終わるなら0/100法、2期間程度なら50/50法、それより長いなら加重マイルストーン法、数えられる反復作業なら出来高法。EVMは規模が大きく実コストを作業単位で集計できる現場では効きますが、数人が数か月動く程度の案件ではオーバーヘッドが見合わず、バーンダウンと残件数の推移で足ります。使うならSPIが終盤に1.0へ収束することとクリティカルパスを区別しないことを踏まえ、クリティカルパスの状況と必ず併読します。

ただし、ここまでの設計を全部やっても効かない場面があります。悪い数字を上げた担当者がその場で詰められる会議では、完了基準を決めようが測定方式を揃えようが、報告は楽観方向に歪み続けます。指標をいじるより、その場のふるまいを変えるほうが早いことがあります。