レッスン7：実行のコントロール——進捗を「率」で語らない

このレッスンで学ぶこと

進捗率の罠（作業時間ベースと成果物ベースの違い）を理解する
アーンドバリューの考え方を、数式を最小限にして図解で理解する
ステータスレポートに含めるべき5項目を把握する
週次定例のアジェンダ設計の基本を理解する
遅れが出たときの4つの手を使い分けられる
ベースラインと再計画の線引きを理解する

レッスン6では、リスクと課題を表で管理する技術を扱いました。今回は、計画したスケジュールに対して、実際の進捗をどう確認し、遅れが出たときにどう手を打つかという、実行段階のコントロール技術を扱います。中核メッセージの1つ「進捗率は最も嘘をつきやすい数字」を、具体的な技術として学ぶレッスンです。

「順調です」という報告の危うさ

具体的な場面で考えてみましょう。あるシステム導入プロジェクトで、担当メンバーは毎週の定例会議で「順調です、進捗は予定どおり70%です」と報告し続けていました。プロジェクトリーダーはこの報告を信じ、特に踏み込んだ確認をしないまま数週間が過ぎました。

ところが、納期の10日前になって、担当メンバーから「実は、想定していなかった連携部分の設計に手間取っていて、まだ完成の見通しが立っていません」という相談が持ち込まれました。慌てて内容を確認すると、これまで「70%」と報告されていた進捗は、あくまで「予定していた作業時間のうち70%を使った」という意味であり、実際に完成していた機能は全体の半分にも満たない状態でした。プロジェクトリーダーは、納期直前になって初めて、事態の深刻さに気づいたのです。

この失敗の原因は、担当メンバーが嘘をついていたことではありません。本人は「予定の時間を使った割合」を素直に報告していただけで、悪意はありませんでした。問題は、プロジェクトリーダー側が「進捗率」という言葉の中身を確認せずに、額面どおり受け取ってしまったことにあります。本レッスンで扱う技術は、この種のすれ違いを防ぐためのものです。

進捗率の罠

プロジェクトの定例会議で、「進捗はどうですか」と尋ねると、「80%くらい終わりました」という答えが返ってくることがあります。この「80%」という数字は、どのように算出されたものでしょうか。

多くの場合、この数字は「予定していた作業時間のうち、すでに何時間分を消化したか」という、作業時間ベースの感覚から出てきます。しかし、作業時間を消化したことと、実際に成果物が完成に近づいていることは、必ずしも一致しません。

具体的な場面で考えてみましょう。ある報告書の作成というワークパッケージに、5日間の見積もりが立てられていたとします。4日目が終わった時点で、担当者は「予定の4日分を使ったので、80%は終わっている」と報告しました。しかし、実際に完成した内容を確認すると、報告書の骨子と前半部分しかできておらず、後半部分にはまったく手がついていませんでした。成果物ベースで見れば、進捗はせいぜい40%程度だったのです。

このズレが起きる理由は、「時間を使った」ことと「成果物ができあがった」ことが、別の物差しだからです。本コースでは、この2つの物差しを、次のように区別します。

作業時間ベースの進捗：予定していた時間のうち、どれだけを消化したか
成果物ベースの進捗（出来高）：実際に完成した成果物が、全体のどれだけに相当するか

進捗を正しく把握するには、作業時間ベースの感覚的な報告ではなく、成果物ベースの出来高で確認する必要があります。

⚠️ 注意 「80%完了」という報告を鵜呑みにせず、「具体的に、何が完成していて、何が残っているか」を確認する習慣をつけてください。レッスン4で扱った「90%症候群」は、まさにこの作業時間ベースの進捗感覚から生まれる現象です。

アーンドバリューの考え方

成果物ベースで進捗を数値化し、予算の使い方とあわせて確認する技術に、「アーンドバリューマネジメント」があります。アーンドバリューマネジメントは、英語表記の頭文字を取って「EVM」とも呼ばれます。

