要件定義書の読み方｜発注者が署名前に確認すべき5項目とチェックリスト

開発会社から要件定義書が届き、「内容をご確認のうえ、ご署名ください」と求められたものの、数十ページの文書を前にして「何を確認すれば見落としを防げるのかが分からない」と感じていないでしょうか。社内にエンジニア専任がおらず、相談できる相手も限られる中で、署名期日だけが迫ってくる。そんな状況に置かれている発注者の方は決して少なくありません。

要件定義書は、開発会社と発注者が「ここまでの内容で合意しました」と握り合うための契約上の証拠書類です。署名後に「この機能は要件に書いてありませんでしたよね」と指摘されれば、それは仕様変更扱いとなり、追加費用や納期遅延の起点になります。読めた気になっていたつもりが、後から「想定していた機能が入っていない」と気づくケースは、現場で頻繁に起きています。

とはいえ、要件定義書を細部まで完璧に読み解こうとすると、専門知識のない発注者にとっては現実的ではありません。署名期日までの数営業日で判定するためには、「どこを見れば致命的な見落としを防げるか」を絞り込む必要があります。

本記事では、開発会社から届いた要件定義書を発注者が署名前に確認するための5観点（スコープ・非機能要件・除外事項・変更管理・承認フロー）と、各観点の判定基準、開発会社にそのまま投げられる質問例、そして手元の文書と照合できるチェックリストまでをまとめました。署名期日までに最低1往復の確認を回し、後悔のない承認判断ができる状態を目指して読み進めてみてください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

要件定義書の読み方が発注者にとってなぜ重要か

最初に押さえておきたいのは、「要件定義書に署名する」という行為が法的・実務的にどういう意味を持つかという点です。ここを腹落ちさせておくと、以降のチェック項目を「自分事」として読めるようになります。

要件定義書は「決定済みの合意」の証拠書類

要件定義書は、開発会社と発注者の間で「このシステムには何を実装し、何を実装しないか」を合意した結果をまとめた文書です。署名・押印された要件定義書は、その後の設計・実装・テスト・検収すべての工程で「合意済みの基準点」として参照されます。

たとえば、開発の中盤で発注者が「この画面にも検索ボックスを追加してほしい」と依頼したとします。要件定義書に「検索ボックス」の記載がなければ、開発会社は「これは要件定義時点では合意していない新規要件」として扱い、仕様変更プロセスに乗せます。仕様変更プロセスに乗るということは、影響範囲の調査・追加見積・スケジュール再調整が発生し、追加費用と納期延伸が現実的に発生するということです。

この点は、要件定義書のあいまいな記述が後の追加費用の引き金になることを解説したシステム開発の仕様変更で追加費用が発生する原因と発注者が取れる具体的な防止策で詳しく扱われています。要件定義書の精度がそのまま発注者の費用リスクに直結するという構造を理解しておくことが、署名前のレビューに真剣に取り組む第一歩になります。

なお、2026年1月に下請法が「中小受託取引適正化法（取適法）」へ改正され、委託内容の書面明示義務（旧3条書面・新4条書面）の運用も見直されました（出典: 公正取引委員会「取適法リーフレット」）。発注者と開発会社の間で書面合意した内容は、法令上も「給付の内容」の明示として機能します。要件定義書はこの「給付の内容」の中核を成す書面であり、署名は実務上も法令上も重い意味を持ちます。

読み落としが招く3つの典型トラブル

要件定義書の読み落としによって現場で発生しやすいトラブルは、大きく以下の3つに集約されます。

いずれも、署名前のレビューで「未記載」「あいまい」「数値化されていない」を見抜いておけば事前に潰せるトラブルです。逆に言えば、署名後にこれらを発見しても、追加費用や工数の追加なしに修正してもらうことは難しくなります。署名前の数営業日のレビューが、その後の数ヶ月のプロジェクト運営の安定性を左右します。

要件定義書に含まれているべき項目の全体像

具体的な判定基準に入る前に、まず「標準的な要件定義書にはどんな章が並ぶか」を押さえておきます。手元の要件定義書と章立てを照合することで、「そもそも章として欠けているもの」を発見できます。章の欠落は最も見つけやすい異常パターンであり、ここを最初に固めることで、レビュー作業の不安を一段下げることができます。

