目的
  • 製品の経済的正当化を図る。
手順
入力とする成果物: 結果となる成果物:
頻度: 反復ごとに 1 回
役割: プロジェクト管理者
ツール メンター:

ワークフローの詳細:

開発企画書は製品の経済的価値を文書化します。これはプロジェクトの資金を獲得する手段です。開発企画書の文書化がうまくないために、製品のアイディアが最良のものさえ沈没することがありえます。一方、開発企画書をうまく文書化することによって、それなりの製品にその価値に見合った資金を確保できるということもありえます。

製品の記述 ページの先頭へ

目的 開発する製品の簡潔な定義を作成する。

利害関係者全員が納得するような簡潔な製品説明が、プロジェクト成功の鍵となります。製品説明は、その製品がどのようなものとなるのか、どのような問題を解決するのか、そして、なぜその製品が必要であるのかを、ごく短い数パラグラフで定義することが望ましいのです。この説明は問題の詳細に深く立ち入るべきではなく、どうしてこの製品が必要かという説得力のある議論を展開すべきです。ただし、これは短くし、プロジェクト チームの全メンバーが理解して覚えられるよう、十分簡単にする必要があります。

ビジネス状況の定義 ページの先頭へ

目的 製品を導入する環境を定義する。
製品の市場を定義する。

ビジネス状況がわかることによって、プロジェクトの利害関係者は、製品を販売しようとしている市場を理解し、合意に達することができます。同じ組み合わせの要求でも、別の顧客向けに解釈し直せば、まったく異なるシステムをもたらすことができます。

ビジネス状況では、システムの運用領域 (たとえば電気通信、銀行、Web コマースなど) と製品ユーザーの定義を含め、製品を販売しようとしている市場を定義します。この領域が十分に理解されていれば短い説明でも十分ですが、新市場に対しては、焦点となる空間をより完璧に説明する必要があるかもしれません。市場の定義には、類似の製品を含め、競合する企業やソリューションを明らかにします。

ある契約を遂行するために、その製品を開発している場合は、契約条件を注記するようにします。その契約に対する支払いを受けるため、主要なマイルストーンを通過しなければならない場合には、その達成条件を注記します。

この製品が既存の製品の拡張になる場合、既存の製品を記述すべきです。

プロジェクトの目的の定義ページの先頭へ

目的 製品の目的を明確に述べる。

製品を開発する目的 (それを行う価値がある理由) を記述します。仮のスケジュールとスケジュールのリスク評価が、これに含まれます。明確に定義 / 表現された目的があると、マイルストーンを設定したり、リスク管理をしたりする良い土台になります。つまり、プロジェクトが予定通り進行し、成功につながるということです。

財務予測の作成 ページの先頭へ

目的 プロジェクト費用と収入の予測を作成する。

商業用ソフトウェア製品の場合、開発企画書には製品についての一連の想定、およびその想定が正しい場合に投資利益 (ROI) の等級を含める必要があります。たとえば、1 年で完了した場合、ROI 等級が 5、2 年で完了した場合、ROI 等級が 2、それ以降は負というようにします。これらの想定は、開発範囲や計画がより正確に分かる推敲フェーズの最後に確認されます。利益は、コスト予測と潜在的収入予測を基にします。

内部的なソフトウェア プロジェクトの場合には、利益はそのプロジェクトの「正味現在価値」で計算するか、あるいは内部的な収益率で計算します。正味現在価値の場合には、プロジェクトがもたらすキャッシュ フロー (プロジェクトの展開とサポートから生ずる負のキャッシュ フローを含む) の将来の流れを見積もってから、プロジェクトのリスクに基づいて組織が決定する、要求された収益率で差し引きます。正味現在価値がゼロより大きければ、プロジェクトは全体として、会社に対して正の経済利益を有していることを示しています。

内部的な収益率の計算の場合には、正味現在価値は 0 ベースで開始し、正味現在価値を作り出すのに必要な内部的な収益率を計算します。次にプロジェクトの内部収益率を、類似のリスクを伴うプロジェクトが最低限必要な収益率と比較します。プロジェクトの内部収益率が、最低限必要な収益率より大きければ、このプロジェクトはその会社にとって正の経済利益を有することになります。

正味現在価値と内部的な利益率は商用ソフトウェア製品についても同様に計算可能です。

リソース予測は、納品までを含むプロジェクト全体にわたるものです。この予測は各フェーズ、各反復ごとに更新され、各反復が完了するたびに正確さが増します。

見積りのベースの記述も入れてください。

プロジェクト制約の記述 ページの先頭へ

目的 プロジェクトの制約を定義する。

プロジェクトが行われる際の制約を明確にします。これらの制約は、リスクやコストに影響します。制約の中には、システムが守るべき外部インターフェイス、標準、認証、また、特定 のデータベース技術や配信メカニズムの使用などの政策上の理由から導入された技術アプローチなどが考えられます。

オプションの記述 ページの先頭へ

目的 製品とプロジェクトに対してある種のオプションを提示し、財務予測やプロジェクトの制約に関する影響を記述する。

オプションの能力と機能および関連する費用と利益という、製品に対するオプション、およびプロジェクトにアプローチするオプションを記述します。プロジェクト オプションには、異なる契約ベース、異なるプロジェクト ライフサイクル、「開発」と「購入」の異なる組み合わせなどがあります。どの場合でも、そのオプションが財務予測に与える影響、そして制約に与える影響 (さらにリスクにも影響) を記述すべきです。この目的は、プロジェクト資金の権限を持つ、レビューを行うマネージャに対して、能力、費用、投資収益率 (ROI)、スケジュール、契約ベース、開発ライフサイクル、技術的制約などの点から、意思決定の自由度を与えることにあります。



Rational Unified Process   2003.06.15