プロジェクトマネジメント - ビジネス・ケース

• 大事をなさんと欲せば、小なる事を怠（おこた）らず勤（いそ）しむべし、小積（こづも）りて大となればなり
  

# プロジェクト成功のためのマネジメント手法ービジネスケース

# はじめに

# プロジェクト

合意されたビジネス・ケースに基づき、一定期間内に 1 つまたは複数のビジネス成果物を提供するために実施される業務である。

# 特徴

• 変更：プロジェクトは変更をもたらすための手段である。
• 一時的：プロジェクトは本質的に一時的なものである。
• 機能横断的：プロジェクトでは、さまざまなスキルを持つ人々がチームとして一時的に連携していく必要があり、組織内の通常の機能別部門の垣根 (かきね) を越えた作業が多く、時には外部の組織にまで広がることもある。プロジェクトに関与する関係者は、それぞれが異なる観点や動機を持っている。
• 独自性：どのプロジェクトも同じではない。(同じもの一つもない)
• 不確実性：プロジェクトでは、一般的に、通常業務を行う場合よりも脅威にさらされ、機会が生まれることが多くなる。

# プロジェクト・マネジメント

プロジェクトが目標を達成できるように、手法、ツール、技法、コンピテンシーを適用することである。

# 課題

• プロジェクトのどの側面に誰が実行責任を負うかが曖昧であり、混乱と説明責任の欠如 (けつじょ) が発生する。
• プロジェクトの提供物、コスト、時期に対して非現実的な期待を抱く。
• プロジェクト作業の労力、期間、コストの見積もりが困難である。
• コントロールされない変更（スコープ・クリープとも呼ばれる)。
• プロジェクト・ライフサイクルにおいて、プロジェクト・マネジメント・チームと利害関係者への通知、エンゲージメント、モチベーションの維持が困難になる。

プロジェクト・マネジメントの目的は、曖昧さを減らしたり管理したりすることより、これらの課題に対処することである。これは、関係者を結束させ、達成目標と作業プラクティスを明確にすることによって達成される。狙い (ねらい) はプロジェクトに必要な成果物を作成するために必要とされる専門的な作業をコントロールすることである。
プロジェクト・マネジメントには、プロジェクトのあらゆる側面を計画立案、委任、モニタリング、コントロールすることと、関係者への動機付けが含まれる。それにより期待されるパフォーマンス最終目標内でプロジェクト目標が達成される。

# パフォーマンス最終目標

期待される成功レベルが設定され、それに対してプロジェクトのマネジメントが判断される。

• ベネフィット：プロジェクトに関与する人々は、「なぜプロジェクトを実行するのか、誰のためにプロジェクトを実行するか」という質問に答えられる必要がある。プロジェクト・マネジメント・チームは、プロジェクトの目的と達成すべきことを明確に理解し、その投資を正当化する必要がある。
• コスト：プロジェクト開発が進行するにつれて、利用可能なコスト予算に影響を与える可能性のある要因や、コス卜予算に対する（潜在的な）支出不足または支出超過につながる可能性のある多くの要因が発生する。
• 時間：プロジェクトはいつ開始され、主な成果物はいつ提供され、プロジェクトはいつ終了する。
• 品質：プロジェクトが期限どおり、かつ予算内で終了したとしても、その結果が仕様どおりでなく満足できるものでなければ意味がない。プロジェクトで提供するものは、目的に適合している必要がある。
• スコープ：プロジェクトは何を提供するか？プロジェクトのスコープについての合意がなければ、何が含まれ、何が除外されるかについて、さまざまな関係者が異なる前提条件を持つ可能性がある。プロジェクト・マネジメント・チームはスコープ外の成果物を提供しないようにする。それは、遅延や過剰なコストの発生、コントロールされない変更（スコープ・クリープとも呼ばれる）の原因になることがよくあるためである。
• 持続可能性：すベてのプロジェクトは環境にインパクトを与えるため、プロジェクト・マネジメン・チームは、プロジェクト作業とプロジェクトに必要な成果物の持続可能性パフォーマンス最終目標を把握する必要がある。
• リスク：すべてのプロジェクトにはリスクが伴う (ともなう)。しかし、具体的にビジネスはどの程度のリスクを覚悟しているでしょうか？ビジネスのリスク選好度についての共通の理解がなければ、プロジェクト・マネジメント・チームはリスク回避的すぎたり、ビジネスが受け入れる準備ができている以上のリスクを負ったりする可能性がある。

プロジェクトのパフォーマンス最終目標に合意することによって、優先度付けを確立できる。
パフォーマンス最終目標には、許容度が狭いものもあれば、許容度が広いものもある。パフォーマンス最終目標とその許容度の合意は、オプションを検討し、プロジェクト・アプローチを決定するための前提条件である。

