小刻みの開発を繰り返すことの利点と欠点

ソフトウエアの開発企業が、リリース後に商品を随時改修して、購入後の利用者にバージョンアップの機会を提供する。こうしたアフターサービスの提供はインターネットの通信速度や容量が高まるとともに容易になり、今ではOSから、ゲーム、ビジネス・アプリと幅広い領域で採用されるようになっている。アジャイル開発は、こうした潮流に先駆けて提唱され、臨機応変なバージョンアップを支える開発方式となった。

一方で今でもウォーターフォール開発への需要は根強くある。情報システムの開発を発注する側の組織の担当者は、必要な予算については早期に確定したいと考える。最終的なシステムの仕様が曖昧なまま、社内の予算承認を受けるのは不安だ。

ところが、小刻みの開発を繰り返していくアジャイル開発では、開発の初期に予算や仕様を確定できない。アジャイルでは、初期コストは低減できるが、最終的にはどのくらいの金額が必要となるかは、やりながら決まっていく。不確実性を嫌い、早期に見通しを立てたがる組織の担当者には、アジャイル開発は手離れが悪く、リスクを先送りしているように見える。

「イノベーターのジレンマ」に直面した富士通

ウォーターフォールやアジャイルといった方式は、情報システムに限定されない幅広い製品やサービスの開発や生産の基礎となるロジックである。日本では、自動車産業などのように以前からアジャイル的なスタイルの開発や生産が主流となっている領域も少なくない。

しかし情報システムの開発においては、ウォーターフォール開発が主流だった。ところが、日本のシステムベンダーがお手本としていた米国で、2000年代に入るとアジャイル開発への移行が進んでいく。

富士通も、米国でアジャイル開発が提唱され、情報システム開発の潮流に変化が生じはじめていることは当然つかんでいた。同社で技術戦略の策定を担当する岡田英人理事によると、同社は変化をとらえるべく学習を進め、アジャイル開発を手がける体制を2000年代の後半には整えるようになっていた。

しかし、アジャイル開発ができるようになりさえすれば、受注が順調に増加するわけではなかった。富士通が受注するアジャイル開発の案件は伸び悩む。

これはアジャイル開発に特有の問題ではない。新たな技術や開発手法をマスターしさえすれば、千客万来となるわけではない。なぜなら、顧客との関係を変えなければ、旧来の方式での受注が続いてしまうからである。

アジャイル開発についていえば、発注する顧客の側はウォーターフォール開発になじんでおり、開発する情報システムの予算と仕様を早期に確定したいと考えていた。ハーバード大学教授のC・クリステンセン氏がいう「イノベーターのジレンマ」に富士通は直面したのである。