要件定義書テンプレート｜記入例・受入基準・変更履歴の作り方

要件定義書は、関係者が必要な仕事と完成条件を同じ言葉で確認するための文書です。見出しがそろっていても、「使いやすく」「既存データを移す」だけでは、何を確かめれば受け入れられるか分かりません。必要な挙動、条件、確認方法、担当、証拠を要件IDでつなぎ、未確定事項を確定済みのように見せない構成にします。以下の画面、件数、性能値は架空の記入例です。

要件定義書の役割：RFP・設計・契約文書との関係

RFPは共通条件で提案を募る文書、要件定義書は必要な挙動や制約を関係者の合意へ具体化する文書です。設計は実現方法を詳しくする役割ですが、既存システムとの接続や指定環境など、技術的な条件自体が要件になる場合もあります。「何」と「どう」を機械的に切り分けるだけでは足りません。

IPAの要件定義の解説では、利用者のニーズ等を分析し、関係者の合意で要件をまとめる工程として整理されています。要件は選定前から具体化することもあり、契約後だけに行う固定の順番ではありません。

誰が下書きを作っても、業務の必要性、技術的な実現可能性、試験方法を役割分担して確認します。発注者が分からない記述は、できることと制約を業務の言葉で説明してもらいます。技術面を誰も確認せずに承認する状態は避けてください。

文書と責務の関係を考える参考には、IPAの情報システム・モデル取引・契約書があります。ただし実際の契約範囲や文書間の優先順は当事者で確認する必要があり、要件一覧への記載の有無だけで法律上の責任を断定しません。

7章の構成例とコピー用の要件一覧

章立ては次の七つを出発点にできます。使わない章を消すだけでなく、その論点が不要か、別資料で扱うかを確認します。文量に標準ページ数を置くより、合意と検証に必要な情報が追えるかで判断してください。

要件一覧には、要件ID、利用者または根拠、必要な挙動と条件、優先度、受入基準、確認方法と試験ID、確認責任者、証拠、状態と版を持たせます。要件が複数の試験へ分かれる場合は、対応表を別に作ります。文書の位置ではなくIDで質問や変更を参照できるようにします。

「問い合わせを月30件から60件へ増やす」は事業目標です。必要性を説明する背景には使えますが、システム納品だけで達成する検収条件とは分けます。画面が正常に動くことと、商品や集客も含む成果を得ることは異なります。

検証できる機能・非機能要件の記入例

F-01では、許可される操作だけでなく、許可されない操作も確認します。対象者の権限、対象版、保存と公開の違いを明示し、エラー、権限不足、再試行時に必要な挙動も別の試験へ展開します。数字や機能名があるだけで検証可能になるわけではありません。

N-01の1万件、100同時利用、10分、800msは架空の条件で、推奨標準値ではありません。p95は測定値の95パーセンタイルです。計測区間、成功・失敗の扱い、負荷のかけ方、データ、キャッシュ、試験回数、環境を固定します。エラー率の合格条件が未確定なら、そのまま最終受入にしません。

要件の明確さ、実現可能性、検証可能性と確認表の考え方は、NASA Systems Engineering Handbookの付録も参考になります。異なる分野の資料であり、この架空の性能値や日本の契約条件を定めるものではありません。

Webの表示性能を使う場合は、GoogleのLCPの解説が示す最大コンテンツの描画時刻と、ページ全体の表示完了を区別します。LCPの2.5秒以下という良好値は実ユーザー分布の75パーセンタイルで端末別に評価するもので、「4Gで全ページが必ず2.5秒以内」と同義ではありません。ラボ試験と実ユーザー評価も分けます。

データ移行・旧URL・公開後運用の確認項目

D-01の480記事は、件数が一致するだけでは合格にしません。対象IDが一致するか、本文・画像・公開状態・対応URLが保たれるか、対象外の記事の扱いまで照合します。全件で行う確認と、内容のサンプル確認を分け、サンプルの選び方と限界を残します。

Google Search CentralのURL移転ガイドでは、関連する移転先への恒久転送や、代替がない廃止ページの404/410が案内されています。旧ページを一律にトップへ転送する例を、そのまま要件にしないでください。

移行要件には、データ整形、差分反映、旧環境の停止、保存と復旧、公開後の更新担当も含めます。新環境で受け付けたデータを切り戻しで失わないか、どこまで戻せるかを確認します。バックアップ、権限、保持期間、アクセシビリティなどの必要な論点も、専門担当と対象を決めます。

発注者と技術担当で行うレビュー・受入確認

発注者の業務担当は、利用場面、必要情報、役割、対象外を確認します。技術担当やベンダーは、実現可能性、依存、権限、性能、安全性、試験方法を確認します。必要に応じて運用、情報管理、アクセシビリティ等の担当も加えます。五つのチェックだけで網羅性を保証できるわけではありません。

受入確認では、対象版、環境、試験データ、手順、期待結果、実結果、証拠、担当を記録します。合格、未実施、不合格、条件付きの扱いを分け、条件付きで進めるなら残条件、期限、判断者を明示します。未実施を合格へ含めないでください。

初回の確認で不一致が出たら、要件の誤解、実装不具合、要件不足、追加要求を切り分けます。文書にない作業を自動的に発注者へ割り当てず、元の合意、提案、契約の参照関係を確認します。必要な専門判断を、現場担当一人へ押し付けないことも大切です。

未確定事項と変更履歴を合意して管理する

未確定事項には、何が決まればどの工程へ進めるかを付けます。仮定で進む場合は、その仮定が違ったときの影響と見直し日を共有します。期限が来ても決まらないなら、後続作業への影響を示して判断を求めます。

変更申請は、理由、影響する要件、費用、納期、依存、受入方法、見積もり、判断結果を残します。変更は必ず起こると決め付ける必要はありませんが、発生した場合に商業条件の調整や承認が不要になるわけではありません。改訂版と履歴を保ち、採用された条件だけを現行版へ反映します。

まず重要な要件三件を選び、必要な挙動、確認方法、証拠、担当を一行ずつ埋めてください。埋まらない欄を隠さず未確定として扱うことが、関係者が同じ完成条件を判断する出発点になります。

次の作業に合わせて、RFPの書き方｜必須条件・評価表までそろえる提案依頼書の記入例、サイトリニューアルの進め方｜工程・URL移行表・公開判断のチェック例、オリエンシートの書き方｜課題・対象者・予算をまとめる依頼概要の記入例を参照してください。