PMI PMP: チームリーダーシップとリソース管理 — 学習ガイド

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

こちらの一部です： PMP — 学習ガイド. 検証済みの解答で練習： PMI試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

チームの編成、チャーター、役割の明確化

優れたパフォーマンスを発揮するチームは、最初のステータス会議で生まれるのではなく、意図的な編成の儀式を経て始動します。チームチャーターは、その創設時の成果物です。これはチームが共同で作成する文書であり、チームの共通の価値観、意思決定のルール、タイムゾーンをまたいだ稼働時間、コミュニケーションの頻度、エスカレーションパスなどを記録します。プロジェクトチャーター（プロジェクトを承認し、スポンサーを指名するもの）とは異なり、チームチャーターはチームによって、チームのために作成されます。その力は、共同で作成したという事実にあります。後日、ある開発者が同僚の作業を中断させたり、スタンドアップミーティングを欠席したりした場合、プロジェクトマネージャーは個人の権威を振りかざすのではなく、チーム自身が確立した規範を指し示します。

チャーターと並行して、グラウンドルールは日々の規律を運用可能にします。例えば、設計レビューではカメラをオンにする、レトロスペクティブ中はマルチタスクをしない、口頭でのアップデートは2分ルール、決定事項は24時間以内に文書化する、などです。グラウンドルールは、チームルームに掲示したり、コラボレーションチャネルにピン留めしたりして、目に見えるようにすべきです。そして、各イテレーションやフェーズゲートの開始時に見直されるべきです。誰も開かないSharePointフォルダに存在するチャーターは飾りですが、毎週参照されるチャーターは規制力を持つものです。

役割の明確化は、チーム編成の三角形の最後の一辺を閉じます。RACI（またはその派生であるRASCI）マトリックスは、成果物と、実行責任者（Responsible）、説明責任者（Accountable）、協業先（Consulted）、報告先（Informed）をマッピングし、「あなたが担当だと思っていました」という失敗モードを排除します。プロジェクトマネージャーが、リーダーシップ不在のまま数週間漂流していたグループを引き継いだ新しいチームにおいて、最初にとるべき正しい行動は、攻撃的な再計画でも、スポンサーとの即時のスケジュール再交渉でもありません。それは、チームを招集し、彼らが何にブロックされていると感じているかを聞き、チャーターと役割マップを再構築することです。チームが迷走していると感じるのは、まさにこれらのアンカーが欠けているからです。

成熟度に合わせたリーダーシップスタイルの適応

シチュエーशनल・リーダーシップでは、リーダーシップのスタイルを人格ではなく、変数として扱います。古典的なハーシー・ブランチャード・モデルは、フォロワーの成熟度に合わせてスタイルを対応させます。

• コンピテンシーは低いが、コミットメントは高い（新人）
  • 推奨スタイル：指示型
  • 行動：何を、いつ、どのように行うかを指示する
• コンピテンシーはいくらかあるが、コミットメントは変動する
  • 推奨スタイル：コーチ型
  • 行動：説明し、決定を売り込み、対話を促す
• コンピテンシーは高いが、コミットメントは変動する
  • 推奨スタイル：支援型
  • 行動：ファシリテートし、意思決定を共有する
• コンピテンシーもコミットメントも高い
  • 推奨スタイル：委任型
  • 行動：責任を委譲する

サーバント・リーダーシップの姿勢（障害を取り除き、チームをノイズから守り、彼らの成長を優先する）は、このモデルに重なりますが、状況に応じた判断に取って代わるものではありません。サーバント・リーダーシップは、放任的なリーダーシップを意味するものではありません。チームが迷走しているとき、サーバントリーダーは依然として指示を出します。ただ、自身の知名度のためではなく、チームの成功のためにそうするだけです。

方向性を見失ったチームに対する自由放任型リーダーシップの罠は、よくある失敗です。チームが作業の共有モデルを持たないときに、「チームが自己組織化するのを待つ」ために一歩引いてしまうと、混乱、依存関係の見落とし、士気の低下を招きます。自己組織化は成熟の結果であり、開始条件ではありません。逆に、同様の作業を5回も納品してきたシニアエンジニアをマイクロマネジメントすることは、不信感を示し、自発性を抑制し、離職を招きます。プロジェクトマネージャーがポートフォリオレベルでのリスクに関する会話を無視する一方で、ドメインエキスパートの作業のコミットレベルの詳細をレビューしているときが、その兆候です。

