The Rational Edge

「アジャイル」「RUP」「Rational XDE」の融合

by Gary K. Evans
President, Evanetics, Inc.

2002/10/10

---

　今日のソフトウェア開発をめぐって最も熱い（そして論争の種になっている）話題の1つが「アジャイル（機敏な）」プロセステクニックだ。数多くのライターによっていくつかのアプローチが提案されてきたが、最近行われた世論調査の結果によると、アジリティ（敏捷性）の実践はまだごく一部で始まったばかりであるという。

　私は2002年4月にカリフォルニア州サンノゼで開催されたSoftware Development West Conference（SD West）での方法論の討論会に招待されて参加したことがある。この討論会が始まる前に、司会者は約800人の参加者に対し、現在採用しているソフトウェア開発プロセスについて意見を聞いた。司会者がウォーターフォール（もしくはモディファイドウォーターフォール）アプローチを採用している人に挙手を求めたところ、会場にいたほぼ全員が手を挙げたようだった。次に司会者がアジャイルテクニックを積極的に実践している人に挙手を求めると約半数の手が挙がった。さらに司会者がエクストリームプログラミング（XP）を利用している人に挙手を求めたところ、手を挙げたのはわずかに6人だった。

アジャイルプロセスの導入

　アジャイルなプロセスによる開発プロジェクトのメリットは、実際に完遂されるまで、見る人によってみな違ってくる。メリットの有無あるいは種類は、ソフトウェアはどのように開発されるべきかという、各人それぞれのゲシュタルト（統一されたパターン、統合性、全体性）に大きく影響されるものである。ソフトウェアは自動車や航空機と同じように製造（設計）されるというのがここ30年ほどの一般的な認識だが、われわれのようにソフトウェアの開発を職業にする人間は、ソフトウェアの開発手法がこのような製造手法にピッタリとは収まらないことにかなり以前から気付いている。われわれの多くにとって、ソフトウェアが橋やビルのように順を追った流れ作業で組み立てられるのではなく、音楽や短編小説のように系統的に組み立てられていることは自明の理である。*1

　アジリティの根本理念とは何だろうか？ これを最も簡単に説明すると、「必要であれば実行し、必要でなければ実行しない」というごく当たり前のことになる。だが、このような考え方を適用する場合、「X、Y、もしくはZの要不要をどうやって判断するのか？ 」という不安が付きまとうことになる。

　何十年も前から語られてきたソフトウェアプロセスの改善という歴史において、アジリティは破壊的要素である。それは「仕事量と結果は反比例する」という意図的かつ計算された約束を掲げてソフトウェア業界に突然現れた。まゆつばものの気がしないでもないが、風変わりな現象が主流になることも多い。この場合、アジリティの根本理念や実践は、コードに影響を与えるよりもはるかに激しく思考や快適域を攻撃してくるのだ。アジリティ（という要素または概念）はコードの書き方を変えるだけではなく、ソフトウェアの開発手法全体を変えてしまうのだ。

着眼点の対比

【アジャイルプロセスの種類】 　アジリティは1つのテクニックや方法論ではない。これは姿勢であり哲学である。アジリティを実現するにはいくつものアプローチがある。以下は有名なアプローチの一覧である。それぞれの詳細についても分かるようになっている。

Adaptive Software Development （アダプティブ・ソフトウェア開発）

Jim Highsmith氏のWebサイト参照

アジャイルモデリング

Scott Ambler氏のWebサイトおよび“Agile Modeling: Effective Practices for Extreme Programming and the Unified Process”（2002年John Wiley＆Sons刊）参照

クリスタル

Alistair Cockburn氏のWebサイト参照

エクストリームプログラミング（XP）

Ron Jeffries氏のWebサイトおよびKent Beck氏の著書“Extreme Programming Explained：Embrace Change”（1999年Addison-Wesley刊）参照

フィーチャ駆動開発

