Enterprise Unified Process

EUPのフェーズ

By Scott W. Ambler

Order now! このホワイトペーパーの題材は、Scott W. AmblerJohn NalboneMichael Vizdosによる「エンタープライズ統一プロセス: IT 業務の全体最適化のためのプロセスフレームワーク」から抜粋したものです。

 

図1のライフサイクル図から分かるように、エンタープライズ統一プロセス (EUP) は6つのフェーズから構成されます。

 

図1. EUPのライフサイクル(2004年版)

0. 方向づけ前

この図を見ると、エンタープライズ作業分野にはプロジェクト開始前の作業が含まれていることが分かります。この「フェーズ前」の主な作業は次のようなものです。

  1. エンタープライズビジネスモデルの作成開始: この情報を使ってシステムの対象範囲を定めます。

  2. ポートフォリオ計画: ここでは、IT組織が実施するプロジェクトの候補を洗い出し、優先順位を付けます。

  3. エンタープライズアーキテクチャモデリング: エンタープライズアーキテクトは「最初のとっかかりとして」エンタープライズアーキテクチャの一部をモデリングし、プロジェクトチームはそれをベースにしてシステムレベルのアーキテクチャを作成します。

  4. 再利用可能な資産の洗い出し: プロジェクトチームが再利用リポジトリを見て、現在どの資産が再利用可能かを調べることができれば理想的です。

  5. 担当者の割り当て: プロジェクトを開始する前に、要員を採用し、トレーニングをして、プロジェクトチームに割り当てることがあります。

  6. プロセスの定義: 多くの組織では、RUP開発プロセスのベースラインとなっているバージョンを、チームが使いやすいようにカスタマイズします。このベースラインバージョンは、たいていプロジェクトが始まる前に開発してありますが、必要に応じて、プロジェクトチーム個々のニーズに合わせてカスタマイズします。

 

1. EUP の方向づけフェーズ

方向づけフェーズの主要な目的は、プロジェクトの目的について利害関係者と合意し、資金を確保することです。このフェーズの主な作業には次のものがあります。

  1. プロジェクトの対象範囲の定義: ここでは、プロジェクトに何を含めるかを大雑把に定義します。それと同じくらい大切なのは、プロジェクトに何を含めないかを定義することです。それによって境界を定め、チームはその中で作業を行うことができます。通常は、高いレベルの機能の一覧や、全体の80%程度のユースケースを明らかにしたユースケースモデルという形で行ないます。

  2. 費用とスケジュールの見積もり: プロジェクトのスケジュールと費用を大雑把に見積もります。後のフェーズの反復について大雑把な見積もりを、推敲フェーズの早い段階の反復についてはより詳細な見積もりを作成します。しかし、この時点でプロジェクト全体の計画を立てるという意味に解釈してはいけません。どんな計画にも言えるように、すぐ先に完了するタスクに関してはより正確かつ自信を持って詳細化することができますが、ずっと先のタスクの見積もりには間違いが発生する余地が多くなることが分かっています。キックオフ時に十分な自信を持ってプロジェクト全体のスケジュールを立てるのは不可能であるということが、この業界のほとんどの人に(やっと)認識されるようになりました。せいぜい可能なのは、近い期間については精度の高い計画を立て、もっと先の期間についてはできる範囲で計画を立てるということです。

  3. リスクの定義: プロジェクトのリスクは、まずこのフェーズで定義します。RUP プロジェクトではリスクは重要な概念です。リスクリストは変動するものであり、リスクを識別したり、緩和したり、回避したり、起きてしまったものに対処したりするのに応じて、変わっていきます。プロジェクトの管理はリスクを中心に動きます。もっとも優先度の高いリスクによって反復のスケジュールが決まるからです。たとえば、優先度の高いリスクは、優先度の低いリスクよりも早い反復で対処します。優先度の高いリスクの対処を遅らせると、プロジェクト全体が危険にさらされます。そのため、リスクが何かを知り、正面から立ち向かうことが不可欠です。

  4. 開発企画書の作成: 開発企画書では、なぜそのプロジェクトに価値があるのか(あるいは、ないのか)について、業務的な視点から定義します。開発企画書からプロジェクトに価値がないと分かったら、そのプロジェクトは中止するべきです。開発企画書では、プロジェクトがエンタープライズビジネスモデルのどの部分に対応するかも示します。

  5. プロジェクト環境の整備: ここでは、チームの作業場所を確保する、必要な要員を要求する、すぐに必要になるハードウェアやソフトウェアを入手する、後で必要になると予想されるハードウェアやソフトウェアの一覧を作成する、といったことを行います。また、プロジェクトで使用するソフトウェアプロセスもこのフェーズで定義します。これは、チームが採用するプロセスについて記述した成果物(RUPの「開発個別定義書」)の形を取ることもあれば、組織の標準的なプロセスと異なる部分を記述することもありますし、プロジェクトが取るアプローチを他の方法で文書化する場合もあります。

