ウォーターフォールの次に行け！〜日本のソフトウェア開発を今一度洗濯いたし申し候

なぜアジャイルが注目を浴びているのか

　最近「アジャイル開発」が大きく盛り上がっているように感じます。大規模なイベントが開催され、MicrosoftやIBM等の大手も参画。筆者の周辺では「iPadか？アジャイルか？」という勢いを感じます。最近ではアジャイル支援の仕事も増えてきました。

　では、アジャイル開発のどんなところが凄いのでしょう？ 本に書いてある通りのアジャイル開発を実践すれば本当に効果が出るのでしょうか？ 皆さんの中には、トップダウンでアジャイル導入が決まり、「どうしたらいいんだろう」と感じておられる情報システム部門の方もいらっしゃるかもしれません。

　この連載では主にユーザー企業の情報システム担当者の皆さんに向けて、筆者が長年のアジャイルの実践経験を通じて学んだ「アジャイル開発における導入成功の秘訣」をこっそりお話いたします。連載の第一回はイントロダクションとして、アジャイル開発の導入のメリットをご説明しましょう。

70％のプロジェクトを失敗させる既存の手法

　アジャイル導入のメリットはズバリ「プロジェクト成功率の向上」です。Standish Groupが2000年に発表した有名なレポートによると、ソフトウェア開発プロジェクトの成功率はなんと30%を下回っています。それほどまでにプロジェクトが失敗する理由とはなんでしょうか？ 下の図は一般的な開発手法での失敗要因をまとめたものです。

一般的な開発手法に潜むプロジェクト失敗の要因

　ウォーターフォール型の開発プロジェクトが開始すると、まずベンダーとともに要求仕様を取りまとめることになります。この段階で用意されるのは、大抵の場合は紙ベースの資料、よくてモックアップ（はりぼてアプリケーション）といった程度。基本的にユーザー側は紙で書かれた仕様書に対して「承認する」ことを求められます。

　正直なところ、動いているアプリケーションを見ないうちに、仕様を決めるのは相当に難しいことです。開発メンバーだって、実際にやってみないことには技術的に実現可能かどうかはわからないのですから。その後も、中間分析や設計の段階でキングファイルに一杯のドキュメントが作られ、それぞれに承認を求められますが、大量の技術的な文書を精査しろと言われても厳しいのが正直なところでしょう。私がその立場でも難しいといわざるを得ません。

　ところが「紙づくり」が終了して、開発者が実際にアプリケーションを作り始めると問題が一気に噴出します。「できたアプリケーションを見たら全然イメージと違う」「業務運用に耐えられない」。ベンダーから「技術的に可能と思っていたけど現実には出来ませんでした」という報告を受ける事も。高額な仕様変更料金を支払い、現場の技術者達が徹夜続きでリリースにこぎつけたとしても話は終わりません。運用で出てきた要望に対応するためにはまたもや高額な対応料金をとられるため、変更もままなりません。（次のページに続く）