Peter Coad氏、Eric Lefebvre氏、Jeff De Luca氏共著の“Java Modeling In Color With UML: Enterprise Components and Process”（1999年Prentice Hall PTR刊）参照

スクラム

Jeff Sutherland氏およびKen Schwaber氏のWebサイト参照

　われわれが商用ソフトウェアの開発で掲げるゴールは、カスタマの期待にこたえることだ。われわれはこれらの期待をどのように集め、どのように理解しているだろうか？ これについてはカスタマの要件定義を利用しているのだ。また、要求を満たすかどうかをどう検証するのだろう？ そう、ここがわれわれを不安にさせる分かれ道である。

　従来のウォーターフォールアプローチは「大規模」に検証を行う。これは通常は電話帳のような大量のドキュメントで具体化され、“システムを構築する前にすべてを理解しなくてはならない”、そして“文書化したものは正しいものでなくてはならない”という2つの定説によって正当化される「Big Requirements Up Front（BRUF：何より先に要件定義ありき）」形式で実施される。ウォーターフォールアプローチは、ソフトウェアは大量生産されるものであり、すべてを事前に理解することが実際に可能であって、コーディングを開始する前にデザインを完成させることや、システムテストの前にコーディングを完成させることなどが可能だと暗示しているのだ。

　一方、アジャイルアプローチは「小規模」に検証を行う。このアプローチでは解決すべき問題を「適度に」理解し、ソフトウェアを細かい段階に分けて構築していくことを唱えている。アジャイルでは、“実際にシステムを構築しない限り、自分たちのシステムでも理解することは絶対にできない”という謙虚な考え方をする。そして、正しいシステムを構築するためには、検証可能な小さい部品に分割し、カスタマの期待に沿うよう継続的な検証を行う必要がある。

　簡単にいうと、ウォーターフォールアプローチでは、システムの構築作業を始めるために、システムを理解しようとする。だがアジャイルアプローチでは、システムを理解していくために、システムの構築作業を始めるのだ。従来のアプローチでは（作業開始前にすべてを理解しているはずなので）作業をやり直して、すでに完了したことに対して変更を加えるための時間を見積もったり、スケジュールに入れたりすることはしない。だが、アジャイルアプローチでは、回避できずに見過ごしてしまったことを前の段階に戻って補完する作業を正当化できるように作業を進める。このような逆行は計画の中に織り込み済みなのだ。XPコミュニティいわく、「アジリティは変更を進んで受け入れる」のである。

　これが、「計画的反復作業」と、ウォーターフォールベースのプロジェクトであまりにも当たり前に行われている「無計画修正作業」の本質的な違いだ。従来のアプローチでは、所定のソフトウェアプロセスを厳守することが成功を大きく左右すると考えられている。一方のアジャイルアプローチでは、稼働するソフトウェアという最終目標達成に向けた作業工程への順応こそが成功を左右する大きな要因となる。

　表1に、この2つの大きく異なるアプローチの相違点を簡単にまとめる。

	ウォーターフォール	アジャイル
指針となる メタファー	大量生産／エンジニアリング	系統的／創発的
焦点	ドキュメント、スケジュール	人、実稼働コード
動的構造	因果関係、予防型アプローチ	Chaordic（カオディック：秩序ある混沌）、順応型アプローチ
表1　ウォーターフォールアプローチ対アジャイルアプローチ

RUPのアジャイルな側面

　もしアジリティの思想が従来のものとそれほどまでにかけ離れているのなら、われわれはソフトウェア開発を改革しなければならず、プロセス、専門用語、そして作業を「手作り」していかなくてはならないということになるのだろうか？ そして、大規模で、意図的に一般化されたRational Unified Process（RUP）などのプロセスからはどのようなメリットを得られるのだろうか？

