プロジェクトマネージャーは進捗係ではない – 責任分界、判断条件、変更管理を設計する仕事

プロジェクトマネージャーの仕事を、進捗を聞いて表にまとめる役割として捉えると、プロジェクトはかなり弱くなります。進捗確認は必要ですが、それは結果を観測しているだけです。プロジェクトを前に進めるには、誰が何を決めるのか、どの条件で判断するのか、変更が起きたときに何を守るのかを設計する必要があります。

特にシステム開発やインフラ構築では、進捗の遅れそのものよりも、責任分界、前提条件、依存関係、承認経路、変更管理が曖昧なことの方が大きな問題になります。作業が遅れているように見えても、実際には仕様が決まっていない、環境が用意されていない、判断者が不明確、リスクの扱いが決まっていない、という状態が原因で止まっていることがあります。

進捗管理は状態の観測にすぎない

進捗管理は、プロジェクトの状態を知るためには必要です。予定より進んでいるのか、遅れているのか、未着手の作業がどれだけあるのか、期限に対して余裕があるのかを確認しなければ、判断材料がありません。

しかし、進捗率やチケット数だけを見ても、プロジェクトが健全かどうかは分かりません。80% 完了と書かれていても、残り 20% が外部システム連携、性能試験、移行、運用引き継ぎ、顧客承認であれば、実際のリスクはかなり大きくなります。反対に、進捗率が低く見えても、難しい設計判断が終わっていて、残りが機械的な作業であれば、危険度はそれほど高くない場合もあります。

見えている情報	確認すべきこと
進捗率	残っている作業の難しさ、依存関係、承認待ちの有無。
チケット数	粒度が揃っているか、未分解の大きな作業が残っていないか。
遅延日数	作業遅れなのか、判断待ちなのか、外部依存なのか。
課題件数	解決担当、期限、意思決定者、放置時の影響。
リスク一覧	検知条件、対応方針、受容するか回避するかの判断。

PM が設計すべき責任分界

プロジェクトマネージャーが最初に整理すべきものの一つは責任分界です。発注側、受注側、ベンダー、社内情報システム部門、業務部門、セキュリティ部門、運用部門の間で、誰が何を決め、誰が何を作り、誰が何を受け入れるのかを明確にしなければなりません。

責任分界が曖昧なまま進むと、問題が起きたときに初めて境界線を引くことになります。仕様の解釈、追加費用、テスト範囲、障害時の切り分け、運用引き継ぎ、セキュリティ例外の扱いが、その場の力関係や声の大きさで決まりやすくなります。

ここで重要なのは、責任を押し付けることではありません。責任分界は、誰を責めるかを決めるためのものではなく、判断と作業を滞らせないための設計です。境界が明確であれば、相談すべき相手、承認すべき人、変更時に影響を受ける人が見えます。

判断条件を決めなければ会議が増える

プロジェクトが進まない原因の一つは、判断条件が決まっていないことです。会議で状況を共有しても、何を基準に決めるのかがなければ、次回までの宿題が増えるだけです。

たとえば、スケジュールを守るために品質を落としてよいのか、費用を増やして人を追加するのか、範囲を削るのか、リリースを延期するのか。これらは単なる進捗確認では決められません。優先順位、制約、許容できるリスク、変更時の承認者を事前に決めておく必要があります。

判断対象	事前に決める条件
スコープ変更	追加費用、納期、品質、契約への影響を誰が承認するか。
リリース延期	延期する条件、通知先、代替案、事業影響。
品質基準	どの欠陥ならリリース不可か、暫定対応を認めるか。
性能問題	目標値、測定条件、未達時の対応方針。
セキュリティ例外	例外を認める条件、期限、補完策、責任者。

変更管理は止めるためではなく守るためにある

変更管理という言葉は、現場では面倒な承認手続きとして扱われがちです。しかし、本来の目的は変更を止めることではなく、変更によって何が変わるのかを見えるようにすることです。

仕様変更、設計変更、構成変更、スケジュール変更、担当変更は、それぞれ別の影響を持ちます。小さく見える変更でも、テスト範囲、運用手順、監視項目、権限設計、移行計画、教育資料に影響することがあります。PM は変更を受け付けるかどうかだけでなく、変更が波及する範囲を確認する役割を持ちます。

変更管理が弱いプロジェクトでは、後半になってから『聞いていない』『想定と違う』『それは範囲外だ』という話が増えます。これはコミュニケーション不足だけではなく、変更を設計情報として扱っていないことが原因です。

