プロジェクト・マネジメント-プロジェクトの始動 | 差配 / PRINCE2 / 講究

プロジェクトの始動

プロジェクトの始動プロセスの目的は、「このプロジェクトは実行可能で、利益をもたらすものか」という問いに答えることによって、プロジェクトの立ち上げのための必須条件が確立されていることを確認すること。

本格的な立ち上げの前に、必須条件が整っているかを確認するゲートキーパーの役割を果たす。

合理的な判断：十分に吟味されていないアイデアの立ち上げを防ぐ
効率性：詳細かつ綿密なプロジェクトの立ち上げプロセスに比べ、最低限の活動で価値を判断する簡略的なプロセス
基盤整備：役割と責任を割り当て、詳細な計画立案のための基盤を整えるまでは、いかなる作業も開始すべきではない

達成目標

以下の点を確認・確立することを目指す。

プロジェクトを立ち上げるビジネス正当性があること(ビジネス・ケース概要で文書化)
プロジェクトを開始するために必要な権限がすべて存在すること(人のアサインやリソースの確保)
プロジェクト・スコープを定義・確認するために十分な情報が(プロジェクト要約書の形式で)用意されていること
代替のアプローチが評価され、選択されたプロジェクト・アプローチが合意されていること
立ち上げステージに必要な作業を行う者・プロジェクト中にプロジェクト・マネジメントの重要な役割を担う者のいずれかが任命されていること
立ち上げステージに必要な作業計画が策定されていること(ステージ計画書で文書化)
プロジェクト・スコープ・期間・受け入れ基準・制約条件について曖昧な前提に基づかないこと

位置付け

トリガー：プロジェクト権限委任

プロジェクトが正式に開始される前のトリガーをプロジェクト権限委任と呼ぶ。

提供元：ビジネス・レイヤー(プロジェクト外部)の責任権限者(エグゼクティブ・グループ・プログラム・ポートフォリオ・顧客など)から提供される
内容：実行可能性調査・提案依頼書など、形態はさまざまである
最低限の情報：少なくとも、プロジェクト・エグゼクティブ候補を特定できるだけの情報が必要
展開：この権限委任の情報が詳細化され、プロジェクト要約書へとまとめられる

実施のポイント

反復的な作業：ビジネス・ケース概要の準備とプロジェクト要約書の作成は、並行かつ反復的に行う
頻繁なコミュニケーション：PMとプロジェクト委員会などの利害関係者間で、密なやり取りが必要
プログラムとの関連：プロジェクトがプログラムの一部である場合、多くの作業(要約書の提供やメンバー任命)がプログラム側で行われ、本プロセスの作業は大半が省かれる
先行投資のメリット：この段階で要件を明確に把握しておくことで、後のデリバリーにおける課題・例外・計画見直しを避け、大幅な時間を節約できる

主要なアウトプット

アウトプット	内容
プロジェクト要約書	プロジェクトの定義・アプローチ・役割などをまとめた文書
ビジネス・ケース概要	プロジェクトの正当性を示す根拠
ステージ計画書(立ち上げステージ用)	次のステップである立ち上げステージで何を行うかを定義した計画

活動

インプット	活動	アウトプット
プロジェクト権限委任(トリガー)、前回の教訓報告書(レビュー)	① プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命	デイリー・ログ(作成)
プロジェクト権限委任(トリガー)、前回の教訓報告書(レビュー)	② 前回の教訓の評価	教訓ログ(作成)
プロジェクト権限委任(トリガー)、前回の教訓報告書(レビュー)	③ ビジネス・ケース概要の準備	プロジェクト成果物記述書(作成)、ビジネス・ケース概要(作成)
プロジェクト権限委任(トリガー)、前回の教訓報告書(レビュー)	④ プロジェクト・マネジメント・チームの任命	プロジェクト要約書(作成)
プロジェクト権限委任(トリガー)、前回の教訓報告書(レビュー)	⑤ プロジェクト・アプローチの選択	プロジェクト要約書(作成)
プロジェクト権限委任(トリガー)、前回の教訓報告書(レビュー)	⑥ プロジェクト要約書のとりまとめ	プロジェクト要約書(作成)
プロジェクト権限委任(トリガー)、前回の教訓報告書(レビュー)	⑦ 立ち上げステージの計画	ステージ計画書(立ち上げステージ用に作成)
プロジェクト権限委任(トリガー)、前回の教訓報告書(レビュー)	⑧ プロジェクトの立ち上げ要求	プロジェクト立ち上げの要求(指揮プロセスをトリガー)

各活動の詳細

① プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命

プロジェクトを推進するためには、意思決定権を持つ責任者と、日々の管理を担う実務責任者を早期に確立する。

