要件定義書と仕様書の違い 要求定義書・設計書との関係と使い分け、確認すべき点を解説

「要件定義書と仕様書は何が違うのか」「開発会社から届いた書類のどれを承認すればよいのか分からない」。システム開発に初めて関わる担当者から、必ず出てくる質問です。

要件定義書は何を実現するかを定めた文書、仕様書はそれをどう作るかを定めた文書です。役割が違い、作られる順序も、読むべき人も異なります。

混乱が起きるのは、実務では要求定義書、要求仕様書、基本設計書、詳細設計書といった似た名前の文書が並ぶうえ、組織によって呼び方が違うためです。同じ内容の文書が別の名前で呼ばれていることも珍しくありません。

この記事では、両者の違いを整理したうえで、紛らわしい文書との関係、記載内容の具体的な書き分け、混同が招くトラブル、そして発注側が確認すべき点までを順に整理します。

確認したいポイント	結論	詳細
一番の違いは？	「何を」と「どう作るか」の違い	要件定義書は実現すべきことを、仕様書はそれをどう作るかを記述した文書になります。
どちらが先に作る？	要件定義書が先、仕様書が後	要件定義書で合意した内容をもとに、設計工程で仕様書が作られるという順序になります。
誰が作成する？	どちらも基本的には開発側	要件定義書は発注側と合意しながら作成し、仕様書は開発側が設計工程で作成します。
混同すると何が起きる？	完成後に「想定と違う」となる	要件が合意されないまま設計に進むと、手戻りと追加費用をめぐる交渉が発生します。

この記事でわかること

• 要件定義書と仕様書の役割の違いと、作成される順序および読み手の違い
• RFP、要求定義書、要求仕様書、設計書を含めた文書全体の関係の整理
• 同じ機能を各文書でどう書き分けるかという記載内容の具体例
• 誰が作成し、誰が承認するのかという役割分担と検収との関係
• 文書の混同が招く典型的なトラブルと、発注側が承認前に確認すべき点

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発の依頼範囲や体制の決め方、費用と期間の目安を1冊にまとめました。社内での検討材料としてご活用いただけます。 ▶ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

要件定義書と仕様書の違いを一言で整理する

最初に結論を示します。要件定義書は「何を実現するか」、仕様書は「どう作るか」を書いた文書です。この一点を押さえておけば、細かい呼び方の違いに振り回されずに済みます。

「何を実現するか」と「どう作るか」

要件定義書には、システムで解決したい課題、必要な機能、満たすべき性能やセキュリティの条件が書かれます。業務の言葉で書かれ、発注側が読んで意味が分かるのが特徴です。

仕様書には、その要件を実現するための具体的な設計が書かれます。画面のレイアウト、データベースのテーブル構成、処理のロジック、外部システムとのやり取りの形式といった内容です。

同じ機能でも、記述の抽象度がまったく違います。「承認者が申請内容を確認して承認できること」が要件定義書なら、「承認画面のボタン配置と押下時の状態遷移」が仕様書です。

作成される順序と関係

順序は明確です。要件定義書が先、仕様書が後になります。要件定義工程で合意した内容をもとに、設計工程で仕様書が作られます。

この順序が守られないと、何のためにその機能を作るのかが不明なまま実装が進むことになります。作った後で「そもそも不要だった」と判明する事態が起こります。

IPAが公開する共通フレーム2013は、システムのライフサイクルを通じて必要な作業項目と役割を包括的に規定した枠組みです。関係者が同じ言葉で話せるようにすることを目的としており、工程と成果物の対応を整理する際の共通の拠り所になります。

読み手が違う

見落とされやすい違いです。要件定義書の主な読み手は発注側、仕様書の主な読み手は開発者です。

要件定義書は、発注側の担当者や決裁者が読んで内容を承認するための文書です。専門用語が並んでいて理解できないなら、その時点で目的を果たしていません。

一方、仕様書は実装する開発者が読むものです。発注側が細部まで理解する必要はありません。ここを混同して「設計書が読めない」と悩む必要はなく、要件定義書の段階で合意できていれば十分です。

