プロジェクト・マネジメント-チーム | 项目管理

プロジェクト・エコシステム

複雑で変化し続けるプロジェクト環境では、うまく進めるために、効果的なプロジェクト・チーム体制を整えることが不可欠である。

定義

役割: 特定のプロジェクトにおいて個人やグループに割り当てられる機能を指す。
- ビジネス: ビジネスニーズを満たし続けることと価値の正当性を担保する役割(望ましい)である。(プロジェクト・エグゼクティブ)
- ユーザー: 成果物の要件定義とその実現を支援し、利用者としての利益を代表しつつ、運用や維持にも関与する役割(達成可能)である。(シニア・ユーザー)
- サプライヤー: 成果物を提供するために必要なスキルや知識を持ち、組織内外を問わず実行面を担う役割(実行可能)である。(シニア・サプライヤー)
責任: 成果や結果に対して最終的に説明し引き受ける義務(アカウンタビリティ)である。
プロジェクト・マネジメント・チーム: プロジェクト委員会、プロジェクト・マネージャー、チーム・マネージャー、プロジェクト保証、プロジェクト支援などの役割で構成されている。
プロジェクト・チーム: プロジェクトに関与し時間を投入するすべてのメンバーを指す。

役割は状況に応じて共有や兼務が可能だが、責任は必ず明確にする必要がある。役割を兼務する際には、以下の点を十分に考慮する必要がある。

職責間の衝突がないか
統合された職責を担う能力があるか
ボトルネックが発生しないか

委託(ビジネス・レイヤー): プロジェクトの権限委任やエグゼクティブの任命、全体の許容度設定など、上位レベルでの枠組みを定める役割である。
指揮(プロジェクト委員会): 各ステージの開始・終了を承認し、リソースや期間などの許容度を設定してプロジェクトを統制する役割である。
マネジメント(プロジェクト・マネージャー): 委員会が定めた制約の中で日々のプロジェクト運営を行い、関係者を調整しながら目標や要件に沿って成果物を確実に生み出す役割である。
提供(チーム・マネージャー): プロジェクト・マネージャーの設定した条件のもとで、各作業の実行や日常的な意思決定を担う役割である。

プロジェクト・マネジメント・チーム

プロセス活動の責任はRACI 表の形式で整理される。

プロジェクト・エグゼクティブ

プロジェクトの成功に対して最終的な責任を負う、ビジネス側から任命された唯一の説明責任者。

本質的な属性

唯一性: 複数の人に割り当てることはできない。
独立性: プロジェクト・マネージャー(PM)の役割と兼務することはできない。
不可譲性: 成功に対する最終的な説明責任を他者に委任することはできない。

主な実行責任

ビジネス正当性の担保:
- プロジェクト資金の確保。
- ビジネス・ケースの継続性およびプロジェクトのビジネス正当性の維持。
戦略的ガバナンス:
- ビジネス戦略に整合した方法での効果的なガバナンス。
- 環境や社会へのインパクト等、長期的視点に基づいた意思決定。

シニア・ユーザー

ユーザー・コミュニティを代表し、ユーザー要件の把握およびプロジェクト成果がビジネス価値につながるに対して保証責任を負う役割。

主な実行責任

賛同の確保: プロジェクトのアプローチに対し、ユーザー側の合意とコミットメントを確保する。
要件のモニタリング: 成果物がビジネス・ケースに沿った要件を満たしているか、進捗を監視する。
ベネフィットのデモンストレーション: 予測されたベネフィット(便益)の実現が順調であることを、ビジネス側に実証する。
変更のコントロール: ユーザー・ビジネス・プロジェクトの各所から発生する、要件やベネフィットの変更を管理する。
移管と導入の成功: 成果物のビジネスへのスムーズな移管を主導し、プロジェクト終了後もベネフィットが継続して得られる状態を作る。

備考

構成人数: ユーザー・コミュニティの規模や複雑性に応じて、複数名のアサインが必要な場合もある。意思決定の複雑化を避けるため、人数は最小限に抑えるべきである。

シニア・サブライヤー

サプライヤー・コミュニティを代表し、プロジェクト成果物の提供におけるあらゆる側面、および技術的完全性に対して説明責任を負う役割。

