要件定義書テンプレート｜Web・システム発注で使えるサンプルと書き方
納品されたものを見て「思っていたのと違う」となる。追加費用の話が出て「それは要件に入っていない」と言われる。発注案件で起きるトラブルの多くは、要件定義書の書き方にさかのぼれます。この記事では、要件定義書とは何を確定させる文書なのか、そのまま流用できる章立て、曖昧さを残さない書き方、そして発注者としてレビューするときの確認観点までを整理します。
要件定義書とは、発注先が決まった後に「何を作るか」を確定させる文書です。契約の範囲を具体化し、完成の判断基準を定める役割を持ちます。ここで書かれていないものは作られませんし、書かれているものは作られなければ未完成という扱いになります。
文書の流れとしては、提案依頼書で候補企業から提案を集め、発注先を選定し、契約を結び、そのうえで要件定義に入ります。提案依頼書が「解決したい課題と満たすべき条件」を伝えるものであるのに対し、要件定義書は「その課題をどう解決する形にするか」を具体的な仕様のレベルまで落とし込んだものです。
実務では2つのパターンがあります。ベンダーがヒアリングをもとに作成し、発注者が内容を確認して承認するパターン。もう1つは、発注者側がたたき台を作り、ベンダーが技術的な実現方法を加えて完成させるパターンです。システム開発では前者、Webサイト制作や小規模な案件では後者も珍しくありません。
どちらの場合でも、発注者が中身を判断できないまま承認印を押すのは避けたいところです。要件定義書は契約の範囲を規定する文書なので、承認した時点でその内容に同意したことになります。書く側でなくても、読んで判断できる程度には構造を理解しておく必要があります。
要件定義書が「何を作るか」を書くのに対し、設計書は「どう作るか」を書きます。データベースのテーブル構造やクラス設計は設計書の領域で、要件定義書には含めません。この線引きが曖昧だと、発注者が判断できない技術的記述が要件定義書に混ざり、レビューが形骸化します。
以下の章立てをそのまま見出しとして使い、各項目を埋めていけば要件定義書として成立します。案件の規模に応じて、使わない章は省いて構いません。
目的、対象範囲、関係者と承認者、前提条件を記載します。ここで書く目的は、後から仕様の判断に迷ったときの拠り所になります。「問い合わせ件数を月30件から60件に」のように達成したい状態が書いてあれば、細部の仕様で迷ったときに立ち返れます。
システムを使う人が、どういう手順で仕事を進めるかを書きます。現行の業務フローと、導入後の業務フローを並べる形が分かりやすいです。ここを飛ばして機能の話に入ると、実際の運用に合わない機能ができあがります。
利用者の種類（一般社員、管理者、外部の顧客など）と、それぞれが何をするかを整理しておくと、次の機能要件と権限設計がぶれません。
必要な機能を一覧にします。表形式にして、機能ID・機能名・概要・利用者・優先度の列を持たせると管理しやすくなります。優先度は必須・推奨・任意の3区分で十分です。
機能IDを振っておくと、後の質疑や変更依頼で「F-012の件」と指定できるようになり、認識のずれが減ります。地味ですが効果の大きい工夫です。
画面の一覧と、画面間の遷移を記載します。各画面について、表示する項目、入力できる項目、入力チェックの内容、ボタンを押したときの動作を書きます。
ここで漏れやすいのがエラー時の挙動です。入力が不正だったとき、通信に失敗したとき、権限がないとき、画面に何が表示されるのか。正常系だけ書かれた要件定義書は、開発の途中で必ず質問が発生します。
扱うデータの項目、桁数、必須かどうか、保持期間を定義します。詳細なテーブル設計は設計書の領域ですが、業務上の意味を持つデータ項目は要件定義書で確定させておきます。
既存システムとの連携がある場合は、どのデータを、どの方向に、どのタイミングで受け渡すかをここに書きます。連携の仕様は後から発覚すると影響が大きい領域です。
性能、可用性、セキュリティ、対応環境、運用保守の条件を書きます。機能要件と違って目に見えないため後回しにされがちですが、ここが曖昧なまま進むと、完成後に「遅い」「落ちる」という形で問題が表面化します。
最低限、想定する同時利用者数、応答時間の目標、対応ブラウザとバージョン、バックアップの頻度、障害時の復旧目標は決めておきます。
既存データをどう移すか、旧システムをいつ止めるか、公開後の運用を誰が担うかを記載します。リニューアル案件では、旧URLからの転送設定もここに含めます。
移行は見積から漏れやすい領域です。データの整形作業を誰がやるのか、移行に失敗したときにどう戻すのかまで、契約前に確定させておいてください。
要件定義書の質は、判断の余地をどれだけ潰せているかで決まります。判定基準は1つ、「この記述を読んだ2人が、同じものを想像するか」です。
確定側の記述に共通しているのは、数量、対象、条件のいずれかが入っている点です。逆に「適切に」「柔軟に」「使いやすく」といった言葉が出てきたら、そこはまだ決まっていないと考えてください。
見落とされやすいのが対象外の明記です。「多言語対応は今回の範囲に含まない」「スマートフォンアプリは対象外」と書いておくことで、後から「当然入っていると思った」という議論を避けられます。
検討したうえで外したものは、外した事実を残すと価値があります。次期フェーズの検討材料になりますし、なぜ入っていないのかを説明する手間も省けます。
ベンダーが作成した要件定義書を承認する立場のとき、技術的な妥当性まで判断する必要はありません。次の5点を確認すれば、実務上の大きな抜けは防げます。
レビューは現場の担当者を必ず入れてください。実際にその画面を毎日使う人でなければ、業務要件のずれには気づけません。決裁者だけで承認した要件定義書は、稼働後に不満が噴出しがちです。
要件は必ず変わります。承認したあとに変更が出ること自体は問題ではなく、変更の扱い方が決まっていないことが問題になります。
要件定義書の承認と同時に、次の3点を決めておいてください。変更の申請方法、影響（費用と納期）の見積を誰がいつ出すか、承認する人は誰か。この手順があれば、変更は交渉ではなく手続きになります。
変更の履歴は要件定義書自体に残します。版数、変更日、変更内容、承認者を表にして冒頭か末尾に置く形です。上書きしてしまうと、いつ何が変わったのかが追えなくなり、後の責任の所在も曖昧になります。
案件規模によりますが、中規模のWebサイト制作で30〜60ページ程度が目安です。ただし分量は品質と比例しません。画面一覧やデータ項目定義は別紙に分け、本文は判断が必要な部分に絞ったほうが、レビューの精度は上がります。
未確定であること自体は問題ありません。危険なのは、未確定なのに決まったように書かれている状態です。「未確定」と明記し、いつまでに誰が決めるかを添えてください。決定期限を過ぎると全体の日程に影響が出るため、そこを合意しておくことが重要です。
正式な文書でなくても、範囲と完成条件は文字にしておくべきです。数十万円規模の案件でも、認識のずれによる手戻りは発生します。1〜2ページで、やること・やらないこと・完成の判断基準・双方の作業分担を書くだけでも効果があります。
判断できない記述があること自体を伝えてください。要件定義書は発注者が承認する文書なので、発注者が理解できない書き方は本来成立していません。「この記述で何ができるようになるのかを、業務の言葉で説明してほしい」と依頼するのが正当な要求です。
要件定義書の目的は、完璧な仕様を書き切ることではありません。後から揉める箇所を先に潰しておくことです。まずは7章の見出しだけを並べ、埋まらない項目がどこかを確認するところから始めてみてください。埋まらない場所が、いま決まっていないことです。
