要件定義書

要件定義書は、プロジェクトの初期に「何を作るか」を関係者で合意するために作られます。企画で描いた狙いや、利用部門から集めた要求は、そのままでは開発に渡せません。優先順位や実現範囲がばらついているため、いったん一つの文書に集約し、合意の土台にする必要があります。要件定義書はその役割を担います。

位置づけとしては、システム化企画や要求定義の後、基本設計の前に置かれます。企画が「なぜやるか」、要求定義が「利用者が何を望むか」を扱うのに対し、要件定義書は「システムとして何を満たすか」を確定させる段階です。ここで決めた範囲が、後の設計・見積り・スケジュールの前提になります。

PM（プロジェクトマネージャー）にとっては、スコープと判断基準を固定する文書でもあります。追加要望が出たときに、要件定義書に照らして範囲内か範囲外かを切り分けられると、変更管理の議論が感情論になりにくくなります。合意の記録として残る点が、口頭での取り決めとの大きな違いです。

要件定義書に決まった様式はありませんが、多くの現場で共通して含まれる項目があります。軸を「業務」「機能」「非機能」の三つに分けて考えると整理しやすくなります。

• 業務要件
  対象となる業務の流れ、登場する役割、現状の課題と、システム化後にどう変わるかを記します。業務フロー図を添えることが多い部分です。
• 機能要件
  画面、帳票、データ項目、処理の内容といった「システムが備える機能」を列挙します。一覧表と、代表的な処理の説明で構成することが一般的です。
• 非機能要件
  性能、可用性、セキュリティ、運用・保守など、機能以外の品質に関する条件を定めます。応答時間や稼働率など、測れる形で書けると後の検証が楽になります。

これらに加えて、対象範囲と対象外を明記した「スコープ」、用語の定義集、前提条件や制約条件を書き添えることも多いです。特にスコープと対象外の記述は、後の変更管理で効いてくる部分なので、曖昧にしないことが望まれます。

作成は、要求のヒアリングから始まります。PMや要件定義担当は、利用部門の担当者や業務responsible者に対して、現状の業務と困りごとを聞き取ります。この段階では要望が発散するため、いったん広く集めることに徹し、取捨選択は後回しにするのが進めやすい形です。

次に、集めた要求を整理し、機能要件と非機能要件に分類します。似た要望をまとめ、矛盾する要望は関係者に確認して寄せていきます。ここで優先順位も付けます。すべてを同じ重みで扱うと範囲が膨らむため、必須・推奨・見送りといった区分を設けることが多いです。

整理した内容を文書に起こしたら、レビューにかけます。利用部門には「望んだ業務が実現できるか」を、開発側には「この記述で設計・見積りができるか」を、それぞれの視点で確認してもらいます。両者の合意が取れて初めて、要件定義書は基本設計へ渡せる状態になります。合意は口頭で終わらせず、承認の記録を残しておくと後で参照できます。

要件定義書でよく起きるつまづきには、いくつか典型的な形があります。

• 粒度がそろわない
  ある機能は細かく、別の機能はひと言だけ、という状態だと、設計側が判断に迷います。同じ階層の項目は同程度の詳しさで書くことが目安になります。
• 非機能要件が後回しになる
  機能の議論に時間を取られ、性能やセキュリティが曖昧なまま進むと、後工程で手戻りが発生しやすくなります。早い段階で測れる条件を置いておくと安全です。
• スコープの境界が書かれていない
  「やること」だけ書いて「やらないこと」を書かないと、追加要望のたびに範囲が揺れます。対象外を明記しておくと切り分けの根拠になります。

隣接概念との違いも押さえておくと混乱を避けられます。要求定義は利用者側の「こうしたい」を集める段階、要件定義書はそれをシステムの条件へ翻訳して合意した成果物です。基本設計は要件定義書を受けて「どう作るか」を決める工程で、要件定義書はその入力になります。役割の順序を意識すると、どこまでを書くべきかが判断しやすくなります。

要件定義書を扱える力は、PM（プロジェクトマネージャー）の上流工程への関与度を示す材料になります。単に文書を作れるだけでなく、発散した要求を整理し、利用部門と開発側の合意を取りまとめた経験は、スコープ管理や変更管理の土台があることを伝えられます。転職を検討する場面でも、どの規模の案件で、どの範囲まで要件をまとめたかを具体的に語れると、担える工程の幅が伝わりやすくなります。

キャリアの方向としては、要件定義の経験を足がかりに、より上流の企画や課題設定へ広げていく道が考えられます。逆に、非機能要件や品質の条件づくりを深めていく進み方もあります。自分がどの軸を伸ばしたいかを意識して案件を選ぶと、次の一歩を描きやすくなります。

要件定義書と要求定義は何が違いますか。

要求定義は利用者や発注側の「こうしたい」という要望を集めて整理する段階を指します。要件定義書は、その要求をシステムが満たすべき条件へ翻訳し、機能要件と非機能要件として合意した成果物です。要求が入力、要件定義書がその出力にあたると考えると整理しやすくなります。

要件定義書には何を書けばよいですか。

業務要件、機能要件、非機能要件を軸に構成することが多いです。加えて対象範囲と対象外を示すスコープ、用語定義、前提条件や制約を添えます。特に対象外の記述とスコープは、後の変更管理で範囲を切り分ける根拠になるため、曖昧にしないことが望まれます。

PMは要件定義書作成にどう関わりますか。

PM（プロジェクトマネージャー）は、要求のヒアリングから整理、優先順位付け、関係者のレビュー調整までの進行を担うことが多いです。自身が全文を書かない場合でも、スコープの確定と合意形成に責任を持ちます。ここで固めた範囲が後続の見積りやスケジュールの前提になります。