# プロジェクト環境

プロジェクトは、価値の実現にさまざまな影響を与える内外の環境の中に存在し運営される。内外の環境は、計画とその他のプロジェクト活動に影響を与える。これらの影響は、プロジェクトの特性、ステークホルダー、またはプロジェクト・チームに、好ましい影響、好ましくない影響、または中立的な影響を与える。

# 内部環境

組織内部の要因は、組織自体、ポートフォリオ、プログラム、別のプロジェクト、またはこれらの組み合わせに由来する。これには、作成物、実務慣行、または内部の知識が含まれる。知識には、以前のプロジェクトからの教訓に加え、完成した作成物が含まれる。知識の例には以下のものが含まれるが、これらに限定されるものではない。

• プロセス資産：プロセス資産には、ツール、方法論、アプローチ、テンプレート、フレームワーク、パターン、または PMO の資源が含まれることがある。
• ガバナンス文書：方針とプロセスが含まれる。
• データ資産：データ資産には、データベース、文書ライブラリー、メトリックス、データ、および以前のプロジェクトの作成物が含まれることがある。
• 知識資産：知識資産には、プロジェクト・チーム・メンバー、当該分野専門家、およびその他の従業員が共有する暗黙知が含まれる。
• セキュリティと安全：セキュリティと安全対策には、施設へのアクセス、データ保護、機密性のレベル、独占している秘密事項に関する手続きと実務慣行が含まれる。
• 組織の文化、構造、ガバナンス：組織のこれらの側面には、ビジョン、ミッション、価値、信条、文化的規範、リーダーシップ・スタイル、階層と権限の関係、組織のスタイル、倫理、および行動規範が含まれる。
• 施設や資源の地理的分布：これらの資源には、職場、バーチャル・プロジェクト・チーム、共有システムが含まれる。
• インフラストラクチャー：インフラストラクチャーには、既存の施設、機器、組織チャネルと通信チャネル、情報技術ハードウェア、可用性、およびキャパシティが含まれる。
• 情報技術ソフトウェア：たとえば、スケジューリング・ソフトウェア、コンフィギュレーション・マネジメント・システム、オンライン自動化システムへのウェブ・インターフェイス、コラボレーション・ツール、および作業認可システムが含まれる。
• 資源の可用性：たとえば、契約および購買の制約条件、承認されたプロバイダーおよびサブコントラクター、提携合意が含まれる。人員と資源の両方に関する可用性には、契約および購買の制約条件、承認されたプロバイダーおよびサブコントラクター、スケジュールが含まれる。
• 従業員の能力：たとえば、一般的な知識や専門知識、スキル、コンピテンシー、技法、知識が含まれる。

# 外部環境

組織の外部要因は、プロジェクトの成果を強化したり、抑制したり、中立的な影響を与えたりしうる。例には以下のものが含まれるが、これらに限定されるものではない。

• 市場 (しじょう) の状況：市場の状況には、競合他社、市場シェア、ブランド認知、技術動向、商標が含まれる。
• 社会的、文化的な影響と事柄：これらの要素には、政治情勢、地域の習慣と伝統、祝日やイベント、行動規範、倫理、および認知が含まれる。
• 規制環境：規制環境には、セキュリティ、データ保護、業務遂行、雇用、ライセンス付与 (ふよ)、および調達に関する国・地域の法律と規制が含まれる。
• 商用データベース：このデータベースには、標準化されたコスト見積りデータと業界のリスク調査情報が含まれる。
• 学術調査：この調査には、業界調査、出版物、およびベンチマーキングの結果が含まれる。
• 業界標準：この標準は、プロダクト、製造、環境、品質、技能に関係する。
• 財務上の考慮事項：この考慮事項には、外国為替 (かわせ) レート、金利、インフレ、税金、関税が含まれる。
• 物理的環境：物理的環境は、作業条件と気候に関係する。

# 原則

過去の成功・失敗したプロジェクトから得られた教訓を基に、プロジェクト関係者が意思決定および問題解決を行う際の体系的な指針を提供する。

# ビジネス正当性の継続の確保

プロジェクトを継続するためには、開始から完了まで一貫したビジネス正当性が不可欠である。(ビジネス正当性がなければプロジェクトを中止するべきである。)