主な実行責任

リソースのコミットメント: サプライヤー組織から、プロジェクト作業を支援するための十分な人員とリソースを継続的に確保する。
品質と技術の担保: 提供される成果物の品質、およびプロジェクト全体の技術的な整合性(完全性)を保証する。
保守・支援の代表: プロジェクト終了後のスペシャリスト成果物の保守サービス(エンジニアリング保守や支援など)を提供する側の利害を代弁する。

備考

構成人数: サプライヤー・コミュニティの規模や複雑性に応じて、複数名のアサインが必要な場合もある。意思決定の効率を維持するため、人数は最小限に抑えるべきである。

プロジェクト委員会

プロジェクトの意思決定とガバナンスに責任を持ち、プロジェクト・エコシステム全体の信頼を得るための適切な権限を有する機関。

構成と役割の原則

利益相反の回避: ユーザー(シニア・ユーザー)とサプライヤー(シニア・サプライヤー)の役割は、利害を適切に反映させるため兼務不可とする。
小規模プロジェクトの特例: 複雑性が低い場合、エグゼクティブがシニア・ユーザーまたはシニア・サプライヤーの役割を兼務できる。
独立した保証: PMから独立した視点で、パフォーマンスと成果物のあらゆる側面を保証する。

環境構築とリソース管理

リソースの確保: 目標達成に必要な資金、人員、機材等のリソースを確実に提供する。
効率的なガバナンス:
- 例外によるマネジメント: ステージごとの許容度を設定し、PMに権限を委譲する。
- 意思決定の指針: ルール、制約、共通の価値観、変更予算を確立し、ガイドラインを示す。
フィードバック: プロジェクトの適応と進化を支援する明確なループを確立する。

戦略的・社会的責任

戦略との整合: ビジネス・ケースに戦略目標を反映させ、組織のコミットメントと整合させる。
ウェルビーイング: プロジェクト・チームの安全と健康(ウェルビーイング)に焦点を当てる。
エコシステムの管理: プロジェクト内および組織全体とのインターフェースにおける関係性を管理し、社会的結束を支援・モニタリングする。

プロジェクト保証

プロジェクト委員会に代わり、プロジェクトが適切に運営されているかを客観的に確認・保証する役割。

役割と実施主体

実施の柔軟性: プロジェクトの規模や必要なスキルに応じて、以下のような主体が担当する。
- プロジェクト委員会のメンバー自身。
- ビジネス(組織)内の専門部署。
- 外部の第三者機関。
専門性の提供: プロジェクト・チームを支援するための知識、スキル、キャパシティを供給する。

厳格な制約(独立性の確保)

利益相反を回避し、客観性を保つため、以下の役割との兼務・アサインは厳禁とされる。
- プロジェクト・マネジャー
- チーム・マネジャー
- プロジェクト・チーム・メンバー
- プロジェクト支援

統治と説明責任

委員会の実行責任: 保証の実施方法の確立、役割・責任の明確化、担当者間の連携確保を行う。
最終的な説明責任: 保証実務を外部や担当者に委任した場合でも、プロジェクト委員会の各メンバーは引き続き最終的な説明責任を負う。

プロジェクト・マネジャー

プロジェクト委員会に代わり、合意された許容度と制約の範囲内でプロジェクトを推進する日々のマネジメントの責任者。

主な権限と実行責任

作業管理と委任: プロジェクト全体の作業を統括し、チーム・マネジャーやメンバーへ適切に権限を委任する。
制約条件の設定: ワーク・パッケージごとの許容度を設定し、チームがその範囲内で自律的に動けるよう管理する。
意思決定の統制: プロジェクト委員会のガイダンスに沿った意思決定がなされるよう、全体をコントロールする。
関係性のマネジメント: プロジェクト保証担当や委員会など、プロジェクト・エスシステム内の関係を管理する。

サポートと持続可能性

ウェルビーイングの推進: チームメンバーの安全、健康、および精神的な充足をモニタリングし、支援する。
持続可能性の追求: プロジェクト・アプローチが環境や組織に対して持続可能であるかを確認する。

体制の柔軟性(スケーラビリティ)

