チームとリソースの管理

リソースの​ギャップ分析

• 現状把握: プロジェクトに必要なスキルや人員数を明確化。
• 不足の特定: 現在のチームに欠けている能力や人数を洗い出す。
• 対応策: 研修、外部ベンダーの活用、追加採用などでギャップを埋める。

リソースライフサイクルと​リソースの​タイプ

• リソースライフサイクル: リソースは「調達・ニーズ評価 → 割り当て・活用 → 保守（メンテナンス） → 廃棄（ハードウェアの廃棄・ソフトウェアのEOL）」という流れで管理します。
• サクセッションプラン（継承者計画 / Succession Plan）: キーパーソンの離脱・交代に備え、後任者を事前に育成・確保しておく計画。プロジェクトの推進力（モメンタム）を維持するために重要です。
• リソースのタイプ: 人的リソース、物理的リソース、資本リソースに大別されます。
• 内部と外部 / 共有と占有: 組織内部か外部（ベンダー等）か、他プロジェクトと共有するリソースか当プロジェクト専有かで、可用性や調整の難易度が変わります。

チームパフォーマンスの​管理

• 目標設定: SMART基準（具体的・測定可能・達成可能・関連性・期限）でタスクを割り当てる。
• モニタリング: 定期的な進捗確認や人事評価（プロジェクト・パフォーマンス・アプライザル）、レビュー会議を通じて成果を把握。
• 改善促進: フィードバックを行い、モチベーション維持や効率化を支援。

役割と​責任の​定義​（主要な​役割・ロール）

プロジェクトの成功には、体制図内の各リソースの役割を明確に定義することが不可欠です。

• プロジェクトスポンサー（Sponsor）: 資金（予算）提供者。最高意思決定権を持ち、プロジェクト憲章を承認・発行します。
• プロジェクトマネージャー（PM）: スケジュール、予算、リスク、チーム全体の実務運営に対して全面的な実行責任を持ちます。
• プロジェクトチャンピオン（Champion）: 組織内の「政治的障害を排除」し、プロジェクトの価値を熱心に擁護・宣伝する応援団長（スポンサーと兼任されることが多い）。
• プロダクトオーナー（PO）: アジャイル環境において、プロダクトバックログの優先順位を決め、「顧客の利益を代表し、何を作るか」に責任を持ちます。
• スクラムマスター（SM）: アジャイル/スクラムチームがプロセスに従えるよう支援し、障害を取り除く「サーバント・リーダー」。
• プロジェクトスケジューラ（Scheduler）: WBSやガントチャートの更新・維持など、スケジュール策定と進捗報告を専門に行います。
• プロジェクトコーディネーター（Coordinator）: PMのサポート役（事務・調整）。PMほどの強い意思決定権や権限を持たず、機能型組織などでよくアサインされます。
• プログラムマネージャー（Program Manager）: 共通の目的を持つ複数の関連プロジェクト（プログラム）を統合的に管理し、個別では得られないシナジーを引き出す役割。
• プロダクトマネージャー（Product Manager）: プロダクトの市場戦略やロードマップ全体に責任を持つ役割。特定プロジェクトの実行に責任を持つPMより広い、製品ライフサイクル全体を見る立場。
• テスター / QAスペシャリスト（Tester / QA Specialist）: 成果物が品質基準や要件を満たしているかをテスト・検証し、品質を保証する役割。

SME・ビジネスアナリスト・アーキテクトの​違い

• SME（Subject Matter Expert / 主題専門家）: 特定の技術や業務に深い専門知識を持つ人。通常は相談相手（RACIのC）として関わり、システムの安全性を検証する 「テクニカル承認（Technical Sign-off）」 を担当します。
• ビジネスアナリスト（BA）: ビジネス側と技術・開発側の仲介役（架け架け橋）となり、ビジネスニーズを要件定義に翻訳する役割。
• アーキテクト（Architect）: 会社全体のシステム構造を把握し、プロジェクトのニーズを評価して、既存システムの能力限界を超えない最適なソリューションを設計する役割。