• プロジェクトを開始するためには、明確かつ正当な理由が必要である。また、そのビジネス正当性は、プロジェクト開始時点だけでなく、プロジェクトのライフサイクル全体を通じて有効であり続ける必要があり、継続的に再検証されなければならない。(ビジネス正当性は意思決定の基盤となり、プロジェクトが想定されるベネフィットと整合し、組織のビジネス目標に貢献していることを確保する役割を果たす。)
• 法律や規制によって推進されるような義務的なプロジェクトにも、コストに見合う最大の価値を確保するため、選択したアプローチに正当性が求められる。プロジェクトに関与するすベての関係者は、関与するにあたりビジネス正当性を得るために、予想ベネフィット、コスト、リスクのバランスを取る必要がある。
• プロジェクト完了後には、プロジェクトレビューを実施し、最終的な投資を保証するのに十分なベネフィットが実現したかどうか、プロジエクトからどのような教訓を学ぶことができるかを評価する。
• プロジェクト全体を通して、各投資関係者は自身のビジネス正当性を継続的にモニタリングし、当該プロジェクトが引き続き価値を提供しているかを確認することが求められる。

# 経験からの学習

過去のプロジェクトおよびプロジェクト遂行中に得られた関連する教訓を、改善の機会として積極的に整理して、将来のプロジェクトに適用・共有する。

• 独自性 (プロジェクトの特徴)
• 教訓はプロジェクトのライフサイクルを通して得られる。
  • 始動時：過去のプロジェクトや類似するプロジェクトをレビューし、適用可能な教訓がないかを確認する。（教訓の特定にあたっては、社内プロジェクトに限らず、社外の人や組織が実施したプロジェクトから得られる知見を含める場合もある。）
  • 進行中：教訓は各ステージの終わりに、関連する報告書やレビューに反映します。プロジェクト期間中に改善を実施できる機会を継続的に探ることである。
  • クローズ時：プロジェクト期間中に得られた情報を整理し、将来のプロジェクトで活用できるよう共有する。
• 学習のニーズや好みは人によって異なるため、プロジェクトに関与するすべての人に対して教訓を効果的に共有できる方法を検討することが重要である。
• 継続的な改善および革新を実現するためには、失敗と成功の双方から学ぶ姿勢が不可欠である。プロジェクトに関与するすべての関係者は、他者から教えられるのを待つのではなく、自ら教訓を見出す意識を持つことが求められる。

# 役割、責任、関係の定義

役割と責任を明確にし、利害関係者間で共通認識を持つことで、プロジェクトの目標達成を支える一貫した構造を確立する。

• プロジェクト期間を通じて個人に割り当てられる役割および責任は、曖昧さのない形で明確に定義され、関係者に受け入れられている必要がある。
• プロジェクトを成功させるためには、明確なプロジェクト・マネジメント・チームの組織体制を構築し、その中で関係者それぞれの役割と責任について合意を形成することが重要である。
• 関係者間の関係性を理解した上で、効果的なコミュニケーションの仕組みを整えることが求められる。

# ステージによるマネジメント

プロジェクトを複数のステージに分割し、各ステージ終了時に承認と意思決定を行いながら進めることで、リスクを管理し、プロジェクトの実行可能性を継続的に確保する。

# 適切なステージを選択する要因

• プロジェクト・ライフサイクル全体を通じて、リスクの影響度を最小化できる
• プロジェクトの規模および複雑性（ステージが短いほどコントロールの機会は増え、ステージが長いほどシニア・マネジメントの負担は軽減される）
• プロジェクト・ライフサイクル全体で必要となる重要な決定ポイントおよびコントロール・ポイント（多くの場合、主要な投資判断、ビジネス上または技術的な意思決定と関連する）
• セクター別または組織の方針・標準

# 利点

• プロジェクトまたはビジネス環境の変化に柔軟に対応できる
• 明確なレビューおよび意思決定ポイントを提供する
• 主要な意思決定を先に行い、その後に必要な詳細作業へ移行することを可能にする
• 組織の予算策定プロセスや法令の最終決定など、外部環境による影響を明確にできる
• ステージごとにプロジェクト・マネージャーへ権限を委任することで、「例外によるマネジメント」の原則を促進する

プロジェクト委員会は、1 回の承認につきプロジェクトの 1 ステージのみを認可し、ステージ内の日常的なコントロール権限を、合意された許容度の範囲でプロジェクト・マネージャーに委任する。
ステージが許容度内に収まると予測される場合に限り、プロジェクト・マネージャーは自身の裁量で必要な調整を行うことができる。
プロジェクト委員会は、十分なビジネス正当性および資金が継続的に確保されている場合にのみ、次のステージを認可する。
有効なビジネス・ケースが失われた場合、プロジェクト委員会はプロジェクトを回復させるか、その方法を検討するか、または途中で終了するかを判断する。

# 例外によるマネジメント

計画に対する許容度をあらかじめ定義し、その範囲内では権限を委任して管理を行い、許容度を超える偏差が予測された場合にのみ、上位のマネジメント・レベルへエスカレーションして意思決定を行う