要件定義書とは

システム開発の最初の成果物であり、その後のすべての工程の土台になる文書です。ここでの決定が、設計、実装、テストのすべてに影響します。

記載する内容

決まった様式はありませんが、一般的に含まれるのは次の項目です。

• システム化の背景と目的：なぜ作るのか、何を解決したいのか
• 対象範囲：どの業務をシステム化するのか、対象外はどこか
• 業務要件：現行業務の流れと、システム導入後にどう変わるのか
• 機能要件：システムが備えるべき機能の一覧と、それぞれの概要
• 非機能要件：性能、可用性、セキュリティ、運用保守の条件
• 移行要件・運用要件：既存データの移行範囲、稼働後の運用体制
• 制約条件：予算、期間、使用する技術やインフラの前提

非機能要件が抜けている要件定義書は少なくありません。機能の一覧は書かれていても、想定同時利用者数や応答時間の条件が書かれていないと、後で性能不足が発覚します。

具体的な書き方については要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集で、体裁や様式については要件定義書のフォーマット｜表紙・改訂履歴・ID体系・表のレイアウトの決め方で整理しています。

誰がいつ作るのか

作成するのは基本的に開発側です。発注側から提示されたRFPや要望をもとに、開発側が実現可能な形に整理します。

ただし、開発側だけで書けるものではありません。業務を知っているのは発注側だけであり、ヒアリングと確認を繰り返しながら共同で作り上げるのが実態です。

作成のタイミングは、契約後の最初の工程です。要件定義だけを先に別契約とし、その結果をもとに開発の見積りと契約を行うという進め方もあります。

発注側が読んで分かる言葉で書かれる

要件定義書の品質を判断する最も簡単な方法は、発注側が読んで理解できるかどうかです。理解できない文書に承認印を押しても、合意したことにはなりません。

技術的な用語が並んでいて意味が取れない場合は、業務の言葉で書き直してもらう余地があります。これは発注側のわがままではなく、合意形成に必要な作業です。

逆に、実装方法が細かく書かれている要件定義書も適切ではありません。どう作るかは設計工程で決めることであり、要件定義の段階で固めると、より良い実現方法の余地を潰すことになります。

仕様書とは｜複数の種類がある

混乱の最大の原因はここにあります。「仕様書」という言葉が指すものは1つではありません。文脈によって別の文書を指しています。

基本設計書（外部設計書）

要件定義書の次に作られる文書です。利用者から見える部分の設計を記述します。外部設計書と呼ばれることもあります。

内容は、画面の一覧とレイアウト、画面遷移、帳票のレイアウト、扱うデータの項目、外部システムとの連携方式などです。発注側が確認する最後の設計書になることが多い文書です。

「仕様書を確認してください」と言われた場合、多くはこの基本設計書を指しています。画面のイメージが含まれるため、発注側でも判断できる部分が多く残っています。

詳細設計書（内部設計書）

基本設計書をもとに、プログラムをどう組むかを記述した文書です。内部設計書とも呼ばれます。

モジュールの構成、処理のロジック、データベースのテーブル定義、エラー処理の方式といった内容が書かれます。読み手は実装を担当する開発者です。

発注側がこの文書を細かく確認する必要は通常ありません。ただし、成果物として納品対象に含まれるかどうかは、契約時に確認しておきます。

要求仕様書

紛らわしい名前の文書です。これは発注側が作成し、開発側に依頼する内容をまとめたものを指します。

位置づけとしては要件定義書より前、RFPと近い性質の文書です。発注側の要望を文書化したものであり、実現方法までは踏み込みません。

内容が十分に整理されている場合、要求仕様書を精査したうえで、そのまま要件定義書として採用することもあります。ただし多くの場合は、開発側が実現可能性を検討して整理し直します。

「仕様書」という言葉の曖昧さ

ここまで見たとおり、仕様書には複数の意味があります。打ち合わせで「仕様書」という言葉が出たら、どの文書を指しているかを確認するのが安全です。