標準的な要件定義書の章立て一覧

標準的な要件定義書は、おおむね以下の章立てで構成されます。すべての章が必須というわけではありませんが、業務システム開発であれば下記のうち多くが含まれているのが通常です。

要件定義書の構成項目そのものについては、要件定義書の書き方とテンプレート【非エンジニア発注者向け7項目・記入例付き】が記入例付きで解説しています。自社の要件定義書にどんな章が並んでいるべきかをあらかじめイメージしておくと、レビューがスムーズに進みます。

「ない章」を見つけたときの初動

照合の結果、上記のうち複数の章が手元の要件定義書にまったく存在しない場合は、注意が必要です。とくに以下の3つが章として独立していない要件定義書は、後のトラブル率が高くなります。

• スコープ・除外事項: 「やること」だけが書かれていて「やらないこと」がない
• 非機能要件: 機能要件のみが詳細に書かれており、性能・可用性・セキュリティの章がない、または1ページ未満で終わっている
• 変更管理プロセス: 仕様変更時の手続きについての記載が見当たらない

これらの章が抜けている場合、ベストな対応は「該当章の追記をお願いできますか」と開発会社に投げ返すことです。「要件定義そのもののやり直し」までは多くの場合不要で、章単位の追記であれば数営業日で対応してもらえます。

逆に、業務要件や機能要件の章そのものが手薄で、自社の業務理解が浅いと感じる場合は、要件定義そのもののやり直しを検討する余地があります。要件定義と要求定義の役割分担については、要求定義と要件定義の違いとは？発注側がすべき準備を解説で詳しく整理されているので、「そもそも要求定義段階に戻すべきか」を判断する材料として参考になります。

発注者が署名前に確認すべき5項目

ここからが本記事の中核です。発注者が署名前に最低限確認すべき5つの観点と、各観点の「OK／要質問／NG」の判定基準、見落とした場合に起きる典型トラブル、開発会社に投げるべき質問例を順に提示します。

5観点はそれぞれ独立していますが、いずれも「未記載」「あいまい」「数値化されていない」を見抜くという点で共通しています。手元の要件定義書を開いて、章ごとに照合しながら読み進めてみてください。

スコープの境界線（やること・やらないこと）

最初に確認すべきは、スコープの境界線です。要件定義書に「やること」が詳細に書かれていても、「やらないこと」が同じ精度で書かれていなければ、その境界線はあいまいなままです。あいまいな境界線は、開発中盤以降に「どちらに含まれるか」の解釈論争を生み、追加費用の引き金になります。

判定基準

見落とすと何が起きるか

スコープ境界が曖昧な要件定義書を承認すると、「画面の多言語化は当然含まれていると思っていた」「既存システムとのデータ連携機能は入っていない」といった解釈の食い違いが、開発中盤や受入テスト段階で顕在化します。発注者側は「常識的に含まれるはず」と主張しますが、開発会社側は「要件定義書に書かれていないので追加見積になります」と回答します。書面に書かれていない以上、契約上は開発会社の主張が通りやすく、結果として追加費用と納期遅延が発生します。

開発会社への質問例

• 「対象外範囲」の章に書かれていない機能で、開発中に発注側から依頼があった場合は、すべて仕様変更プロセスに乗る理解で正しいでしょうか
• 既存の◯◯システム（社内の関連システム名）との連携は、対象範囲・対象外範囲のどちらに含まれますか。書面のどこに記載されているか教えてください
• 多言語対応、スマートフォン最適化、印刷機能など、本要件定義書では明示されていない一般的な機能が「対象外」であると確認できる箇所を教えてください

非機能要件の数値化

次に確認すべきは、非機能要件（性能・可用性・セキュリティ）が具体的な数値で書かれているかです。「快適に動作する」「セキュアに通信する」のような形容詞だけの記述は、検収段階で「期待値が違った」というもめごとの典型的な原因になります。

判定基準

見落とすと何が起きるか