• プロジェクトを指揮、マネジメント、提供するための明確な役割と責任を定義し、各レベルの説明責任を明確にすることで、適切なガバナンスを実現する。説明責任は、以下の方法によって確立される。
  • 各マネジメント・レベル（プロジェクト、ステージ、チーム）において、パフォーマンスの 7 つの側面（ベネフィット、コスト、時間、品質、スコープ、持続可能性、リスク）に対する許容度を設定し、下位のマネジメント・レベルへ権限を委任する
  • 許容度を超過することが予測される場合には、それを「例外」として明確にし、直ちに 1 つ上位のマネジメント・レベルへエスカレーションして、今後の進め方に関する意思決定を求めるためのコントロールを確立する
  • 各マネジメント・レベルが効果的なコントロールを行えるよう、適切な保証が提供される仕組みを整える
• 計画において許容度を定義するパフォーマンスの 7 つの側面は、以下のとおりである。
  • ベネフィット：計画されたベネフィットに対して、過小または過大に提供することが許容される度合い
  • コスト：合意された予算に対して、支出の超過または不足が許容される度合い
  • 時間：プロジェクト計画書、ステージ計画書、ワーク・パッケージ記述書と比較して、合意されたターゲット完了日より遅延または前倒しとなることが許容される度合い
  • 品質：合意された受け入れ基準と比較して許容される差異の度合い
  • スコープ：計画された成果物に対して許容されるバリエーション
  • 持続可能性：プロジェクト成果物またはプロジェクト活動が、持続可能性目標と比較してどの程度異なることが許容されるかの度合い
  • リスク：計画において集約されたリスクの許容範囲

• 「例外によるマネジメント」を実施することで、コントロールの機会を損なうことなく、シニア・マネジメントの時間的負担を軽減できる。その結果、シニア・マネジメントは戦略的な意思決定に集中でき、組織内の適切なレベルで効率的な意思決定が行われるようになる。(意思決定者は、発生または予測される偏差およびその影響を受け入れるか、またはそれを排除・低減するための対応を取るかを判断する。)
• 各ステージの終了時に許容度をレビューすることで、プロジェクトは変化する運用環境を反映し、次のステージの活動を適応・調整することが可能となる。

# 成果物重視

成果物重視とは、作成・提供される成果物を明確に定義し、ユーザーの期待する品質や要件について関係者間で合意した上で、作業ではなくアウトプットのデリバリーに焦点を当ててプロジェクトを管理するアプローチである。
プロジェクトの目的は、ビジネス正当性に基づき、利害関係者の期待に応えることにある。そのため、必要な成果物およびそれらに対するユーザーの期待品質について、関係者間で共通の理解を持つことが不可欠である。

# 成果物

• マネジメント成果物：主にビジネス・ケースや各種計画書など、プロジェクトの管理・統制を支援するために必要な文書や情報。
• スペシャリスト成果物：プロジェクトに必要なベネフィットを実現するために、ユーザーが必要とする成果物。
• プロジェクト成果物：プロジェクト成果物記述書で定義される、プロジェクト全体から生み出される総アウトプット
• 外部成果物：プロジェクトのコントロール外で開発または提供されるが、プロジェクトが依存している成果物

作成される成果物や、それらの承認に用いられる基準が明確に理解されていない場合、関係者間で解釈の相違が生じやすくなる。
これは、プロジェクトが作業重視型ではなく、アウトプット重視型であることを求められているためである。

成果物を重視することにより、以下が実現される。

• プロジェクトでは、成果物のデリバリーに直接貢献する作業のみが実施される（合意された成果物を提供するために必要な作業以上のことは行われない）。
• すべての変更について、成果物およびビジネス・ケースへの影響の観点から合意を行うことで、コントロールされない変更（いわゆる「スコープ・クリープ」）の管理が可能となる。
• プロジェクト開始時に成果物について合意しておくことで、ユーザーの不満や受け入れを巡る紛争のリスクを低減できる。
• プロジェクトの一時中断または終了を容易にする。特定の成果物の完成を区切りとして合意できるため、中断・終了や再開時のコントロールがしやすくなる。

合意された一連の成果物は、以下の基盤となる。

• プロジェクトのスコープ定義
• 計画立案およびプロジェクトコントロール
  そのために、成果物記述書を使用し、以下を判断する。
• 作業見積もり
• リソース要件
• 依存関係
• 活動スケジュール

成果物重視の考え方は、計画立案、責任分担、進捗報告、品質管理、変更コントロール、受け入れ、リスク・マネジメントを強力に支援する。

# 留意点

• 成果物が細分化されるほど、プロジェクト委員会が成果物記述書が正しいかどうかを判断できなくなりる。(理解に専門知識が必要となるため)

# プロジェクトに合わせたテーラリング