プロジェクトの規模、複雑性、自身のスキルやキャパシティに応じて、以下の運用が可能である。
- 役割の兼務: チーム・マネジャーやプロジェクト支援の役割を自ら実施する。
- 直接委任: これらの役割を介さず、チーム・メンバーへ直接タスクを委任する。

プロジェクト支援

プロジェクト・マネジャー(PM)を実務面でバックアップし、プロジェクト・エコシステム全体の統合と効率化を推進する役割。

主な提供サービス(実行責任)

管理・事務支援: 事務管理、会議やワークショップの進行(ファシリテーション)。
専門的ガイダンス: プロジェクト・ツールの活用助言、計画立案の支援。
プロセス管理: リスク、課題、および変更マネジメントの運用支援。
エコシステムの改善:
- 作業方法改善のためのフィードバック獲得。
- プロジェクトの指揮(ガバナンス)の進化と社会的結束の構築支援。

任命と組織運営の柔軟性

基本的な責任: 原則としてプロジェクト・マネジャーの責任範囲に属する。
委任の形態: 規模や複雑性、PMのスキルに応じて、以下に委任可能。
- サプライヤー(外部委託)、個人、またはビジネス内の特定グループ。
- プロジェクト・オフィス (PMO): 組織として確立された支援部門。

独立性の維持(制約事項)

保証との分離: プロジェクト保証の客観的な独立性を維持するため、プロジェクト保証の役割を兼務することはできず、明確に分離されなければならない。

チーム・マネジャー

プロジェクト・マネジャーから「ワーク・パッケージ」として割り当てられた作業に対し、合意された制約内での実行と意思決定に責任を持つ役割。

成果物と作業の管理

成果物の提供: 合意された仕様に従い、品質・納期を満たした成果物を確実に作成・提供する。
チーム内制約の設定: チーム・メンバーが作業を遂行するにあたっての具体的な許容度と制約を定義する。
意思決定の統制: チーム内の判断が、PMのガイダンスやプロジェクト全体の許容度に沿っていることを保証する。

インターフェースと関係管理

多角的な連携:
- チーム内の人間関係の管理。
- 外部インターフェース(他チーム、プロジェクト・マネジャー、プロジェクト保証、プロジェクト支援)との円滑な関係構築。

チームの健全性と持続可能性

ウェルビーイングの支援: チーム・メンバーの安全と健康、精神的な安定をモニタリングし、サポートする。
アプローチの持続性: チームの作業手法が、プロジェクト全体や組織にとって持続可能なものであるかを確認する。

プロジェクト・エスシステム

組織のエスシステムの理解

プロジェクトは一時的な組織であるため、母体となる組織のエコシステムとどのように整合性を保つかを定義する必要がある。

責任を明確にすべき4つの主要領域
- 人的マネジメント
  
  プロジェクト・チームのパフォーマンス向上や意欲維持に関わる領域。
  - 内容: パフォーマンス・マネジメント、報酬、昇進、ウェルビーイングなど。
  - 重要点: 誰がメンバーの評価を行い、どのようにキャリア形成や福利厚生をサポートするかを定める。
- ガバナンス
  
  意思決定の枠組みと権限に関する領域。
  - 内容: どの決定がコーポレート・ガバナンスの対象となるか、またガバナンスの経路(報告・承認ルート)など。
  - 重要点: プロジェクト独自の決定権限と、組織全体のルールの境界線を明確にする。
- マネジメント・アプローチ
  
  実務の進め方やルールに関する領域。
  - 内容: 方針、手順、具体的な作業方法など。
  - 重要点: プロジェクトが組織標準のプロセスに従うのか、または独自のカスタマイズを適用するのかを定義する。
- 方法とタイミング(リソースの移行)
  
  プロジェクトの開始・終了時における人員の動きに関する領域。
  - 内容: プロジェクトの内外におけるチーム・メンバーの移行(アサインとリリース)。
  - 重要点: メンバーがいつプロジェクトに加わり、終了後にどの部署へ戻るのか、そのプロセスと時期を明確にする。

プロジェクト・エスシステムの設計

プロジェクト目標達成のために、「仕事」と「人」を最適に組織化するプロセスである。

