ここにきて、アジャイル開発手法を業務システム（アプリケーション）の開発に適用しようとする動きが本格化している。これまで小規模、Webシステムへの適用が目立ったが、最近は業務システムや大規模プロジェクトへの適用事例も出てきた。アジャイルはもはや“ブーム”ではなく、本格的な普及が始まったと見てよさそうだ。

　ところが、実際にアジャイルを採用した現場に話を聞くと、何とことごとく失敗している。そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。さらに業務システムへの適用となると、コストや納期の制約があり、品質優先で開発を繰り返しながらシステムを成長させていくアジャイルと考え方が相反する面がある。

　それでも開発現場はアジャイルに望みをかけている。刻々と変わる要求やリスクに迅速に対応する必要があるからだ。最近ではユーザー企業や自社の幹部が「うちもアジャイルをやろう」とトップダウンで取り組むケースも増えている。いやが上にも開発現場がアジャイルに引きずり込まれる状況になっている。

　では、業務システムの開発にアジャイルは適用できないのか。答えは「ノー」である。実際にうまくいっている現場はある。日経SYSTEMS2010年9月号の特集1「成功するアジャイル、失敗するアジャイル」では11の事例を通じて、難しさを克服した現場の成功テクニックを紹介した。

　特集の取材で記者は「アジャイルはウォーターフォールよりも難しい」という声をよく聞いた。同時に、この現場の声にこそ成功のヒントが隠されていると感じた。ウォーターフォールと比べたアジャイルの難しさとは、言ってみれば“落とし穴”である。落とし穴がどこにあるかを見抜き、穴を埋める工夫さえすれば成功の道が開けるわけだ。

　一見簡単にも思えるアジャイルだが、なぜウォーターフォールよりも難しいのか。多くの取材を通じて、その難しさは大きく四つあることが分かった。

難しさ（1）終わりなきイテレーション

　一つ目は、イテレーション（反復）に関する難しさだ。2週間や1カ月という短い周期で設計・実装・テストを繰り返すアジャイルでは、慣れないと期間内になかなか機能が出来上がらない事態に直面することがよくある。

　もちろん仕様の変更や突発的な作業によって、機能が完成しないこともあるだろう。この場合、次のイテレーションにその機能の開発を回せばよい。ところが、取りこぼし分の機能が積み上がり、プロジェクトがどんどん苦しくなる状況に陥ってしまう。そして“終わりなきイテレーション”に突入する。

　根底には三つの原因があると考える。（a）何を作るかという要求がほとんど決まらないままイテレーションを始める、（b）作業の負荷を考えずに各イテレーションの機能配分を行う、（c）イテレーションの反省を次のイテレーションに生かせない――である。

　アジャイルでも要件が特に複雑な業務システムについては、やりすぎない程度で要求定義が必要になる。さらには習熟や作業内容を考慮して、開発すべき機能数をイテレーションごとに割り当てなければならない。

　振り返り（レトロスペクティブ）と呼ぶ会議体によって、イテレーションそのものの質を高める工夫も必要だ。これらを実践するにはウォーターフォールとは違ったノウハウがいる。