役割

プロジェクト・エグゼクティブ：ビジネス側の各利害関係者の関心を代表し、プロジェクトの正当性を確保する役割を担う。エグゼクティブの任命は、プロジェクトを開始する上での必須条件である
プロジェクト・マネージャー(PM)：エグゼクティブに代わり、日々のプロジェクト運営を管理する。PMを任命することで、マネジメント業務が具体的に動き出す

推奨される処置

プロジェクト権限委任のレビュー(ビジネス)

ビジネス側が内容を確認し、不明点や曖昧な箇所を明確にする

プロジェクト・エグゼクティブの特定と任命(ビジネス)

適切な権限を持つ人物を選択し、正式に任命する

PMの特定と任命(プロジェクト・エグゼクティブ)

エグゼクティブが実務を任せるPMを選択し、任命する(必要に応じてビジネス側と協議し合意を得る)

デイリー・ログの作成(PM)

PMはプロジェクト情報の最初のリポジトリ(保管場所)としてデイリー・ログを作成し、記録を開始する

② 前回の教訓の評価

過去のプロジェクト(組織内・外を問わず)から得られた知見を、今回のプロジェクトの基盤構築に反映させる。

教訓の内容と活用範囲

教訓の対象：プロセスの強み・弱み、使用された手順・技法・ツール、それらの使用タイミングや方法、関与した人員などが含まれる
活用の場：以下の策定において、過去の教訓を反映させる
- プロジェクト・マネジメント・チームの編成
- ビジネス・ケース概要
- プロジェクト要約書
- 立ち上げステージのステージ計画書

知見を把握する手段

ワークショップの開催：関係者や類似プロジェクトの経験者を集めて議論する
外部知見の活用：組織内に類似の経験がない場合は、外部の専門家や経験者を含めることも検討する

PMに推奨される処置

関連教訓のレビュー：類似プロジェクトの監査結果やレビュー報告書を確認し、適用可能な教訓を特定する
ヒアリングの実施：類似プロジェクトに関わった個人やチームと直接対話する
教訓ログの作成：特定した教訓と、それに対する具体的な措置を記録するための教訓ログを作成する

③ ビジネス・ケース概要の準備

この段階では情報が限られているため、ビジネス・ケースは詳細なものではなく、あくまで全体像を示す「概要」に留める。

立ち上げプロセスで詳細なビジネス・ケースを策定する際の合意形成の基盤となる。

推奨される処置

ビジネス・ケース概要の作成(プロジェクト・エグゼクティブ)

プロジェクト権限委任と最新情報に基づき作成する
シニア・ユーザーが任命されている場合は協議を行い、プロジェクトがどのようにビジネス目標に貢献するのかを明確にする

成果物の定義(PM)

プロジェクト・エグゼクティブ・シニア・ユーザー・シニア・サプライヤーと協議し、プロジェクトが提供すべき成果物を定義する
プロジェクト成果物記述書としてまとめる

主要リスクの特定(PM)

デイリー・ログに記録されたリスクを再確認する
プロジェクトの継続・実行可能性に重大な影響を及ぼす主要リスクを抽出し、ビジネス・ケース概要に反映させる

④ プロジェクト・マネジメント・チームの任命

プロジェクトにおいて迅速な意思決定を行うためには、適切な権限・責任・知識を持つ人員を配置し、体制を明確にすることが不可欠である。

チーム編成の基本原則

利益の反映：ビジネス・ユーザー・サプライヤーという「3つの利益」を代表する関係者が含まれる
協力体制：権限や知識だけでなく、関係者が協力してパフォーマンスの高いチームを形成できること
責任と系統の明確化：誰が誰に対して説明責任を負い、誰が何の実行責任を負うのか、また報告・コミュニケーション系統について全員が合意していなければならない

推奨される処置

組織設計と役割の定義(PM)

教訓ログを確認し、過去の知見を活かした組織設計を行う
各メンバーの役割記述書を準備し、責任範囲を明確にする

チームの特定と任命(プロジェクト・エグゼクティブ)

シニア・ユーザーおよびPMと協議し、最適なメンバーを特定・選択した上で正式に任命する

作業基盤の合意とリスク管理(PM)

立ち上げステージにおけるチームの作業ルール(プラクティス)やコミュニケーション方法について合意を形成する
この過程で特定されたリスクは、速やかにプロジェクト・ログに追加する

⑤ プロジェクト・アプローチの選択

計画立案を立てる前に、プロジェクトを「どのように進めるか」という戦略的な方向性を決定する。

この選択は、後のマネジメント・アプローチや進捗管理の基盤となる。