前提条件
- 各ステージにおけるニーズとプロジェクトのコンテキスト(状況)。
- アサインされたメンバーのスキル、能力、キャパシティ。
主な要素
- チーム構造の決定: 効果的な成果を生むための体制の策定。
- リソースの特定: 必要な人材および物理的リソースの明確化。
- 作業プラクティスの統合: 統一された実務慣行の実施。
- カルチャーの構築: プロジェクト特有の振る舞いや文化の形成。
ステージごとの変遷と計画
- 動的なエスシステム: プロジェクトの規模、複雑性、デリバリー手法により、ステージごとにエスシステムの移転や変更が必要になる場合がある。
- 早期計画: これらは可能な限り立ち上げステージで特定・計画し、各段階に応じたプロジェクト・マネジメント・チームを確立する。
- 決定要因: WBS(ワーク・ブレークダウン・ストラクチャー)および商業マネジメント・アプローチに強く依存する。
実行責任と文書化
- 責任者: プロジェクト・エグゼクティブが実行責任を負い、プロジェクト・マネージャーがこれを支援する。
- 文書化: 設計内容はプロジェクト立ち上げ文書に記載しなければならない。
- 専門性: プロジェクト・エスシステムは一時的かつ流動的であるため、一般的なビジネス組織設計とは異なる専門知識が求められる。規模や複雑性に応じて、内部委任や外部スペシャリストへのアウトソーシングも検討される。

プロジェクト・エスシステムの開発

プロジェクト組織設計を具現化し、プロジェクトの進展や環境変化に合わせて適応・進化させるプロセスである。

目的と性質
- 継続的開発: 変化するニーズ、チームメンバーの入れ替わり、新しい人間関係に応じて、プロジェクト期間中絶えず行われる。
- 目標達成と改善: プロジェクトが目標を達成し、かつ継続的にパフォーマンスを向上させる状態を維持する。
主な開発活動
- オンボーディング: ユーザーやメンバーの受け入れ（サイト訪問、誘導、認定など）。
- スキル評価・監査: チーム全体のスキルや能力が十分かを定期的に確認する。
- トレーニング: 新しい手法の導入や、特定されたスキルのギャップを埋めるための教育。
- チームビルディング: 協力体制の強化と信頼関係の構築。
- カルチャーの維持: 特定のプロジェクト文化（価値観や行動指針）を確立し、浸透させる。
- 後継者育成計画: 完了前に離脱するメンバーがいる可能性を考慮し、業務の継続性を確保する。
- オフボーディング: 離脱時や終了時に、経験から教訓（Lessons Learned）を抽出・蓄積する。
実行責任
- 責任者: プロジェクト・エグゼクティブが実行責任を負い、プロジェクト・マネージャーが実務的な支援を行う。

プロジェクト・エスシステムへの継続的な変更の管理

プロジェクト・エスシステムは固定的なものではなく、状況の変化に応じて適切に管理・調整される必要がある。

関係構築とフィードバック・ループ
- 習熟時間の考慮: メンバーがプロジェクトに慣れ、能力を発揮し、人間関係を築くには一定の時間が必要である。
- ギャップの特定: 明確なフィードバック・ループ（振り返りや報告の仕組み）を確立し、以下の課題を早期に判断する。
  - スキルや能力の不足（能力ギャップ）
  - リソースの過不足（キャパシティ・ギャップ）
  - チーム内の人間関係における課題
構造と役割の見直し
- 定期的なレビュー: プロジェクト・マネジメント・チームの構成、および各メンバーの役割・責任（R&R）が現状に即しているかを適宜見直す。
- 整合性の確認: 構造の変更を提案する際は、それが既存の**商業マネジメント・アプローチ（契約条件や外注スキームなど）**でサポート可能かどうかを必ず確認する。

組織のエスシステムへのプロジェクトの移行

プロジェクトのクローズ時には、開始時と同様に、成果物やチームメンバーを組織のエスシステムへ適切に引き継ぐ必要がある。プロジェクト委員会（Project Board）が考慮すべき重要な側面は以下の3 点である。

