セッションレポート

当セッションでは、ソフトウェア開発の有効な選択肢の一つとしてアジャイル開発が注目される中で、エンタープライズなアジャイルを見据えて進化を遂げているRational Unified Processについて解説し、Rational Method ComposerおよびRational Team Concertとの連携、プラクティス・ベースの開発組織への変革シナリオを示した。

開発生産性の向上に開発プロセスの改善は重要だが、「ウォーターフォール開発」（安定性が最重要な要素）、「反復開発」（安定性と変更が同等の重要性をもつ）、「アジャイル開発」（変更が最重要要素）はそれぞれ開発のための選択肢の１つといえる。
これまでRationalは、開発プロセスとしてRUP（Rational Unified Process）、開発プロセスを定義・発行するためのツールとしてRMC（Rational Method Composer）を提供してきた。RUPは、誰が何をいつどうやって行うかを詳細に定義したHTMLベースの百科事典ともいえるもので、ビジネス駆動型開発の６つのベストプラクティスをもっている。

一方、アジャイルはセオリーではなく「プラクティス」を基礎としている。プラクティスとは一般的にゴール達成のためのテクニックの集まりであり、より大きなプロセスの一部になる。 RUPの原点もプラクティスであるがアジャイルとは切り口が異なっている。RUPは、開発プロセスを工程、時間（フェーズ、反復）の２つの軸で捉え、それぞれのタスク・ロール・成果物の詳細な定義をもっている。
RUPのプラクティスに、アジャイルな要素を付加し、組織の規模や文化に合わせて選択でき、段階的に適用できるようにすることで、エンタープライズなアジャイルが可能になる。このような趣旨のもとに、大規模なアジャイル開発を見据えた「IBMプラクティス」を開発している。現行のRUPではプラクティス記述ページに各プラクティスに関連するほかの要素（タスク・ロール・成果物）との明示的なマッピングを提供していないが、IBMプラクティスでは関連する成果物やタスクへのマッピングも提供する。IBMプラクティスの一部はアジャイル・コミュニティーと協業し、EPFプラクティスとしてオープンソース化を行っている。10月末にリリース予定のRMC7.5にIBMプラクティスが同梱される予定である。
フォーマル性が重視される開発プロセスはRUPがカバーし、アジャイルな開発におけるプラクティスはIBMプラクティスがカバーする。開発プロジェクトの特性、組織の文化、スキル・レベルに合わせて開発プロセスを選択できる。

RMCは、IBMが提供するプロセスのオーサリング・ツールで、Rational Team Concert（RTC）と連携してプロジェクト立ち上げを効率化できる。RMCから定義したプロセスをRTCへエクスポートし、RTCはプロセス・テンプレートとしてインポートする。プロジェクトの開始時に定義済みプロセスを選択するだけでプロジェクトを立ち上げられる。

組織レベルで変革を行うには、ビジネス要求にマッチしたプラクティスを選択し、段階的に導入することが重要である。段階的な組織の変革をシステマティックに支援するフレームワークとしてRationalの10年以上にわたる経験を網羅したMeasured Capability Improvement Framework（MCIF）を提供している。

最後にまとめとして、次世代のプロセスアプローチは、プロセスを文書化するだけでなく、選択し、再利用しながら実装し、プロジェクトに対して実効化する必要があると述べ、当セッションを終了した。

上に戻る