要件定義で定義できる要件は、本当の要件の８０％程度

システムテストとか開発後工程になると、かなり前に作った「要件定義書」の存在や中身が、大きくクローズアップされる。

もちろんその前から状況によっては参照される。代表例が変更管理。要件定義にないけど追加してほしい要件や、あるけど変更してほしい要件、それに開発現工程で対応してもらえるようクライアントと折衝するわけだ。

けれど、全てのその変更要求にこたえることはできない。最終納期が守れないものは無理。突然の法規制対応や、確かに定義漏れだけど対応しないと稼働後の業務に耐えないものなら、別の対応作業とBarter。そうやって調整はしていく。

毎回思うのだけれど、そもそも、

要件定義で定義できる要件は、本当の要件の８０％程度だと思うべきなのだ。

ユーザ企業がやろうが、ベンダーが代行しようが、全ての要件を定義することは無理だろう。必ず漏れる。

経験的に、完成度は８０％だと思っている。つまり２０％漏れてるくらいにかまえるべきだ。

定義漏れの責任はおいといて、ライフサイクル全体で努めるべきことは2点。

要件定義の完成度を９０以上に上げることだ。要件定義工程でできればすばらしいが、到達できなくても次工程で要件分析をうまく盛り込み、設計を進めていけば、定義漏れがたくさん見つけられるだろう。

もう１つは、1割程度の変更要求に対応するバッファを予算に積んでおくことだ。理論的にはバッファの計算式は10%÷90%なのでちょっと違うがそこは双方の営業努力でカバーということで（笑）、とにかく予算管理側の努力として1割のバッファを「捻出」しておくことは肝要だ。

この２つとも対応できずに後工程に来て「必須」の変更要求が多数出現すると、これはつらい。。。

ひまが捻出できたら、自分が何らか関わった９０くらいのプロジェクトで、統計してみたいところだ。