方向づけフェーズから抜けるには、チームがライフサイクル目標 (Lifecycle Objectives: LCO) のマイルストーンを通過しなければなりません。このマイルストーンでは、利害関係者がプロジェクトの状況を評価します。利害関係者が合意しなければならないのは次の点です。

プロジェクトが上記の基準を満たしていることに利害関係者が合意すると、プロジェクトは推敲フェーズに移ります。いずれかの基準を満たさなければ、方向が変えられたり、すぐに中止されることもあります。

 

2. EUP の推敲フェーズ

推敲フェーズの目的は、要求をさらに詳細に仕様化し、開発するシステムのアーキテクチャのベースラインを定めることです。このフェーズで、要求は、高いレベルの機能やユースケースモデルから、より具体的な形へ展開されます(通常は、システムユースケースと、ビジネスルールや技術要求といった補足要求の形を取ります)。この時点で要求を完全に仕様化するのではないという点に注意してください。アーキテクチャ上のリスクを理解し、各要求の範囲を理解できていることを確認できる程度に詳細に作成して、その後の計画を実行できればよいのです。

推敲フェーズの主要な納品物は、プロジェクトのアーキテクチャのベースラインです。アーキテクチャのベースラインを作成する目的は、要求を満たすシステムを実際に開発できるかどうか確認することです。アーキテクチャ上のリスクを洗い出して優先順位を付け、重大なものについては推敲フェーズ中に対処します。アーキテクチャ上のリスクに対処する方法はいくつかあります。同様のシステムの調査、スタンドアロンのテストスイート、動くプロトタイプなどです。たいていの場合、アーキテクチャを目に見える形で示すための動くプロトタイプは完成しています。また、システムレベルのアーキテクチャは、全社的なエンタープライズアーキテクチャを反映したものでもなければなりません。

推敲フェーズでは、作成フェーズの準備も行います。システムのアーキテクチャをしっかり理解できてくると、チームはハードウェアやソフトウェアやツールを購入して、作成フェーズに向けた環境の設定を始めます。その他に人員の配置も行い、要員を要求したり雇用したりします。コミュニケーションやコラボレーションの計画も最終的に決定します(チームが異なる場所に分散して作業をする場合には特に重要です)。

推敲フェーズから抜けるには、チームがライフサイクルアーキテクチャ (Lifecycle Architecture: LCA) のマイルストーンを通過しなければなりません。このマイルストーンで、利害関係者はプロジェクトの状態を評価します。合意しなければならないのは次の点です。

プロジェクトが上記の基準を満たしていることに利害関係者が合意すると、プロジェクトは作成フェーズに移ります。いずれかの基準を満たさなければ、方向が変えられたり、中止されることもあります。

 

3. EUP の作成フェーズ

作成フェーズの中心となるのは、稼動前テストを実施できるレベルまでシステムを開発することです。これまでのフェーズで、要求の大部分が明らかにされ、システムのアーキテクチャのベースラインが作成されています。これからの重点は、要求に優先順位を付けて仕様を完成し、分析し、それを満たす解決策を設計し、ソフトウェアのコードを書いてテストすることに移ります。必要であれば、システムを早期に内部または外部にリリースし、ユーザのフィードバックを得ます。

作成フェーズから抜けるには、チームが初期運用能力 (Initial Operational Capability: IOC) のマイルストーンを通過しなければなりません。このマイルストーンでは、利害関係者は次の点に合意する必要があります。

利害関係者が合意すると、プロジェクトは移行フェーズに移ります。上記のいずれかの基準を満たさなければ、プロジェクトの方向が変えられたり、中止されることもあります。

 

4. EUP の移行フェーズ

移行フェーズでは、システムを導入して稼動させることに注力します。ベータテストなど、大規模なテストがこのフェーズで行われることもあります。製品の微調整や重大な不具合に対処するための再作業もここで行います(今回のリリースに既知の不具合がいくらか存在しても構わないと利害関係者が判断することもあります)。