プロジェクトの特性に応じて、プロジェクト・マネジメント手法や管理レベルを調整・最適化する

# テーラリングする時、必ずに考慮する要素

• プロジェクトの環境
• 規模・複雑性
• 重要度（ビジネス価値・影響度）
• デリバリー手法（ウォーターフォール／アジャイル等）
• チームの能力・経験
• リスク・レベル

# 目的

• 形式的に手法を守ることではなく、プロジェクト成功に必要な「情報」と「意思決定」を、適切な方法と粒度で確保する

# 責任と役割

• プロジェクト・マネージャーは、テーラリングに対する実行責任を持ち、過去の教訓や組織の標準を参考にして、適切なマネジメント・アプローチの勧告を作成する。
• プロジェクト委員会は説明責任を持ち、立ち上げステージの終了時、およびマネジメント・アプローチの変更が提案されるたびに、その勧告を承認する必要がある。

# ビジネス・ケース

ビジネス・ケースは、プロジェクトへの投資を継続するかどうかの意思決定を支援するための手段である。プロジェクトが (継続的に) 望ましく、実行可能で、達成可能であるかを判断するためのメカニズムを確立する。

• プロジェクトにはビジネス正当性 (ビジネス・ケース) が必要である。ビジネス・ケースはプロジェクトの理由を確立するだけでなく、次の 3 点を確認する。

• 望ましい (Desirable): コスト・ベネフィット・リスクのバランスが取れている
• 実行可能 (Viable): 成果物を提供できる
• 達成可能 (Achievable): 成果物を使用することで、想定される成果およびベネフィットが得られる可能性がある

• ビジネス正当性はプロジェクト開始時に作成して終わりではなく、価値・実行可能性・達成可能性に影響を与えうる意思決定やイベントに応じて、定期的にレビュー・更新する必要がある。ビジネス正当性が失われた場合、プロジェクトは停止または変更しなければならない。

# 用語定義

• アウトプット (Output): 活動の有形または無形の提供物である。(変更を実現するために使用されるスペシャリスト成果物。)
• 能力 (Capability): 成果を提供するために必要なプロジェクトのアウトプットの全体である。
• 成果 (Outcome): 変更の結果として生じるもので、現状の振る舞いや環境に影響を与える。(成果は、変更を促進するための活動の結果として達成された状態を指す。)
• ベネフィット (Benefit): 投資組織によって利点として認識され、1 つ以上のビジネス目標に貢献する、成果によって生じる測定可能な改善である。
  • パフォーマンス最終目標から許容される偏差であり、次のマネジメント・レベルへエスカレーション不要な範囲を示す。
  • 許容度を逸脱する場合は適切なレベルへレビュー・処置のためにエスカレーションする。
• ディスベネフィット (Disbenefit): 投資組織によってマイナスと認識され、1 つ以上のビジネス目標を損なう成果の結果として生じる測定可能な減少である。
• ビジネス目標 (Business Objective): 組織戦略に関連し、プロジェクトが貢献すべき測定可能な成果である。進捗状況を示す指標となる。

# ライフサイクル

1. ビジネス・ケースは、プロジェクト権限委任で提供された情報を基に、開始時点で ** アウトライン (概要)** として作成される。
   この概要は、プロジェクト委員会がビジネス正当性を確認し、プロジェクト・マネージャーに立ち上げを認可するのに足る情報を含む必要があり、プロジェクト要約書に文書化される。
2. 開始時点では、コスト・期間・成果物・リスク・ターゲットが十分に確定しないことが多いため、確実な正当性を完全に示せない。計画が詳細化され情報が明確になるにつれて、ビジネス・ケース概要はより詳細なビジネス・ケースへと発展する。
3. ステージが進むにつれ、実績コストの発生、予測ベネフィットの実現可能性、前提理解の深まりによって、ビジネス・ケースがさらに詳細化されることがある。

# 技法

# 管理技法

• ビジネス・ケース作成時には、プロジェクトのパフォーマンス最終目標の側面と相互関係を考慮しつつ、側面間で発生するトレードオフを整理し、最適なバランスとなるオプションを選択する。

  • 7 側面すべてで許容度内に収められない場合、そのプロジェクトの正当性は疑わしい可能性がある。
  • ビジネス・ケースには、開発コストだけでなく、プロジェクト終了後の運用コスト変化も含める。
  • ビジネス・ケースは概要から詳細へと発展し、ライフサイクル全体でレビュー・更新される。
  • ステージ境界など意思決定ポイントごとにプロジェクト委員会が確認し、ベネフィットが発生する期間を通じて実証される。