　コンサルティング活動の経験から、RUPには本質的な要素をめぐってかなりの混乱がある、と私は認識している。ラショナルソフトウェア（以下ラショナル）は当初、RUPをプロセスと製品の両方の形で市場に出した。しかし、ここ2年ほどのラショナルは、この混乱に率先して対応し、実現可能で機能するプロセスを生み出すべく、RUPを組織に特化したコンテンツを備える、作業者の役割、活動、成果物などにまとめたフレームワークに作り直して投入してきた。RUPの「アジャイル」な機能の活用方法に関する記事や書籍の数も1年半ほど前から急増している。私も自分のコンサルティング活動の中で達成に努める「エクストリーム」RUPプロセスについて2001年1月の「Rational Edge」にごく簡単な説明（“A Simplified Approach to RUP”）を掲載している。Philippe Kruchten氏が「Rational Edge」で書いた“Agility with the RUP”（RUPによるアジリティの実現）という記事は、このフレームワーク的見方を明確に伝える伝道的な研究小論文となっている。また、Scott Ambler氏の近著である“Agile Modeling”（2002年John Wiley＆Sons刊）では、オブジェクトモデリングにおけるアジリティがRUPフレームワークの中でどのように実現可能であるかに複数の章を割いている。本稿の中でたびたびアジャイルモデリング（AM）の実践に言及していくのは、これとRUPのモデリング機能との間に密接な関係があるためだ。

　RUPとは何であり、何が可能であるかにかかわらず、これが最優良事例をベースにしているところは称賛に値するだろう。RUPの適用についても、反復開発、ビジュアルモデリング、もしくはコンポーネントベースアーキテクチャの使用の“質的”価値に問題はなかった。その代わり、私の経験では、「モデルはいくつ開発すべきか？」「どこまで詳細に記述すべきか？」「実現に向けてはどのような処理が必要か？」「どのCASEツールを使用すべきか？」など、懸念されてきたのはこれらの処理の“量的”適用だった。

アジャイルプロセスのどこでCASEツールを使うか？

　実際、CASEツールがアジャイルプロセスの中で使えるのか、そして使うとすればどこか、という問題は大きな論議を呼んでいる。賛否が大きく議論されているが、大半のツールは基本的にプロセスに対して寛容であるというのが現実だ。AMの慣例の1つが「最もシンプルなツールを使う」であり、最もシンプルなツールはホワイトボードであったり、付せんであったり、それが5000ドルもするCASEツールの場合もある。問題はツールではなく、その使い方なのだ。

　私は先日、ラショナルの新しいXDE／Javaツール（*2）のレビュー記事を書いたが、これは包括的な機能セットを見ただけでも印象的な製品である。だが、さらに印象的なのは、これが簡単に活用できる点だ。XDEは望めば大規模で堅苦しいプロセスにも利用できるが、本来は融通を利かせるという特性を持っている。

　アジャイルアプローチによる小規模ソフトウェア開発でXDEのようなツールを使う方法を見てみよう。本稿のスペースが限られている関係上、ここでは小規模のケーススタディを示すが、基本的なアプローチはこれよりはるかに規模が大きく、複数の人間が携わる開発プロジェクトにも利用可能だ。

　このプロジェクトの基本的ビジョンは、ボディビルダーや健康管理に積極的な人々の食事パターンを管理するJavaアプリケーションの開発だ。このような人々は脂肪、炭水化物、たんぱく質という三大栄養素を具体的な目標値まで補充する食事プランの作成に非常に関心が高い。最も関係の深いのがボディビルダーとフィットネス関係者、そして個人トレーナーと栄養コンサルタントだ。

　では重要な機能は何であり、これらをどのようにして表現すればよいのだろうか？ われわれには少なくとも次の3つの選択肢がある。

• 以前から使われている、段落スタイルの要求仕様フォーマット（「本システムは〜するものとする」といったもの）
  
• 使用事例の記述
  
• ストーリー
  