検討すべき主要な疑問

疑問	選択肢
デリバリー・モデル	ソリューション開発を自社で行うか、外部へ委託するか
構築方法	既存の成果物を修正・再利用するか、完全にゼロから構築するか
製品の性質	既製品(オフザシェルフ)をベースにするか、特注(フルスクラッチ)とするか
デリバリー手法	アジャイルなどの「反復的・段階的」な方法を用いるか、ウォーターフォールのような「直線的・連続的」な方法を用いるか
持続可能性	選択したアプローチが、持続可能性に関する期待や要件をどのように支援・実現するか

基準と理解の共有

業務の実施方法は、ユーザーやサプライヤーが持つ標準・プラクティス・ガイドラインに強く影響される。

これらの基準は、プロジェクト要約書の一部として明文化する
ユーザーとサプライヤーがプロジェクト・アプローチを共通認識として持つことで、予期せぬ誤解がプロジェクトを脅かすリスクを防ぐ

PMに推奨される処置

最適なアプローチの判断：デリバリー案を評価し、成果物の提供とビジネス・ケースの実現にとって最も効果的なアプローチを決定する
テーラリングの定義：現時点で判明している範囲で、標準的な管理手法をどのようにプロジェクトの規模や状況に合わせてテーラリングするかを定義する
リスク管理：検討過程で判明した新たな課題やリスクを、速やかにプロジェクト・ログに記録する

⑥ プロジェクト要約書のとりまとめ

関係者全員が共通の理解を持ち、プロジェクトの開始点を明確に定義できる。

PMに推奨される処置

プロジェクト要約書を完成させるために、PMは以下の項目を確認・整理し、文書化する。

項目	内容
現状と背景の確認	プロジェクトの背景や、これまでに実施された準備作業などの現在のステータスを確認する
目標と成果の定義	達成すべき目標と、最終的に望まれる成果を明確にする
範囲と限界の設定	スコープ(範囲)・除外項目(範囲外)・プロジェクト許容度(トレランス)を確認する
前提と制約の特定	プロジェクトを縛る制約条件や、成立の前提となる条件を特定する
関係者の特定と組織のレビュー	ユーザーを含む既知の関係者を特定し、プロジェクト・マネジメント・チームの組織と役割記述書をレビューする
依存関係の把握	他のプロジェクトや進行中の活動との相互影響(依存関係)を特定する
文書化とリスク管理	以上の情報をプロジェクト要約書として集約・文書化し、新たな課題やリスクをプロジェクト・ログへ記録する

⑦ 立ち上げステージの計画

プロジェクトの立ち上げには相応の時間とリソースが必要である。無計画な開始を避け、整理された状態で進めるために、このステージの作業内容を計画し、承認を得る必要がある。

計画立案の意義

秩序ある開始：狙いが不明確で整理されていない状態での立ち上げを防ぐ
プログラムとの整合性：プロジェクトがプログラムの一部である場合、立ち上げステージの終了日をプログラム計画と照合し、要件に矛盾がないか確認する
プロセスの適用：プロジェクトによっては、立ち上げステージ内であってもステージのコントロールや成果物デリバリーのマネジメントプロセスを適用し、厳密に管理する場合がある

PMに推奨される処置

マネジメント・コントロールの決定

採用したプロジェクト・アプローチに基づき、立ち上げステージの活動に適したコントロールを決定する

ステージ計画書の作成

時間とコストの制約条件を特定し、適切な原則と技法を用いて立ち上げステージのためのステージ計画書を作成する

リスクの評価とログの更新

プロジェクト・ログに記録されたリスクをレビューし、立ち上げステージの計画に対するインパクトを評価する
新たなリスクの特定や既存リスクの変化があった場合は、速やかにログを更新する

⑧ プロジェクトの立ち上げ要求

プロジェクトの始動プロセスを締めくくり、次なるプロジェクトの立ち上げフェーズへ進むための正式な手続きである。

プロジェクト委員会への報告

PMは、これまでに作成した成果物を基に、プロジェクト委員会に対してプロジェクトの立ち上げを要求する。

正当性の提示：ビジネス・ケース概要とプロジェクト要約書を提示し、プロジェクトを開始するに足る合理的な理由を説明する

PMに推奨される処置

重要事項の説明：以下の項目についてプロジェクト委員会に詳細を説明し、理解を得る

ビジネス・ケース概要：プロジェクトの投資対効果と正当性
プロジェクト成果物：何を完成させるのか
プロジェクト・アプローチ：どのように進めるのか
プロジェクト・マネジメント・チームの任命：誰が責任を負うのか
立ち上げステージの活動とコントロール：次のステージで何を行い、どう管理するか

