アジャイルに開発できないパターン

概要

アジャイル開発は良いソフトウェアを開発できる優れた手法であると思いますが、
世の中の全ての製品をアジャイルで開発できる訳ではありません。
以下に、アジャイル以外の開発手法を取るしかないと思うパターンを示します。

受注前に見積もりする必要がある

cannotajile1
ほとんどの場合、受注に競争がある。
・プロトタイプ作成→フィードバックをもらい仕様を固める
・プロトタイプ作成→プロトタイプの工数を元に全体の工数を見積もる
等のアジャイル手法が使えない。
※プロトタイプを作成時点では「受注」しておらず、「ただ働き」である為。
受注を得る為の最低限の「必要経費」としてプロトタイプ作成が認められない場合。

営業が仕様を決めて受注を取る

cannotajile2
チーム外またはチームの一員(営業等)が、
チームメンバー全員の合意を得ずに仕様・納期等を決める場合

顧客が開発に協力的にでない

cannotajile3
顧客がチームに参加できない。
(やる気がない、忙しい等)
顧客の協力が得られないとプロダクトオーナー不在という事態になり、
スクラム開発の定義ではスタートから破綻している。

メンバーに決定権がない

cannotajile4
仕様を変える⇒スコープを減らす等の話し合いの結果をチーム外の人間(組織の上司)等が認めなかったり、納期の短縮、スコープの追加等を強制される場合
スクラムで言うプロダクトオーナーに権限が不足しているという事なのでこれもスクラム開発の定義ではスタートから破城している。

仕様書ベースの契約

役所等の仕事に多い。
まず仕様書があり、その仕様を満たす前提で契約が履行されたか否かが判定される為、
仕様変更を伴うスコープ調整等の交渉の余地はない。
顧客が支払う報酬、期日も仕様書に記された仕様分の予算に固定されている。
と言っていたらいつまで低予算で良い開発ができず、ひいては税金の無駄遣いになるので、
どこかで誰かがアジャイルベースの契約の前例を作る必要がある。