　従来のアプローチでは量が膨れ上がり、BRUFで容易に身動きがとれなくなってしまう。では使用事例はどうだろう？ これはRUPに欠くことのできない部品だが、プロセスを完全に記述するためには１〜3ページのスペースが必要になる。このフィットネスアプリケーションの基本サービスはかなり細かいので、ストーリー形式を試してみたい。ストーリーはXPの一部であり、システムの個々の機能を非常にシンプルなテキスト形式で記述したものだ（使用事例の中の項目と同じようなものだと考えられる）。われわれのシステムにおける主なストーリーを以下に示す。

#1：品目管理

　クライアント（すなわちユーザー）は品目とその栄養成分の作成と管理を行うことができる。例えば、品目を“ローストビーフ110グラム、250Kcal、脂肪12グラム、炭水化物2グラム、たんぱく質22グラム”というように記録することができる。

#2：食事管理

　クライアントは食事のプランを組み立て、これらを品目単位で埋めていくことができる。食事の栄養成分はその構成品目の栄養成分から計算する。含まれている品目に対する変更はすべて食事の栄養成分に即座に反映される。

#3：調理方法

　本システムでは、品目として管理するよう調理方法をクライアントが定義できる。

#4：目標値のグラフ化

　本システムはクライアントが計画した栄養摂取目標と実際の摂取栄養成分をグラフ化する。クライアントは任意でグラフ化する期間（1週間、1カ月、6月6〜21日など）を指定することができる。

#5：分量変換

　本システムはクライアントが品目の量の変更（例：450グラムから112グラム）や単位の変更（例：1ポンドから64グラム）を行った場合、自動的に栄養成分をアップデートする。

　これで提供すべき動作に関する基本概念は固まった。では次は何をすればいいだろうか？ そう、このシステムの中にはクラスにできる概念がいくつかあるのだ。クラスを決める判断基準はいくつかあるが、最も重要なのは、（1）候補に挙がっている概念がここで扱う範囲内で有意義かつ特定可能な動作をすること、そして、（2）候補概念が（通常は）この動作の対象となる関連データを持っていることだ。

　おそらくFoodItem（品目）とMeal（食事）のクラスを使うのはすぐに分かるだろう（これらがなければ栄養管理アプリケーションが成り立たない）。では、XDEの中でこれらのモデリングをすぐに開始するのだろうか？ それはまだ早い。いまはAMの核となる「身軽な行動」（最低限必要なドキュメントとモデルだけを作るということ）の原則に従い、とにかく身軽にしておこう。そして、次にこれら2つのクラスの役目を定義する。ここでは表2に示されるように、標準のインデックスカードやCRC（Class-Responsibility-Collaborator）アプローチを利用することができる。

クラス：FoodItem
役割	コラボレータ
自身の栄養成分とその量を保持
クラス：Meal
役割	コラボレータ
自身の栄養プロファイルを保持	FoodItem
表2　クラスの役割の定義

　ストーリーやCRCカードを使うことは、AMの「Create Several Models in Parallel and Iterate to Another Artifact」（複数のモデルを並行して作成し、別の成果物にも繰り返し利用する）の慣習に従うことになる。

　ここまでくれば、自分がMeal（食事）とFoodItem（品目）との間の関係の基本的な意味を理解しているか確認するため、ホワイトボードを使ってUMLクラスの簡単なダイアグラムを描くことができる。これは結合だろうか、集約だろうか、それとも合成だろうか？ さて、結合は対等の関係であり、そこには全部に及ぶ関係があるように思える。合成は一度形成されたら不変となる全部のために使いたいので、集約がベストチョイスのようだ。

　AMの「Prove It with Code」（コードによって証明する）の慣習に従い、これでXDEを起動してごく簡単なモデルを入力していく（画面1）。

画面1　XDE／Javaモデリングウィンドウ（クリックで拡大）

　

1/2

　

本記事は「The Rational Edge」に掲載された「The CASE (Tool) for Agility: Rational XDE 」をアットマーク・アイティが翻訳したものです。