はじめに
要件定義の打ち合わせを重ねると、現場から集めた要望の一覧がどんどん長くなっていきます。それを整えて要件定義書と呼んでいるプロジェクトも少なくありません。けれども、要望の一覧と要件定義書は、似ているようで役割がまったく違います。
要望は「欲しいもの」、要件は「満たすべき条件」
要望は、使う人が「こうなってほしい」と考えていることです。一方の要件は、システムが満たすべき条件を、作る人が判断できる形で書いたものです。
たとえば「画面を見やすくしてほしい」は要望です。これを要件にするには、誰が、どの業務で、何を見て、何を判断するのかを確かめ、「一覧で状態ごとに色分けして表示する」のように、確かめられる条件に置き換える必要があります。
要望は出発点。要件は、作る人と使う人が同じものを思い描ける約束です。
要望を要件に置き換える3つの手順
まず、要望の背景にある困りごとを確かめます。同じ困りごとから出てきた別々の要望は、一つにまとめられることがあります。
次に、あるべき業務の流れに照らして、その要望が本当にシステムで解決すべきものかを判断します。業務のやり方を変えることで、システムの機能がいらなくなる場合もあります。
最後に、残ったものを、確かめられる条件として書き表します。「速く」「使いやすく」のような言葉は、数字や具体的な動きに置き換えておきます。
要件定義書に入れておきたいこと
要件定義書のチェックポイント
- プロジェクトの目的と範囲（今回やらないことも含む）
- あるべき業務の流れと、システムが担う部分
- 機能の要件と、性能・セキュリティなどの非機能の要件
- 要件ごとの優先順位と、決めた人・決めた理由
まとめ
要望の一覧は、要件定義の材料です。材料を整理し、判断し、約束の形に書き直す作業こそが要件定義です。この違いを関係者で共有しておくだけで、打ち合わせの進め方は大きく変わります。
執筆ディシェアー ITコンサルティングチーム
大手企業様のITプロジェクトで、要件定義、関係部署・ステークホルダーとの調整、プロジェクトの推進を担っています。