組織によっては、基本設計書と詳細設計書を分けず、まとめて「設計書」と呼ぶこともあります。逆に、機能ごとに「機能仕様書」を作る組織もあります。

呼び方の正解を探すより、そのプロジェクトで何をどう呼ぶかを最初に決めるほうが実務的です。文書の一覧を作り、それぞれの目的と読み手を明記しておくと混乱が減ります。

受け取った文書の読み解きからご相談いただけます 違いは分かっても、自社の文書に何が足りないかの判断は別の問題です。要件の整理からご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

紛らわしい文書の関係を整理する

登場する文書を時系列に並べると、全体像がつかめます。上流から下流へ、抽象から具体へという流れになっています。

文書の流れを一本に並べる

一般的な進行では、次の順で文書が作られます。組織によって名称は変わりますが、役割の順序は共通です。

• RFP（提案依頼書）：発注側が作成。課題と要望をベンダーに提示する
• 提案書：開発側が作成。RFPに対する実現方法と見積りを示す
• 要件定義書：契約後に作成。何を実現するかを両者で合意する
• 基本設計書：利用者から見える部分の設計を記述する
• 詳細設計書：プログラムの内部構造を記述する

それぞれが前の文書を根拠にしているという関係が重要です。設計書に書かれている内容は、要件定義書のどの要件に対応するのかをたどれる状態が理想です。

要求と要件の違い

文書名の違いの背景にある、言葉の使い分けです。要求は発注側が望むこと、要件は開発側が実現すると約束したことを指します。

「営業担当が外出先から実績を確認したい」が要求で、「スマートフォンのブラウザから実績照会画面にアクセスできる」が要件です。要求を実現可能な形に翻訳したものが要件だと考えると分かりやすくなります。

すべての要求が要件になるわけではありません。予算や期間の制約から実現しないと判断したものは、対象外として明記します。この判断と記録が、後の認識のずれを防ぎます。

呼び方が組織で違うときの対処

同じ内容の文書が、会社によって別の名前で呼ばれているのは日常的に起こります。「基本設計書」と呼ぶ会社もあれば「外部仕様書」と呼ぶ会社もあり、どちらが正しいというものではありません。

複数社が関わるプロジェクトでは、この差が実務上の混乱を生みます。「設計書を出してください」という依頼に対して、想定と違う文書が出てくるという事態です。

対処は単純で、プロジェクトの開始時に成果物の一覧を作ることです。文書名、目的、記載内容、作成者、承認者、提出時期を表にまとめ、関係者で合意します。名称そのものは何でも構いません。

この一覧があると、契約時の納品物の定義にもそのまま使えます。後から「その文書は納品対象に含まれていない」という争いを防ぐ効果もあります。

アジャイル開発では文書の扱いが変わる

ここまではウォーターフォール型を前提としてきました。アジャイル開発では、要件定義書と設計書を一括で作り込むのではなく、必要な範囲を都度整理していきます。

文書が不要になるわけではありません。プロダクトバックログという形で要求を管理し、実装した内容は別の形で記録します。何をどこまで文書化するかを、チームで決めておく必要があります。

どの開発モデルを選ぶかによって、必要な文書と作成のタイミングが変わります。この点は着手前に確認しておきます。

記載内容の違いを具体例で見る

抽象的な説明では分かりにくいため、同じ機能を各文書でどう書き分けるかを示します。題材は「経費申請の承認機能」とします。

同じ機能を3つの文書で書き分ける

まずRFPや要求の段階では、業務上の困りごととして表現されます。

【要求】

経費申請の承認が紙の回覧のため時間がかかっている。

承認の進捗が分からず、申請者からの問い合わせも多い。

要件定義書では、これを実現すべきことに変換します。

【要件】

・申請者は経費申請を登録でき、登録時に上長へ通知される

・承認者は申請内容を確認し、承認または差し戻しができる

・申請者は自身の申請の承認状況をいつでも確認できる

・金額が10万円以上の場合は部門長の承認を追加で必要とする

基本設計書では、これを画面と処理の形に落とします。

【基本設計】