成果物の移行 プロジェクトが生み出した成果物が、ビジネス側に確実に受け入れられるようにする。 * 所有権の明確化: さらなる開発、ベネフィットのモニタリング、運用、保守などの継続的な活動が、ビジネスの適切な部門によって所有（管理）される状態を保証する。 * 受入確認: すべての成果物がビジネス要件を満たし、運用可能な状態で引き渡される。
人（リソース）の移行 プロジェクトに従事したメンバーの事後処理を適切に行う。 * ビジネスへの復帰: プロジェクト専用にアサインされていた内部メンバーが、滞りなく元の業務や新しい役割に復帰できるように調整する。 * 外部リソースの管理: 外部サプライヤーについては、締結されている商業上の契約（取り決め）に基づき、契約終了やリソースの解放を適切に管理する。
学習（ナレッジ）の移行 プロジェクトを通じて得られた知見を組織の資産とする。 * 教訓の共有: 得られた知識や教訓を、組織全体で活用できる最も効果的な手段で共有する。 * スキルと能力の活用: プロジェクト活動を通じてメンバーが習得した新しいスキルや能力は、広範なビジネスや関連組織に利益をもたらす可能性があるため、これらを有効活用する視点を持つ。

支援技法

デリバリー・モデル

プロジェクトの目標達成に向けて、組織的・商業的な枠組み（リソース確保や外部委託の方針）を決定する仕組みである。

定義と決定要因
- 目的: 組織内に必要なキャパシティや能力が不足している場合、外部サプライヤーを導入して補完する。
- 決定基準: ユーザー、ビジネス、サプライヤーそれぞれの制約条件と能力を考慮し、「商業マネジメント・アプローチ」で説明される。
- 反映先: プロジェクト・マネジメント・チームの組織構成（体制図）に直接反映される。
クライアント・モデルのバリエーション デリバリー・モデルは、外部サプライヤーへの依存度によってシン（Thin）からシック（Thick）まで多岐にわたる。
- シン・クライアント・モデル (Thin Client):
  - 作業の大部分だけでなく、プロジェクト管理作業の多くも外部サプライヤーが実行する。
- シック・クライアント・モデル (Thick Client):
  - 作業の大部分をビジネス（自社）側で実行する。

契約形態による責任の所在

契約形態	実行責任	特徴
労力ベース	クライアント	投入された労働力に対して対価を払い、パフォーマンス責任はクライアントが負う。
成果物ベース	サプライヤー	特定の成果物の完成に対して責任を負う。

外部サプライヤー活用の判断要素
- 専門性の補完: プロジェクト委員会に技術的な理解が不足している場合、外部の専門知識を活用して意思決定やプロジェクト保証を強化する。
- リスクの割り当て: リスク管理能力が最も高い組織（自社またはサプライヤー）に対して、適切にリスクを割り当てられるモデルを選択すべきである。
- プロジェクトの独自性: 業務が組織にとってどれほどユニークかによっても、選択すべきモデルは影響を受ける。

RACIチャート

プロジェクトにおけるすべての活動や意思決定権限に対し、関係する個人や役割示しす。

各役割の定義

区分	名称	定義	ポイント
R	実行責任 (Responsible)	タスクを実際に実行する役割	複数人可
A	説明責任 (Accountable)	最終成果に責任を持ち、意思決定を行う役割	必ず1 人のみ
C	協議先 (Consulted)	必要な情報や専門知識を提供する役割	双方向コミュニケーション
I	情報先 (Informed)	進捗や結果の報告を受ける役割	一方向コミュニケーション

メリット
- オーナーシップの明確化: 誰が最終決定を下すのか（A）がひと目でわかる。
- デリバリー責任の所在: 誰が実際に作業を行うのか（R）が明確になる。
- チームワークの強化: 各自の役割が定義されることで、協力体制がスムーズになる。
- 混乱の軽減: 視覚的な形式により、役割の重複や「責任の空白（ギャップ）」を防ぐことができる。

マネジメント成果物

アウトプット

商業マネジメント・アプローチ(プロジェクト立ち上げ文書の一部)

