「アジャイル」「RUP」「Rational XDE」の融合：The Rational Edge（2/2 ページ）

[Gary K. Evans，President, Evanetics, Inc.]

　ここまでシンプルで貧弱なのはなぜだろう？ それは、私がAMの「Create Simple Content」（シンプルなコンテンツを作成する）という慣習に従っているためだ。このアプリケーションには確かに2つ以上のクラスがある。もっと分析を進めてすべてのクラスを確実に理解するようにしないのはなぜだろうか？ これらのモデルに処理や属性を付加しなかったのはなぜだろうか？ それは、作業を開始するにはこのモデルで十分だからだ。また、自動シンクロモードにしていたので、デフォルトのコンストラクタを持つJavaクラスの骨格はXDEが生成してくれたのだ（画面2参照）。

画面2　XDE／Javaによって生成されたクラスコード

　これらのクラスはどうやって埋めていったらよいだろう？ これらのクラスの中にまだ存在しないオペレーションを呼び出すテストを用意するのだ。使っているのはJUnitのユニットテストフレームワークなので、自分のXDEプロジェクトのビルド・パスに「junit.jar」ファイルを追加し、XDEの中にJUnitフレームワークと一緒にテストドライバモジュールを作成する。ここまで大丈夫だろうか。

　では、FoodItemクラスから始めよう。これの役割は、自身の栄養成分と、その量を把握することだ。私がカスタマと話をしたところ、このことは栄養成分のデータを完全にそろえたFoodItemを作成する機能になることに気付いた。そこでKcal、量、量の単位、脂肪、炭水化物、そしてたんぱく質の値を示す引数を持ったFoodItemのインスタンスを作成するJUnitテストメソッド（画面3のtestNewFoodItem()）を書いた。testNewFoodItem()の中では、assertEquals()の引数で示される条件の真偽を評価するJUnit assertEquals()メソッドを呼んでいる。

画面3　XDE／JavaのJUnitテストドライバ（クリックで拡大）

　testNewFoodItem()というこのメソッドが興味深いのは、うまくテストを実施できるコードを書く前にこのテストを書いている点だ。私のストーリーでは、データが完全にそろったFoodItemを作成できなければならないことになっているが、用意したFoodItemクラスにはいまのところ引数のないコンストラクタであるFoodItem()しかない。getName()やgetKCal()などのメソッドもこのクラスにまだ入っていない。これはつまり、testNewFoodItem()は最初の起動時に障害を起こすことを意味する。だが、これが期待どおりの動作なのだ。画面4では、テストを実行した結果としてXDEが表示するエラーをXDEのRun／Debug表示で見ることができる。

画面4　JUnitテストによるXDE／Javaのランタイムエラー表示（クリックで拡大）

　ここで私が作ったモデリング表示ウィンドウに戻り、FoodItem用のコードウィンドウを開いて、testNewFoodItem()メソッドをうまく機能させるために必要なメソッドを追加する（画面5）。これでプログラムを実行するとテストがうまくいく。

画面5　JUnitテストの通過に必要なFoodItemクラスコード（クリックで拡大）

　次に、Mealクラスに話題を移す。ストーリー2では、MealにFoodItemsを登録できることが必要だ。そこで、これを実行するテストを書こう。TestAddFoodItem()はFoodItemのインスタンスを作成し、Meal.add（FoodItem）メソッドをコールする。

public void testAddFoodItem()
{ 
    FoodItem fi1 = new FoodItem("beef、"2、POUNDS、500、5、20、50);
    Meal m = new Meal();
    m.add(fi1);
}

　だが、Meal.add（FoodItem）メソッドをまだ書いていないため、このテストはコンパイル時にエラーを起こしてしまう。そこで、Mealにこのメソッドを追加し、テストプログラムを返すようにする。これでテストはOKだ。面白くなってきた。

　よし、これでプログラムは動作している。これらの要求を検証するテストから書き始め、それからテストをうまく成功させるコードを追加していったので、これがストーリーの中の要求を満たしていることは分かっている。これでMealとFoodItemを連動させられるようになった。

　だがストーリー5では、このプログラムがポンドからオンス、もしくはオンスからグラムなどへと、FoodItemの単位の換算をしなくてはならないことになっている。考えてみたところでは、最初のアプローチとしてはFoodItemのconvert ()オペレーションが妥当だという判断に至った。だがここでちょっと考えてみたい。FoodItemのような「ビジネス」オブジェクトは、ユーティリティのような計算処理をすべきなのだろうか？ 私にはこれが気に入らなかった。なぜなら、これではFoodItemクラスのインターフェイスが台無しになるし、この変換機能は別の方法でも利用したかったのだ。

　そこで、XDEモデリングウィンドウへと移動し、量や単位を示すQuantityという新しいクラスを追加する（画面6）。これで、量と単位のあるものはすべてQuantityのインスタンスを使って表示することになる。FoodItemクラスのメンバーとしてQuantityを追加する。

画面6　Quantityクラス追加のためのクラスのリファクタリング（クリックで拡大）

　今度はコードウィンドウに戻り、FoodItemクラスでインスタンス変数の量と単位を新しいQuantityクラスのインスタンスと入れ替える。そしてgetAmount()およびgetDimension ()の両メソッドを修正し、Quantityクラスを使用する。FoodItemの共通インターフェイスを変更せずに既存のロジックをリファクタリングしただけなので、これらの変更を加えてもJUnitテストは機能する。