RAMと​RACIチャート

• RAM（Responsibility Assignment Matrix / 責任割当マトリクス）: タスクと担当者を交差させ、役割分担を一覧にした表。
  • 試験対策: プロジェクトの超初期段階である 「開始（Initiation / 立ち上げ）フェーズ」 で作成・完了します。初期段階で役割分担を明確にすることで、後々の手戻りやコミュニケーションの遅延をプロアクティブに防ぐためです。
• RACIチャート: RAMの代表的な表記方法。
  • R（Responsible / 実行責任者）: 実際に作業を行う担当者。
  • A（Accountable / 説明責任者）: タスクの最終的な成果に責任を持ち、承認を下す人。1つのタスクに必ず「1人だけ」割り当てます（PMなど）。
  • C（Consulted / 協業先）: 専門知識のアドバイスを提供する人（SMEなど）。
  • I（Informed / 報告先）: 進捗や結果の報告を受ける人（スポンサーなど）。

組織構造の​タイプと​PMの​権限

組織構造のタイプ	特徴	PMの権限レベル	予算/人事権の所有者
機能型組織	部門ごとに縦割りで編成された伝統的な組織。	極めて弱い / 無し	部門長（ラインマネージャー）
マトリックス型組織	機能型とプロジェクト型を複合。メンバーは部門長とPMの双方に報告する。	中程度	弱いマトリックス：部門長 強いマトリックス：PM
プロジェクト型組織	プロジェクト専用の専従チームを組織して業務を行う。	極めて強い / 最強	プロジェクトマネージャー（PM）

• マトリックス組織の3分類:
  • 弱いマトリックス（Weak Matrix）: 機能型に近く、PMは調整役（コーディネーター）にとどまります。
  • バランス・マトリックス（Balanced Matrix）: PMと部門長の権限バランスが均等。
  • 強いマトリックス（Strong Matrix）: プロジェクト型に近く、PMが非常に強い権限や予算権限を持ちます。

PMO​（プロジェクトマネジメントオフィス）の​3つの​タイプ

組織のプロジェクトを標準化・支援・統制する部門。コントロールの強さ順に分類されます。

• 支持的/支援型（Supportive PMO） 【コントロール度：低】: テンプレートや過去の教訓の提供など、アドバイスや支援のみを行い、標準の適用を強制しません。
• 統制型/制御型（Controlling PMO） 【コントロール度：中】: 特定の管理フレームワークの遵守や標準化を要求します（マトリックス組織でよく好まれます）。
• 指示型（Directive PMO） 【コントロール度：高】: PMOがプロジェクトに対して完全な支配権を持ち、PMをPMOから直接任命・派遣し、プロジェクトの意思決定を統制します。

対立​（コンフリクト）​解決の​手法

• 対峙 / 問題解決（Confronting / Problem Solving）: 対立の根本原因を特定し、双方が納得するWin-Winの解決策を見つける。（最も推奨される手法）

• 協力（Collaborating / コラボレーション）: 全員の視点を取り入れ、お互いに協力して最良のWin-Winの解決策を探る。（推奨）

• 妥協（Compromising）: 双方が譲歩して中間点を見つける。完全な満足は得られない（Win-Lose / Lose-Loseの中間）。

• 回避（Avoiding / Withdrawing）: 問題を先送りにして無視する。一時的には有効だが根本解決にならない。（非推奨）

• 強制（Forcing）: 一方の意見を力で押し通す。Win-Loseの結果になる。（非推奨）

• 鎮静 / スムージング（Smoothing / Accommodating）: 対立を最小化し、共通点や合意領域を強調して、表面的な調和（チームの調和）を最優先する。（状況による）

• Glaslのコンフリクトエスカレーションモデル: 対立の深刻化を9つの段階（フェーズ）で表し、それらを3つのレベルに分類して管理します。

チームライフサイクル​（タックマンモデル）の​5段階​（時系列ステップ）

チームの結成から解散までは、以下の 5つの時系列フェーズ を経て成長していきます。