様々な年次のメンバーが混在するチームに参加する場合、最初に行うべきは、一連のワンオンワンとワーキングアグリーメントのワークショップを組み合わせることです。これにより、各個人が成熟度のスペクトラムのどこに位置するかが明らかになり、スタイルを画一的に適用するのではなく、個人ごとに調整することが可能になります。

コーチング、ワンオンワン、パフォーマンス管理

定期的（通常は隔週30分）に行われるワンオンワンは、コーチング、問題の早期発見、キャリア開発のための主要なチャネルです。これはステータス会議ではありません。アジェンダはチームメンバーが主導権を持ち、プロジェクトマネージャーは70%の時間、聞き役に徹するべきです。トピックは、現在のブロッカー、スキルアップ、双方向のフィードバック、そして士気について、ローテーションで話し合われます。

パフォーマンスの問題は、最初に観察された時点で提起されなければならず、公式な評価サイクルまで溜め込むべきではありません。難しい会話を遅らせることは、プロジェクトリーダーシップにおいて最も有害なパターンの1つです。パフォーマンスの低いメンバーは手遅れになるまで何も学ばず、ハイパフォーマーはそれを見て関与をやめ、士気は静かに侵食されます。フィードバックは、「やる気がないようだ」といった主観的な印象ではなく、欠陥の流出率、ストーリーのサイクルタイム、コードレビューの所要時間、会議への出席率、コミットメントの信頼性といった測定可能な指標に言及すべきです。測定可能な指標は、会話を観察可能な行動に根ざさせ、チームメンバーに具体的な目標を与えます。

機能マネージャーへのエスカレーション、あるいは最終的にリソースの交代を要求することは、コーチング、明確な期待設定、そして文書化されたパフォーマンス改善の話し合いが失敗した後にのみ正当化されます。これらのステップを省略すると、信頼を損ない、しばしば人事ポリシーに違反します。

対立の解消とチームビルディング

対人関係の対立は、放置されると深刻化します。短期プロジェクトでチームメンバーが同僚から孤立させられている場合、プロジェクトマネージャーの対応は、静観する（力学が解決する前にプロジェクトが終了してしまう）ことでも、公の場でグループと対決する（屈辱を与え、立場を硬化させる）ことでもありません。正しいパターンは、3つの動きを組み合わせることです。まず、影響を受けている個人と非公開で会話し、その経験を理解します。次に、排他的な行動を示している同僚と個別に話し、観察されたパターンとその影響を指摘します。そして、チーム憲章とファシリテーション付きのチームビルディング活動を通じて、インクルージョンの規範を強化します。HRへのエスカレーションが必要になった場合に備え、介入の記録は不可欠です。

トーマス・キルマンの5つの対立モード（協調、妥協、円滑化、強制、回避）は、選択の指針となります。協調（ウィンウィンを見つけるための問題解決）は、永続的なチームにおける対人関係や技術的な論争で一般的に好まれます。一方、強制は、安全性、倫理、または厳しい期限に関する決定の場合にのみ正当化されることがあります。

リソースの割り当て、平準化、キャパシティプランニング

リソース管理は、算術計算であると同時に交渉でもあります。リソース平準化は、スケジュールを延長して過剰な割り当てを平準化します。リソース円滑化は、終了日を固定し、フロート（余裕時間）の範囲内で作業します。重要な専門家が過剰にコミットされ、品質が損なわれる恐れがある場合は平準化を選択し、終了日が契約で定められている場合は円滑化を選択します。

機能部門マネージャーがスプリントの途中で共有アーキテクトを再割り当てした場合、プロジェクトマネージャーはデータを用いて交渉します。具体的には、現在のコミットメント、クリティカルパスへの影響、下流工程での遅延コストなどです。スポンサーやステアリングコミッティへのエスカレーションは、直接交渉を試み、それを記録した後にのみ適切です。最初に解決を試みずに不満をそのまま上層部に持ち込むことは、ポリティカルキャピタルを浪費します。

ナレッジトランスファーとクロストレーニング

単一依存点は、最も予測可能なプロジェクトリスクの一つでありながら、最も頻繁に無視されるリスクでもあります。ある人物がサブシステムの唯一の所有者であり、2か月間入院した場合、その失敗は事故そのものではなく、事前の緩和策がなかったことです。予防策には、ペアプログラミングやペアメンタリング、オンコール担当のローテーション、属人化した知識のランブックへの文書化の義務付け、録画されたナレッジトランスファーセッション、そしてセカンダリオーナーが専門家のタスクをシャドーイングし、その後実行するクロストレーニングのローテーションなどがあります。新規採用者のオンボーディング計画では、バディと30-60-90日のコンピテンシーマップを明確に割り当てるべきです。