・申請登録画面：入力項目、必須チェック、添付ファイルの上限

・承認一覧画面：表示条件、並び順、絞り込み条件

・承認処理：金額判定による承認ルートの分岐フロー

・通知：メールのテンプレートと送信タイミング

上から下へ進むほど、記述は具体的になり、判断の余地は狭まります。逆に言えば、上流で決めなかったことは、下流で誰かが勝手に決めることになります。

粒度の目安

要件定義書に書くべきかどうか迷ったときの判断基準は、「発注側が意思決定すべきことか」という問いです。

承認ルートを何段階にするかは業務ルールなので要件定義書に書きます。承認画面のボタンを右上に置くか下部に置くかは、設計の領域です。

業務が変われば変わることは要件、技術的な選択は設計という切り分けが実務的です。この線引きが曖昧な項目は、要件定義書に書いたうえで設計工程で詳細化すると決めておきます。

どこまで書くと書きすぎか

要件定義書に実装方法まで書き込むと、より良い実現方法の余地を潰します。「Aというテーブルに保存する」ではなく「入力内容が保存され、後から参照できる」と書きます。

一方で、抽象的すぎるのも問題です。「使いやすい画面であること」では検証できません。完成したときに満たしているかどうかを判定できる書き方が目安になります。

判定できるかという観点で読み返すと、書きすぎと書き足りなさの両方を見つけられます。

誰が作り、誰が承認するか

文書の役割と同じくらい重要なのが、作成と承認の責任の所在です。ここが曖昧だと、トラブル時に責任の押し付け合いになります。

作成の主体

要件定義書も設計書も、作成するのは基本的に開発側です。ただし要件定義書については、発注側の関与なしには成立しません。

業務を知っているのは発注側だけです。開発側がヒアリングして文書化しても、内容が正しいかを判断できるのは発注側という関係になります。

「専門家に任せておけばよい」という姿勢で臨むと、後で「そんなつもりではなかった」となります。要件定義は、発注側の関与が最も濃い工程です。

承認と検収の関係

各工程の終わりには、成果物のレビューと承認があります。承認した文書は、以降の工程の前提として扱われます。

IPAが公開する情報システム・モデル取引・契約書（第二版）は、ユーザ企業とITベンダのいずれにもメリットが偏らない中立的な契約書を目指して作成されたものです。役割分担や連絡協議会といった条項が整理されており、成果物の確認の進め方を検討する際の参考になります。

承認した後の変更は、原則として変更管理の手続きに乗ります。追加費用と納期の再調整が発生する可能性があるため、承認の重みを理解したうえで印を押す必要があります。

読めない文書には承認しない

実務でよく起こるのが、内容を理解しないまま承認してしまうケースです。分からないまま承認すると、後で異議を唱える根拠を失います。

理解できない箇所があれば、説明を求めます。それでも分からない場合は、業務の言葉で書き直してもらうか、具体例を添えてもらいます。

質問することは、プロジェクトへの協力です。承認を急かされても、理解できていない状態で押すべきではありません。

混同が招くトラブルと対策

文書の役割を取り違えると、具体的な形で問題が現れます。典型的な5つのパターンを挙げます。

「要求したものと違う」の正体

完成間際に発注側が「思っていたものと違う」と言い出すケースです。多くは、要件定義の段階で合意が形式的にしか取れていなかったことが原因です。

文書は提出され、承認印も押されている。しかし発注側が内容を理解していなかった。この状態では、後から異議を唱えても交渉は難航します。

対策は、要件定義書のレビューを読み合わせの形で行うことです。画面イメージや具体例を添えて、完成したときの姿を共有します。

要件定義書に実装方法が書かれている

発注側が技術に詳しい場合に起こりがちです。要件ではなく実現方法を指定してしまい、より適した方法を採れなくなります。

「この画面はこのフレームワークで作る」といった記述は、要件定義書の役割を超えています。制約として指定する必要があるなら、その理由も併記します。

技術的な制約が実際にある場合は、制約条件の欄に書くのが正しい扱いです。要件と制約を分けて書くことで、開発側も判断しやすくなります。