課題管理は一覧表ではなく意思決定の入口である

課題管理表は、項目を並べるだけでは意味がありません。課題には、発生日、影響範囲、原因、担当者、期限、判断者、対応方針、未解決のまま残した場合の影響が必要です。これらがなければ、課題は単なるメモになります。

また、課題には種類があります。すぐ解決すべき障害、設計判断が必要な論点、外部回答待ち、リスクとして監視するもの、仕様変更として扱うものを分けなければ、優先順位が崩れます。PM の役割は、課題を集めることではなく、課題を判断可能な形へ整えることです。

課題の種類	PM が整理すること
作業課題	担当者、期限、完了条件。
設計論点	選択肢、判断基準、決定者。
外部依存	回答待ち相手、期限、遅延時の代替案。
仕様変更	影響範囲、費用、納期、承認。
リスク	発生条件、兆候、対応方針、受容可否。

PM は技術を知らなくてよいのか

プロジェクトマネージャーがすべての技術を実装できる必要はありません。しかし、技術的な制約や依存関係を理解しないまま管理することは難しいです。データ移行、認証、ネットワーク、性能、監視、バックアップ、セキュリティ、運用引き継ぎは、進捗表の項目としては一行でも、実際には多くの前提を持ちます。

技術を知らない PM が危険なのは、細かいコマンドを知らないからではありません。技術的な未決事項を、単なる作業遅れとして扱ってしまうからです。設計判断が必要な問題を担当者の頑張りで解決しようとすると、後半で手戻りが大きくなります。

PM に必要なのは、実装者の代わりに設計する能力ではなく、技術的な論点を判断可能な言葉へ変換する能力です。何が未定なのか。何を決める必要があるのか。決めないとどこに影響するのか。誰が判断できるのか。ここを整理できなければ、進捗管理は形だけになります。

ベンダー任せにしないための PM

外部ベンダーを使うプロジェクトでは、PM の役割はさらに重要になります。ベンダーに作業を依頼することと、プロジェクトの判断を委ねることは違います。社内で決めるべき業務要件、優先順位、受け入れ条件、運用責任、リスク許容度まで外部へ渡してしまうと、完成したものが自社の判断と合っているかを評価できません。

RFI や RFP の段階で、社内が何を握り、外部に何を任せるのかを分けておく必要があります。技術選定を任せるとしても、制約条件、既存システムとの関係、運用体制、セキュリティ要件、将来の保守方針は社内の判断として残ります。

PM の成果物は予定表だけではない

PM の成果物をスケジュール表や議事録だけだと考えると、プロジェクト運営の実体が見えなくなります。PM が残すべきものは、判断の前提、責任分界、変更履歴、課題の扱い、リスク判断、承認の記録です。これらが残っていれば、なぜその選択をしたのかを後から確認できます。

成果物	残す意味
責任分界表	誰が何を決め、何を実行し、何を受け入れるのかを明確にする。
判断基準	納期、品質、費用、スコープ、リスクの優先順位を残す。
変更履歴	何が変わり、何に影響し、誰が承認したのかを追えるようにする。
課題管理	未決事項を判断可能な形で管理する。
リスク管理	兆候、発生条件、対応方針を事前に決める。
受け入れ条件	完了とみなす状態を明確にする。

まとめ

プロジェクトマネージャーは、進捗を聞いて表を更新するだけの役割ではありません。進捗管理は必要ですが、それはプロジェクトの状態を観測するための手段です。プロジェクトを成立させるには、責任分界、判断条件、変更管理、課題管理、リスク管理、受け入れ条件を設計する必要があります。

PM が弱いプロジェクトでは、問題が起きるたびに会議が増え、判断が先送りされ、後半で『誰が決めるのか』『何が完了条件なのか』『これは範囲内なのか』という話になります。反対に、PM が構造を作れているプロジェクトでは、問題が起きても、誰が、何を根拠に、どの範囲で判断するのかが見えています。

進捗は結果です。PM の仕事は、その結果が悪くなる前に、判断と責任の構造を作ることです。プロジェクトマネージャーを進捗係として扱うのではなく、プロジェクトの意思決定と責任分界を設計する役割として位置付けるべきです。

参考書籍

参考資料

• IPA: IT スキル標準（ITSS）
• IPA: 研修ロードマップの構成
• IPA: プロジェクトマネージャ試験

関連する記事