分散開発とアジャイル開発は、水と油か？

“分散開発”と”アジャイル開発”は、「水と油」の関係か？

　分散開発とアジャイル開発ーこの2つは、程度の差こそあれ、多くの開発組織が関心を持っているキーワードだと言っても過言ではないでしょう。筆者の所属する日本アイビーエムのソフトウェア事業Rational部門では、Jazzプロジェクト（図1）と呼ばれる、「アジャイルな製品開発プロジェクト」を運営しており、その状況は広くインターネット上で公開されています。IBM Rational Team Concertという製品はその成果の1つです。Jazzプロジェクトはそれ自体が、海外7拠点にわたる分散アジャイル開発の実例であり、その運営からは多くのことを学ぶことができます。

　本連載では、このJazzプロジェクトの運営を題材に、分散したチームでのアジャイル開発について、その課題と解決策を論じていきたいと思います。

　そもそもこの2つの開発スタイル、一般的なイメージは以下のようなものではないでしょうか？

・アジャイル開発：開発者視点、少人数、密なコラボレーション、ドキュメント・レス、自由度の高さ
・分散開発：管理者視点、組織論、分散した開発拠点、厳格に規定されたルール、（アジャイルのイメージから比較すると）多人数、時差や言葉の壁によるコミュニケーションの難しさ

　こうして並べると、開発スタイルの両極端に位置するように見えます。だからといって、「“水”と“油”なんです、この2つは」と言いきってしまっては、話が終わってしまいます。アジャイル開発と分散開発との間に横たわるギャップを、1つ1つ具体的に検証していかなければ、“水”と“油”を結びつける化学反応を起こすことはできません。

アジャイル開発をスケールアップするための代表的な考慮点

　IBMでは、アジャイル開発をよりスケールアップしていくにあたって考慮すべきポイントとして、さまざまなポイントをリストアップしています。それは、地理的な分散状況（オフショア、ニアショア）から、コンプライアンスや規制についてまで、多岐に亘ります。順にそのポイントについて見ていきましょう。

　海外へのオフショア（Off-shore）や、国内でも地方のIT産業振興政策と結びついたニアショア（Near-shore）等々……拠点が分散することによって少々効率を犠牲にすることになっても、それを補って余りある（人件費などの）コストメリットを追求したり、独自技術の取り込むために提携したりするなど、開発拠点の分散化は大きな流れであり、今後ともとどまることはないでしょう。しかしこの流れは、密なコミュニケーションによって得られる価値を重視するアジャイル開発にとっては、最大の敵となります。われわれ日本人には厳しい言葉の問題を筆頭に、時差、労働慣習の違い等々多くのコミュニケーションエラーを産み出す要因が存在します。それらのエラーを回避するために、文書化を始めると、いつのまにか作成すべき文書の種類がどんどん増えていき……ということになりがちです。

　分散開発でのアジャイル適用は、“チームの少人数感”を維持するために、チーム編成と地理的な分散とを組み合わせコミュニケーションエラーをいかに最小化するかいう仕組み作りと、チームの集合体であるプロジェクト全体の方向性をどうコントロールするか？が重要です。

　「スケールアップする」と言えっても、そのアプローチには2種類あります。「より大規模な（場合によっては特定の）システム開発案件に適用する」というプロジェクトにフォーカスしたアプローチと、より広範囲に企業の中で複数行われている（場合によってはさまざまなタイプの）システム開発に適用するというアプローチです。後者のアプローチを取るなら、アジャイルの枠組みで語られる個々の技法の選択よりも、より組織的な”標準化”に近いアプローチ、すなわち、適用される規範をどうのようにして決定し適用、評価するか？現場での適用を推進するためのサポートチームは何をすべきか？という“仕組み作り”の観点が必要になってきます。