• 運用行為

  • 開発 (Develop): オプション検討と投資判断に必要な情報を整える。
  • 確認 (Verify): プロジェクトが (現在も) 価値があるかを評価する。
  • 維持 (Maintain): 実績と最新予測 (予測ベネフィット含む) に基づき最新化する。
  • 実証 (Confirm/Prove): 意図したベネフィットが実現した／するかを評価する。(主にクローズ後だが、反復リリース等で期間中に実現する場合もある。)

# 開発

• ビジネス上の基本オプション

  • 特に何もしない
  • 最低限のことを行う
  • 最低限以上のことを行う

• 「特に何もしない」を常に基準 (ベースライン) とし、その他オプションを定量的に評価する。

• 「何もしない」と「最低限／最低限以上」の差分が、投資で得られるベネフィットとなる。

# 確認

選択したオプションに基づいて作成されたビジネス・ケースは、価値の創出、実行可能性、達成可能性の観点から、継続的に評価する必要がある。(新たなリスクや変更の発生に伴い、他のオプションに切り替えることが正当化される場合があるためである。)

• プロジェクト委員会が確認すべき主なタイミング
  • 始動プロセス終了時：立ち上げ認可
  • 立ち上げプロセス終了時：プロジェクト認可
  • 各ステージ終了時：次ステージ／継続認可
  • 例外計画の評価時：改訂ステージ／継続認可
• プロジェクト・マネージャーが確認するタイミング
  • 進捗・リスク・課題評価時：ビジネス正当性への影響判断
  • 最終ステージ：クローズの一環として成果と予測ベネフィット整合を評価
  • 利害関係者協議時：ゴール変更や追加目標 (持続可能性等) の有無確認

# 維持

• 各ステージ終了時、進捗データと最新予測ベネフィット等を用いて更新する。
• 過去版へアクセスできるよう、適切なバージョン管理を行う。

# 実証

• 終了後のベネフィット・レビューとしてビジネス・ケースを見直し、成果とベネフィット実現を判断する。
• シニア・ユーザーはベネフィット特定の実行責任と、実現の実証に対する説明責任を負う。
• 多くのベネフィットはクローズ後に実現するため、プロジェクト期間を超えるコミットメントが必要になる場合がある。

# 支援技法

投資評価では、一定期間にわたるベネフィット価値と、開発・運用・保守を含むコストを比較し、ベネフィット／コスト／リスクの関係を検証する。

# 投資評価技法

• ライフサイクル全体のコスト：実施および段階的な移行コスト、運用コスト、保守コストを含む総コストを分析する
• 正味ベネフィット：ベネフィットの総額から、一定の期間を定めて計算した実施、移行、継続的な運用コストを引いたものを分析する
• 投資収益率 (ROI): 投資の結果生じる利益や削減額を、初期投資額に対する割合で表す
• 回収：現金やその他のりソースの投資から価値が得られる時間の尺度
• 正味現在価値 (NPV): 特定の時点までに投資によって得られる金額。割引率を使用して割引キャッシュ・フ口一を判断することで金銭の時間的価値を考慮する (例えば、割引率が 6%⊘ 場合、金銭価値は約 12 年ごとに半減するため、プロジェクトが 12 年で 50 万ポンドのベネフィットを実現することを予測している場合、現在の貨幣価値では 25 万ポンドにしかならない)
• 内部収益率 (IRR): NPV がゼ口の場合の投資収益率を割合で示したもの
• オプション分析：重み付けされた評価基準に対して各オプションをスコアリングする方法によるオプションの比較。望ましいオプションを特定するのに役立つ (ペアワイズ比較を使用してオプションを区別し、候補リストと優先オプションを確立することもできる)
• 感度分析：インプット要因を調整して、アウトプット要因が投資を正当化できなくなるポイントを探る
  • 例えば、4 か月で完了できれば価値があるプロジェクトでも、6 か月かかった時点で価値がなくなる場合がある。
  • ビジネス・ケースは不確定な予測に基づいている。ビジネス・ケースの健全性を判断するには、とアウトプット要因 (運用コストと保守コスト、ビジネスのベネフィットとリスクなど) の関係を理解することが有効。

# マルチケース・モデル

• 財務リターンだけでなく、複数観点から包括的に評価することで、「望ましい／実行可能／達成可能」を確認できる。
  • 戦略的観点：変更の推進要因を理解し、投資によってどのように戦略的適合性を提供できるかを示す
  • 経済的観点：より広範な社会、環境、持続可能性への配慮を含む、最適な価値を提供するオプションを特定する
  • 財務的観点：プロジェクトおよびプロジェクト成果物の存続期間にわたる採算性、資金調達、予算編成、キャッシュフローを評価する
  • 実施と商業的観点：望ましいオプションがサービス提供者によって提供されること、およびプロジェクトのデリバリーを成功させるための確実な取り決めが確立されていることを示す