設計書がないまま実装が進む

小規模な案件で起こりやすい状態です。要件定義書だけを根拠に実装を進め、設計の判断が開発者の頭の中にしか残らないという事態になります。

短期的には速く進みますが、保守の段階で困ります。担当者が変わった時点で、なぜその作りになっているのかが誰にも分からなくなります。

どこまで文書化するかを契約時に決めておくことが対策です。すべてを詳細に書く必要はありませんが、判断の記録は何らかの形で残します。

同じ言葉を別の意味で使っている

打ち合わせで「仕様」という言葉が飛び交っているのに、発注側は業務ルールを、開発側は画面の挙動を指しているというケースです。会話は成立しているように見えて、実際には噛み合っていません。

この食い違いは議事録にも残りません。両者とも自分の解釈で理解しているため、疑問が生じないためです。表面化するのは、成果物が出てきた後になります。

対策は、曖昧な言葉が出たらその場で具体例に置き換えることです。「仕様を変更したい」ではなく「承認者が2人必要な条件を変えたい」と言い直せば、どの文書に影響するかが明確になります。

変更がどの文書に反映されるか決まっていない

開発中に仕様変更が発生したとき、要件定義書は更新せず設計書だけ直すという運用をすると、文書間の整合が崩れます。

後から要件定義書を読んだ人が、実際の動きと違う内容を前提にしてしまいます。保守や機能追加の際に、この不整合が問題を引き起こします。

対策は、変更管理の手順に文書の更新を含めることです。どの文書を、誰が、いつまでに更新するかを手順として定めます。

発注側が確認すべきポイント

最後に、文書を受け取る立場で何をどう確認すればよいかを整理します。

要件定義書で見るべき点

最も重点的に確認すべき文書です。次の観点でチェックします。

• 目的と課題が自社の認識と一致しているか
• 対象範囲と対象外が明記されているか
• 現行業務がどう変わるのかが読み取れるか
• 非機能要件（性能、可用性、セキュリティ）が書かれているか
• 自社側の作業（データ提供、受け入れテスト）が明記されているか

最後の項目は特に見落とされます。自社の作業量が計画に入っていないと、開発が進んだ段階で「そんな作業があるとは聞いていない」という状況になります。

設計書で見るべき点

基本設計書については、画面と帳票のイメージ、そして業務の流れに絞って確認します。詳細設計書まで踏み込む必要は通常ありません。

画面イメージを見て、現場の担当者が実際に使えるかを確認します。この段階で違和感があれば、実装前に修正できます。

現場の担当者に見てもらうことが重要です。管理者だけで判断すると、実際の運用に合わない設計を通してしまいます。

承認する前に確認すること

承認は形式的な手続きではありません。承認した内容が、以降の変更で費用が発生する基準になります。

内容を理解しているか、関係部署の確認は取れているか、決裁権限の範囲内か。この3点を確認してから押します。

外注時の全体の進め方や役割分担についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方で整理しています。

まとめ

要件定義書は「何を実現するか」、仕様書は「どう作るか」を書いた文書です。要件定義書が先、仕様書が後という順序で作られ、読み手も発注側と開発者で分かれます。

混乱の原因は、仕様書という言葉が基本設計書、詳細設計書、要求仕様書など複数のものを指すことにあります。打ち合わせでは、どの文書を指しているかを確認するのが安全です。

書き分けの目安は、発注側が意思決定すべきことは要件、技術的な選択は設計という切り分けです。要件定義書に実装方法を書き込むと、より良い方法の余地を潰します。

そして最も重要なのが、承認の重みです。承認した文書は以降の前提となり、後の変更には費用と時間がかかります。理解できない文書には承認しないという姿勢が必要です。

手元に要件定義書があるなら、非機能要件と自社側の作業が書かれているかを確認してみてください。この2つが抜けている文書は、実際に非常に多く見られます。

システム開発の進め方から、無料で相談できます 受け取った要件定義書を承認してよいか判断したい、社内に開発の知見がなく不安があるといった段階のご相談も承っています。営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