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

RUPはどこに消えたのか？

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

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

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

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

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

そもそもRUPとは？

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

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

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

図1　Rational Unified Process

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

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

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

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

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