📝 補足 「EVM」という略語は、コンピュータの分野で使われる別の意味（仮想機械の一種）でも使われることがあります。本コースで扱う「EVM」は、あくまでプロジェクトマネジメントにおける「アーンドバリューマネジメント」を指します。

アーンドバリューマネジメントは、次の3つの数値を軸に組み立てられます。

PV（計画価値）：ある時点までに、計画上完了しているはずの作業の価値（予算換算）
EV（出来高）：ある時点までに、実際に完了した作業の価値（予算換算）。「アーンドバリュー」という名前は、このEVに由来する
AC（実コスト）：ある時点までに、実際にかかったコスト

この3つを比較することで、「予定どおり進んでいるか」と「予算どおりに使っているか」を、それぞれ独立して確認できます。

具体例で考えてみましょう。ある新商品発売プロジェクトの、ある時点での状況が、次のとおりだったとします。

予定では、この時点までに100万円分の作業が完了しているはずだった（PV＝100万円）
実際に完了した作業は、金額に換算すると80万円分だった（EV＝80万円）
ここまでに実際にかかったコストは、90万円だった（AC＝90万円）

この3つの数値から、次の2つの指標を計算します。

スケジュール差異（SV）＝ EV － PV ＝ 80万円－ 100万円＝マイナス20万円コスト差異（CV）＝ EV － AC ＝ 80万円－ 90万円＝マイナス10万円

スケジュール差異（SV）がマイナスということは、「計画より20万円分、作業の完了が遅れている」ことを意味します。コスト差異（CV）がマイナスということは、「出来高に対して、10万円分コストがかかりすぎている」ことを意味します。この例では、進捗の遅れとコストの超過が、同時に起きていることがわかります。

さらに、この2つの差異を比率で表した指標もあります。

スケジュール効率指数（SPI）＝ EV ÷ PV ＝ 80 ÷ 100 ＝ 0.8 コスト効率指数（CPI）＝ EV ÷ AC ＝ 80 ÷ 90 ＝約0.89

SPIが1より小さければ計画より遅れており、CPIが1より小さければ予算より使いすぎている、というように、1を基準に判断します。この例では、SPIが0.8、CPIが約0.89と、どちらも1を下回っているため、進捗もコストも計画から外れている状態だとわかります。

flowchart LR
  PV["PV 計画価値<br/>100万円"] -.差異.-> EV["EV 出来高<br/>80万円"]
  EV -.差異.-> AC["AC 実コスト<br/>90万円"]

図1：PV（計画価値）・EV（出来高）・AC（実コスト）の3つを比較することで、「進捗の遅れ」と「コストの超過」を、それぞれ独立して把握できます。EVがPVより小さければ進捗の遅れ、EVがACより小さければコストの超過を示します。

💡 ポイント アーンドバリューマネジメントの本質は、複雑な数式を覚えることではなく、「予算を使った量（AC）」と「実際にできあがった量（EV）」を分けて考える発想にあります。この発想さえ押さえておけば、「予算の半分を使ったから、進捗も半分のはずだ」という誤解を避けられます。

SPIとCPIを組み合わせると、プロジェクトの状態を4つのパターンに整理できます。

SPI（進捗）	CPI（コスト）	状態
1以上	1以上	予定より早く、予算内で進んでいる理想的な状態
1未満	1以上	予算内だが、進捗が計画より遅れている
1以上	1未満	進捗は計画どおりだが、コストが超過している
1未満	1未満	進捗の遅れとコストの超過が同時に起きている、最も注意が必要な状態

先ほどの新商品発売プロジェクトの例（SPI＝0.8、CPI＝約0.89）は、この表の4番目、「進捗の遅れとコストの超過が同時に起きている」状態に該当します。このように状態を分類しておくと、「遅れているだけなのか」「予算だけが超過しているのか」「両方とも問題なのか」を、感覚ではなく数値で切り分けられます。

