アジャイル開発の本質をつかんだ各社は、大規模への適用を模索し、ハードルを引き下げる改善を続ける。アジャイル開発での品質基準の調整と、契約の結び方も見えてきた。

 まず大規模プロジェクトへの適用だ。基本的な二つのコンセプトは固まりつつある。一つは小規模チームをいくつも並行して走らせるということ。

 例えば米IBMは今年1月に出荷した開発ツール「Rational Team Concert」を3年をかけてスクラムで開発する際に、全体を管理するチームと個別機能を開発する20チームに分けて取り組んだ(図1)。全体管理は10人が担当し、関係性がある機能同士にずれが生じないように「バディ」と呼ぶ役割を設けて調整役となった。

図1●IBMは二階層に分けたプロジェクト体制で120人のアジャイル開発を成功
図1●IBMは二階層に分けたプロジェクト体制で120人のアジャイル開発を成功
開発ツール「Rational Team Concert」を2005年から7カ国に分散した開発者120人がアジャイル開発
[画像のクリックで拡大表示]

 個別機能は国をまたがり4~10人が1チームに所属し、全チームが同じ繰り返しの期間で開発を進めた。毎日のミ ーティングは時間を合わせてテレビ会議などで実施したという。「繰り返しと振り返りは大規模開発でもそのまま適用できる」と日本IBM ソフトウェア事業 Rationalテクニカル・セールス部長の玉川憲IBMソフトウェア・エバンジェリストは言い切る。

 米マイクロソフトも開発ツール「Visual Studio 2008」の開発時に、九つの主要機能を1200まで詳細化して、それぞれ一人のマネジャ、5人以下の開発担当者、5人以下のテスト担当者の組み合わせでチームを作った。開発期間は3~6週間。デベロッパー&プラットフォーム統括本部 デベロッパーテクノロジー推進部の長沢智治エバンジェリストは「前バージョンと比べてバグは10分の1に減った」と話す。

 日本ではKDDIの元CIO(最高情報責任者)である繁野高仁社長が率いる情報システム総研が、ある企業で基幹系システムの再構築をアジャイル開発で進めている。小さなチームの並行開発に加え、「長く使えるシステムにするということにも主眼をおかなければいけないので、アプリケーションのアーキテクチャを先に固めることを実施した」と繁野社長は話す。10年にわたり繰り返し型の開発プロジェクトでマネジャを務めてきたウルシステムズの河野正幸ディレクターも「概念データを先に作っておくことが大事」と同様の意見だ。