要件定義書に書くべき内容
要件定義書に書くべき内容は何か考えてみたい。
要件定義書という言葉を分解すると、要件を定義した書となる。
当たり前だが、要件を、定義するのである。
ものによっては、イメージ図やフロー図が記載されいるが、これらはあくまでも補助的な資料である。これらは定義された要件ではないため、イメージ図通りにシステムを作る必要もないし、フロー図に従う必要もない。大切なのは、要件なのである。イメージ図通りに作らせたいならば、「イメージ図XXに従って機能実現すること」「フロー図XXに従って機能実現すること」というような要件を書くべきである。
要件を定義するとは？
では、具体的に、要件定義書に記載すべきことは何であろうか？これは簡単である。要件に番号(識別子)を振り、システムに対して望むことを一覧形式で記載すればよい。ここで大切なことは、ベンダに対する命令であることがわかるような表現にすることである。なので、〇〇すること、〇〇できること、〇〇しない、といったような、するしないに関する立場を明確にした表現が必要なのである。「〇〇を実現」というような表現は、するのかしないのかはっきりしないので好ましくない。下記に記載要件の例を示す。
要件定義書へ記載する要件の例
要件１：〇〇の場合に、〇〇が、〇〇できること
要件２：〇〇の場合に、〇〇が、〇〇できること
要件３：〇〇の場合に、システムが〇〇すること
要件の段階的詳細化が重要
ここで出てくる一つの疑問が、粒度が荒すぎるのではないかという疑問である。結論からいうと、最初は荒くてよい。通常、システムを開発するときは、顧客は何らかの問題を抱えており、それらの問題を解決するために、課題化が行われる。この課題を解決するために、システムに求められることが、要件なのである。
顧客の問題を解決するためにシステムに求められる要件は、初期の段階においては荒くてよいのだ。初期段階において大事なのは、顧客の問題が何で、システムに求められていることは何か、全体感としてわかることが大事なのだ。
しかしながら、要件が荒いままでは、システムを完成させることはできない。そのために要件の段階的詳細化が必要となる。
例えば、テレビリモコンというものの要件に下記要件があったとする。
- 課題：テレビに近づかなくても、テレビの電源をつけられるようにしたい
- 要件１：リモコン操作でテレビの電源をつけられること
この要件を実現しようとした場合、もう少し細かく要件を詳細化する必要が出てくる
その時に、要件１を深堀すればよい。例えば、
- 要件１-１：リモコンの電源ボタンを押下することで、テレビの電源をつけられること
というように要件を深堀詳細化していくことで、そもそもの要件に不足がある(オフする場合の考慮も必要)ということや、用語の定義があいまいである(テレビの電源がつくとはどういう状態なのか)という点に気づくことができる
段階的詳細化は、顧客とベンダの認識齟齬を排除していくために、重要な工程なのである。よく、薄い要件リストに対して、ベンダがQA表を作成していき、もとの要件定義書はほったらかしという開発があるが、私の考えとしては、それらのQAはもとの要件定義書に組み込み、要件を厳密化していくべきだと考える。
要件定義は、顧客とベンダでひざ詰めで行うもの
これらの作業は、顧客とベンダ間で双方向のやりとりが行われる作業である。したがって、顧客が抱える問題を明確化する能力、顧客が抱える問題・課題を言語化する能力が必要となる。これがいわゆるコミュニケーション能力というものであり、要件定義工程で最も必要な能力なのだ。