---

　この小さなサンプルアプリケーションの開発を考察することで、目前の作業に最適な作業を奨励するアジリティの思想を追ってきた。できる限り早くコードを書くためのXDE／Java、CRCカード、ホワイトボードモデルや、コードを書く前にまずテストを書く、といった手法はどれもうまく機能する。

　本稿ではさまざまな問題を扱ってきた。簡単なサンプルプロジェクトを発展させることでアジャイルの思想と実践が明確になったことを願っている。本稿を読んで何も得るものがなくても、アジャイルテクニックに関する一部の無知蒙昧（もうまい）な誇張表現とは逆に、アジャイルプロセスが非常にしっかりとした、要求の厳しいものであることを理解してくれるよう願っている。アジャイルなプロセスは、実稼働ソフトウェアという目に見える結果に焦点を合わせて開発を行うということなのである。

　自らアジリティについて詳しく調べていく中で、私は自分のコンサルティングプロジェクトのどの作業でも、「この作業は実稼働ソフトウェアの投入に直接寄与するだろうか？ 」と自問することを学んだ。もしその答えが「ノー」であったら、これがソフトウェアを提供するという最大の目標を達成する際に障害になることを関係者に知らせるべきだ（これは「関係者の投資を最大限活用する」というAMの核となる原理と一致する）。もしくは、いまの作業を即座に中断し、だれかが実際にそれに気付くかどうかを見守ってもよいだろう。

　私がアジャイルモデリングフォーラム（*3）に参加したときには、XPコミュニティが唱えるいくつかの概念に大きな疑念を抱いていた。XPの世界で有名なRon Jeffries氏が「プロセスの半分を排除したら寂しくはないのか？」としてグループに挑戦してきたのだ。私はこの言葉にはあぜんとさせられた。私はここ数年間、作業がどんどん減る一方で成果がどんどん上がっていたことに気付いた。私はRUPに従ってすべてのプロジェクトを進めているが、今日の私はわずか3年前にやっていたことの半分の作業しかしていないのだ。だが私は、なくなった作業をまったく恋しいと思わない。問題は「RUP」対「別のプロセス」ではないし、CASEツールの有無でも、「モデル」対「コード」でもない。可能な限りシンプルに作業を進め、実稼働ソフトウェアの提供に直接寄与する作業に専念することが大切なのである。たったそれだけのことだ。

【注釈】

*1 Peter McBreen氏の近著である“Software Craftsmanship: The New Imperative”（2001年Addison Wesley刊）はソフトウェア開発の職人気質を明確に表現している。

*2 http://www.sdmagazine.com/documents/s=7147/sdm0206d/0206d.htm参照。

*3 http://www.agilemodeling.com参照。

「The Rational Edge」バックナンバー

• トランザクション管理の複雑性を克服する（パート1）
• アジャイルとシステムテストの新たな関係（後編）
• アジャイルとシステムテストの新たな関係（前編）
• アジャイル開発の広範な普及を目指して
• 見積もりの精度 Accuracy of Estimation
• 複雑性を理解する（後編）：ソフトウェアの複雑性を手なずける
• 複雑性を理解する（前編）：ソフトウェアが複雑なのは仕方がない？
• 鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）
• 人事評価と開発者のモチベーション/パート3：役割とポリシー（中編）
• 自己管理型チームの利点と弱点/パート3：役割とポリシー（前編）
• プロセスはチャンスが訪れるたびに改善する/パート2：プロセスと基準（後編）
• 開発プロセス導入のアンチパターン/パート2：プロセスと基準（中編）
• 反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）
• 開発プロジェクト「統治」のピンポイント解説/パート1：原則と組織（後編）
• 開発プロジェクトを「統治」するベストプラクティス/パート1：原則と組織（前編）
• 初歩の「Perl」「Python」「Ruby」
• ビルドが全滅する原因/プロジェクトの状態を評価する：パート2（後編）
• 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）
• UMLを使ったビジネスモデリング（後編）：そうだったのか！ システムユースケース
• UMLを使ったビジネスモデリング（前編）:なるほど！ ビジネスユースケース
• 「この開発プロジェクトは中止！」の基準/プロジェクトの状態を評価する：パート1（後編）
• プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する：パート1（前編）
• 専門家に聞くモデル駆動開発のメカニズム
• 「設計」や「構築」よりも重宝されるスキル
• キミのコードが汚い理由
• 汎用グラフィカルモデリング言語「SysML」 パート2：グラフィカルなモデル言語で製品構造を記述
• 汎用グラフィカルモデリング言語「SysML」 パート1： 要件、ユースケース、およびテストケースのモデリング
• ウォーターフォールから反復型への移行手順
• ソフトウェアアーキテクティングのメリット
• ソフトウェアアーキテクティングのプロセス
• ソフトウェアアーキテクトの役割
• ソフトウェアアーキテクチャって何なの？（後編）
• ソフトウェアアーキテクチャって何なの？（前編）
• ITプロジェクトを見える化する
• ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
• オブジェクト指向を超えて
• ルネサンスの巨匠たちに学ぶエンジニアリングの技
• ソフトウェア開発の「いま」と「近未来」の話
• 中国のソフトウェア開発現場はこんなにスゴイ
• 隣のテストチームが優秀ないくつかの理由（後編）
• 隣のテストチームが優秀ないくつかの理由（前編）