目的: プロジェクト成功に不可欠な**商業的合意（市場開拓・調達・契約管理）**を、適切な手順・基準・責任のもとで確実に実行・維持するための方針を定める。
コンテンツ概要
- スコープ: 必要とされる商業的関係（ユーザー合意、サプライヤー契約など）の記述書
- デリバリー・モデル: 外部委託範囲（WBS 要素）を含む、作業提供形態の記述書
- リソース: 調達や契約管理に関わる人員・資金の割り当て
- 責任: 各商業活動（入札・交渉・管理）における役割と責任を定義
- 支援ツールと技法: 使用する入札システムや契約管理ツール
- 標準: 組織の調達方針や既存のフレームワークなど、準拠すべきルールの規定

プロジェクト・マネジメント・チーム組織(プロジェクト立ち上げ文書の一部)

目的: プロジェクトに関与する人員、相互の関係性、および協力体制を定義する。(チーム外の主要なステークホルダーとの関わりについても明確にする。)
コンテンツ概要
- プロジェクト構造: チーム構成と指揮系統（レポートライン）を示す組織図
- 権限と責任の概要:
  - 各マネジメント階層における意思決定権限と説明責任の定義
  - ガバナンス体制の構築
  - 勤務形態（対面・リモート）に応じた作業プラクティスの取り決め
- 支援情報: プロジェクトに影響を与える外部の主要人物や、補完的な関係性の記述

役割記述書(プロジェクト立ち上げ文書の一部)

目的: プロジェクト・マネジメント・チームにおける各メンバーの役割と具体的な責任範囲を明確に定義し、円滑な業務遂行を支援する。
コンテンツ概要
- 役割: 役職名またはロール名（例: プロジェクト・マネジャー、PMOなど）。
- 権限: 意思決定や承認を行うことができる具体的な権限範囲。
- 責任: その役割が遂行すべき具体的な業務・タスクのリスト。
- 説明責任先: 業務の進捗や結果を報告すべき上位の役割（レポートライン）。
- 支援情報: 従事形態（フルタイム／パートタイム）や、他ロールとの兼務状況に関する補足。

主要な役割

役割	責任
ビジネス・レイヤー	ビジネス・レイヤーの責任
プロジェクト・エグゼクティブ	プロジェクト・エグゼクティブの責任
シニア・ユーザー	シニア・ユーザーの責任
シニア・サプライヤー	シニア・サプライヤーの責任
プロジェクト・マネージャー	プロジェクト・マネージャーの責任
チーム・マネージャー	チーム・マネージャーの責任
プロジェクト保証	プロジェクト保証の責任
プロジェクト支援	プロジェクト支援の責任

ビジネス・レイヤーの責任

プロジェクト・エグゼクティブとプロジェクト・マネージャー（場合による）を任命する
ビジネスに必要なコミュニケーション標準を提供する
コミュニケーション・マネジメント・アプローチの定義に基づくプロジェクトに情報を提供する

プロジェクトエグゼクティブの責任

プロジェクト・マネージャーを任命する（ビジネスが任命しない場合）
プロジェクト・マネージャーと協力して、プロジェクトの組織設計を確認し、プロジェクト・マネジメント・チーム組織を承認する
プロジェクト・マネジメント・チームへの任命を確認する
商業マネジメント・アプローチ、コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチを承認する
プロジェクト・アプローチとデリバリー・モデルの選択をレビューおよび確認し、それらがビジネスのESG 目標に対応するようにする

シニアユーザーの責任

ユーザー・コミュニティの適切なレベルの人々が関与できるようにする
商業マネジメント・アプローチ、コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチに合意する
利害関係者分析に貢献する
ユーザー・コミュニティの人的側面、例えば、主要なインフルエンサーが誰であるかなどについて助言を行う

シニアサプライヤーの責任

サプライヤーのコミュニティの適切なレベルの人々が関与できるようにする
商業マネジメント・アプローチ（該当する場合）、コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチに合意する
サプライヤー・チームの人的側面（特定の健康、安全、ウェルビーイングの要件など）について助言を行う

プロジェクトマネージャーの責任

商業マネジメント・アプローチ、コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチを準備、更新する
プロジェクト・マネジメント・チーム組織とワーク・ブレークダウン・ストラクチャーを設計、レビュー、更新する
役割記述書を作成する
健全なプロジェクト・エコシステムを確立、維持し、プロジェクト・マネジメント・チームのウェルビーイングを確保する

