2009年2月12日および13日、東京目黒において「Developers Summit（通称：デブサミ）」が開催されました。このイベントは、デベロッパーコミュニティとの連携から生まれた総合ITカンファレンス。今回は「つなぐ、つながる、そして未来へ」をテーマに、さまざまなセッションが行われました。今回は、イベント1日目に行われた、日本アイ・ビー・エム株式会社 ソフトウェア事業 Rationalテクニカルセールス＆サービスの藤井智弘氏による「Eclipse-Way：分散アジャイル開発のためのプラクティスとその事例」の内容を紹介します。
オープンなアジャイル開発手法の実例「Jazz Project」
IBMはRationalの買収後、社内の製品開発をRUP（Rational Unified Process）をベースにした反復型のプロセスで運営している。また、一部の製品については3年ほど前からEclipseのようなアジャイル型の開発スタイルを、分散した開発組織で実践している。そして、今回紹介する「Team Concert」という製品開発プロジェクトのように、IBMの開発手法もRUPからアジャイルに転換しつつある。そこで藤井氏は、積極的にアジャイルにアプローチしていこうという活動を行っている。
最近はアジャイルに関する分かりやすい書籍なども出てきて、事例もたくさん出ている。そこで、多くの企業などはこれは良さそうだということになりチャレンジしようとするのだが、計画の時点で止まってしまうケースが非常に多い。これは、アジャイルに関するリファレンスがなく、事例においてもリファレンスになるような細かいものがないためではないかと考えている。
Team Concertは、オープンソースと同じようなスタイルで製品開発を行おうとするJazz Projectが主導している。具体的には、何を実装するかを決める段階からコミュニティにアイディアを公開し、コミュニティの人からフィードバックをもらう。また、商品としての成熟度が上がる前からソースコードをダウンロードできるようにして機能拡張のリクエストなどをもらっている。
また、あらかじめリリースの公開時期と機能を掲載しており、IBMのコンフィデンシャルな情報以外のTeam Concertの開発経緯をすべて公開している。これは、従来のIBMの製品開発とはまったく異なるモデルであるが、開発状況がどうなっていて、現在どのようなバグが発生しており、誰の生産性が高いのかなど、すべての状況を把握できる。
IBMとしては当然ながら製品を売りたいのだが、このJazz Projectのサイトそのものがリアルな実践例であり、コミュニティからのフィードバックが、より製品の価値を高めるという考え方から、このサイトを公開している。メールアドレスの登録だけで閲覧できるので、ぜひ利用して欲しい。
Eclipseの開発プロセスを発展させた「Eclipse Way」
ではまず、Team Concertの製品開発プロセスの基本プラクティス「Eclipse Way」について紹介する。下図がEclipse Wayの体系を示したもので、それぞれのプラクティスがどう影響し合うのかを考えている。アジャイルの特質としてはまず、必ず動くコードで進行状況を測っていく「ライブベータ」がある。お客様にライブベータを確認してもらい、コミュニケーションの上で具体的なフィードバックをいただくわけだ。
「マイルストーン・ファースト」は、常にマイルストーンを決めていくというもの。典型的なウォーターフォールでは、誰が作業しても同じアウトプットが出るという前提で、作業（WBS）の最終的な標準化ということになるが、マイルストーン・ファーストではものを考えるのではなく、最終的なリリースに向けてその中間、中間で何を達成するのかという考え方だ。
「アダプティブ・プランニング」は、プロジェクトを運営している真っ最中にプランニングがどんどん変わっていくことがある。具体的には、お客様側のビジネス上の理由で作ろうとしているものの優先順位が変わったり、予想していなかったテクニカルなリスクが発生することがある。これらの要因に合わせて作業の内容を変更していくというもの。
「継続した統合」や「継続したテスト」は、例えば統合と回帰テストを繰り返してクオリティが一定の水準をクリアしていることを常に確認しながら開発を進めていくというものだ。さらに「レトロスペクティブ」は振り返りと訳すことがあり、イテレーションが終わった時点で達成できたことやできなかったこと、新しく発見されたこと、この先やることなどの棚卸しを行っていくというもの。これにはプロジェクト自体の軌道がずれていないかを短いサイクルで確認するという意味もある。
Team Concertでは、これらのプラクティスすべてを適用しているため、純粋なアジャイルといって差し支えないと思う。また、Eclipseでの私たちのラーニングとして、「コミュニティを巻き込む」「new ＆ noteworthy」を追加している。スクラムやXPがお客様とがっちり組むのと同様、特定のお客様の顔が見えない製品開発では、オープンに情報を公開してコミュニティからフィードバックを得ていくわけだ。これは、さまざまな立場の不特定多数の方からさまざまな意見が出てくるということであり、それを強く意識して開発を進めることになる。
スクラムやXPのようにお客様の代表者のみの意見を聞くわけではないので、当然発想も変わってくる。まずはコミュニティを巻き込むためにどうするかを考える必要があるだろう。さらに、アジャイルと言うと小規模に効果的であるという共通のイメージがあるが、業務システムやパッケージシステムといった商品の開発を考えると、ドキュメントやモジュール、ライブシステム連携など、周辺のさまざまなものも作っていかなければならないため、規模が大きくなっていく。そうすると50人や100人といった規模でもアジャイルを有効活用できるプラクティスが必要になってくる。
それが図の「スケールアップのためのプラクティス」になる。規模の大きな開発では、チームの全員が一つの部屋で作業することはあり得ない。そこにはオフショアやニアショア、場所が離れていたり時差があったり、言語が違うということが考えられる。このような環境の中で、どのようにアジャイルを展開していくかということが私たちのターゲットであり、Eclipse Wayでもそれを見据えたプラクティスとなっている。
