後編　新しい開発スタイル「ＲＵＰ」と「ＸＰ」

株式会社豆蔵
上級コンサルタント　岡村敦彦
CEO　羽生田栄一
2002/3/1

前編ではなぜ開発プロセスが重要なのか、開発を遂行しプロジェクトを成功に導くためにどんなスタンスで臨まなければいけないのか、基本的な心構えを簡単に述べました。今回は、それを踏まえて具体的にどのようなプロセスが考えられるのか、メジャーなものとして、RUPとXPの2つを取り上げて紹介いたします。

（１）ラショナル統一プロセスとは？

　ラショナル統一プロセス（Rational Unified Process：RUP）とは何でしょうか。RUPとは、米国ラショナルソフトウェア社がBooch、Rumbaugh、Jacobsonの3人（スリーアミーゴという愛称で親しまれています）のそれぞれの手法に加えて、自社で培われてきた経験をはじめとした業界におけるさまざまなプラクティスを反映し、オブジェクト指向の分析／設計にとどまらない包括的な体系として構築したオブジェクト指向開発方法論です。近年では、例えば要求管理、構成管理、プロジェクト管理、組み込みシステムなどの概念をも取り入れ、最新版は「RUP 2002」となり、Webやコンポーネント技術のみならず、J2EEや.NET、アジャイルな開発方法など最新の技術テーマにも対応したプロセスとなっています。

　ちなみにOMGでは、具体的なプロセスそのものではなく、プロセスの管理体系やプロセスメタモデルを標準化し、ラショナルソフトウェア社をはじめとした企業（IBM、Unisysなど）からの提案を基に構築されたSPEM（Software Process Engineering Management）が昨年採択されました。

　さて、本題のRUPの解説に入る前に、これまでのソフトウェア開発の問題点をもう一度整理しましょう。前回、開発プロジェクトが抱えるリスクを以下のように紹介しました。

（1）	要求リスク	システムに対する要求に関する誤解など
（2）	技術リスク	安定性、設計技術、運用と干渉、製品サポート、将来性など
（3）	要員リスク	適切な人材の確保や教育、チームワークや適性など
（4）	政治リスク	プロジェクトの利害関係者の圧力や対立からの干渉など

　従来の標準開発プロセスであるウオーターフォール型プロセスでは、上記のリスク管理が意識されていません。この場合、メンバーの全員がそのドメインで何度も経験があり、仕様も完全に事前に固定されていて、さらに開発で用いる技術にも手なれていてリスクがない、ということが成功の条件となります。

　しかし現実には、開発プロジェクトには上記のリスクが原因となり、必ず変更が発生します。そして、無理やり仕様書や実装コードをやっつけで直すということが何回も積み重なり、それが工数の増大、品質の歪みを累積します。結果としてプロジェクトは、納期の遅れ、コストのオーバーフロー、収束しないバグといった失敗に陥るわけです。

　そこで、ウオーターフォール型に対するプロセスの改良が始まりました。その結果生み出されたのがRUPです。前回の記事で説明したように、繰り返し型の開発とエンジニアリング―製造の2ステージモデルの実務的な組み合わせによって、上記のリスクを回避するという趣旨で形成されました。

RUPの特徴

　それでは、RUPの特徴を見ていきましょう。RUPで開発を行うときの根本的な考え方としては、以下のものが挙げられます。

• 反復型開発（Iterative Development）
  
• ユースケース駆動（Use Case Driven)
  
• アーキテクチャ中心（Architecture Centirc）
  
• リスク駆動（Risk Driven）
  
• カスタマイズ可能（Configurable Process）

■反復型開発

　反復型開発というのは、小さなリリースを繰り返しながら全体的なシステムを構築していくというアプローチです。この小さなリリースのたびに統合作業が繰り返され何度も検証されるため、最後になってから致命的な問題が発覚するということがありません。このリリースのことを反復（Iteration：イテレーション）と呼びます。ただし、有効に思えるこの反復開発も、ただ無計画に反復させているだけでは決して機能しないだけでなく、逆に混とんとした状況を招いてしまう危険があります。そこで、RUPではこの反復を重要な管理対象として扱い、開発のライフサイクルを支えるキモとして評価しているのが特徴です。つまり、前回説明したように、エンジニアリングステージと製造ステージをさらに管理しやすく分割したフェーズと、フェーズおよびそれぞれの反復の主要な目標であるマイルストーンという概念を用いて、プロジェクト管理的にも管理可能な単位として反復を位置付けているのです（フェーズとマイルストーンについては、また次の機会に説明しましょう）。

図1　反復型開発の「反復」イメージ

■ユースケース駆動

