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

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

2012/03/12 13:00

　“開発プロセス”と聞いて、何を思い浮かべますか？分厚い文書の塊？神聖にして不可侵な聖典？あるいは、アンチテーゼとしてのアジャイル“革命”か……。ビジネスへの貢献を今まで以上に求められている開発組織にとっては、今や“静的なプロセス定義”だけでは意味がない、とIBM Rationalチームは考えます。開発プロセスを“実現可能なモノ”にするIBM Rationalのプロセス戦略を、本連載ではご紹介します。

RUPはどこに消えたのか？

　……なんて始まり方は少々扇情的に過ぎるでしょうか？

　震災以降、いまだにおさまらない円高等々さまざまな要因があいまって、コスト削減という言葉に「抜本的」「聖域なき」という枕詞が付くようになりました。

　もちろんソフトウェアの開発に携わる組織も、無関係ではいられません。「やり方を根本的に変えてでも」という言葉にも、今までにない真剣味がくみ取れるようになった昨今、昔からRationalの名前を知っている方から、「そういえばRUPはどうなったの？」と訊かれることが少なくありません。

　開発技法の多様化やITの重要性がどんどん増している現実を受けて、RUPそれ自身も、そしてRationalのプロセスを核としたソリューションも大きく変貌しています。

　ベンダーの記事は、どんなに繕っても所詮提灯記事の域を越えることはないわけで、この連載もその例外ではありません。しかし、ソフトウェア開発改善の現場に長く関与してきたRationalチームが、どういう問題意識を持ち、それをどのように解決しようとしているかを提示しておくことは、これから「自分達のやり方を見直す」ことを求められる方々に何らかの参考になるのではないか？…そういう想いのもとに、書くことにします。

そもそもRUPとは？

　RUP（ラップと発音します）の名前を耳にしたことがあっても、それがどういうモノかご存じない読者も今となっては多かろう…ということで、簡単にポイントをご紹介しておきます。

3つのアプローチと6つのベストプラクティス

　RUPは、短期間のウォーターフォールを繰り返しながら、製品の機能を段階的に高めていく、いわゆる反復型プロセスに分類されます（図1）。開発単位として、反復のたびに1つ以上のユースケース（あるいはそのインスタンスであるシナリオ）を実装していきます（ユースケース駆動のアプローチ）。プロジェクトの早い段階では、技術的なリスクの高いユースケースを優先して実装します（リスク駆動のアプローチ）。これにより、早い段階でアーキテクチャを確立することを狙っています（アーキテクチャ中心のアプローチ）。ウォーターフォール型開発では、開発期間後期のシステム統合段階でトラブルが頻発することが多く（って、いまでも多いですよね？）、それへの解決策としてこのリスク駆動＆アーキテクチャ中心のアプローチがあります。

図1　Rational Unified Process

　これらのアプローチを現実にどうやって実行していくか？そのために、次の6つのベストプラクティスを提唱していました。

反復的に開発すべし
要求を管理すべし
ビジュアルモデリング
コンポーネント・アーキテクチャ
変更を管理すべし
品質の継続的な検証

　RUP登場以前にも多くのメソドロジーやプラクティスが提唱されていました。その多くがオブジェクト指向の観点からシステムをどう捉えるかを説明したものだったといってもよいでしょう（ちょっと乱暴ですかね）。しかし、実際にそれをプロジェクトに適用する段になると、どれをどう組み合わせ、どのタイミングで何をするべきかを考えることに頭を悩ましているような状態でした。まして、ある程度の規模のプロジェクトで開発者が増えてくると、なんらかの進め方の規範なしには、進まなくなってしまいます。

　そこで、RUPの登場です。RUPが評価された1つのポイントは、それが何かの大発見や大発明ではなく、プロジェクトに適用するにはどうするか？という利用者視点で、乱立するメソドロジーを、整理・統合・体系化し、さらに作業ステップまでブレークダウンしたことにあります。それによって、「始めたい」と思った開発者に「どう進めていくか」を提示することができた、という点が重要です。

