アジャイル開発手法ではオフショア開発でも有効ではないか、という調査結果

アジャイル開発手法はオフショアを用いた開発でも使えるのか？ この問いはアジャイル開発手法を議論する場で何度となく発せられている質問です。小規模なチームが発注者を巻き込んでコミュニケーションを密にとり、短期間の開発を反復して行うアジャイル開発手法は、地理的に離れた場所にあったり、文化的に異なるバックグラウンドを持つ人たちで構成されたチームでも有効なのでしょうか？

アジャイル開発手法のコンサルティング業務などで知られるテクノロジックアートと、アジャイル開発手法の論客マーチン・ファウラー氏が所属するThoughtWorksが主催して12月8日に都内で行われた「Agile Conference tokyo 2009」では、日立製作所の山中敦氏が、オフショアと協力して行ったアジャイル開発の例を紹介しました。

果たしてアジャイル開発はオフショア開発の現場でも機能したのか。この記事では山中氏が行ったプレゼンテーションの内容を紹介していきましょう。

事前に2カ月の準備や計画

山中氏の説明によると、今回の開発案件は、プロジェクト支援などを行う社内システムへの機能追加で、管理者用にはクライアント･サーバ型のアプリケーション、利用者用にはWebブラウザで利用可能なアプリケーションとなっています。開発規模は、サーバ側のJavaが約30万ステップ、クライアントのVisual Basicが約5万ステップ。

中国上海にあるオフショアのメンバーとは日本語でコミュニケーションを行います。アジャイル開発手法を採用するに当たり、テクノロジックアートのコンサルテーションと教育を受け、また、オフショアのキーマンも日本に招き、事前にアジャイル開発手法の教育を受けてもらったそうです。

こうした事前準備や計画に約2カ月をかけた後、実際の開発を開始しています。

開発は約1カ月を1スプリントとする反復型の開発で、スプリント1、スプリント2は国内でオフショアのキーマンと一緒に開発を行い、スプリント3からはオフショアのキーマンが中国上海の拠点に戻り、現地でのプロジェクトリーダーやブリッジSEを担当する形式での開発になったとのこと。

ブリッジSEを通常より3倍に

今回のシステム開発では、オフショアとのコミュニケーションを強化するために以下の施策をしたとのことです。

• 約3倍のブリッジSEを配置
• 国内、オフショア拠点間のスクラムマスターミーティング実施
• 月に1度あるスプリント立ち上げと終結の期間にはオフショア現地出張

ウォーターフォールでのオフショア開発では、プログラマ20人か30人に1人程度のブリッジSEを、アジャイル開発の今回は約3倍に増やして、日々の仕様確認、プロダクトオーナーとオフショアとのコミュニケーションを強化。

また、スクラムマスターミーティングは週3回テレビ会議を実施。1回15分程度で、プロジェクトのマネジメントに関することを中心に話し合い、月に1回の現地出張では、スプリントのふりかえりと、次のスプリントの計画ミーティングを現地で行いました。

このようにプロジェクトにおける重要なコミュニケーションはフェイス・ツー・フェイスで行ったことを山中氏は紹介しました。

今回のプロジェクトでは生産性はウォーターフォールと変わらず

さて、オフショアを含むアジャイル開発手法の結果はどうだったのでしょうか？

過去のウォーターフォールでの生産性と、今回のアジャイル開発手法の生産性を比較した結果、アジャイル開発手法ではスプリントごとの生産性にばらつきがあり、ウォーターフォールよりも高い場合、低い場合などがありましたが、平均するとウォーターフォールとほぼ同等の結果が出ていると、山中氏は結果を発表しました。

アジャイル開発手法では一般に生産性が高くなると言われていますが、これはブリッジSEの強化などによる影響が原因ではないかと山中氏は推測しています。

一方で、開発チームが回答したアンケートでは全体的にアジャイル開発手法への満足度は高く、特にオフショアメンバーの満足度が国内メンバーよりも高くなったことが特徴となっています。満足度が低い部分は仕様の理解、プログラムの理解についてでしたが「アジャイルはウォーターフォールよりドキュメントが揃わないので、そこに苦労したのかなと思った」（山中氏）。

できあがったソフトウェアの品質については、オフショア開発チームでは従来より高くなったと考える人が多い一方で、国内メンバーはそれほど変わらないと考えているようだ、という結果となりました。

アジャイル開発手法はオフショアでも有効

山中氏は今回のプロジェクトを振り返り、次のようにまとめています。発言をそのまま引用します。

「アジャイル開発手法は、ドキュメント作成作業が軽減され、作業にとりかかりやすく、ドキュメントではなく実際に動くソフトウェアで仕様の確認をするため、確認作業が明確で手戻りが小さく、仕様変更にも対応しやすい」

「また、アジャイル開発手法では、オフショア開発でよくみられたコミュニケーションミスや情報伝達不足がない」

「従来、オフショア開発では、仕様変更によるモチベーションや品質へ低下の影響が大きく感じられたが、アジャイル開発手法ではそれがなかった」

「従来、オフショア開発は、きっちりドキュメントを書いてそれをオフショアにしっかり守らせる方法がうまくいく方法だとが考えられていた。アジャイル開発手法を使うことで逆の結果が出ており、アジャイル開発手法はオフショア開発でも有効である、という結果が得られたのではないか」