システム開発の虎ノ巻

プロマネ初級者必見!システム開発の鉄板ノウハウをいつでも使える形に!徐々に充実させていきます!

<要件定義のポイント>追加要件や要件変更は発生することを前提にせよ!

f:id:tsunetsune7:20200116222138j:plain


要件定義工程の主な目的は、「業務要件を明確にしてシステム要件に落とし込む」ことで、要件を漏れなく洗い出して明確にすることです。しかし、現実には「人間だもの」、すべてを完璧にこなせる訳ではなく、時間が経てば意見も見方も変わることがあるし、体制変更で上司の意見に振り回されることもあります。そして、ウォーターフォール型の開発スタイルでは、そのような変更は大きな手戻りとなる訳です。そのため、「追加要件や要件変更は必ず起こるもの」と考えておくのが、無難です。

だからと言って、どうせ変更が入るから程々にしておいてもいいや、ではありません。きちんと確定した要件に対する追加要望であれば、概ね基本設計完了後は変更管理として、軽微な変更などの場合であればオンスケで実施するか、軽微な内容で済まないようであれば別費用(予算)&別スケジュールで進めるかなどの判断に持ち込むことができますし、それ以外であれば追加要件として振り分けることができます。

もっとも良くないのは、グレーゾーンを作ってしまうことです。このような場合、ユーザーは(システム側の)要件漏れを主張してきますし、システム側は追加要件を主張することになりますが、原則として力関係はユーザーの方が上です。この事実については賛否両論あろうかと思いますが、そもそも資本主義社会では、お金は権力の高い方から低い方へ流れるという大原則があるので反論しても致し方ありません。

なので、身を守る意味でも要件定義はグレーゾーンを作らないようにきちんとやりましょう。

ポイント

  • 後々追加や変更が入らないような完璧な要件定義は無理。
  • 要件定義では、グレーゾーンを作るな!