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でもそれを見据えたプラクティスとなっている。
「Team First」と「ワークアイテム」の考え方
Team Concertの開発やツールの機能としての基本的なポリシーの一つに「Team First」の考え方がある。チームが基本的な発想の軸になっていて、ドキュメントを書くチームやコードを書くチームなど独自のプロセス、作業領域を持つチームが複数同時進行し、場合によってはお互いのチームをフォローしていく。また、チームは「イベント」を生成し、自分たちが現在何をしているかという状況把握を行う。あくまで個人の観点ではなく、チームとしてイベントをクリアして成果物を作り上げていくことがアジャイルの特徴だ。
また、トラッキングを強く意識していることもアジャイルの特徴。「作業依頼のチケットを発行して、それをトラッキングしていく」というスタイルは、広く知られるようになったが、Team Concertが採用するJazzの世界観では、「ワークアイテム」を軸に考える。ワークアイテムと「チェンジセット」は、ソースコードや設定ファイルなどのリソースの変更として密にリンクされている。ほかにも、チームはリリースのためにビルドを作ったり、その都度スナップショットを撮っていく。このように、ワークアイテムを軸にインフォメーションモデルを規定していくことで、誰がいつ何をするのかを関連づけ、管理することができる。
実際のRational Team Concertの開発体制
実践例としてRational Team Concertの開発をみていくと、まず「分散開発体制」を採用していることが挙げられる。この地図のように開発チームは世界8箇所に拠点がある。メンバー数は時期によって異なるが、通常は70名前後、リリースが近くなると100名くらいになり、この体制で3年間続けている。
作業のタイムラインは、この図のようになっている。これは1回のリリースサイクルを表現したもので、Team Concertでは毎年6月下旬にリリースを公開している。昨年の6月にバージョン1.0を公開しており、今年の6月に2.0をリリースすることが決まっている。最初のフェーズはウォームアップと呼び、前回のリリースに対する反省を踏まえた上で次のリリースに何を盛り込んでいくかというマスタープランを決定する。
最後の部分はエンドゲームと呼び、機能の作成は終了しているので、細かいバグを修正し商品としての安定度を高めていくフェーズとなる。このマスタープランとエンドゲームの間を、通常は4週間のスプリントで回していく。100名で4週間のイメージとなる。スプリントごとにマイルストーンを設定し、ダウンロードして使用できるものを提供するまでが4週間ということになる。一つのスプリントは「プラン」「デベロップ」「スタビライズ」で構成されており、イテレーション終了時には外部デモを必ず実施し、レトロスペクティブとnew ＆ noteworthyによって何を達成したかを確認していく。
チームの詳細
ここで、組織のフォーメーションの話としてメンバーの役割について説明する。最小単位は各チームとなるが、分散したチームはどのようなコミュニケーション手段を使っても生産効率が悪くなってしまう。このため、アーキテクチャとチームの編成、そしてロケーションはできるだけ密にするよう意識している。また、Team Concertでは階層型のチーム構成を採用しており、それぞれの階層にリードを置くことで、チームの力を最大限に引き出せるようにしている。
また、チームにはそれぞれリードがいて、チーム参加の個々のメンバーとデイリーやウイークリーのミーティングを行い、コンポーネントリードに報告する。コンポーネントが大きくなると複数のチームが傘下に入るため、コンポーネントリードはチームリードと密に連絡を取ることになる。このようなコンポーネントが世界中に分散しているため、これらの最上位としてプロジェクト・マネージメント・コミッティ（PMC）が存在する。PMCは、コンポーネント間の調整や、コンポーネントの集合体である商品の最終的な意志決定を行う。
実際にJazz Projectで計画して使用されるものには、障害レポート（Defects）、タスク（Tasks）、機能拡張（Enhancements）、ビルド・ステータス（Build status）、レトロスペクティブ（Retrospectives）、計画項目（Plan Items）、ストーリ（Stories）、RFS itemsがあり、これらを追跡していくことになる。またワークアイテムでは、Plan Item（フィーチャー）、ストーリー（Story）、タスク（Task）の3つが使用される。
プロジェクト管理のポイント
なお、お客様との話の中でよく質問されるのは、もっと上のレベルのものが多い。一つは「全体のプランはどうするのか」というもので、一般にアジャイル開発では業務を短いストーリーに区切って進めていくが、それで本当に必要な機能がもれなく実現できるのか？ という質問だ。ウォーターフォールのプロジェクトでは、初期にがっちりと決めた機能を粛々と開発していくが、議論にブレが生じることは避けられない。全体像を決めずにフィードバックだけで、予算と期間の枠内で、十分な機能を持たせることができるのか、というのである。
Jazz.netではさまざまなフィードバックを受け付けることで、リリース計画のコントロールが必要になる。そこで、プロジェクトが本来達成すべき要求などを確認するために、4つの構造となっている。基軸になるのは「ストーリー」で、ここにシンプルな操作イメージを載せていく。ストーリーに対してもう少し抽象度の高いものが「フィーチャー」である。さらにこの上に「テーマ」があり、ここでは大枠を固めている。
アジャイルの解説では、ストーリーに関連する話が多く、全体感をきちんと説明しているものが意外と少なく、それがもともと達成しなければならないことに対して漏れや抜けがないかという不安感につながっているように思う。アジャイルでは抽象度に応じて内容を切っているので、より上位の部分ではブレを気にしない。なお、テーマで設定する定義はシンプルで「エンタープライズ」「スケーラビリティ」「セキュリティ」それに「他の製品との連携」「セットアップのやり方」「メンテナンスの簡易さ」という程度である。
実際の流れとしては、商品として考慮しなければならないこと、漏れや抜けがあってはならないことはテーマで大枠を固めておき、製品に求められていることをフィーチャーで定義する。これを実際に形にするためにどう動くのかはストーリーで決めて、ストーリーを実現するためにタスクを切っていく。フィードバックについては、それに対してこのような機能を提供しましたということを明確にしたnew ＆ noteworthyというドキュメントを作成する。これによって、全体的な視点でどのような方向に向かっているか、何がどのくらい達成できているのかといった状況を把握できる。
もう一つの質問は、フィードバックにおける「好き勝手」をどうするのかという問題だ。これには、不特定多数の、いろいろな利害関係者がいる中で、いい意味で議論の方向性を誘導していく必要がある。具体的には、フィードバックのポイントを絞り込み、それに対して適切なフィードバックをもらう。また、どのようなフィードバックが欲しいのかをきっちりと定義して、フィードバックの質を上げていく。これはプランニングとnew ＆ noteworhtyで対応していくことになる。
リソース管理のポイント
また、アジャイルの導入において障害となっている点を洗い出すと、誰が何をしているのかを管理できるのかということに集約される。ただし、人の仕事をすべて管理することはアジャイルでなくても難しいことである。同じチームが同じ場所で、10名程度で作業していれば目が届くし、状況の把握やサポートもできる。しかし、規模が大きくなり分散した環境になってくると、誰が何をやっているのかが把握できなくなり、何が起こるかの予測もできなくなってしまう。
これを解決するためのポイントの一つは、チームがアジャイルのテクニックを駆使する上での阻害要因を排除していくことだ。そしてその条件は、これがTeam Concertのキモでもあるのだが、「おのおののチームの流儀を邪魔されないこと」、そして「作ったものを壊されないこと」が重要となる。とはいえ、チームが孤立した島国になってしまうと、お互いにコラボレーションすることができない。チームの独立性はある程度維持しながら、ちゃんと他のチームと協業できるよう作業を分担できる環境が必要となる。
もう一つのポイントは、リリースとビルドを考え直すことだ。共同作業ではソースコード管理システムのリポジトリがサーバにあり、Eclipseのクライアントからチェックイン、チェックアウトする。この際、個人ベースである一定のクオリティを出したうえで共有する場合は問題ないが、アジャイルの世界では実験的なコードを作って、よりよいものをマージしていきたいと考えるし、その場を楽しみながら作業しようとする傾向がある。
しかし、分散した環境ではこのようなことはできない。実験的なコードを書きたいが、共有部分には置きたくない。かといって自分のローカルに置いておくと、その情報は日の目を見ないし、作業に詰まったときに助けてもらえない。そこで、Team Concertのソースコード管理システムのエンジンでは、サーバのほかに「リポジトリワークスペース」という“サーバー上の個人用お砂箱”を作っている。見た目はクライアントのワークスペースなのだが、リポジトリとクライアントの間にレイヤを追加することで、離れた人に対して実験的なコードを共有領域を崩すことなく共有することが可能となる。後はチャットなどで差分を添付して相手に送れば、マージできる。
この方法によって、例えば状況を離れた相手に見て欲しいときに、相手のところで同じ環境を再現したり、一つの状況を離れた他のスタッフと共有し、それぞれが別のテストを同時に行うといったことも可能になる。分散開発ではリソース管理をしっかりやらないと、いつの間にかリソースが変わってしまう危険性がある。例えば完了基準をクリアしないとチェックインできないようにしたり、承認者の承認を得ないとチェックインできないようにするなど、リソースが崩れることをいかにブロックするかに重点を置く必要がある。
このように、アーキテクチャとチームをうまくつなげていくことで、規模が変わっても同じようにプロジェクトを進めていくことができる。また、無駄なことや付帯作業に発生するロスを最小限にするためにもリソースの管理は必要だ。さらには、スキルのばらつきは避けられないため、平均的な作業量を考えるよりは各マイルストーンやイテレーションの完了基準を明確にした方が良い。このような対策を行うことで、個々のチームが安心してチームワークに集中できる。分散環境では、このようなことが非常に大事になる。
