不確実性が低い案件にアジャイルを適用すると

 不確実性が低い案件とは、プロジェクトのゴールの時点で、現在と状況が変わらず、要件定義した通りに実装すれば計画通りの価値が得られることが強く想定されるプロジェクトです。このようなプロジェクトには見直しが必要な要素がないので、イテレーションごとに計画やユーザーストーリーリストを見直すアジャイル開発よりも従来型開発の方が適しています。そこに無理にアジャイルを入れると、「見直す」「変える」方向のバイアスが生じてしまい、かえって回り道になります。

 たとえばこんな失敗をしたことがあります。ユーザーからの依頼は、保証が切れた古いバージョンの開発言語で開発していたプログラムを新しいバージョンに移行してほしいというものでした。「現在のプログラムの使い勝手は問題ないので、修正は必要ない。とにかく最低限の費用と期間でそのまま移行してくれれば良い。不具合もあるがそれを織り込んだ運用も確立しているのでそのまま移植してほしい」という不確定要素が何もない案件で、今であれば従来型開発でやる方が適切だと判断できます。

 ところが当時の私は、アジャイル開発のアプローチを取り入れ、「イテレーションごとにお客さまの価値を最大化する」というお題目に沿おうとして、もっと良い方法はないかと見直し、変更できるところはないかを模索しながら、プロジェクトを推進しました。

 結果、移行が終わった時点で確かにプログラムは少し良くなりましたが、予算も期間も当初想定の2倍かかってしまい、「お金も時間もかけずにそのまま移行したい」というお客さまの真の満足を得ることはできなかったのです。

アジャイルを実際にやってみて失敗した人へ