チームマネージャーの責任

チーム・メンバーを管理する
チームのウェルビーイングを確保する
プロジェクトにおけるチーム・メンバーの選択について助言を行う
ワーク・パッケージ記述書で合意されたコミュニケーション・マネジメント手順、変更マネジメント手順、商業マネジメント手順を実施する

プロジェクト保証の責任

プロジェクト・チーム・メンバーの選択についてプロジェクト・マネージャーに助言を行う
コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチ、商業マネジメント・アプローチについてプロジェクト・マネージャーに助言を行う
コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチ、商業マネジメント・アプローチがビジネスの方針に準拠していることをプロジェクト委員会に確認する
コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチ、商業マネジメント・アプローチ（商業マネジメント手順の適切な実施など）の実施についてプロジェクト委員会に保証する

プロジェクト支援の責任

オンボーディングとオフボーディングに支援を提供する
利害関係者の分析に支援を提供する
コミュニケーション・マネジメント活動に支援を提供する
変更マネジメント活動に支援を提供する
商業マネジメント活動に支援を提供する

備考

複雑性

関係者の多様性(サブライヤーの複雑さ): 多くの利害関係者(ビジネス、ユーザー、サブライヤーなど)が関与し、それぞれ異なる期待や利害を持つこと。
関係性の複雑さ(相互依存): 人・組織・プロセス・成果物の間に多数の依存関係があり、変更が連鎖的な影響を与えること。
変化の多さ(不確実性): 要件、環境、技術、ビジネス条件などが継続的に変化すること。
組織構造の複雑さ: 複数の部門や外部組織が関与し、責任範囲や権限が分散していること。
コミュニケーションの複雑さ: 情報の伝達経路が多く、誤解や情報の遅延が発生しやすいこと。
技術的な複雑さ: 使用する技術やシステムが高度で、専門知識が必要であること。
リスクの多様性: 多くの不確実要因やリスクが存在し、それらが相互に影響し合うこと。

絶え間なく変化する関係を構築していく複雑なエコシステムでは、成功させるために、この複雑性(関係者の多様性、関係性の複雑さ、組織構造の複雑さ　など)を乗り切るための効果的なプロジェクト・マネジメント・チーム組織を確立することが不可欠である。プロジェクトのニーズに応じて、一定の制約の中で複数の人で役割を共有、または1 人が複数の役割を兼務する場合があるが、責任は必す割り当てておく必要がある。

ワーク・ブレークダウン・ストラクチャー(WBS)

プロジェクト全体のスコープを、管理しやすい小さな単位まで「成果物指向」で階層的に分解した構造図である。

主な構成要素と関係
- 最上位: プロジェクト全体(最終成果物)
- 中間層: 主要な成果物やフェーズ(例: 要件定義書、設計書、システム本体など)
- 最下層: ワークパッケージ(これ以上分解できない最小の管理単位)
成果物ブレークダウン・ストラクチャー(Deliverable Breakdown Structure)との関係
- WBSは成果物を中心に作業を分解するため、成果物ブレークダウン・ストラクチャーと強く結びついている。
- 成果物とワークパッケージの間に明確なリンクを作成することで、プロジェクト・チームの構成方法やチーム間の境界を決めやすくなる。
ポイント
- 100%ルール: WBSに記載された作業の合計がプロジェクトの全作業(100%)になるようにする。記載がない作業はスコープ外です。これにより抜け漏れや責任の曖昧さを防ぐ。
- ワークパッケージの推奨粒度: 通常、8 時間〜80 時間程度の作業量で管理できるレベルまで分解。担当者・スケジュール・コストの見積もりが明確になるサイズが理想。
- 内部・外部チームの混在を避ける:
  - 内部合意と外部契約では性質・関係性が根本的に異なるため、別々に管理した方がリスクコントロールや進捗管理がしやすくなる。
メリット
- プロジェクトのスコープを可視化し、作業の抜け漏れを防止
- 正確なスケジュール作成、コスト見積もり、進捗管理が可能になる
- チーム間の責任範囲を明確にし、コミュニケーションをスムーズにする
- 変更管理のベースラインとして活用できる