第1回　RUPはどこに消えたのか？

“アジャイル”の次へ：IBMの開発プロセス戦略の今（1）

2012/03/12 13:00

ポスト

変わり続けるRUP

　さて、このような努力の甲斐あって、RUPは中・大規模プロジェクト向けの開発プロセスとして広く認知いただけるようになりました。しかし、このRUPも急速に変化してきました。そこには、「開発プロセス、かくあるべし」の思想を見て取ることができます（図2）。

図2　変わり続けるRUP

1）オープンソース・コミュニティへの寄贈

　1つはオープンソース・コミュニティや標準化活動への技術提供です。　

　2000年代半ば、IBMは、RUPをベースに2つの活動を行います。1つは、Eclipse Foundationに対し、プロセスフレームワークを定義するプロジェクトを提案します。これが、Eclipse Process Framework（EPF）です。この際に、RUPの軽量化バージョンであるOpenUP（オープンナップ）と、プロセスを編集するツールEPF Composerを寄贈します。

　2つめは、 UMLの標準化団体で知られるOMGに対する、プロセスのメタモデル定義の提案です。これは、Software Process　Engineering Metamodel（SPEM）として採択されています。

　この2つは何を意味しているのでしょうか？ RUPを唯一無二の開発プロセスとするため（世界征服）？いえいえ、違います。この2つによって次のことが可能になります。

プロセスメタモデルによって、「そもそもプロセスを構成する要素とはなにか？」を、企業内のローカルルールを越えて、揃えることができる
プロセスフレームワークによって、特定の開発技法への依存性を下げた「進め方の大枠」を扱えるようになる。

　開発対象の複雑さが増し、採用される技術やアーキテクチャも多様化すると、単一のメソドロジーやプロセスでカバーすることが自体が非現実的になります。しかし、開発対象が替わり、メソドロジーが変わるたびに、プロジェクトとして取るべきアクションや成果物が一からすべて変わっているようでは、オーバーヘッドばかりで効率化もなにもありません。オフショアに見られるように、開発体制自体がグローバル化し、さまざまな企業が共同開発を進めるようになると、これらの問題は無視できません。

　プロセスメタモデルとプロセスフレームワークを組み合わせることで、メソドロジーの差異から少し距離を置いた組織やチームの規範を設定できるようになるのです。

2）プラクティスのライブラリ化

　いまでも誤解されている方がいらっしゃいますが、RUPは、完成型のプロセスではなく、カスタマイズを前提したプロセスのテンプレートです（とはいいつつ、結構な情報量が入っているのですが^^;)。当初は、HTML形式のドキュメント集でしたから、カスタマイズする場合は、HTMLを直接編集するか、別に文書をおこすのが常でした（中にはFlashで、まったく同じ見た目を作られたお客様もいましたな）。

　しかし、EJBやらSOAやら.NETやら、果てはSAPのようなパッケージ主体の開発やらと、さまざまなバリエーションが派生しうることを考えると、カスタマイズの作業そのものが大変になり、プロジェクトに適切なプロセスの準備に時間がかかりすぎるようになりました。

　現在のRationalのプロセスでは、特定の技術領域や開発工程に関するノウハウを、ライブラリ化して、編集ツールでそれらを組み合わせて最終版のプロセス記述を整形するというアプローチを取っています。前述のEPFは、まさにこのアプローチのオープンソース実装です。新しい技法が出てくれば、そのメソドロジーをメソッドコンテンツと呼ばれる形式で定義してライブラリに追加し、メソッドコンテンツ同士を組み合わせる…そんな流れで短期間でプロセスの拡張が実現できるのです（図3）。

図3　モジュール化されたコンテンツ