非機能要件が数値化されていない場合、結合テスト・受入テスト段階で「応答が遅すぎる」「ピーク時に画面が固まる」といった問題が発覚しても、開発会社は「要件定義書に具体的な性能数値の記載がないため、現状で要件は満たしています」と回答することになります。発注者側は「常識的にこの程度の速さは出るはず」と主張しても、書面に数値がない以上、改修対応は仕様変更扱いとなり、追加費用と納期遅延を引き受けることになります。

開発会社への質問例

• 主要画面の応答時間は何秒以内を目標値として設計されていますか。書面のどこに数値が記載されているか教えてください
• 同時接続ユーザー数の上限と、その人数で運用した場合の応答時間目標を教えてください
• セキュリティ要件で「業界標準」と書かれている部分について、具体的に準拠する基準（例: OWASP Top 10、PCI DSS、自社のセキュリティポリシー）を明示していただけますか
• 障害発生時の復旧目標時間（RTO）と、データ復旧目標地点（RPO）の数値を教えてください

除外事項・前提条件の明示

3つ目に確認するのは、「本要件定義に含まれない事項」と「発注者側で用意するもの」が章として独立して書かれているかです。これは前述のスコープと一部重なりますが、「前提条件」は「発注者側の責任範囲」を確定する重要な要素なので、独立した観点としてチェックする価値があります。

判定基準

見落とすと何が起きるか

前提条件・発注者側準備が明示されていない場合、開発開始後に「データ移行用の既存データをCSVで提供してください」「テスト用のユーザーアカウントを発注者側で用意してください」「本番環境のドメイン取得は発注者側でお願いします」といった依頼が次々と発生し、発注者側のリソースが想定以上に逼迫します。最悪の場合、これらの準備が間に合わず、プロジェクト全体のスケジュールが後ろ倒しになります。さらに「準備が遅れたのは発注者側の責任」として扱われ、追加費用や納期延伸の根拠にもなります。

開発会社への質問例

• 発注者側で用意すべき成果物・データ・環境のすべてを一覧化していただけますか。それぞれいつまでに必要かもセットで教えてください
• 受入テストで発注者側に求められる作業（テスト項目数、必要工数の目安、レビュー回数）の見込みを教えてください
• 運用フェーズ移行時に発注者側で行うべき準備（運用担当者の研修、運用マニュアル整備等）は要件定義書のどこに記載されていますか

変更管理プロセス

4つ目は変更管理プロセスです。プロジェクトの途中で仕様変更が発生したとき、「どう申請して、誰がどう承認し、追加費用と納期はどう算定するか」のルールが要件定義書に明記されているかを確認します。

判定基準

見落とすと何が起きるか

変更管理プロセスが定義されていない場合、開発中の仕様変更が口頭やチャットでやり取りされ、後から「言った／言わない」のトラブルになります。さらに、追加費用の算定根拠が事前に共有されていないと、変更依頼のたびに開発会社から提示される追加見積に対して「妥当性が判断できない」状態が続きます。結果として、発注者は「予算超過が怖くて変更依頼ができない」「業務上必要な変更ができないままシステムが完成する」というジレンマに陥ります。

変更管理プロセスの組み立て方そのものについては、変更管理・仕様変更プロセスとは？システム開発で使える5つのステップと変更要求書の書き方で5ステップの実務手順が解説されています。要件定義書の変更管理章を読む際の比較基準として参考になります。

開発会社への質問例

• 仕様変更が発生した場合の申請方法・承認権限・追加費用算定の流れを、書面化していただけますか
• 軽微な変更（例: ボタンの文言修正、画面項目の順序変更）と重要な変更（例: 新機能追加、外部システム連携の追加）で、手続きの違いはありますか
• 仕様変更の依頼から追加見積回答までのリードタイムは何営業日を目安としますか
• 開発フェーズの進行度に応じて、変更費用の算定方法が変わりますか（例: 設計フェーズ完了後の変更は◯倍の費用がかかる、等）

承認フロー・検収条件

5つ目は、承認フロー・検収条件です。「誰が」「何をもって」「どう承認するか」が要件定義書に定義されているかを確認します。検収完了の基準があいまいだと、最終工程の支払い・運用開始のタイミングでもめごとが発生します。