• 投資が堅牢であるためには、これらすべてを満たすことを示す必要がある。

# 各シナリオ

• スコープとベネフィットについて、複数シナリオを提示する。
  • 最良ケース：必須・推奨・できればの要件が満たされる
  • 期待ケース：必須・推奨が満たされる
  • 最悪ケース：必須のみが満たされる
• 最悪ケースでも、プロジェクトがなお実行可能であることを示さなければならない。

# 備考

• ベネフィットはプログラム側で定義・追跡・管理されることがあり、プロジェクトのベネフィット・マネジメント・アプローチはプログラムの計画書の一部となる。
• 三者（ユーザー／ビジネス／サプライヤー）の関心を整合させ、互換性を確保するのはプロジェクト・エグゼクティブの責任。
• ビジネス・ケースの形式・詳細度は、プロジェクトの規模と複雑性に合わせて調整する。

# マネジメント成果物

# インプット

# プロジェクト要約書

• 目的：プロジェクト開始の完全かつ確固たる基盤を提供する。
• コンテンツ概要
  • 定義：プロジェクトが達成すベきことの説明で、以下の内容が含まれる。
    • 背景
    • プロジェクト目標
    • 期待される成果
    • プロジェクト・スコープおよび除外項目
    • 制約条件および前提条件
    • プロジェクト許容度
    • ユーザー、およびその他の既知の利害関係者
  • ビジネス・ケース概要：プロジェクトが必要とされる理由と、選択されたビジネス上のオプション
  • プロジェクト成果物記述書：ユーザーの期待品質と受け入れ基準を含む
  • プロジェクト・アプローチ：ビジネス・ケース概要で選択されたビジネス上のオプションを提供するためのアプローチを定義する
  • プロジェクト・マネジメント・チーム組織と役割記述書：誰がどのような役割で、どのような委任と報告のスキームでプロジェクトに取り組むか

# アウトプット

# ビジネス・ケース

• 目的：コスト見積が予測ベネフィットとリスクに見合うかを根拠立て、ビジネス正当性を文書化する。（ベネフィットの測定方法とタイミングのアウトラインを含む）
• コンテンツ概要
  • エグゼクティブ要約：ビジネス・ケースの主要ポイントを取り上げる (重要なベネフィットと投資収益率を含める)
  • 理由：プロジェクトを実施する理由を定義し、プロジェクトがどのようにしてビジネス目標を達成するかを説明する
  • ビジネス上のオプション：オプションの基盤となる前提条件を含む、オプションの分析と合理的な勧告
  • 予想ベネフィット・ディスベネフィット：プロジェクト実施前の状況と比較した、測定可能な単位で示されたベネフィットとディスベネフィット。測定にはベネフィット許容度が含まれる
  • 持続可能性目標：プロジェクトが達成する必要がある持続可能性に関連する目標。目標には持続可能性の許容度が含まれる
  • 時間：プロジェクトを実行する期間、およびベネフィットが実現されるまでの期間
  • コスト：プロジェクト・コスト、継続的な運用と保守コスト、資金調達の取り決めの要約
  • 投資評価：集約されたベネフィットとディスベネフィットを、プロジェクト・コスト、継続的な段階的運用、保守コストと比較し、投資としてのプロジェクトの価値を定義する
  • 主要リスク：プロジェクトに関連する主要な脅威と機会、およびこれらが発生した場合に考えられるインパクトと対応の要約

# ベネフィット・マネジメント・アプローチ

• 目的：成果の達成確保とベネフィット実現確認のためのアクションとレビューを定義する。
• コンテンツ概要
  • スコープ：管理および測定するベネフィットの説明
  • ベネフィットを実現する手順：プロジェクトの成果を確実に達成するために必要なマネジメント・アクションについて説明する (これには、プロジェクトがクローズした後にビジネス・レイヤーによって実施されるベネフィットを実現する活動の取り決めを含む。)
  • ベネフィットの測定：予想ベネフィットの達成度を測定する方法、測定するタイミング、改善を計算するうえで指標となるベースラインの測定について説明する
  • ベネフィット許容度ガイダンス：ビジネス・ケースでプロジェクトに対して定義されたベネフィット許容度レベルに追加のガイダンスを提供する
  • 成果物のパフォーマンス：プロジェクト成果物のパフォーマンスをレビューする方法を説明する
  • 責任：予想ベネフィットに対して誰が説明責任を負うかなど、ビジネス・ケースの活動の責任を定義する
  • リソース：ベネフィット・マネジメント活動 (調査の実施など) 用
  • 支援ツールと技法：ベネフィット・マネジメント活動 (シミュレーターの使用など) 用
  • 標準：ベネフィットの測定に適用される標準