チームレベルでの後継者育成計画では、各重要な役割を引き継げる人物と、その人物が埋めるべき能力のギャップを特定します。これはスキルマトリックスに記録され、四半期ごとにレビューされます。

会議のファシリテーションと評価

会議は、チームのキャパシティの中で最も目に見える部分を消費します。規律を保つためには、明記された目的、事前に配布されたタイムボックス化されたアジェンダ、適切（最大ではない）な出席者、所有者と期日を明記した明確な決定事項とアクションアイテム、そして議題から外れた話題のためのパーキングロットが必要です。決定事項のない定例会議はキャンセルすべきです。

最後に、評価（チームの勝利に対してはタイムリーで具体的かつ公に、個人のコーチングは非公開で）は、単なる気休めではありません。チーム憲章の価値観に沿った報酬は、それを生み出した行動を強化します。レビューでの簡単な称賛、機能部門マネージャーと連携したスポットボーナス、または誰かの直属の上司への書面でのメモなどは、ほとんどコストがかからず、士気と定着率に大きく貢献します。

実践的な問題：ユースケースシナリオ

シナリオ： Priya Kapoorは、中規模の地方銀行で、予算420万ドル、期間14ヶ月の決済近代化プロジェクト「Meridian」のリーダーに任命されたばかりです。11人のチームは3つのタイムゾーンにまたがっています。バンガロールに5人の開発者、ロンドンに3人のビジネスアナリスト、そしてトロントにQAリード、アーキテクト、そしてPriya自身がいます。プロジェクト開始から2週間後、バンガロールの開発者が構築したプロトタイプが、ロンドンのBA（ビジネスアナリスト）から「全員が読んでいると思い込んでいた」コンプライアンス要件と整合性が取れていないとして却下されました。さらに、トロントのアーキテクトは、技術スタックの決定について全く相談されていなかったと主張しています。

課題： Priyaは、特定のグループを非難しているように見せることなく、プロジェクトがさらに遅延する前に、チームの行動規範と役割の明確さをリセットしなければなりません。

推奨されるアプローチ：

1. 進行中の開発を一時停止し、2日間のバーチャルチーム組成ワークショップを実施します。全11人のメンバーが成果物をライブで共同作成できるよう、重複する時間帯（トロント午前7時～10時／ロンドン午後12時～3時／バンガロール午後4時30分～7時30分）をスケジュールします。
2. 共通の就業時間帯、意思決定権、「相談される(consulted)」と「報告される(informed)」の定義、非同期での意思決定に関する24時間以内の対応ルール、そして最終的にスポンサーに至るエスカレーションラダーを網羅したチームチャーターの共同作成をファシリテートします。
3. WBSにある18の主要な成果物に対してRASCIマトリクスを作成し、チームと共に各行を確認します。これにより、「実行責任者(Accountable)」は常に指名された1人とし、「協業先(Consulted)」には技術スタックに関するあらゆる決定においてアーキテクトを明記します。
4. 基本ルール（設計レビューではカメラをオンにする、決定事項は1営業日以内にConfluenceに記録する、重複する時間帯に週次で30分間のタイムゾーンをまたいだ同期ミーティングを行うなど）を確立し、チームのSlackチャンネルにピン留めします。
5. BAと開発者が共同でプロトタイプのスコープを再検討し、新たに明確化されたRASCIを用いて、コードを記述する前に誰が承認（サインオフ）するのかを特定します。
6. 各イテレーションの最初のふりかえり（retrospective）に、定例の10分間の「チャーターチェック」を追加し、チームの成熟に合わせて規範を改訂します。

このアプローチが有効な理由： 共同で作成することにより、チャーターはトップダウンの指示から仲間同士の約束へと変わります。これにより、PMは職務上の権限を行使することなく、規範を徹底させるための正当性を得ることができます。RASCIは、コンプライアンスの見落としを生んだ「あなたが担当だと思っていた」という認識のズレをなくします。また、イテレーションごとに規範を見直すことで、チャーターが形骸化した成果物ではなく、生きた合意事項であり続けることを保証します。

← ステークホルダーエンゲージメントとコミュニケーション · すべてのドメイン · Agile、Scrum、ハイブリッドデリバリー →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →