Rational Method Composer 入門

Key Concept編 1

Comments

はじめに

世界はさまざまなテクノロジーが入り組み、地理的な境界が消滅してThomas Friedmanの言うように「フラット化」しつつあります(注記2)。オンデマンド・ビジネス(注記1)へと進化することでこの世界で勝ち抜こうとしている企業にとって、システムとソフトウェア・アプリケーションの開発、統合、現代化、拡張、およびデプロイが非常に重要なものになってきています。今日、多くの組織において、ITはビジネスをサポートするだけではなく、実際にビジネスのあり方を規定しています(注記3)。私たちの目の前で、新しいコンピューティング・パラダイムが出現しているのです。IBMはこれを「ビジネス駆動型開発(business-driven development:BDD)」(注記4)と呼んでいます。BDDを行う組織では、業績拡大のために、柔軟な開発プロセスをIT運用だけでなくさまざまな基幹業務のビジネス・プロセス開発と全面的に統合し連携させています。

ビジネス駆動型開発プロジェクトを実施するには、きわめて柔軟な開発プロセスが必要です。このようなプロセスでは、アジャイル、反復、アーキテクチャー中心、リスク駆動、品質駆動など、最新のソフトウェア開発方式へのサポートとガイダンスを実際に提供するだけでなく、プロセス自体の導入や調整を迅速に行えるだけの十分な柔軟性も求められます。こうしたプロセスは複数のプロジェクトを経ながら進化する必要があり、また実施されるプロジェクト自体もその過程で生じるビジネス・ニーズの変化に応じて進化する必要があります(注記5)。

Rational Unified Process(以下、RUP)は、市場を代表するプロセス・フレームワーク製品として長い実績を持ち、プロセスの調整、拡張、およびデプロイのための柔軟なアーキテクチャーとツール・サポートを備えています(注記6)。この記事では、RUP開発チームが開発した次世代プロセス管理のツール・プラットフォームであり、概念的フレームワークでもあるRational Method Composer(以下、RMC)を紹介します。RMCは、全面的に設計し直されたユーザー・エクスペリエンスと、開発プロセスのオーサリング、調整、およびデプロイのための豊富な新機能を提供します。

この新しいプラットフォームは、メソッド・コンテンツとプロセスのオーサリング、構成、および表示のためのツールで構成されています(注記7)。 また、Rationalで現在使用されているRational Process Workbench、RUP Builder、および MyRUPに代わるツールです。さらに、さまざまなバリアントにパッケージされたRUPベースのメソッド・コンテンツとプロセスも含まれます。本稿を書いている時点でこのプラットフォームは、商用製品として、また「Eclipse Process Framework」という提供されたフレームワークとして入手できます(図1参照)。

  1. Eclipse Process Framework(以下、EPF)(注記8)は、eclipse.orgでオープン・ソース・プロジェクトとして提供されています。IBMは、次世代RUPプラットフォームから主要なツール・コンポーネントとコンテンツを無償提供する予定です。図1のとおり、EPFツールにはプロセス・オーサリングと公開の全機能が含まれています。EPFとRMCツールとの違いは、Rational Portfolio Manager(以下、RPM)やRational Software Architectなど、他のRationalツールと統合されていないという点(訳注1)と、Rational Process Workbenchからのマイグレーション機能がないという点です。次回提供される部分には、新しいOpenUP/Basicをサポートするコンテンツが含まれる予定です。(訳注2)これは、RUPの原則と手法を応用した小規模なチーム向けの新しいアジャイル型プロセスです。
  2. RMCは、Rationalの新しい商用製品であり、EPFプロジェクトに無償提供されたものがすべて含まれています。また、すべてのRUPコンテンツと共に、Rationalツール統合とマイグレーション機能も含まれています。RUPのフル・バージョンに加えて、RUPプラグイン(RUPコンテンツの拡張機能であり、RUP上にのみインストール可能)が同梱され、サービス指向アーキテクチャー、システム・エンジニアリング、プログラム、およびポートフォリオ管理などの重要なコンテンツ分野に使用できます。 厳密に言えば、本稿で扱うのはEPFプロジェクトに無償提供されるRMCツール・プラットフォームの概要ですが、特に違いが明記されていない限り、機能に関する説明はすべてEPFバージョンとRMCツール全体の両方に該当とすると考えてください。 今回の連載では、RMCの主要な機能と概念の概要と、典型的なRMCの使用シナリオについて説明します。今後、掲載予定の連載では、メソッド・コンテンツやプロセスのオーサリングに関する詳細を、ガイダンスとRMCでサポートされるさまざまなガイダンス形式の概要も含めて説明する予定です。
図1:Method ComposerとEclipse Process Frameworkの概要
図1
図1

どちらの列でも、黒い文字の部分は過去のリリースに既に存在する機能を示します。 グレーの文字の部分は、今回のリリースで追加された機能を示します。

Rational Method Composer:目的と機能

RMCは、開発組織や個々のプロジェクトでプロセスの保守と実装を担当する、プロセス・エンジニア、プロジェクト・リーダー、プロジェクト・マネージャー、およびプログラム・マネージャーのためのツール・プラットフォームです。

通常、このようなプロセスを実装する際には、2つの重要な課題に取り組まなければなりません。 まず、開発者がソフトウェア開発メソッドを理解する必要があります。開発者は、要求を引き出して管理する方法、分析と設計の方法、設計またはテスト・ケースのための実装方法、要求に対して実装をテストする方法、プロジェクト・スコープと変更を管理する方法など、基本的な開発タスクに精通していなければなりません。 一般的なアジャイル開発手法では、自己組織化チーム、つまり開発者がメソッドを文書化しなくても何をすればよいかを暗黙的に理解しているという前提に依存します(注記9)。しかし多くの企業では依然として、統制された共通の手法を確立するために、こうしたメソッドを明示的に文書化し指導する必要があります。さらに、これはコンプライアンスの点からも要求されます(『主な用語と概念について』で説明するように、RMCでは明示的なメソッド・コンテンツを任意に選択可能にすることで、どちらのケースもサポートしています)。

次に、開発チームも、プロジェクトのライフ・サイクルを通してどのように自分たちの開発メソッドを適用するかを定義する必要があります。 つまり、開発プロセスの定義または選択を行う必要があります。例えば、関係者のニーズや要求を引き出したり、ビジョンのスコープを設定することに重点が置かれるプロジェクトの初期段階では、ある要求管理メソッドを適用し、後の段階では、要求の更新や変更を管理したり、要求の変更によって生じるパフォーマンス上の影響を分析することに重点が移るので、別の要求管理メソッドを適用する必要があります。また、チームは、メソッドで実施されるさまざまなタスクが互いにどう関連しているかも明確に理解する必要があります。例えば、ライフ・サイクルを通して、変更管理メソッドがレグレッション・テスト・メソッドだけでなく要求管理メソッドにもどのように影響するのかを理解しておかなければなりません。 自己組織化チームでさえ、ライフ・サイクルを通して開発スコープをどのように設定するか、マイルストーンをいつ達成して検証するかなどに関するガイダンスを提供するプロセスを少なくとも定義する必要があります。

RMCには、このようなニーズを満たすために2つの主な目的があります。

  1. 開発担当者がコンテンツの参照、管理、およびデプロイを実施できるように知的資産(IC)の知識ベースを提供する。 このコンテンツはライセンス提供や取得が可能ですが、何よりも重要なのは、これに独自のコンテンツを加えることもできるという点です(メソッド定義、ホワイト・ペーパー、ガイドライン、テンプレート、原則、ベスト・プラクティス、社内手続きと規制、トレーニング資料、およびソフトウェア開発方法に関する全般的な説明など)。この知識ベースは参照や教育に利用でき、開発プロセスの基礎となります。RMCは、コンテンツ管理システムとして設計されており、すべてのコンテンツに共通の管理構造と外観を提供するシステムです。形状やフォーマットがばらばらで維持管理の難しい従来の文書の保存やアクセスを行う文書管理システムではありません。RMCで管理されるすべてのコンテンツは、HTMLとして公開し、Webサーバーにデプロイして配布することができます。
  2. プロセス・エンジニアリング機能を提供し、プロセス・エンジニアやプロジェクト・マネージャーが実際の開発プロジェクトのために、プロセスを選択、調整、および迅速に構築できるようにします。 RMCでは、標準的なプロジェクトにおける各状況のプロセスをあらかじめ定義したカタログが提供され、それを個々のニーズに合わせて調整できます。また、特定の分野、テクノロジー、または開発スタイルに対応した開発のベスト・プラクティスである、ケーパリティー・パターンと呼ばれるプロセスのビルディング・ブロックを使用することもできます。このビルディング・ブロックによって、プロジェクト固有のニーズに基づいてプロセスを迅速に構築するためのツールキットが構成されます(図2参照)。また、RMCでは組織独自のケーパリティー・パターンを持つライブラリーをセットアップすることができます。最終的に、RMCを使用して作成した文書化されたプロセスをWebサイトとして公開しデプロイすることができます。この文書化されたプロセスは、RMCの商用製品バージョンで、RPM用のプロジェクト計画テンプレートとしてデプロイすることができます。
