検討結果のまとめかた

 要件定義では、通常、顧客との打ち合わせのタイミングにあわせて、①検討資料の準備、②顧客との打ち合わせでの検討のための議論、③検討資料への検討結果の反映、というサイクルを繰り返しながら、検討作業全体を進めていく。
 このサイクルのうちの「③検討資料への検討結果の反映」を行う際に、1点注意すべきことがある。
 それは、決定した結果だけを反映するのではなく、決定に至る考え方を記載する、ということである。

 決定に至る考え方は、数学にたとえると方程式にあたり、決定事項は方程式で求めた答えの値にあたる。
 方程式が書いてあれば、同じ答えがいつでも出せるだけでなく、新しい課題が出てきても、方程式に当てはめることで容易に答えを導きだすことができる。

 たとえば、システムの利用実績出力対象項目を検討し、「項目A、B、C、D、Eのうち、A、B、Eを対象項目とする」と決定されたとしよう。
 しかし、決定されたことだけを記載したのでは、後日、新たな項目F、Gが出てきたときに、利用実績出力対象項目とすべきかどうかを、また一から検討しなければならなくなる。
 そうならないためには、この項目に決定した理由、決定に至る考え方を記載しておく必要がある。

 先ほどの利用実績出力対象項目の例ならば、以下のように記述をするとよい。

--------
利用実績対象項目の考え方

 ファーストリリースの開発規模を抑えるため、ファーストリリースで提供する利用実績出力機能の対象項目の考え方は以下の通りとする。

1.契約上の制限値に該当する項目
2.サーバリソースの消費量に直結する項目
  :
  :

-------

 考え方を記述したあと、実際の決定事項が確かにこの考え方にのっとっているかどうかをチェックすることにより、考え方の正当性を検証し、決定事項と共に記載する。
 このように考え方を記載しておけば、後で新たな項目の検討が必要になっても、この考え方に照らすだけで、対象とするかどうかを決定できるのである。

 ただし、検討結果の考え方をまとめるのは、思いのほか難しいことが多い。というのは、検討時の議論の中では、この考え方が明確に言葉になっていないことが多いからである。
 その場合は、言葉になっていない考え方を顧客に確認してもらうために、想定される考え方を「考え方のたたき台」や「考え方を引き出すための質問事項」などの言葉にして顧客にぶつけ、顧客の確認をとってから記載する必要がある。

コメント

このブログの人気の投稿

ヌケとモレの違いは?

類推の4つの判断パターン

パターンを洗い出すには