　かつてオブジェクト指向開発の難しさとして、オブジェクトの世界と実際のシステムの機能が結び付きにくいということがいわれてきました。つまり、オブジェクト同士のやりとりをシステム化したとしても、一体そのシステムがどのように使われるのか、そのシステムを使うと何ができるのか、というようなことが分かりにくいという面があったわけです。そのギャップを埋めるのがユースケースです。ユースケースというのは、一言でいえばユーザーから見たシステムの使い方です。対象のシステムを、ユーザーが何のためにどのように使うのかを表現し記述したものです。従って開発者はもちろん、ユーザーから見てもシステムがどのようなものになるのかが大変分かりやすく、相互のコミュニケーションの促進に非常に有効です。そして、このユースケースをベースに開発の進め方を考えて、要求から分析・設計、実装、テストだけでなく、プロジェクト管理といったものまでをユースケースを通じて一貫してとらえるのが、ユースケース駆動という考え方になります。

■アーキテクチャ中心

　アーキテクチャという言葉はいろいろな解釈ができてしまいますが、一言でいえばシステムを支える骨組みであるといえます。ユースケースは機能を中心としたとらえ方ですが、それだけでシステムを構築することはできません。そこで、機能以外の要求、例えば性能や信頼性、拡張性などを考慮したうえで、システムの骨組みをしっかり考えて構築していこう、というのがアーキテクチャ中心という考え方です。RUPではコンポーネントベースのアーキテクチャを採用し、再利用性を重要視しています。このアーキテクチャとユースケースという両面から取り組むことにより、柔軟かつ頑強なシステムを構築することができるわけです。

■リスク駆動

　従来型の開発手法においては工程終盤の致命的な問題による手戻りの影響範囲は想像を絶するものがあります。これは開発全体にかかわるリスクを解消する局面を従来の開発手法が持たないことに原因があります。RUPではそうした現象を避けるために、リスクに基づいて開発を進めることが要求されます。つまり、開発ライフサイクルの早期に大きなリスクに対処し、初期段階でリスクを解消しておくことで、後から致命的な欠陥が明らかになることを防ぎます。また、リスクというものは開発が進むに従って変化していくため、日々変化するリスクを管理していくことが開発を成功に導くポイントになります。従来でもリスク管理の重要性は認識しつつも、それを有効に生かせる手段が提供されていなかったわけですが、反復型開発によりリスク駆動の考え方を実際に具現することができるようになりました。

■カスタマイズ可能

　少し観点は異なりますが、やはり従来の手法の問題点として「高いお金を払ってそろえた開発方法論なのにだれも使ってくれない（以前は手法のバインダ自体で数百万円、数千万円（中には数億円というものも……）ありました）」という問題がありました。なぜこうした問題が発生するのでしょうか。それは、それぞれの開発プロジェクトはそれぞれ別の組織が担当し、別の文化を持っていて、別のドメインを対象とし、別の技術を必要とし……というように実際はさまざまなバリエーションがあるにもかかわらず、それを1つの手法で賄おうとしたことと、日進月歩で進化する新しい技術に対応できなかったことが主な要因と考えられます。RUP にも大量の情報が盛り込まれていて、それをそのまま使用するのは現実的とはいえないため、同じ問題が当てはまりそうです。ですが、実はRUPはプロセスのフレームワークとして構成されているため、それぞれの組織、プロジェクトにフィットした形にカスタマイズして利用するのが一般的な使い方になります。さらに RUP の面白いところは、ラショナルソフトウェア社という1企業によって開発されているプロセスのため、ほかのソフトウェア製品と同じように必ず毎年2回バージョンアップがあることです。そのため、常に新しい技術に対応することが可能なわけです。

RUPのプロセスとしての全体像

　以上の根本的な概念に従えば、従来型の開発手法の問題点を克服できることは分かりました。それではそれらを実際に、どのようにソフトウェア開発の中で実践していけばよいのでしょうか？ 実はそれらを開発ライフサイクルの中に折り込み、だれが、いつ、何を、どのように行えばよいのかをプロセスとして実現したのがRUPということになります。

図2　RUPの概要 出典：「The Rational Unified Process：by Philippe Kruchten, 2000, Addison Wesley」

　この図から分かる（といっても図をどう読めばいいか分からない人も多いでしょう。それは今後のDevelopment Styleコーナーの連載のお楽しみといたしましょう）ように、各フェーズの目的は、方向付けフェーズで定義されたマイルストーンの確実なクリアであり、そのために短期間で分析・設計・実装を繰り返して実際の技術リスク・組織リスク・管理リスクを具体的に洗い出し、見つけたリスクをすぐ次のサイクルで確実につぶすことで、リスクの先送りをしないというのがポイントです。従来のウオーターフォール型プロセスでは問題が発覚するのが「実装フェーズ」というプロジェクト全体の7〜8割がた過ぎになってからで、まったく手遅れという事態に陥りがちでした。それが短期間のサイクルの積み重ねによって早期に解決できる機会が得られるのです。

1/2

INDEX 　いまなぜ開発プロセスを注目するのか
後編　新しい開発スタイル「ＲＵＰ」と「ＸＰ」
	（1）ラショナル統一プロセスとは
	（2）XPはプログラマーの復権を目指す？
前編　従来の開発プロセスと現場が抱える課題

　

IT Architect 連載記事一覧