📖 もっと詳しく アーンドバリューマネジメントには、このほかにも、完了までにかかる見込みの総コストを予測する「完成時総コスト見積り」など、より発展的な指標があります。本コースでは、SV・CV・SPI・CPIという基本の4指標を扱う範囲にとどめ、これ以上の発展的な指標は、プロジェクトマネジメントを専門に扱う書籍や資格教材で学ぶことをおすすめします。

ステータスレポートの5項目

進捗を関係者に共有する定番の手段が「ステータスレポート」です。ステータスレポートは、プロジェクトの現在地を、関係者が短時間で把握できるようにまとめた定期報告です。次の5項目を基本の構成とします。

全体状況：計画どおりか、遅れているか、進んでいるかを一言で示す
今回の期間で完了した成果物：出来高ベースで、具体的に何が完成したか
次回の期間で完了予定の成果物：次の報告までに、何を完成させる予定か
課題・リスクの状況：レッスン6で扱った課題管理表・リスク登録簿の中で、特に注意が必要な項目
判断や支援が必要な事項：報告を受ける側に、何かしらの判断や協力を求める場合、その内容を明示する

この5項目のうち、特に見落とされがちなのが5番目です。ステータスレポートを「進捗を伝えるだけの一方通行の報告」にとどめず、「必要な判断や支援を引き出すための手段」として使うことが、レポートの価値を高めます。

🔰 初学者の方へ ステータスレポートは、長く書けばよいというものではありません。5項目それぞれを1〜2行程度に簡潔にまとめ、詳細はレッスン3のWBS辞書やレッスン6のリスク登録簿・課題管理表を別途参照する形にすると、報告を受ける側の負担を減らせます。

先ほどのシステム導入プロジェクトの例で、望ましいステータスレポートを作るなら、次のような内容になったはずです。

項目	記載内容の例
全体状況	計画よりやや遅れ気味（出来高ベースで進捗約45%）
完了した成果物	画面設計書、基本的なデータ登録機能
次回完了予定の成果物	外部システムとの連携部分の設計書
課題・リスクの状況	連携部分の仕様確認に想定より時間がかかっている（課題管理表No.3）
判断や支援が必要な事項	連携先システムの担当部門への確認を、リーダーから依頼してほしい

「順調です、70%です」という一言だけの報告と比べると、情報量に大きな差があることがわかります。特に「判断や支援が必要な事項」まで書かれていれば、プロジェクトリーダーは早い段階で連携先部門への働きかけに動けたはずです。

週次定例のアジェンダ設計

ステータスレポートを共有する場として、多くのプロジェクトで週次の定例会議が設けられます。この定例会議の時間配分を工夫しないと、「進捗の読み上げだけで時間が終わる」会議になりがちです。

効果的な週次定例のアジェンダの一例を示すと、次のようになります。

時間配分	議題
5分	全体状況の共有（ステータスレポートの要点のみ）
15分	遅れている項目・課題管理表の確認と対応方針の決定
5分	リスク登録簿の見直し（新しいリスクの有無）
5分	次回までのアクションの確認

この配分の意図は、「順調な項目の説明」に時間を使いすぎず、「遅れている項目」と「課題」の確認と対応方針の決定に、多くの時間を割り当てる点にあります。定例会議は、単なる報告の場ではなく、遅れや課題への対応を決める「意思決定の場」として設計します。

📝 補足 定例会議の頻度は、プロジェクトの規模やスピード感によって調整します。変化の少ない段階では隔週や月次に、クリティカルパス上の作業が集中する時期には週次や、場合によってはそれ以上の頻度に、柔軟に切り替えることも実務的な工夫です。

遅れが出たときの4つの手

進捗を確認した結果、遅れが判明したら、次に取るべき手を検討します。レッスン1で扱った制約の三角形を思い出してください。遅れへの対応も、この三角形の枠組みで整理できます。取れる手は、大きく4つです。

