プロジェクト構造の世界へようこそ！
こんにちは！CIMA E2シラバスの中でも非常に重要な「プロジェクト構造（Project Structure）」の学習を始めましょう。プロジェクトを「家を建てること」に例えてみてください。いきなりレンガを積み始めることはしませんよね？建築家、現場監督、そして専門家グループが必要です。ビジネスにおいても、成功のためには適切な「人員構造」が不可欠です。役割が明確でなければプロジェクトは失敗します。このノートを読み終える頃には、誰が何をすべきか、そして企業がどのようにプロジェクトチームを組織しているのかが完全に理解できるようになっているはずです。
最初は少し「堅苦しい」と感じるかもしれませんが、大丈夫です！わかりやすい例えを使って、しっかり頭に残るように解説しますね。
1. プロジェクトにおける主要な役割
すべてのプロジェクトには明確な階層が必要です。それがなければ、誰に助けを求めればよいのか、誰が予算に責任を持つのかが分からなくなってしまいます。4人の主要なプレイヤーを見ていきましょう。
A. プロジェクト・スポンサー（「オーナー」）
プロジェクト・スポンサーは通常、ビジネスの観点からプロジェクトを「所有」する上級管理職です。日々の作業を行うわけではありませんが、最終的な成果を求めている張本人です。
主な仕事：
- 資金とリソースの提供。
- プロジェクト全体の目標の定義。
- 究極の意思決定（GO/NO-GO判断）を行うこと。
- 取締役会レベルでプロジェクトを後押しする「擁護者」としての役割。
B. プロジェクト運営委員会 / プロジェクト・ボード（「最高評議会」）
これを「最高評議会」だと考えてください。スポンサー、シニアユーザー（最終製品の利用者）、シニアサプライヤーで構成されます。彼らの仕事は、戦略的なガイダンスを提供し、監視することです。
C. プロジェクト・マネージャー（「指揮者」）
プロジェクト・マネージャー（PM）は現場の責任者です。スポンサーが家のオーナーなら、PMは現場監督です。彼らはプロジェクトが予定通り、予算内で、計画通りに進むように管理します。
クイックレビュー：スポンサーが「金」を提供し、プロジェクト・マネージャーが「管理」を提供します。
D. プロジェクト・チーム（「実行者」）
実際にプロジェクトのタスクを実行するエンジニア、会計士、ITスタッフなどの専門家です。彼らはプロジェクト期間中、プロジェクト・マネージャーの指揮下に入ります。
よくある間違い：プロジェクト・スポンサーとプロジェクト・マネージャーを混同してはいけません！スポンサーは「顧客」や「投資家」であり、マネージャーは遂行に責任を負う「雇用されたリーダー」です。
まとめ：役割が明確であれば責任の所在もはっきりします。スポンサーが資金を出し、ボードが導き、マネージャーが実行し、チームが作り上げます。
2. プロジェクト組織構造のタイプ
プロジェクトが企業内でどのように位置づけられるかは、その企業の組織のあり方によって決まります。主に3つの方法があります。
A. 機能別構造（「サイロ型」アプローチ）
この構造では、プロジェクトは既存の部門（財務、人事、マーケティングなど）の中で管理されます。専任のプロジェクトチームは存在しません。
例え：クリスマスのパーティーを企画しようとしているのに、通常の業務をこなしながら、昼休みにデスクで準備をしなければならない状況を想像してみてください。
メリット：新しいスタッフのための追加コストがかからない。専門家が自分の部門に留まれる。
コンディション：「通常業務（BAU）」が優先されるため、プロジェクト業務が放置されがちになる。
B. プロジェクト専門組織（純粋プロジェクト型）
ここでは、プロジェクトが独立した事業体として扱われます。メンバーは元の部門から引き抜かれ、プロジェクトに100%専念します。
メリット：圧倒的な集中力。プロジェクト・マネージャーが全権限を持つ。
デメリット：コストがかかる。プロジェクト終了後に戻るべき場所がない場合がある（これを「プロジェクトの孤立」と呼びます）。
C. マトリックス構造（ハイブリッド型）
CIMAシラバスで最も一般的な構造です。スタッフは機能別マネージャー（通常の上司）とプロジェクト・マネージャー（一時的なプロジェクトの上司）という2人のボスに報告します。
暗記のヒント：「2人のボスの悩み」。試験問題で「2人の上司」という言葉が出てきたら、マトリックス構造を疑いましょう！
メリット：柔軟性がある。専門家がプロジェクト間で知識を共有できる。
デメリット：対立が起きる。両方の上司から異なる期限を指示された場合、従業員は誰に従えばよいのでしょうか？
知っていましたか？マトリックス構造は、管理が難しい一方で、専門家を効率的に活用できるため多くの企業で採用されています。
重要なポイント：小さな部門内の変更には機能別構造、大規模で単発の構築にはプロジェクト専門組織、異なる専門家を必要とする複雑なプロジェクトにはマトリックス構造を使い分けます。
3. プロジェクト立ち上げ文書（PID: Project Initiation Document）
PIDはプロジェクトの「契約書」のようなものです。先に説明した構造を定義するもので、プロジェクト開始前に承認される必要があります。
PIDに含まれる内容：
1. ビジネスケース：なぜこれを行うのか？（例：年間 \( \$500,000 \) のコスト削減のため）。
2. スコープ：何が含まれ、さらに重要なこととして、何が含まれないのか？
3. プロジェクト組織：スポンサー、PM、チームメンバーは誰か？
4. リスクログ：何がうまくいかなくなる可能性があるか？
PIDはプロジェクトの「北極星」だと考えてください。プロジェクトの方向性について議論になったときは、いつでもPIDに立ち返るのです。
クイックレビューボックス：
- スポンサー：リソースと高レベルな支援を提供。
- PM：日々の計画とコントロールを担当。
- 機能別構造：安定性は高いが、プロジェクトへの注力度は低い。
- マトリックス構造：リソース共有が可能だが、上司同士の対立の可能性がある。
- PID：すべてを定義する基礎文書。
まとめと最後のヒント
E2でプロジェクト構造を学習するときは、常に自分自身にこう問いかけてください。「誰に権限があるのか？」
機能別構造では部門マネージャーが権限を持ちます。プロジェクト専門組織ではプロジェクト・マネージャーが持ちます。マトリックス構造では権限が分散されます（だからこそ複雑になるのです！）。
試験対策ヒント：「優先順位の対立」や「スタッフが二方向に引っ張られているように感じる」といった記述があれば、その回答はほぼ間違いなくマトリックス構造に関連しています。
頑張ってください！順調ですよ。プロジェクト管理の本質は「人」と「組織」にあります。これらの構造さえマスターすれば、このセクションの残りの部分は自然と頭に入ってくるはずです。