当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
『要求仕様書と要件定義書、どっちを先に作るの？そもそも同じもの？』と、資料の名前の多さに戸惑っている方も多いはずです。
結論から言うと、要求仕様は発注側の「こうしてほしい」をまとめたもので、要件定義は発注側と開発側が「こうする」と合意したものです。この記事では、似た名前の文書を「誰が書いて誰に渡すか」の順に並べて、迷わず使い分けられるようにお伝えします。
要求仕様書と要件定義書の違いは？
要求仕様書は発注側が書く「お願いの文書」、要件定義書は双方で作る「約束の文書」です。要求仕様書を材料にして話し合い、その結果を要件定義書にまとめる、という順番になります。
要求仕様書は、発注側がシステムに求めることを書いた文書です。業務の困りごとや、こうなってほしいという姿が中心になります。
要件定義書は、その要求をもとに、予算・期間・技術を踏まえて「今回作るもの」を決めた文書です。発注側と開発側の双方が内容を確認して合意します。要件定義書そのものの役割は要件定義書とはで詳しく紹介しています。
| 観点 | 要求仕様書 | 要件定義書 |
|---|---|---|
| 主に書く人 | 発注側（業務部門・情報システム部門） | 開発側が中心となり、発注側と一緒にまとめる |
| 渡す相手 | 開発側、提案を出す会社 | 発注側の承認者、設計を担当する人 |
| 中身の中心 | 困りごと、目指す姿、求める機能や条件 | 業務要件、機能要件、非機能要件、移行要件など |
| 文の書き方 | 〜してほしい、〜できること | 〜できる、〜する（確かめられる形） |
| 決まっている度合い | 願いの段階で、変わる前提 | 合意済みで、変える時は手続きがいる |
呼び方は会社によって揺れる
ここで一つ注意しておきたいのが、文書の呼び方は会社やプロジェクトでかなり揺れることです。
要求仕様書を「要求定義書」と呼ぶ会社もあれば、要件定義書の中に要求をまとめてしまう会社もあります。名前より「誰が書いたか」「合意済みか」で見分けるのがコツなんです。
要求と要件という言葉そのものの違いは、要求定義と要件定義の違いで会話例を使って紹介しています。
RFP・要求仕様書・要件定義書・仕様書は誰が書いて誰に渡す？
ここがこの記事でいちばん伝えたいところです。似た名前の文書も、「誰が書いて、誰に渡すか」の順に並べると、すっきり整理できます。
- 発注側が要求仕様書を書き、自社のやりたいことをまとめる
- 発注側がRFP（提案依頼書）を書き、要求仕様書を添えて複数の開発会社に渡す
- 開発会社が提案書を書き、発注側に渡す
- 発注側が開発会社を選び、双方で話し合って要件定義書をまとめる
- 開発側が要件定義書をもとに仕様書（設計書）を書き、発注側の確認を受ける
流れを表にすると、次のようになります。
| 文書 | 書く人 | 渡す相手 | 一言でいうと |
|---|---|---|---|
| 要求仕様書 | 発注側 | 開発側、提案する会社 | こうしてほしい |
| RFP（提案依頼書） | 発注側 | 提案する会社 | この条件で提案してほしい |
| 提案書 | 提案する会社 | 発注側 | こう作れます |
| 要件定義書 | 双方（開発側が中心となってまとめる） | 発注側の承認者、設計担当 | これを作ると約束する |
| 仕様書（設計書） | 開発側 | 開発担当、発注側の確認者 | こう作る |
立場ごとに、関わる文書はどれ？
自分がどの文書を書き、どの文書を読む立場なのかが分かると、やることがはっきりします。
| 立場 | 書くことが多い文書 | 読むことが多い文書 |
|---|---|---|
| 発注側の業務部門 | 要求仕様書（困りごとと願いの部分） | 提案書、要件定義書 |
| 発注側の情報システム部門・社内SE | 要求仕様書、RFP | 提案書、要件定義書、仕様書 |
| 開発側のSE・PM | 提案書、要件定義書 | 要求仕様書、RFP |
| 開発側の設計・開発担当 | 仕様書（設計書） | 要件定義書 |
社内SEの方は、発注側と開発側の両方の文書に関わることが多いですよね。どちらの立場で書いているのかを意識するだけで、文の書き方が自然と変わってきます。
RFPと要求仕様書はどう違う？
RFPは、提案を依頼するための文書です。予算の考え方、提案の締め切り、評価の方法、契約の条件など、「提案のルール」も書かれます。
要求仕様書は、そのRFPの中身のうち「システムに何を求めるか」をまとめた部分です。RFPの一部として綴じられることもあれば、別冊で添えられることもあります。
小さなプロジェクトでは省かれることもある
社内で開発する場合や、すでに付き合いのある開発会社に頼む場合は、RFPを作らないこともよくあります。
その場合でも、発注側の願いをまとめた「要求仕様書にあたるもの」はあったほうが安心です。打ち合わせのメモでもいいので、願いを文字にして渡しておくと、要件定義の話し合いがぐっと早く進みますよ。
要件定義から先は、要件定義書をもとに基本設計（外部設計）、詳細設計（内部設計）へと進みます。要件定義書と設計書の線引きは要件定義と基本設計の違いで詳しく紹介しています。
同じ要望が文書ごとにどう書かれるか（記入例）
『文書ごとに何がどう変わるのか、実物を見ないとイメージできない』という方も多いですよね。
そこで架空の題材として、社内の契約書の更新期限を管理する仕組みを新しく作る場合を例に、同じ要望が文書ごとにどう書かれるかを並べてみます。
要求仕様書での書き方（例）
要求仕様書では、発注側の言葉で願いをそのまま書きます。困りごととセットで書いておくと、開発側が理由を理解しやすくなります。
| 番号 | 困りごと（例） | 求めること（例） |
|---|---|---|
| 1 | 契約の更新期限を見落とし、自動更新されてしまったことがある | 更新期限が近い契約を、担当者に前もって知らせてほしい |
| 2 | 契約書の原本がどこにあるか、探すのに時間がかかる | 契約書の保管場所と写しを、一か所で探せるようにしてほしい |
| 3 | 担当者が異動すると、契約の経緯が分からなくなる | 契約ごとに、やり取りの記録を残せるようにしてほしい |
要件定義書での書き方（例）
要件定義書では、話し合いで決めたことを、確かめられる形で書きます。誰が・いつ・何を、をはっきりさせるのがポイントです。
| 番号 | 要件（例） | 区分 |
|---|---|---|
| 1 | 更新期限の一定日数前に、契約の担当者と上長へ通知する（日数は契約ごとに設定できる） | 機能要件 |
| 2 | 契約名・取引先名・期限で契約を検索でき、写しのファイルと原本の保管場所を表示する | 機能要件 |
| 3 | 契約ごとに、対応記録を日時と記入者つきで残せる | 機能要件 |
| 4 | 契約情報は、法務担当と各契約の担当者だけが見られる | 非機能要件（セキュリティ） |
| 5 | 今ある契約の一覧を、表計算ソフトのファイルから取り込む | 移行要件 |
仕様書（設計書）での書き方（例）
仕様書（設計書）では、要件を「どう作るか」に落とします。画面の項目や通知の文面、処理の手順など、作る人が迷わない細かさになります。
| 要件の番号 | 仕様の例 |
|---|---|
| 1 | 毎朝決まった時刻に期限を確かめ、条件に合う契約の担当者へ通知を送る。通知には契約名・期限・契約詳細画面へのリンクを載せる |
| 2 | 検索画面に契約名・取引先名・期限の範囲の入力欄を置き、結果は期限の近い順に一覧表示する |
3つを見比べると、要求仕様書は「なぜ・何を」、要件定義書は「何を、どこまで」、仕様書は「どうやって」が中心になっているのが分かりますよね。
品質や移行の願いはどう書く？
機能の願いに比べて、品質や移行の願いは要求仕様書から抜けやすいところです。発注側の言葉で十分なので、次のような書き方で残しておきましょう。
| 種類 | 要求仕様書の書き方（例） | 要件定義書で決めること（例） |
|---|---|---|
| 止まると困る時間 | 月末の締め前は止まると困る | 使える時間帯と、止まった時の復旧の目標 |
| 見られる人 | 契約の内容は関係者だけに見せたい | 見られる人の範囲と権限の分け方 |
| 今のデータ | 表計算ソフトの一覧をそのまま使いたい | 移す項目、移す時期、移した後の確かめ方 |
非機能要件の決め方には、IPAの「非機能要求グレード」という道具があります。可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目で、レベルを選びながら合意していく方式です。
システム仕様書と要件定義書の違いは？
『システム仕様書と要件定義書って、結局どっちが詳しいの？』という疑問もよく聞きます。
実は、システム仕様書という言葉は使われ方に幅があります。開発側が書く設計書を指すことが多いですが、会社によっては要件定義書と同じ意味で使うこともあるんです。
ここでは一般的な使われ方として、要件定義と仕様の違いを並べてみます。
- システムで実現すると合意した「何を」
- 業務要件、機能要件、非機能要件、移行要件
- 発注側が読んで判断できる言葉
- 受入テストで確かめる基準になる内容
- 合意した内容を「どう作るか」
- 画面の項目、帳票の形、処理の手順、データの持ち方
- 開発担当が作業できる細かさの言葉
- システムテストや結合テストで確かめる内容
左右に良い悪いがあるわけではなく、役割が違うだけです。要件定義書が「約束」、仕様書が「約束を守るための作り方」と覚えておくと迷いにくいですよ。
境目でもめやすい場面の会話例
要件定義と仕様の境目は、打ち合わせでよく話題になります。架空の契約書管理の例で、こんなやり取りを想像してみてください。
利用部門「通知のメールに、契約書のファイルを添付してほしいです」
開発側「通知すること自体は要件として決めておきます。添付するかリンクにするかは、セキュリティの決めごとと合わせて設計で詰めさせてください」
利用部門「なるほど。じゃあ要件定義書には、通知から契約の中身をすぐ見られること、と書いておけばいいですね」
このように「何ができればいいか」は要件定義で決め、「どういう形で実現するか」は設計に回すと、話し合いが前に進みやすくなります。
要件定義書に仕様を書きすぎるとどうなる？
要件定義の段階で、画面の配置やボタンの色まで書き込もうとするケースもあります。
要件定義書に細かい仕様を書き込みすぎると、話し合いが画面の見た目に偏り、肝心の業務の決めごとが後回しになりがちです。見た目の好みは設計の段階で確かめられるので、要件定義では「何ができればいいか」に集中しておきましょう。
逆に、要件定義書に要求仕様書の文をそのまま貼るだけでも困ります。「〜してほしい」のままでは、何を作れば合格なのか判断できませんよね。
要求仕様書を書く時・受け取った時のチェックポイント
ここからは、立場ごとに見ておきたいポイントをまとめます。
発注側が要求仕様書を書く時
要求仕様書は、上手な文章である必要はありません。大事なのは、困りごとと願いが漏れなく伝わることです。
- 今の業務で困っていることを、具体的な場面で書いている
- 「なぜそうしたいのか」の理由が添えられている
- 今回どうしても実現したいことと、できればうれしいことを分けている
- 関わる部署と、使う人のおおよその役割が書かれている
- 決まっていないことを「未定」と正直に書いている
『未定のことを書くと頼りなく見えるかも』と心配になるかもしれません。ただ、未定のまま隠すより、未定だと書いてあるほうが、開発側は提案の中で選択肢を出しやすくなるんです。
開発側が要求仕様書を受け取った時
開発側は、要求仕様書を読んで、要件定義の打ち合わせで何を確かめるかを準備します。
| 見るところ | 見つけたら（例） |
|---|---|
| あいまいな言葉 | 「早く」「簡単に」をどの程度か確かめる質問を用意する |
| 理由が書かれていない要望 | なぜ必要かを最初の打ち合わせで聞く |
| ぶつかり合う要望 | どちらを優先するか、発注側の責任者に判断をお願いする |
| 書かれていない業務 | 例外の処理や月末の処理など、抜けやすい場面を質問する |
| 運用や移行の話がない | 動かした後の運用、今のデータの移し方を確かめる |
受け取った要求仕様書は、要件定義が終わった後も捨てずに残しておきましょう。要件定義書の各要件が、どの要望から来たのかをたどれるようにしておくと、後から変更の話が出た時に役立ちます。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
要件定義書に「出どころ」の列を作っておく
要求と要件をつなぐ一番簡単な方法は、要件定義書の要件一覧に「元の要求の番号」の列を作っておくことです。
| 要件の番号 | 要件（例） | 元の要求の番号 |
|---|---|---|
| 1 | 更新期限の一定日数前に担当者と上長へ通知する | 要求1 |
| 2 | 契約名・取引先名・期限で検索できる | 要求2 |
| 3 | 契約ごとに対応記録を残せる | 要求3 |
こうしておくと、『この機能はなぜ必要なんだっけ？』と聞かれた時に、すぐ元の困りごとまでさかのぼれます。良い要件の性質として挙げられる「追跡できる」も満たしやすくなりますよ。
合意した後に要求が変わったら
要件定義書に合意した後で、『やっぱりこうしてほしい』という新しい願いが出てくることもありますよね。業務は動いているので、願いが変わるのは自然なことです。
その時は、要件定義書をこっそり書き換えるのではなく、変更の依頼として記録しておきましょう。
- 新しい願いと、その理由を発注側が書き出す
- 開発側が、費用や期間、ほかの要件への影響を見積もる
- 双方で取り入れるかどうかを決め、決めた結果を記録する
- 取り入れる場合は、要件定義書の版を上げて承認を取り直す
よくある相談に答えます
要求仕様書と要件定義書について、質問サイトでよく見かける相談を要約して、編集部から答えます。
相談1：要求仕様と要件定義は、同じようなものに見える
いろいろ調べたけれど、要求仕様と要件定義の違いがはっきりしない、という相談です。
いちばん分かりやすい見分け方は「誰が書いたか」と「合意済みか」です。発注側が願いをまとめたものが要求仕様、発注側と開発側が話し合って作る範囲を決めたものが要件定義、と考えると区別しやすくなります。
中身が似て見えるのは、要件定義書が要求仕様書を材料にして作られるからなんです。似ていて当然、と思っておくと気が楽ですよ。
見分けに迷った時は、文書の文末を見てみるのも手です。「〜してほしい」「〜できること」が多ければ要求仕様、「〜できる」「〜する」で、確かめ方まで決まっていれば要件定義の文書と考えられます。
もう一つの手がかりは承認欄です。発注側と開発側の両方が確認した跡があれば、合意済みの要件定義書と見てよいでしょう。
相談2：SEのヒアリングをもとに作る文書は、要求仕様書と要件定義書のどちら？
開発側のSEが発注側から聞き取った内容で文書を作る場合、どちらの名前になるのか、という相談です。
聞き取った内容を「願い」のまままとめた段階なら要求仕様書に近く、作る範囲を決めて発注側の承認を受ける段階なら要件定義書になります。同じSEが書いていても、合意したかどうかで性格が変わる、と考えてみてください。
相談3：仕様書と定義書は、名前のとおり別のもの？
上流工程を勉強していて、「仕様書」と「定義書」の違いが分からなくなった、という相談です。
- 一般的には、定義書は「何を作るか」、仕様書は「どう作るか」を書いた文書です
- 要件定義書の次に、基本設計書や詳細設計書などの仕様書が作られます
- ただし会社によって呼び方が揺れるので、文書の中身と承認する人で見分けるのが確実です
よくある質問
要求仕様書がなくても要件定義は進められますか。
進められます。ただ、発注側の願いが文字になっていないと、打ち合わせのたびに話が戻りやすくなります。メモ程度でもいいので、困りごとと願いを書いてから始めるのがおすすめです。
要求仕様書は誰が書くのが一般的ですか。
発注側の業務部門や情報システム部門が書くのが一般的です。発注側だけで書くのが難しい場合は、外部の支援を受けながらまとめることもあります。
要件定義書と仕様書は、どちらが先にできますか。
要件定義書が先です。要件定義書で作るものを決めてから、それをどう作るかを仕様書（設計書）にまとめていきます。
要求仕様書はどのくらいの細かさで書けばいいですか。
困りごとと願いが、業務を知らない人にも伝わる細かさで十分です。画面の形や操作の手順までは書かなくてかまいません。それは要件定義や設計で、開発側と一緒に決めていきます。
RFPに要件定義書をつけてもいいですか。
発注側ですでに要件まで固めているなら、つけることもあります。ただ多くの場合、RFPの段階では要求仕様書をつけ、要件定義は開発会社を選んだ後に一緒に行います。
まとめ
- 要求仕様書は発注側の「こうしてほしい」、要件定義書は双方で合意した「こうする」です
- 文書は、要求仕様書とRFP、提案書、要件定義書、仕様書の順に受け渡されるのが一般的です
- 同じ要望でも、要求仕様書は「なぜ・何を」、要件定義書は「何を、どこまで」、仕様書は「どうやって」が中心になります
- システム仕様書は設計書を指すことが多いですが、呼び方は会社で揺れるので中身で見分けましょう
- 要件一覧に元の要求の番号を残しておくと、後から理由をたどれます
コメント