スコープを調整する：レッスン2のMoSCoWで整理した優先度をもとに、Could haveの項目を後回しにするか取りやめ、Must haveの完成を優先する
期間を調整する：レッスン5のクラッシングやファストトラッキングで、クリティカルパス上の作業を短縮する。あるいは、全体の完了予定日そのものを見直す
要員を調整する：追加の人員を投入する、あるいはほかの作業とのかけもちを解消して、遅れている作業に集中してもらう
品質基準を調整する：レッスン2で定めた受け入れ基準の一部を、プロジェクトの目的に照らして最小限まで見直す（ただし、安易な品質の切り下げは避けるべき最後の手段）

4つの手のうち、どれを選ぶかは、プロジェクトの状況と、遅れの深刻度によって異なります。重要なのは、「なんとなく頑張って取り戻す」という精神論に頼るのではなく、この4つの手のどれを、どの程度動かすかを、具体的に検討することです。

⚠️ 注意 4つの手を検討せずに「みんなで頑張って挽回しよう」とだけ呼びかけると、担当者の負担が際限なく増えるだけで、根本的な解決にはなりません。遅れが判明した時点で、制約の三角形のどこを動かすかを、関係者を交えて具体的に議論してください。

ベースラインと再計画の線引き

プロジェクトの計画は、一度立てたら固定するものではありません。しかし、遅れが出るたびに計画をどんどん変更していくと、「最初に何を目指していたのか」がわからなくなってしまいます。この問題を扱うために、「ベースライン」という考え方があります。

ベースラインとは、プロジェクトの立ち上げ段階で承認された、当初のスコープ・スケジュール・予算の基準を指します。日々の進捗確認では、このベースラインと実際の状況を比較することで、「計画からどれだけズレているか」を把握します。

一方で、大きな環境変化（レッスン2で扱った変更管理プロセスを経た、大幅なスコープ変更など）があった場合は、ベースラインそのものを更新する「再計画」を行います。再計画は、頻繁に行うものではありません。小さな遅れのたびにベースラインを動かしてしまうと、「計画は常に達成される」という見かけ上の状態になってしまい、本来の目的である「計画とのズレを早期に把握する」という機能が失われます。

ベースラインを更新するかどうかの判断基準として、次の目安が参考になります。

4つの手（スコープ・期間・要員・品質）による調整だけでは、もはや吸収できないほどの変化が起きた場合
レッスン2の変更管理プロセスを経て、スコープの大幅な変更が正式に承認された場合
プロジェクトの前提条件そのものが変わった場合（例えば、外部環境の大きな変化）

💡 ポイント 「計画どおりに進むプロジェクトは存在しない。あるのは、ズレに早く気づける計画だけ」という中核メッセージは、この章の内容に集約されます。ベースラインは、計画を守るための道具ではなく、ズレに気づくための「ものさし」です。ものさし自体を頻繁に動かしてしまえば、ズレを測ることができなくなります。

まとめ

このレッスンでは、以下のことを学びました。

進捗率には、作業時間ベースと成果物ベース（出来高）の2つの物差しがあり、作業時間ベースの感覚的な報告は実態とズレやすい
アーンドバリューマネジメント（EVM）は、PV（計画価値）・EV（出来高）・AC（実コスト）の3つから、スケジュール差異（SV）とコスト差異（CV）、SPIとCPIを算出し、進捗の遅れとコストの超過を独立して把握する
ステータスレポートは、全体状況・完了した成果物・次回完了予定・課題とリスクの状況・判断や支援が必要な事項の5項目で構成する
週次定例は、順調な報告よりも、遅れている項目と課題への対応方針の決定に時間を割り当てる
遅れが出たときは、スコープ・期間・要員・品質という4つの手のどれを、どの程度動かすかを具体的に検討する
ベースラインは計画のものさしであり、頻繁に動かさず、大きな変化があったときにのみ再計画として更新する

次のレッスンでは、ここまで扱ってきたウォーターフォール型の考え方とは異なる、もうひとつの進め方であるスクラムと、ふりかえりの技法を扱います。

確認クイズ

このレッスンの理解度をチェックしましょう。