権限とリソースの正式要求：必要な人員の確保やリソースの割り当てを確定させるため、プロジェクトを正式に開始する権限をプロジェクト委員会に要求する

プロセスの適用

一般的な考慮事項

プロセスの実行にあたっては、形式に縛られず、本質的な「プロジェクトの正当性」の確保に注力する。

活動の柔軟な運用：始動プロセスの各活動は、状況に応じて結合・分割・同時実行が可能である。ただし、プロジェクトの立ち上げ要求を行う際には、プロジェクトの指揮プロセスとの連携が完全(必要な情報が揃っている)よう配慮しなければならない
不確実性への対処：プロジェクト初期段階では、アウトプット(成果物)が明確でない場合も多い。その場合でも、少なくともどのビジネス上の問題を解決するのか、またはどのような成果を求めているのかを明確に定義しておく
関係者との共創：ビジネス・ケース概要・プロジェクト要約書・立ち上げステージ計画書などは、PMが一人で作成するのではなく、将来のユーザーや利害関係者と共に作り上げることで、提案内容への理解と賛同(バイイン)を深めることができる

役割のテーラリング

役割の割り当ては、組織の体制に合わせて柔軟に変更できるが、説明責任の所在は曖昧にしてはならない。

PM 任命のタイミング：初期段階でのPM 任命がベストプラクティスである
代行の許容：プロセスの後半までPMが任命されていない場合は、プロジェクト・エグゼクティブ(またはその指名者)がマネジメント成果物を作成しても構わない
実行の委任と説明責任：プロジェクト・エグゼクティブはビジネス・ケース概要の作成を自ら行う必要はなく、他者に依頼(委任)できる。ただし、内容に対する最終的な説明責任は、常に各役割の本来の責任者に一元化されていなければならない

責任

活動	ビジネス・レイヤー	プロジェクト・エグゼクティブ	シニア・ユーザー	シニア・サプライヤー	プロジェクト・マネージャー	チーム・マネージャー	プロジェクト保証	プロジェクト支援
①プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命	A/R¹	R
②前回の教訓の評価	C	A			R
③ビジネス・ケース概要の準備	C	A/R	C³	C³	R
④プロジェクト・マネジメント・チームの任命	A	R
⑤プロジェクト・アプローチの選択		A	C	C	R	C²	C
⑥プロジェクト要約書のとりまとめ		A	C	C	R		C	C
⑦立ち上げステージの計画		A	C	C	R	I²	C	C
⑧プロジェクトの立ち上げ要求		A	C	C	R	I²	C	I

R = 実行責任、A = 説明責任、C = 協議先、I = 情報先

A/R¹：ビジネスは、プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命に説明責任を負う。また、ビジネスはプロジェクト・エグゼクティブを任命する実行責任がある
C²/I²：プロジェクト・マネジメント・チームを設計および任命するときにチーム・マネージャーが特定された場合、チーム・マネージャーがそのステージに関与しているのであれば、プロジェクト・アプローチについて協議し、立ち上げステージのステージ計画書の重要な詳細を通知することがグッド・プラクティスである
C³：任命された場合

プロセスへのプラクティスの適用

プラクティス	プロジェクトの始動プロセスへの適用
ビジネス・ケース	プロジェクト権限委任や教訓・関係者との協議に基づき、ビジネス・ケース概要(アウトライン)を作成。プロジェクト要約書の一部となる
組織化	プロジェクト・エグゼクティブとPMを任命し、必要なチーム組織を設計。立ち上げに必要な役割に人員を割り当てる
計画	主要マイルストーンを要約書に含める。プロジェクト・アプローチ(デリバリー手法等)を決定し、立ち上げステージ専用の計画書(期間・コスト・作業内容)を作成する
品質	ユーザーの期待品質や既知の標準をプロジェクト成果物記述書に記録。これらは後のプロセスで段階的に精緻化される
リスク	判明している上位レベルのリスクを特定し、プロジェクト要約書に組み込む
課題	判明している上位レベルの課題を特定し、プロジェクト要約書に組み込む
進捗	プロジェクト全体の暫定的な許容度を特定。また、立ち上げステージ自体の許容度をステージ計画書に設定する

他フレームワーク補足

概念	PRINCE2	PMBOK	PgMP
プロセスの位置付け	プロジェクトの始動(SU)	プロジェクト憲章の作成	(今後追記)
プロジェクト開始のトリガー	プロジェクト権限委任	プロジェクト憲章	(今後追記)
初期文書	プロジェクト要約書	プロジェクト憲章	(今後追記)
ビジネス正当性	ビジネス・ケース概要	ビジネス・ケース	(今後追記)