判定基準

見落とすと何が起きるか

検収条件があいまいな場合、納品物に対して発注者が「業務上、まだ使えるレベルに達していない」と主張しても、開発会社は「テスト項目はすべてクリアしています」と反論することになります。客観的な合格基準がない以上、最終的には双方の力関係や粘り強さで決まることになり、検収完了が遅れて支払いと運用開始が遅延します。最悪の場合、「検収拒否」の妥当性をめぐって法的な紛争に発展するケースもあります。

開発会社への質問例

• 検収判定の合格基準を具体的に教えてください（テスト項目数、合格率の目標、許容される不具合のランクと件数）
• 検収期間中に発見された不具合は、どの重要度までを「リリース前修正必須」とし、どこから「リリース後の運用対応」に回す想定ですか
• 検収の承認権限者は、発注者側・開発会社側それぞれ誰を想定していますか。承認権限者が不在の場合の代行ルールはありますか
• 検収後に発覚した不具合の修正対応（瑕疵担保責任、契約不適合責任）の範囲と期間を教えてください

開発会社に投げ返すべき質問リスト

5観点のチェックを実施した結果、「要質問」「NG」の判定が複数出た場合は、開発会社にまとめて質問を投げ返すことになります。署名期日まで時間が限られている状況では、「明日までに回答ください」と一度に質問を投げる方が、複数回に分けるよりも効率的です。

以下に、コピペして社内稟議や開発会社へのメールに使える質問例を、5観点別にまとめました。回答内容を見れば、開発会社のドキュメント精度・対応姿勢を判断する材料にもなります。

質問を投げる際は、メール本文に「署名期日が◯月◯日のため、◯月◯日までにご回答いただけますと幸いです」と回答期日を明記してください。開発会社側にもスケジュール都合がありますので、期日を切らないと回答が遅れがちです。

質問の回答が「文書化されていない事項を口頭でこう説明する」という形になった場合は、回答内容を議事録または合意文書として残してもらうように依頼してください。要件定義以降の議事録管理については、システム開発の議事録管理｜発注者が実践すべき記録保全の方法と手順で記録すべき項目と保全方法が整理されています。

署名前チェックリスト

ここまでの5観点と質問リストを、一枚物のチェックリストとして再掲します。記事を閉じた後に、このセクションだけを見ながら手元の要件定義書と照合できる構成にしています。コピペや印刷でご利用ください。

チェックリスト本体

チェックリストの使い方

このチェックリストは、以下の順序で記入することを推奨します。

1. 章・ページ番号メモ列を先に埋める: 12項目それぞれについて、手元の要件定義書のどの章・ページに該当する記述があるかを探し、ページ番号をメモする。記載が見つからない項目はこの時点で「未記載」とメモする
2. 判定列を埋める: 各項目の記載内容を読み、判定基準（先ほどのセクションで提示した OK / 要質問 / NG）に照らして判定する
3. 質問送付状況メモ列を埋める: 「要質問」「NG」と判定した項目について、開発会社に投げる質問の整理状況（未着手・送付済・回答待ち・回答受領）を記録する

12項目のうち「OK」が10項目以上であれば、質問送付後の修正対応が完了次第、署名できる水準に近いと考えてよいでしょう。「要質問」「NG」が3項目以上ある場合は、署名期日の延期を開発会社に申し入れることも視野に入れてください。

期日からの逆算手順としては、「署名期日の3営業日前までに開発会社からの回答を受領 → 回答内容を1営業日でレビュー → 必要があれば追加質問を1営業日で投げる → 残り1営業日で社内最終承認」という流れが現実的です。署名期日まで5営業日を切っている場合は、まず期日延期の交渉から始めるのが安全です。

署名前に「要修正」と判断した場合の進め方

チェックリストで「NG」判定が出た場合、「では具体的にどう動けばいいのか」が次の課題になります。「開発会社に嫌われたくない」「期日に間に合わせたい」という心理的圧力もあって、判断に迷う場面が多いはずです。ここでは、NG 判定が出た場合の3つの対応パターンと、期日が動かせない場合の落とし所を整理します。