1. 形成期（Forming）: チームが結成されたばかりの段階。メンバーはお互いを探り合い、対立は避ける傾向があります。役割や責任が曖昧なため、PMは明確な指示や方向付けを行う必要があります。
2. 混乱期（Storming）: 業務の進め方や意見の違いから、メンバー間で衝突や対立（コンフリクト）が発生する段階。一時的に生産性や士気が低下します。PMは対立解決（対峙による Win-Win の解決等）をサポートし、コーチとして機能します。
3. 統一期/標準期（Norming）: 互いの違いを認め、共通の目標、ルール、役割分担が確立される段階。チームとしての協調関係が生まれ、生産性が向上し始めます。
4. 機能期/達成期（Performing）: チームが自律的に機能し、高い相互信頼のもとで最大の成果を発揮する段階。PMは細かな指示をせず、チームに権限を委任（デリゲーション）します。
5. 散会期/収束期（Adjourning）: プロジェクト目標を達成し、チームを解散する段階。PMは成果を祝い、メンバーを解放し、教訓を記録します。

関連模擬問題

【問1】

質問: Dion Delaware探偵事務所の探偵であるReedとJamarioは、ある事件へのアプローチ方法について口論しています。上司が介入し、それぞれに自分の意見と、それを裏付ける証拠を提示するよう求めました。その後、上司は両者の主張の共通点を指摘し、それらを基に合意に至るように促しました。上司が用いたコンフリクトマネジメント（対立解決）技法として最も適切なものは、次のうちどれですか？

選択肢:

• A. 強制
• B. スムージング
• C. 妥協
• D. コラボレーション

回答と解説を見る

正解は B です。

解説: 強制: 強制は、一方の当事者が解決策を押し付けることですが、この状況では上司は両方の刑事に意見を述べる機会を与えており、強制的な手法は使用していません。

スムージングは、対立する当事者間の相違を最小限に抑え、共通の利益を強調してチームの調和を維持する手法です。上司はリードとジャマリオの立場の類似点を指摘し、それを基に合意を求めることで、まさにスムージングを実践しています。

妥協: 妥協は双方が譲歩して中間点を見つけることを目指しますが、この状況では上司は直接的な妥協を求めるのではなく、共通点を基にした合意を促しています。

コラボレーション: コラボレーションは双方に利益のある解決策を追求しますが、この状況では長期的な解決よりも、当面の焦点を共通点に置くことで即時の調和を図っています。

【問2】

質問: バックエンド開発者Claudiusとフロントエンド開発者Kishaは、どちらも問題を抱えており、チーム全体に助けを求めていますが同時対応は不可能です。彼らは会議を開き、Claudiusはバックエンド経験のある3名の協力を得る代わりに、Kishaは残りの4名でフロントエンドの対応を行うと提案しました。彼らが用いたコンフリクトマネジメントの形態はどれですか？

選択肢:

• A. コラボレーション
• B. 妥協
• C. スムージング
• D. 強制

回答と解説を見る

正解は B です。

解説: コラボレーション: コラボレーションは、この状況には当てはまりません。コラボレーションは相互の合意によるwin-winの解決策を目指しますが、この文脈では必ずしも譲歩を伴うわけではありません。

妥協は、この状況で Claudius と Kisha が採用した対立管理の形式です。両者が譲歩して妥協点を見つけ、対立を解決しています。Claudius はバックエンド開発の経験豊富な3人のチームメンバーを得る一方で、Kisha は残りの4人のメンバーをフロントエンド開発に充てることができます。これにより、両者が相互に利益のある合意に達しています。

スムージング: スムージングもこの状況には適していません。スムージングは相違点を軽視して共通の利益を強調しますが、必ずしも妥協点を見つけることはありません。一方、この事例では交渉とトレードオフが直接的に行われています。

強制: 強制も、この状況では使用されていません。強制は1人が自分の解決策を押し付け、妥協点を探さないことを意味します。ここでは両者が譲歩して合意に達しています。