監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
要件定義書は、発注側の要求をシステムやプロジェクトで実現するために、満たすべき機能・非機能・制約を確定させ、関係者の合意内容を文書として残す成果物です。要求定義書で描いた「何のために・何をしたいか」を、開発が着手できる粒度の「何を作るか」へ翻訳し、後工程の設計や見積りの拠りどころにします。PMにとっては範囲と責任の境界を示す基準になります。
要件定義書は、プロジェクトで「作るもの・満たすべき条件」を関係者が同じ理解に立つために残す文書です。営業や利用部門から挙がった要求は、多くの場合「業務を楽にしたい」「ミスを減らしたい」といった目的の言葉で表現されます。要件定義書はそれを、画面・帳票・データ・処理といった具体の条件に落とし、開発側が着手できる状態にします。
読み手は一人ではありません。発注側の責任者は投資判断のために読み、設計担当は次工程の入力として読み、テスト担当は検証の根拠として読みます。誰が読んでも同じ結論になる書き方が求められるため、曖昧な形容よりも、対象・条件・例外を具体的に書くことが重視されます。
PMの立場では、この文書は範囲の合意記録でもあります。後から「これも入っているはず」という認識のずれが起きたとき、要件定義書に立ち返って、含む・含まないを確認できます。変更が発生した場合も、この基準があるからこそ、影響と追加の要否を筋道立てて話せます。
軸を「機能・非機能・制約・運用」に置くと、記載項目が整理しやすくなります。機能要件は、利用者がシステムで行える処理を指します。たとえば申請・承認・検索・出力など、業務の流れに沿って一覧化し、それぞれの入力・処理・出力を書きます。
非機能要件は、機能の裏側で満たすべき条件です。応答の速さ、同時に使う人数、稼働の継続性、バックアップ、権限やログといった観点を、業務が困らない水準として言葉で示します。数値を置く場合は、根拠となる業務量や合意した目標を併記します。
進め方としては、要求定義書を入力に、業務担当者へのヒアリングと現行業務の観察を重ね、PMまたは要件定義担当が草案を作ります。その後、利用部門とのレビューで抜けや解釈違いを潰し、優先度と対象範囲を合意して確定させます。ここでは、対応する要求と要件を対応づける一覧を添えると、なぜその要件があるのかを後から追えます。制約条件として、既存システムとの接続、法令や社内規程、稼働時期の制約も忘れず記載します。
最初のつまずきは、要求と要件を混ぜてしまうことです。「使いやすくする」という要求のまま止まると、設計側は何を作るか判断できません。要求を、対象の画面や操作、満たすべき条件まで具体化して初めて要件になります。逆に、決めていないことを断定的に書き込み、後で覆るのも混乱のもとです。
次に多いのが、機能ばかり厚く書き、非機能や例外の扱いを薄くしてしまう形です。正常時の流れは書けても、入力を誤ったとき、通信が切れたとき、権限のない人が操作したときの振る舞いが空白だと、開発とテストの段階で判断が止まります。例外と異常時の期待動作は、機能と同じ重みで書いておく必要があります。
合意の取り方も落とし穴になります。文書を回覧しただけで承認とみなすと、読まれないまま進み、後で「聞いていない」が生まれます。レビューの場で対象範囲と優先度を口頭でも確認し、決めた内容と保留した内容を記録に残しておくと、PMとしての進行が安定します。
隣接する文書との違いは、「誰の視点で・どの粒度か」という軸で捉えると整理できます。要求定義書は発注側の視点で、達成したい目的と業務上の要望を書きます。要件定義書は、その要望を実現するために満たすべき条件を、発注と開発の合意として書きます。つまり要求が「したいこと」、要件が「作るべき条件」という関係です。
基本設計書は、確定した要件を前提に、開発側の視点で「どう実現するか」を描きます。画面の詳細な構成、データの持ち方、処理の分担などが対象になり、要件定義書よりも技術寄りの粒度になります。要件定義書で範囲がぶれていると、基本設計以降で手戻りが増えるため、この文書の確定度が後工程の安定に直結します。
PMとしては、この三つを一連のつながりとして扱うのが実務的です。要求を受け取り、要件に翻訳し、設計に引き渡す各段で、抜けや解釈違いを確認していきます。境界を意識して書き分けることで、どの層で合意が取れていないのかを特定しやすくなります。
要件定義書を書き切れることは、PMとしての範囲管理と合意形成の力に直結します。要求を要件へ翻訳し、含む・含まないを言葉で示せる人は、開発が進んでからの手戻りや認識のずれを抑えやすくなります。転職の場面でも、担当したプロジェクトでどの粒度まで要件をまとめ、どうやって関係者の合意を取ったかは、具体的に語れる経験として評価されやすい領域です。
キャリアを広げる方向としては、要件を確定させる力を土台に、上流の課題設定や、後工程の設計への理解を深めていく道が考えられます。まずは自分が関わった要件定義書を、機能・非機能・制約・運用の軸で振り返り、どこを厚く書けてどこが薄かったかを言語化しておくと、次の役割を考える手がかりになります。
要件定義書は誰が書くのですか。
多くの現場では、PMまたは要件定義を担う担当が草案を作り、利用部門や発注側の責任者とのレビューを通して確定させます。書き手が一人でも、内容は関係者の合意が前提になるため、ヒアリングとレビューを重ねながらまとめていく共同作業に近い性格を持ちます。
要求定義書と要件定義書はどう違いますか。
要求定義書は発注側の目的や要望を書く文書で、要件定義書はそれを実現するために満たすべき条件を、発注と開発の合意として書く文書です。要求が「したいこと」、要件が「作るべき条件」という関係にあり、後者は前者を開発が着手できる粒度に翻訳したものと考えられます。
非機能要件はどこまで書けばよいですか。
応答速度、同時利用者数、稼働の継続性、バックアップ、権限やログといった観点を、業務が困らない水準で言葉にします。数値を置く場合は、根拠となる業務量や合意した目標を併記します。正常時だけでなく、異常時にどう振る舞ってほしいかも記載しておくと後工程が安定します。