次ページ：変わり続けるRUP

変わり続ける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　モジュール化されたコンテンツ

　開発プロセスはそれを決めることがゴールではありません。プロジェクトに適用して効果がでて始めて意味があります。クイックに定義し、現場に適用し、その結果や状況の変化に応じて、適切な修正を施し、再度現場に適用し…プロセスを適用し改善するという活動そのものが反復的である、という考えが根底にあります。

　そしてこのサイクルを短期間で軌道に乗せるためには、学習時間をいかがに少なくするか？が重要です。オープンソース化されたプロセス・メタモデルやプロセス・フレームワークは、「プロセスの基本的な構造」を組織の壁を越えて共有知化することを可能にします。

　あらかじめ各種の技法がライブラリ化されていることで、特定のプロジェクトに最適化されたプロセスを短期間で定義することができます。

　これらの要素は、「開発プロセスはプロジェクトに最適なモノを用意し適用すべき」というビジョンの表れであり、その目指すところは、開発プロセス適用＆改善サイクルのスピードアップに他ならないのです。

　ちなみに、現在のRUPはメタモデルとしてSPEM2を採用し、OpenUPを拡張する形で再構成されています。併せて、EPF Composerの機能強化版を製品（Rational Method Composer）としてリリースしています。

次ページ：これからのプロセスのアプローチ：“開発プロセス”から“開発組織のためのプロセス”へ

これからのプロセスのアプローチ：“開発プロセス”から“開発組織のためのプロセス”へ

　実はここまで、ずーっと「RUPは～」と書きながら、実は違和感を感じていました。前項で、プロセスの元ネタ集としてライブラリ（これを、IBM プラクティス・ライブラリと呼んでいます）があり、そこからコンテキストに応じたプロセスを生成するという話をしました。従来RUPと呼ばれたプロセスは、生成可能なプロセスの一つという位置づけに変わっています（これは、StandardRUPと呼ばれています。図4）。

図4　RUP以外にも多くのプロセス/プラクティス

　これらのプロセスは、いわば「モノを作るためのプロセス」です。新しいプロセスを採用する目的は、個々のプロジェクトの生産性や効率を高めることにありますが、これらの改善活動は本来一過性のものではありません。問題を把握し、分析し、仮説を立て対策をほどこし、結果を検証する…改善活動自身も反復的に行われるプロセスにほかなりません。

　「改善活動そのものをどう進めていくか」「改善されていることをどうやって把握するか」は、改善を推進する責任を持つ推進チームが頭を痛めるところでもあります。

　IBMプラクティスライブラリの守備範囲は、開発の改善活動自体を対象に拡大しています。図5）は「パフォーマンス測定プラクティス」の概念的な絵です。

図5　ビジネスゴールを実現するためのプラクティスの体系化

　あまたある開発プラクティスの中で、自分達はなにを選択すべきなのか、その効果を測る指標は何かを、過去多くのお客様のプロセス改善をお手伝いしてきた経験から体系化しています。

　これもまた、改善活動を短期間で立ち上げる工夫の一つです。

　そしてこれらをある程度の規模で実現するために、さまざまツールによるサポートを提供しています。プロセスやプラクティスをノウハウとするなら、各種のツールはそのノウハウの実行エンジンと言えます（図6）。

図6　「開発のためのプロセス」から、「開発組織のためのプロセス」へ

…そして再び、「RUPはどこに消えたのか」

　RUPは消えていません。技術動向やビジネス状況に合わせて進化しています。しかし、Rationalのプロセスを核とするソリューションは、単一のモノ作りプロジェクトを対象としたものから、改善をもくろむ組織全体をサポートするものへと、その守備範囲を広げています。今後の連載で、この実行エンジンの部分も含めて、プロセスを核としたソリューションの姿をご紹介していきます。次回は、アジャイルプロセスDAD（ディシプリンド・アジャイル・デリバリー）のお話です。おつきあいください。