はじめに

◆この記事は何？
要件定義、見落としがちな「業務要件定義」の注意点とその対策を紹介する記事です。

◆対象は？
要件定義に関わる方

◆この記事のねらい
皆さんの要件定義（とその後のフェーズ）が少しでも楽になれば幸いです。

先に結論

業務要件定義の遅延はシステム要件定義のバッファを消化する
結果、エンジニアの負担が増える
業務要件定義はハイペースで進めるべき

要件定義

要件定義は大きく二つに分かれます。
「業務要件定義」と「システム要件定義」です。

「システム要件定義」はシステムの仕様書になります。

そしてシステム要件は、より上位にある業務要件から生まれます。

そのため「業務要件定義」の後に「システム要件定義」を行います。

よくある要件定義のスケジュール

一括契約ではなく多段階契約を結ぶ場合、「要件定義まで」で契約を分ける契約があります。
この場合、計画は「要件定義+バッファ」となることがあります。

前述の通り要件定義は「業務要件定義」と「システム要件定義」に分かれます。

よって計画は、
①業務要件定義
②システム要件定義
③バッファ
となります。

業務要件定義が遅れるとどうなるか？

「業務要件定義」が遅れると「システム要件定義」が遅れます。
つまり、当初確保していたバッファを消費します。最悪の場合、次工程も圧迫します。

「業務要件定義の遅延」は、気づきにくいのが難点です。
業務要件定義とシステム要件定義に分解できていなければ、ただ「要件定義が遅れている」と認識することになります。

「業務要件定義の遅延」の影響を知らない組織は、同じ過ちを繰り返します。

その結果、エンジニアを苦しめる羽目になります。

対策

業務要件定義の遅延に対する対策です。

(1)そもそもバッファの考え方を改める

次のように考えることで、業務要件定義の遅延の影響を小さくできることがあります。

①業務要件定義
②業務要件定義の要件定義のバッファ
③システム要件定義
④システム要件定義のバッファ

(2)ハイペースで進める

「業務要件定義」はハイスピードで進めることを心がけます。

書籍『要件定義トラブルの予防と対策136』より引用します。

ハイペースを心がける
通常のプロジェクトでは、要件定義フェーズの雰囲気はまだまだ和気あいあいとしたものです。顧客の回答は遅れ、会議は延期され、時間が来ると「続きは次回」となります。
危機感は全くありません。しかしここで思い出すことです。要件定義フェーズでの1日の遅れは後フェーズの作業では何日の遅れになるのか。

要件定義はハイペース、さらにいえば、業務要件定義をハイペースで進行することが、プロジェクトの成功につながります。

おわりに

この記事では、業務要件定義の遅延の影響とその注意点について紹介しました。

対策として、業務要件定義の影響を加味したスケジュールの立て方、心構えを挙げました。

参考になれば幸いです。

参考

『要件定義って食べれるの？』

「ツボ【2】多段階契約の意味を互いに理解する」

『要件定義トラブルの予防と対策136』