「PMとして何をしていいか」が分からないまま、気づいたら全部抱え込んでいた——これは役割範囲が最初から曖昧なプロジェクトでよく起きます。「私が判断してよかったのか」「これはPMOに任せるべきだったのか」という後から気づく感覚も、役割確認が不十分なサインです。
役割範囲を最初に確認することは、遠慮することでも弱さを見せることでもありません。プロジェクトを安全に動かすための前提作業です。
役割範囲が曖昧だとPMは抱え込む
役割範囲が不明確なと、PMは「確認しないまま全部やる」か「確認しながらも判断に迷い続ける」かのどちらかになりがちです。
「全部やる」になると、本来PL・PMO・上司が担うべき仕事まで引き受けてしまい、PMが疲弊します。「判断に迷い続ける」になると、小さなことでも上司確認が必要になり、動きが遅くなります。
着任直後に役割範囲を確認しておくことで、どちらも防げます。
確認すべき5つの領域
役割範囲は以下の5領域で確認するのが有効です。
① 意思決定：PMが単独で決めてよいことと、上位者の承認が必要なことはどこで線引きされているか
② 顧客対応：顧客との連絡・交渉・約束はPMが直接行うか、上司を通すか
③ 進捗管理：チーム全体の進捗管理はPMが主体か、PMOが主体かどちらか
④ 課題管理：課題のエスカレーション基準はどこか。PMが解決できない課題は誰に上げるか
⑤ 品質判断：成果物の品質合否を判断するのはPMか、別の担当者か
上司に聞く質問
着任直後に上司に確認する場合は、以下の質問が使えます。
- 「PMとして私が単独で決めてよい範囲はどこまでですか？」
- 「顧客への連絡・交渉・約束は私が直接行ってよいですか？」
- 「エスカレーションが必要な場面の判断基準を教えてください」
- 「このプロジェクトで特に私が判断しないほうがよい領域はありますか？」
「なんでも相談してください」という返しが来ることもありますが、「具体的にはこういう場面はどうですか？」と具体例を挙げることで、実際の判断基準が引き出しやすくなります。
PL・PMOに確認する質問
PLやPMOがいる場合は、役割の重複をなくすために以下を確認します。
- 「進捗管理は私がやるべきか、あなたにお任せすべき部分はありますか？」
- 「課題管理表の更新は誰が主体ですか？」
- 「顧客側の担当者とのやり取りはどちらが主に動きますか？」
「あなたの仕事を取りたいわけではなく、どちらがやるかをはっきりさせたい」という前置きをしておくと、スムーズに確認できます。
決まった役割をチームへ共有する
上司・PL・PMOと役割範囲を確認できたら、その内容をチームに伝えます。
「このプロジェクトでは、PMである私が顧客対応の窓口を担います。開発側の進捗管理はPLとともに行い、課題のエスカレーションが必要な場合は私を通してください」
こういった共有があることで、「この件は誰に相談すればいいか」というメンバーの迷いを減らせます。
まとめ
PMが着任直後に確認すべき役割範囲の5領域と質問を整理しました。
- ① 意思決定の範囲
- ② 顧客対応の窓口と権限
- ③ 進捗管理の主体
- ④ 課題のエスカレーション基準
- ⑤ 品質判断の担当者
役割範囲の確認は一度でなく、プロジェクトが進む中で状況が変われば再確認することも必要です。「これは自分がやるべきか」という判断に迷ったときは、その都度確認する習慣が、抱え込みを防ぎます。
役割確認サマリー表
確認した内容を以下のような表に整理しておくと、チームへの共有や振り返りに使いやすくなります。
| 領域 | PMが担う | PMが担わない |
|---|---|---|
| 意思決定 | 定例内の課題判断・進め方の調整 | 予算超過の最終承認（上司判断） |
| 顧客対応 | 定例進行・要望の一次受け | 技術的な詳細説明（PL対応） |
| 進捗管理 | WBSの更新・遅延の確認 | メンバーの日次タスク割り当て（PL対応） |
| エスカレーション | 課題の上司報告・顧客報告 | 最終判断（上司判断） |
| 品質判断 | 成果物のレビュー依頼・確認状況把握 | テストの実施（QA・開発担当） |
このサマリーを着任初期に作っておくと、後から「これはPMの仕事か」と迷う場面が減ります。
PM・PMO・PLの役割や実務スキルを体系的に学びたい方はこちらもどうぞ。