和風Agile? Part-2

和風Agile?の続き

ウォーターフォール開発に慣れ親しんだマネージャ達にAgileを売り込むときによく指摘されるのが「最初に要件も予算も確定させないAgileのやり方はおかしい」ということ。

で、「じゃぁ、ウォーターフォールで最初に『確定』させた要件や予算が正しかった事がどれくらいありましたか？」と聞いてみると、「実はそれほど正確ではない。」という答が多いのも事実。

しかも要件抜けが発覚するのがUAT段階なら良い方で、本番稼働後に発覚する事例も珍しくない。そして不思議な事に、こういう「抜け」は要件定義段階の度重なるレビューでは発覚しない。ものすごく丁寧な業務フロー図やらなんやらを描いているのに、だ。

「だからこそ、要件抜けなどに対処しやすいAgileがいいのでは？」と売り込むと、「いや、それは困る」という答。どうやらこういうことらしい。

• 発注元の立場では、まず最初に予算総額を確定させる必要がある。だからこそ、最初に要件と開発範囲を確定させる。
• こうすることで、要件漏れがあったとしても、その対処は「追加開発」として別契約・別料金にできる。
• これなら発注元も納得しやすいし、開発側も「瑕疵責任」の言葉でずるずるとただ働きさせられることがない。

お客のシステム部門は予算さえぶんどってしまえば、あとはそれを使うのみ。別に節約したからといって褒められるわけではなし。むしろ、その予算が正しく使われているかどうかを説明することが重要になる。だからこそ、最初に要件を『確定』させるのであろう。おそらくそこに漏れがあるのは内心わかっているのであろうが、責任を回避する手段はある。世の中で標準といわれているフレームワークに沿って要件定義をまとめればよいだけだ。これだけの分厚い分析資料を揃えたのだから漏れや抜けがあったとしても諦めはつく。そしてその要件定義で期間と予算がじゃぶじゃぶ消費されていることなど知った事ではない。

無責任体制と表裏一体である集団的意思決定体制とウォーターフォール開発モデルは相性がよいようだ。

そういうところにAgile開発契約を持ち込むにはどうすればよいか？
（つづく）