米IBM Practice Leader Agile DevelopmentのScott W.Ambler氏

19日、東京都千代田区において、IDGジャパン主催の技術カンファレンス「JavaWorld Day 2007」が開催された。JavaWorld Dayは、昨年末まで定期刊行されていたJavaWorld誌の内容をライブで技術者へ伝えることを目的として始まった技術カンファレンス。同誌が休刊になった現在も、継続して開催されている。

7回目を迎えた今年のJavaWorld Dayでは、「The Agile Modeling(邦訳:アジャイルモデリング)」などの著書で知られるScott W.Ambler氏をはじめ、国内外の著名なエンジニアによる10のセッションが設けられた。ここでは、同カンファレンスの中からScott W.Ambler氏の基調講演を取り上げ、その模様をお伝えしよう。

アジャイル開発に対する9つの誤解

Ambler氏は、アジャイル開発の伝道師として知られる人物である。主な著書に「Agile Modeling」「Agile Database Techniques」「The Enterprise Unified Process」などがあり、現在は、米IBMにおいてPractice Leader Agile Developmentという立場で業務を遂行している。また、国際的に活動を続ける業界団体「International Association of Software Architects (IASA)」においてフェローを務めるほか、「Eclipse Process Framework (EPF) Project」のコミッターとしても活躍する。

そのような経歴を持つAmbler氏の講演は、アジャイル開発に対する誤解を解くことから始まった。

氏は講演の冒頭、アジャイルプロセスを「必要最小限の"セレモニー"によって進める反復型のアプローチ」と定義したうえで、アジャイル開発に関する9つの誤った"神話"を紹介。それらを以下のように正した。

  1. ドキュメントを作成しない → 作成コストを意識して、価値のあるドキュメントだけを作成する
  2. 規律がない → 適切な規律が求められる
  3. 計画性がない → Just-in-timeの計画が求められる
  4. 先見性がない → 先を見据えた開発手法である
  5. 大規模開発には向かない → Eclipseのような大規模プロジェクトでも使われている
  6. 流行ものにすぎない → 近い将来標準となるだろう
  7. 銀の弾丸(すべての問題を解決する魔法のようなもの)である → 習熟した技術者によって成し遂げられるものである
  8. RUPはアジャイルプロセスではない → RUPは柔軟にカスタマイズできるアジャイルプロセスである
  9. 実績に応じた開発費の変更が難しい → 予算、スケジュール、開発規模をステークホルダーがコントロールできる

アジャイル開発では、動作するプログラムを最重要視し、2週間などの決められた期間で定期的にリリースを行う。さらに、それに対するユーザーからのフィードバックを順次取り込み、顧客にとって利用価値の高いシステムを提供するというアプローチになる。

ウォータフォール型プロセスのように、顧客が求める結果に対して直接の関係がない成果物(ドキュメントなど)はあまり作成しないため、「従来のように、プログラムは一切作成していないのに開発作業の6割が終わったなどと放言するようなことにはならい」(Ambler氏)という。また、「そもそも、そのような(認識の甘い)プロジェクトが開発を継続すべきではないことは、冷静に考えればわかることだ」とも続けた。

プログラミングにおけるポイント

Ambler氏は、アジャイル開発におけるポイントをJavaプログラミングに関連するものとそれ以外のものに分類して紹介した。

Javaプログラミングに関連するものとしては、以下の4つを挙げる。

ペアプログラミング

エンジニアが2人1組になって行うプログラミング手法。1人がプログラミングをしている間、もう1人はチェック役に回り、作成しているプログラムが正しいかどうかをその場で確認する。一見、開発効率が落ちそうに思えるが、「開発者がダラダラと遊ぶようなことがなくなるため、生産性は大幅に向上する」(Ambler氏)という。

リファクタリング

振る舞いを変えずにコードを最適化する作業。「変数の名前を変えるといった些細な変更を行うだけでも、後行程の作業効率が大きく向上する」(Ambler氏)という。

継続的インテグレーション(Continuous Integration)

「1日数回、定時に自動ビルドを実行する」といった具合に、頻繁(継続的)にビルドを行うこと。コードの差分を減らせるため、ビルド失敗時の原因特定が容易になり、開発生産性の向上に寄与する。サポートするツールとしては、Maven/Continuum、Cruise Contorl、Rational Build Forgeなどがある。

テスト/振る舞いドリブン開発(Test/Behabior Driven Development)

プログラムの仕様をテストコード(もしくは、テストとして実行可能な振る舞い定義)として先に書き出し、それらをパスすることを目標にプログラミングを進めるという手法。「ドキュメント(仕様書)の作成を義務づけるよりも、開発者に受け入れられやすい」(Ambler氏)という。