はじめに
◆この記事は何？
要件定義、見落としがちな「業務要件定義」の注意点とその対策を紹介する記事です。
◆対象は？
要件定義に関わる方
◆この記事のねらい
皆さんの要件定義（とその後のフェーズ）が少しでも楽になれば幸いです。
先に結論
- 業務要件定義の遅延はシステム要件定義のバッファを消化する
- 結果、エンジニアの負担が増える
- 業務要件定義はハイペースで進めるべき
要件定義
要件定義は大きく二つに分かれます。
「業務要件定義」と「システム要件定義」です。
「システム要件定義」はシステムの仕様書になります。
そしてシステム要件は、より上位にある業務要件から生まれます。
そのため「業務要件定義」の後に「システム要件定義」を行います。
よくある要件定義のスケジュール
一括契約ではなく多段階契約を結ぶ場合、「要件定義まで」で契約を分ける契約があります。
この場合、計画は「要件定義+バッファ」となることがあります。
前述の通り要件定義は「業務要件定義」と「システム要件定義」に分かれます。
よって計画は、
①業務要件定義
②システム要件定義
③バッファ
となります。
業務要件定義が遅れるとどうなるか？
「業務要件定義」が遅れると「システム要件定義」が遅れます。
つまり、当初確保していたバッファを消費します。最悪の場合、次工程も圧迫します。
「業務要件定義の遅延」は、気づきにくいのが難点です。
業務要件定義とシステム要件定義に分解できていなければ、ただ「要件定義が遅れている」と認識することになります。
「業務要件定義の遅延」の影響を知らない組織は、同じ過ちを繰り返します。
その結果、エンジニアを苦しめる羽目になります。
対策
業務要件定義の遅延に対する対策です。
(1)そもそもバッファの考え方を改める
次のように考えることで、業務要件定義の遅延の影響を小さくできることがあります。
①業務要件定義
②業務要件定義の要件定義のバッファ
③システム要件定義
④システム要件定義のバッファ
(2)ハイペースで進める
「業務要件定義」はハイスピードで進めることを心がけます。
書籍『要件定義トラブルの予防と対策136』より引用します。
ハイペースを心がける
通常のプロジェクトでは、要件定義フェーズの雰囲気はまだまだ和気あいあいとしたものです。顧客の回答は遅れ、会議は延期され、時間が来ると「続きは次回」となります。
危機感は全くありません。しかしここで思い出すことです。要件定義フェーズでの1日の遅れは後フェーズの作業では何日の遅れになるのか。
要件定義はハイペース、さらにいえば、業務要件定義をハイペースで進行することが、プロジェクトの成功につながります。
おわりに
この記事では、業務要件定義の遅延の影響とその注意点について紹介しました。
対策として、業務要件定義の影響を加味したスケジュールの立て方、心構えを挙げました。
参考になれば幸いです。