# 持続可能性マネジメント・アプローチ

• 目的：持続可能性パフォーマンス最終目標の達成のための処置・レビュー・コントロールを定義する。
• コンテンツ概要
  • スコープ：管理および測定する持続可能性目標の説明
  • 測定：持続可能性目標の達成度を測定する方法、測定するタイミング、目標を計算するうえで指標となるベースラインの測定について説明する
  • 責任：持続可能性目標の達成度の測定について誰が説明責任を負うかなど、持続可能性の活動の責任を定義する
  • リソース：持続可能性マネジメント活動 (調査の実施など) 用
  • 支援ツールと技法：持続可能性マネジメント活動用
  • 標準：持続可能性マネジメントに適用される標準

# 主要な役割

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

• プロジェクト権限委任を提供し、ビジネス・ケース策定時に守るべき基準を定義する
• シニア・ユーザーに対して、プロジェクト成果物によって可能となるプロジェクト終了後のベネフィット実現の説明責任を割り当てる
• ベネフィット・マネジメント・アプローチに対する説明責任を負う (プロジェクト終了後)
• プロジェクト・レベルのベネフィット許容度を設定する

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

• プロジェクト期間中、ビジネス・ケースについての説明責任を負う
• ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチを承認し、プロジェクト期間中の説明責任を負う
• ステージ・レベルのベネフィット許容度を設定する
• 実行可能なビジネス・ケースの開発を監督し、プロジェクトがビジネス目標と整合していることを確認する
• プロジェクトが継続的に望ましく、実行可能で、達成可能であることを確認する
• プロジェクトの資金調達を確保する
• シニア・ユーザーが特定したベネフィットが投資に見合う価値を持ち、ビジネス目標と整合しており、実現できることを確認する

# シニア・ユーザーの責任

• ビジネス・ケース承認の根拠となる望ましい成果とベネフィットを特定する説明責任を負う
• ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチに合意する
• ベネフィットの実現に対する説明責任を負い、プロジェクトで望ましい成果を提供する成果物を作成し、その成果が望ましいベネフィットを生み出すことを確保する
• (プロジェクトの成果から得られる) 予想ベネフィットが実現されたこと、または実現できることを確認する
• ベネフィット・レビュー時に、実際のベネフィットの達成と予測ベネフィットを比較した文書を提供する

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

• ビジネス・ケース承認の根拠となる望ましい成果とベネフィットを特定する説明責任を負う
• ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチに合意する
• ベネフィットの実現に対する説明責任を負い、プロジェクトで望ましい成果を提供する成果物を作成し、その成果が望ましいベネフィットを生み出すことを確保する
• (プロジェクトの成果から得られる) 予想ベネフィットが実現されたこと、または実現できることを確認する
• ベネフィット・レビュー時に、実際のベネフィットの達成と予測ベネフィットを比較した文書を提供する

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

• プロジェクト・エグゼクティブから委任されたビジネス・ケース、ベネフィット・マネジメント・アプローチ、持続可能性マネジメント・アプローチを開発する実行責任を負う
• ビジネス・ケースの継続的な実行可能性に対する課題とリスクのインパクトをレビューする
• 各ステージの終了時に、ビジネス・ケース、ベネフィット・マネジメント・アプローチ、持続可能性マネジメント・アプローチを評価し、更新する
• プロジェクトのクローズ時にプロジェクトのパフォーマンスを評価し、報告する
• プロジェクト期間中、利害関係者と協議して、ゴールが変更されたかを確認する

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

• ワーク・パッケージ記述書で合意されたベネフィット・マネジメント手順を実施する

# プロジェクト保証の責任

• プロジェクトが全体的なビジネス目標に適合していることを確認する
• ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチについて、プロジェクト・マネージャーに助言する
• ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチがビジネスの方針に準拠していることをプロジェクト委員会に確認する
• 外部イベントとプロジェクト進捗に対して、ビジネス・ケースを確認し、モニタリングする
• ビジネスを代理してプロジェクトの財務状況をモニタリングする
• プロジェクト計画書の変更をモニタリングし、ビジネスやビジネス・ケースのニーズに対するインパクトを特定する
• ビジネス・ケースおよびプロジェクト計画書に対する潜在的な変更のインパクト評価をレビューする
• ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチの実施についてプロジェクト委員会に保証する (投資に見合う価値をもたらすソリューションが継続的に再評価されているかどうか など)

# プロジェクト支援の責任

• ビジネス・ケース、ベネフィット・マネジメント・アプローチ、持続可能性マネジメント・アプローチのベースラインと変更コントロールを維持する
• ビジネス・ケースに影響を及ぼす成果物に対して提案された変更、または実際の変更をプロジェクト・マネージャーに助言する