|
基本エンタープライズ作業分野： 複数システム環境向け RUP 拡張 |
 |
このホワイトペーパーの題材は、Scott W. Ambler、John Nalbone、Michael Vizdosによる「エンタープライズ統一プロセス: IT 業務の全体最適化のためのプロセスフレームワーク」から抜粋したものです。 |
エンタープライズ統一プロセス (Enterprise Unified Process: EUP) は、ラショナル統一プロセス (RUP) を拡張して、実際のIT組織のニーズに対処できるようにしたものです。拡張の内容は大きく分けて次の2つです。図1を参照してください。
図1. EUPのライフサイクル(2004年版)
EUP と RUP の大きな違いは、対象としている範囲です。RUPが対象としているのは1つのシステムの開発で、稼動段階へのリリースを少なくとも1回、一般には複数回行います。RUP の作業は、特定のプロジェクトという枠内で実施されます。それに対して EUP は、複数のシステムにまたがる問題も考慮しています。 RUP が拡張されてエンタープライズレベルの問題にも対処可能です。つまり、特定の1つのプロジェクトだけに適用されるのではない概念も含んでいます。そのため、RUP とは違って、作業の一部は特定のプロジェクトという範囲を超えて行われるのです。
ここでは、基本エンタープライズ作業分野を概説します。これは今までエンタープライズ管理作業分野(もとはインフラ管理作業分野と呼ばれていたもの)に含まれていました。ここでは、エンタープライズ作業分野に含まれる各作業分野と、それぞれで行われる作業とを大雑把に紹介します。これらの作業分野について、完全に説明するつもりはなく、紹介するだけです。各作業分野については、この後公開する一連の論文で説明します。この作業分野とは次の7つです。
RUP にもビジネスモデリング作業分野が含まれていますが、一般にその範囲は1つのプロジェクト内に限られます。エンタープライズ・ビジネスモデリング作業分野ではビジネスモデリングが拡張され、プロジェクトの枠を超えたビジネスモデリングによって、組織にどのような利点がもたらされるのかを明確に理解できるようになっています。エンタープライズ・ビジネスモデリング作業分野(エンタープライズ要求モデリングとも呼ばれる)の目的は、組織が携わっている業務を理解し、効果的に伝えられるようにすることです。ここでは、組織が携わっているビジネスプロセスと、それをサポートするソフトウェアアプリケーションに対するビジネス要求全体を調査します。
個々のプロジェクトの方向づけフェーズでは、各プロジェクトチーム独自のビジネスモデルがより詳細に調査されるのに合わせて、エンタープライズ・ビジネスモデル ( Enterprise Business Model: EBM ) に詳細情報が追加されていきます。各チームは、EBM をベースに作業を始め、自分のプロジェクトに関する詳細を調査し、その後、エンタープライズ・ビジネスモデラーにフィードバックを行うべきです。それによって EBM は発展することができるからです。
ポートフォリオ管理作業分野では、計画レベルのもの、開発中のもの、稼動しているものを含め、組織のソフトウェアシステム全体の追跡と計画を行います。組織にはたいてい、関連するアプリケーション群(プログラムと呼ばれることも多い)があり、これは個々のアプリケーションとして管理するよりもグループ単位で管理する方がうまくいきます。その方が新しい要求事項を適切に実装することができ、より効果的に開発し、導入することができます。また、異なる複数のアプリケーションで同じ機能を実装することも防ぎやすくなります。
組織が存在する間ずっと、ポートフォリオ管理チームは、定期的に集まってビジネス要求や製品拡張依頼をレビューし、製品のリリース計画を立てます。このサイクルの長さは組織によって異なりますが、代表的には四半期に一度や1年に一度という頻度で行われます。定期的なリリース計画会議の間の期間には、チームは、次の計画会議のための要求や拡張依頼を収集し、プロジェクトの指導を行います。このために余分に必要になる作業量は最低限に抑えられるため、製品リリース計画会議以外のときには、比較的落ち着いています。ただし、初回には製品群を明らかにするという作業も発生するため、初期の工数は幾分多めになります。
プロジェクトの方向づけフェーズでチームがそのプロジェクト向けにオブジェクトの定義を掘り下げ、明確にしなければならないときに、この作業分野の作業がいくらか発生します。プロジェクトの各フェーズの終わりには、プロジェクトの作業の状態を製品群に反映するという作業が少しあります。稼動フェーズの終わりには、システムのリプレースや引退の計画を実行に移すことになるため、さらにもう少し作業が必要になります。
エンタープライズアーキテクチャ作業分野では、組織のエンタープライズ・アーキテクチャを定義します。エンタープライズ・アーキテクチャは、それを定義するためのモデル、参照アーキテクチャ、動き方を示すためのプロトタイプや動くモデル、使いやすくするためのフレームワークなどから構成されます。エンタープライズ・アーキテクチャモデルとは、組織の構造やプロセスを表すものであり、うまく作成すれば、組織の現状と将来像を示し、アーキテクチャを表すさまざまなビューを互いに結び付けることができます。このビューには、ビジネス的な視点から見たものも、技術的な視点から見たものも含まれます。エンタープライズ・アーキテクチャモデルは、多くの意味で、業務に関わる利害関係者の管理職と上級 IT 専門家との橋渡しをするといえるでしょう。
エンタープライズ・アーキテクチャ ( EA ) に関わる作業は、EAチームがエンタープライズ・アーキテクチャを初めて作り上げていくのに合わせて、最初は少しずつ増えていきます。しかし、エンタープライズ・アーキテクチャが安定すると、作業は減ります。その後、新しい技術が採用されたり新しい製品やサービスが追加されると作業量は増え、それが安定すると作業量が減るという繰り返しになります。
プロジェクトチームにエンタープライズ・アーキテクトが関わるのは、方向づけフェーズの終わりごろから推敲フェーズ全体にかけて、アプリケーション・アーキテクチャの作業を支援したりレビューしたり助言するときです。
戦略的再利用作業分野の目的は、成果物を毎回新しく作り直すのではなく再利用することで、高品質なアプリケーションをより早く開発できるようにすることです。再利用を行うと、これまでの開発チームがテストして、うまく動くことが実証されている成果物を利用することができるため、品質が向上します。
初期段階で、チームがどのような再利用アプローチを取るかを定義し、その再利用構想に合わせて組織やプロセスを変えるときに、再利用のための作業は増加します。作業量がピークになるのは、再利用可能な資産を作成し、導入するときです。新しいものを導入するよりも資産のサポートの方が多くなると作業は減り、新しい資産を見つけて開発しようとすると再び作業量が増えます。
再利用がプロジェクトに関係するのは、方向付けフェーズにおいて、再利用可能な資産の適用方法について再利用アーキテクトの助言を得ながら、アプリケーションアーキテクチャ案を作成するときです。さらに、推敲フェーズでアプリケーションチームがアプリケーション・アーキテクチャを定義し、プロトタイプを作成し、文書化するときにも、再利用アーキテクトが関与することになります。また、作成フェーズで再利用資産を導入したり拡張したりする場合や、再利用できる可能性のあるアプリケーション資産を発掘する場合にも、チームを支援します。
プロジェクト管理とは、プロジェクト計画を作成し、発展させるという技術的な仕事だけではありません。チームメンバーを管理し、メンバー間や外部の関係者との間のやり取りを仲裁する必要もあります。人材管理は、協力して円滑に仕事を進めてプロジェクトや組織にプラスの貢献ができるよう、メンバーをまとめ、見守り、指導し、やる気を出させるという仕事です。
人材管理の作業は、プロジェクトの外部ではかなり一定しています。人を雇用する、解雇する、教育する、キャリアプランを作成して実施する、といった具合です。プロジェクトにおいては、方向づけフェーズの始めに全体的な要員計画を立てる段階で作業が増加します。残りのフェーズや反復の最初と最後には、人事担当者と協力して、適切な人材を見つけ出し配属します。
エンタープライズ・アドミニストレーション作業分野には、IT 部門向けの技術/開発インフラストラクチャを保守しサポートするという作業が含まれます。その一部を挙げると、データ管理作業、ネットワーク管理、ツールサポート、ハードウェアサポートなどがあります。会社全体で見ると、エンタープライズ・アドミニストレーションの作業は定常的に発生します。1つのプロジェクトにおいては、方向づけフェーズおよび推敲フェーズの半ばで、システムに対する要求が明らかになり、開発環境のツールや管理作業が洗い出されて実施されるときに、作業が増加します。同様の作業が、作成フェーズ中や移行フェーズの終わりにも必要になります。また、稼動フェーズにおいて、システムを稼動させるためにインフラストラクチャを保守したり更新したりする場合に管理作業が発生しますし、引退フェーズでシステムが終わりを迎えるときにも同様の作業が必要です。
ソフトウェアプロセス改善 ( Software Process Improvement: SPI ) 作業分野の目的は、全社的なソフトウェアプロセスを管理することです。ソフトウェアプロセスに関する組織のニーズを洗い出し、組織で使用するプロセスを定義し、パイロットプロジェクトなどによってプロセスを検証し、プロセスを文書化して公表する、といった作業があります。また、適切な測定を行って結果を収集し、それを分析してプロセスを調節する必要もあります。
プロセスを採用するときには、SPI の作業を何度も繰り返して行います。組織で初めてプロセスを見つけて採用する場合には、初期のサイクルでより多くの作業が必要になります。一般に、後のサイクルに進むほど作業量は減りますが、プロセスの考え方を根本的に変えると、作業は増加することがあります。成熟した組織では、プロセスの監視と調整を常に行っているため、ソフトウェアプロセス改善の作業が完全に止まることはありません。移行フェーズの終わり(プロジェクトの終わり)にあるこぶは、各プロジェクトの終わりに行われるプロセス振り返りレビューを表すもので、このときの情報をもとにプロセス改善作業を行います。
この論文では、エンタープライズ統一プロセス( EUP )のエンタープライズ作業分野の概要を説明しました。EUP の ( さらに言えば RUP の ) 他の作業分野と同様、各組織がエンタープライズ作業分野をそのまま実施するべきだとは考えていません。それぞれの組織で必要なものや望ましいものを考え、何が適しているかを判断しなければなりません。これらの作業分野は、秩序だったやり方でカスタマイズし、採用する必要があります(詳しくは、Adopting the Enterprise Unified Processを参照してください)。
 |
本ページの原文（改訂されている可能性がありますのでご注意ください）: www.enterpriseunifiedprocess.com/essays/enterpriseManagement.html Copyright 2004-2007 Scott W. Ambler
|