移行フェーズにかける時間や工数はプロジェクトによって異なります。店頭で市販する製品の場合には、ソフトウェアおよびドキュメントを複製してパッケージ化し、流通させる必要があります。社内システムは、外部向けのシステムに比べると導入が簡単です。幅広く利用されるシステムは、多数の人にリリースする前に、少数のグループで徹底的なベータテストを行う必要があるかもしれません。まったく新しいシステムならハードウェアを購入して設定する必要があるかもしれませんし、既存システムならデータの変換やユーザコミュニティとの徹底した調整が必要かもしれません。プロジェクトはどれも異なるのです。

移行フェーズから抜けるには、チームが製品リリース(Product Release: PR)のマイルストーンを通過しなければなりません。このマイルストーンで、利害関係者は次の点に合意しなければなりません。

利害関係者が合意すると、プロジェクトは稼動フェーズに移ります。いずれかの基準を満たさなければ、プロジェクトの方向が変えられたり、中止されることもあります(プロジェクトによってはインストールもしたくないほどひどいものがあります)。

 

5. EUP の稼動フェーズ

稼動フェーズの中心となるのは、運用とサポート、そして、新しい要求や不具合の変更管理です。Gartner Groupのレポートによると、ソフトウェアに関わる費用の75%が、システムの開発と導入が済んだ後で生じているということです。ソフトウェアプロセスを完全なものにするには、導入後のソフトウェアの運用およびサポートの問題を考慮しなければなりません。EUPの稼動フェーズでは、そのためのプロセスを定義しています。

稼動フェーズの目的は次の通りです。

稼動フェーズの主な作業には次のようなものがあります。

これらのタスクのほとんどは、EUPで新しく追加された運用とサポートの作業分野で行われます。また、もともとRUPに含まれる、要求、分析と設計、実装、構成と変更の管理といった作業分野も、稼動フェーズのニーズをサポートできるように拡張されています。

稼動フェーズは、リリース置き換え (Release Replacement: RR) マイルストーンで終わります。このマイルストーンでは、以下の点を達成していなければなりません。

稼動フェーズの詳細はシステムによって異なります。たとえば市販するソフトウェアの場合には、通常、運用サポートの担当者を置く必要はありませんが、ユーザを補助するためのヘルプデスクが必要になるでしょう。データセンターに導入された社内システムの場合は、システムを動作させ、監視する運用担当者が必要です。詳しい稼動フェーズの内容は組織によって違います。RUP と同様 EUP も、組織ごとに特有のニーズに合わせて仕立てる必要があります。

 

6. EUP の引退フェーズ

引退フェーズで重要なのは、システムを稼動状態から問題なく取り除くことです。これは、今日の組織のほとんどが直面している重大な問題です。レガシーシステムを停止し、新しいシステムで置き換えるときには、この作業を首尾よく、組織の日常的な業務のニーズを大きく中断することなく、完遂しなければなりません。これまでにそれを経験した人なら、どれだけ困難なことかが分かるでしょう。

ソフトウェアシステムは永遠に使われるわけではありません。いずれは使われなくなったり、他のシステムに置き換えられたりして、取り除かなければならなくなります(これは「たそがれ (sunsetting) 」とも呼ばれます)。システムの稼動を止める理由はいくつかあります。

引退フェーズの目的は次の通りです。

引退フェーズの作業には次のようなものがあります。

引退フェーズの最後にはリリース引退 (Release Retirement: RET) のマイルストーンがあります。このマイルストーンでは、以下の点を達成していなければなりません。

システムの引退は簡単な作業ではありません。プロセスを定義する必要があり、通常は独立したプロジェクトとして実施されます。システムの引退は、今日どの組織でも起きて不思議ではありません。現在チームがそのような状態に直面しているなら、ライフサイクル全体の明示的な一部であるべきです。RUP は出発点としては優れていますが、組織の現在および今後の現実のニーズを満たすには、拡張が必要です。エンタープライズ統一プロセスは、まさにこのニーズを満たすために開発されました。

 

図2. EUPのフェーズとマイルストーン

 

 

Ambysoft Inc.

本ページの原文(改訂されている可能性あり): www.enterpriseunifiedprocess.com/essays/template.html

Copyright 2004-2007 Scott W. Ambler


元ページ更新日: 2004/11/30
日本語訳最終更新日: 2008/6/24