3つの対応パターンと判断軸

NG 判定が出た場合の対応は、大きく以下の3パターンに分かれます。

判断軸としては、「要件定義書の修正なしに署名すると後でもめそうか」を基準にしてください。もめそうであれば A または B、合意内容を文書化さえできれば本体の修正は不要であれば C を選択します。

開発会社との関係性を心配する声をよく聞きますが、署名前の要件定義書に対して質問・修正依頼を投げることは、発注者として正当な業務行為です。むしろ「署名後に発覚した問題で揉める」方が、開発会社にとっても発注者にとっても大きなコストになります。発注者から建設的な質問が来ることを開発会社は歓迎するケースが多いので、過度な遠慮は不要です。

期日が動かせない場合の落とし所

「上位役員から◯月◯日までに署名・契約完了と指示されている」「次工程の見積発行が遅れると年度予算の執行に影響する」など、署名期日が物理的に動かせない場面もあります。その場合の現実的な落とし所として、以下の2つの方法があります。

方法1: 補足合意書を要件定義書とセットで締結する

要件定義書本体は当初予定通り署名し、同日付で「補足合意書」を別途締結する方法です。補足合意書には、要件定義書で曖昧だった点（対象外範囲の具体例、非機能要件の数値、変更管理プロセスの詳細など）を文書化します。要件定義書本体の改訂は不要なため、開発会社のドキュメント改訂工数が発生せず、合意成立までのリードタイムが短くなります。

方法2: 第一段階リリースの範囲を限定する

開発スコープ全体を一度に発注するのではなく、まず「コア機能のみを対象とした第一段階リリース」として範囲を限定し、要件が曖昧な周辺機能は「第二段階以降」として後続フェーズに切り出す方法です。第一段階のスコープを小さくすることで、要件定義書の精度がそれほど高くなくても許容できるリスクに抑えられます。

両方とも、「期日は守りつつ、リスクは限定する」という現実解です。どちらを選ぶかは、開発会社との関係性、自社の予算スケジュール、業務上の優先度を踏まえて判断してください。

なお、要件定義書承認後に進む見積精査の段階で改めてリスク把握をしたい場合は、システム開発における見積もりのチェックポイントとは？費用相場からRFP作成まで詳しく解説が参考になります。次工程の見積精査と要件定義書のレビューは連動しているため、両方を併せて確認する価値があります。

まとめ

開発会社から届いた要件定義書を、発注者が署名前にどう読むかを5観点（スコープ・非機能要件・除外事項・変更管理・承認フロー）に絞って解説しました。各観点について、「OK／要質問／NG」の判定基準、見落とした場合に起きる典型トラブル、開発会社にそのまま投げられる質問例を提示し、最後に12項目の署名前チェックリストと、NG 判定が出た場合の3つの対応パターンを整理しました。

要件定義書のレビューは、専門知識を持たない発注者にとって心理的なハードルが高い作業ですが、本記事の5観点に絞って読めば、署名期日内に十分実施可能です。「12項目のチェックリストで全部 OK が付くまで署名しない」と決めておくだけで、署名後のトラブルの多くは未然に防げます。

要件定義は「上流のプロセス」と「下流の成果物検証」の両輪で機能します。本記事は下流（届いた要件定義書のレビュー）に特化しましたが、上流のプロセス全体を理解しておくと、要件定義書に書かれている内容の意味がより深く読み取れるようになります。要件定義のプロセス全体については、システム開発の要件定義を成功させる完全ガイドで各工程の進め方が体系的に整理されています。本記事と併せて読むと、上流から下流までの理解が一気に深まります。

また、AIシステムやデータ活用システムの要件定義書をレビューする方は、通常のシステム開発とは異なるチェックポイントが必要になります。AIプロジェクトの要件定義ガイド【発注者向け】テンプレート・チェックリスト付きが AI 開発特有のレビュー観点をまとめているので、該当する方は併せて参照してみてください。

手元の要件定義書を開き、5観点と12項目のチェックリストで今日から照合を始めてみてください。署名期日までに最低1往復の確認を回し、後悔のない承認判断ができる状態に持っていけるはずです。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。