アジャイルでのチーム間コミュニケーション

前回の"アジャイル"にまつわっておもしろい記事があるのでその紹介をします。

アジャイルソフトウェアプロセスを使ってオフショア開発

マーチン・ファウラーさん自身が数年前にアジャイルでオフショア開発を経験されているんですね。前回の議論とも絡んで興味深かった部分を引用します。

私は、複数サイトのチームを束ねて仕事を進める際の問題に関する話をいくつか聞いた。インタフェースの定義に多くの注力を払っていても統合する際の問題は頭をもたげてくる。多くの場合これは、インタフェースの意味を厳密に指定するのが非常に難しいからだ。従って全てのシグネチャを正しく指定しても、実際にどのように実装が行われるかの仮定で躓いてしまう。

うんうん。

継続的なインテグレーションとテストというプロセスは結合の際に出てくる多くの問題を即座にあぶり出し、その結果問題を見つけるのが困難にならないうちに修正することが可能になる。

なるほど。


最初から我々はUSチームの誰かが常にインドに滞在してコミュニケーションを促進させる、ということを決定していた。（中略）コミュニケーションが改善されることで飛行機代ぐらいはすぐにペイするのだ。（中略）駐在員の任務の中で重要なものはゴシップを伝えるということだ。プロジェクトには非公式なコミュニケーションが多くなされる。ほとんどは全然重要ではないことだが中には重要なものがあり、またどれが重要なのかは分からないという点が問題なのである。だがら駐在員の任務には、正式な連絡経路では全然重要とは思えないようなちょっとした、多くの連絡をすることが含まれるのである。

これは、実は日本国内にいても、大規模プロジェクトでの各チーム間のコミュニケーションに言えることではないでしょうか。代表者（＝駐在員）が、別のチームといっしょにすごしてコミュニケーションをとることは非常に重要だということです。それ専任の人を設けてコミュニケーションを促進することでその人のコストぐらい"ペイ"できるのだ！と言いたいところです。
大規模プロジェクトでは、そういうコスト見積もりが（ほんとうは）必要でしょう。


米国にいる顧客のために、フィーチャ(XPのストーリーに相当)を肉付けして(2,3ページの)短いストーリを書くことだ。その後、インドにいるアナリストやテスターがこのストーリー向けのテストスクリプトを作る。

アジャイル開発ではテストスクリプトが重視されます。このときは、ストーリ・ベースでの検証内容を伝達し、オフショア側にテストスクリプトを作ってもらっているようですね。
チーム間の情報伝達とインタフェースをどうするかというのは難しいのですが、このときは少なくとも「ストーリ」での情報共有を実施しているようです。


開発チームをオンショアとオフショアに分ける場合、作業工程に沿って分けるのではなく、機能面に沿った分割を行う。システムを大まかなモジュールに分割し、オフショアチームにこのモジュールのうちのいくつかを任せてしまうのだ。でも、他のグループと異なり、モジュール間のインタフェース設計や仕様凍結に多大な努力を払うようなことはやらない。継続的なインテグレーションとコード所有権を重視しないことで、モジュール間インタフェースは開発が進むにつれて発展するのだ。

おもしろい内容なので長々と引用してきましたが、実はここが今回の投稿の一番のポイントです。
前回は、生産性の高い適正なチーム人数に分けるために、"アジャイル"的に開発対象を分けるか、開発チームを（工程にそって）分けるか、ということを書きました。工程に沿って分けるのは、主に建築業や製造業の方式を見習ったものです。
ここで、ファウラーさんは、さすが"アジャイル"提唱者の1人だけあって、開発対象を小分けにして、1つのチームにはなるべく全工程をまかせることが生産性向上につながる、としています。
たしかに、ITではそういうことも可能なので、おそらくもっとも生産性の高い方式は、"アジャイル"的な開発対象の分割かもしれませんね。
しかも、"アジャイル"では、そういう開発体制と手法に適した、継続的インテグレーションとそのツール、ソースコードの管理手法なども提唱されているので、チームが細切れになってもモジュール間のインタフェースに多大な労力がかかるわけではない、と言っています。にわかには信じがたいですが、うまくやれば、これもまた真なのでしょう。


アジャイル手法では、ドキュメントを作る作業の大部分は無駄に終わるという観察結果から、ドキュメント作成を軽視している。しかしながらドキュメント作成はオフショア開発においては、対面のコミュニケーションを減らすことができるのでより重要になる。（中略）でも、オフショアモデルだと、これはやらないといけない。従ってこれは、オフショア開発を行う上での必要経費なのだ。

これも、日本の縦割り開発体制で言えることなのかもしれません。理想的なチーミングではドキュメント軽視でいけるのでしょうが、同じプロジェクトルームにいながらもオフショア開発のようにコミュニケーションが欠如してしまうような環境においては、ある程度のドキュメンテーションが必要なのです。ただし、

アジャイルプロジェクトで成功するドキュメンテーションには2つ鍵がある。まず1つは、「ちょうど十分な」ドキュメント量を見つけることだ。アジャイルドキュメンテーションを成功させる2つ目の鍵は、ドキュメンテーションを重要視しないこと、あるいはアップデートし続けられるなんて非現実的な希望をもたないことだ。ドキュメントは特定の目的に役立つために作成されなければならないし、その目的に役立った後は、あなた方は誰もがおそらくそのドキュメントを更新しつづけるよりも大事なことがあるはずだ。これは、普通はにわかに信じがたいが、おそらく今度必要になった時に新しくドキュメントを作った方がいい。プロジェクトで、ドキュメントが必要になるたびに、それを作り始めることの副作用は、ドキュメント作業を効率的にしておく大きなインセンティブなのだ！

ドキュメンテーション自体が目的なのではなく、それを何に使うのかが重要だということです。
日本では、ドキュメントをお客さんの納品物とすることも多いので（ページ数とか意味ない尺度で！）、なかなか難しいところもありますが、生産性を高めるという観点では非常に重要なポイントですね。

長々と書いてきましたが、チームでの生産性を高めるということは、開発手法やプロジェクト体制、さらには契約方式やお客さんの文化などにも関わってくる非常に奥深いテーマであることは間違いありません。