図2:RMCによって公開されたWebサイト
図2
図2

(ユーザーが公開用に選択したすべてのメソッドとプロセス・コンテンツが含まれ表示されています。)

この例は、RUPフレームワークの構成を示しています。EPFまたはユーザーが生成したコンテンツの構成も同様に表示されます。

RMCは、EPFプロジェクトと同様に、開発リーダーやチームが、メソッドとプロセスを取得して管理する際に直面する、次のような共通の問題に対してソリューションを提供します。

チームに、メソッドやベスト・プラクティスを習得するために必要な最新の知識ベースがない。 開発プロセスを効果的に実施するには、チームをトレーニングしなければなりません。 チームには、プロセス定義やプロジェクト実施のベースになるプラクティスが常に反映されている開発メソッドに関する知識ベース、つまり百科事典が必要です。

プロジェクトにおいてプロセスを効果的に実行する。チームは、同じような表現や用語を使用することによって、プロセス・エンジニアリングとプロセス制定のギャップを埋める必要があります。 マネージャーには、プロジェクト実行環境にプロセスを直接インポートできる機能が必要です。そのために実行タスクやその記述などの計画要素はRPMなどのプロジェクト実行環境へとリンクしています。

RMCは、Rational Process Workbench、RUP Organizer、および RUP Builderに代わるものであり、次のような主要な機能を新たに提供します。

シンプルなフォーム・ベースのユーザー・インターフェースを使用してメソッド・コンテンツを管理します。 このため、UML(統一モデリング言語)のスキルはもう必要ありません。

主な用語と概念について

RMCを効果的に使用するには、コンテンツの編成に使用されるいくつかの概念を理解する必要があります。このセクションでは、これらの概念の概要を説明します。

メソッド・コンテンツとプロセス

RMCにおける最大の基本原則は、再利用可能なコア・メソッド・コンテンツをプロセスへの適用から分離させていることです。これは、前のセクションで説明したRMCの2つの目的と直接関係しています。RMCの他の概念はほぼすべてこの分離に沿って分類されています(図3を参照)。メソッド・コンテンツには、作成するもの、要求されるスキル、および特定の開発目標の達成方法に関する説明をステップ単位に記述します。

このようなメソッド・コンテンツの記述は、開発ライフ・サイクルから独立しています。開発ライフ・サイクルを記述するのはプロセスです。プロセスによって、メソッド・コンテンツの要素が、特定のタイプのプロジェクトに合わせてカスタマイズされたセミオーダーの順序に関連づけられます。

図3:RMCの概念に使用される用語の概要
図3
図3
図4:RUPにおけるメソッドとプロセスの分離を示した二次元図
図4
図4

メソッド・コンテンツとプロセスを分離させるという考えは、新しいものではありません。この考えは、RUPが登場したときから存在し、1992年には既に提唱されていました(注記10)。しかし、RMCでは、RUPに同梱されたプロセス調整ツールによって初めて、メソッド・コンテンツとプロセスを自由に修正できるようになりました(以前のバージョンでは、これらのツールはメソッド・コンテンツ側に重点を置き、プロセス側のオーサリングや調整機能に関しては制限がありました)。

図4は、この分離がRUPでどのように表現されるのかを示す二次元図です。開発作業の実行方法を記述するメソッド・コンテンツが、Y軸上に作業分野別に分類されています。この作業は時系列を表すX軸上のプロセス内で参照され、順序付けられます。これが、開発プロジェクトのライフ・サイクルであり、いつどの作業が実行されるかを表します。中央のグラフは、各作業分野に対するワークロードの推定値を示します。例えば、RUPでは絶えず要求に関する処理が行われていますが、そのなかに必ずピーク時があり、要求を引き出したり記述したりする作業の大部分が実施されます。一方、プロジェクトの終了に向けて要求変更の処理数が減る時期には、下降傾向を示していなければなりません。これにより、機能を次々と追加して要求処理の量が一向に減らないどころか増えてしまう事態を回避します。このように、プロセスは、このようなライフ・サイクルのさまざまな作業分野で実行される作業の変化を表し、メソッド・コンテンツは作業自体を記述します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=312439
ArticleTitle=Rational Method Composer 入門
publish-date=07122006