当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。
『要件定義書と仕様書って、同じものじゃないの？』と、プロジェクトの資料を見ながら首をかしげている方も多いはずです。
結論から言うと、要件定義書はシステムで「何ができればよいか」を決めて合意する最初の文書です。仕様書はもっと広い呼び名で、要件定義書のあとに作る設計書などを含めて呼ぶこともあります。
この記事を読めば、要件定義書・仕様書・設計書の作る順番と中身の差が分かり、手元の書類がどれに当たるかを見分けられます。
要件定義書と仕様書の違いは「範囲」と「順番」
要件定義書は、開発を始める前に作る「何ができればよいか」の文書です。仕様書は、要件定義書や設計書など、作る物の条件を書いた文書の総称として使われることが多い言葉です。
要件定義書は、名前のとおり「要件を定義する」文書です。デジタル庁の標準ガイドライン群用語集では、要件定義を、情報システムの調達で必要な要件を明確に定める行為、またはその定めた内容と説明しています。
一方の「仕様書」は、使う人によって指す範囲が変わる言葉なんです。要件定義書を仕様書と呼ぶ人もいれば、基本設計書や機能仕様書のことを仕様書と呼ぶ人もいます。
| 見るところ | 要件定義書 | 仕様書（広い意味） |
|---|---|---|
| 範囲 | 1つの文書の名前 | いくつもの文書の総称 |
| 作る時期 | 開発の最初 | 要件定義から設計の段階まで |
| 中身 | 業務の要件、機能の要件、非機能の要件 | 機能の動き、画面、データなど作る物の条件 |
| 主な役割 | 頼む側と作る側の合意 | 作る物の条件をそろえる |
仕様書と要件定義書を同じ意味で使う会社もある
『うちの会社では、要件定義書のことを仕様書と呼んでいる』という方もいますよね。それも間違いではありません。
大事なのは、名前より中身です。その書類に「業務で何をしたいか」から書かれていれば要件定義書、「画面やデータをどう作るか」まで書かれていれば設計寄りの仕様書、と考えると迷いません。
作る順番・書く人・主な読み手で並べる
要件定義書、基本設計書、詳細設計書は、この順番で作ります。書く人と主な読み手が少しずつ変わっていくので、流れで覚えると区別がつきやすくなります。
要件定義書と仕様書、設計書の違いは、流れの中で見るといちばん分かりやすいんです。編集部が、作る順番、書く人、主な読み手で並べてみました。
| 順番 | 文書 | 書く人 | 主な読み手 | 決めること |
|---|---|---|---|---|
| 1 | 要件定義書 | 発注側（開発側が手伝うことも多い） | 発注側の部門・開発側 | 何ができればよいか |
| 2 | 基本設計書 | 開発側のSE | 発注側・開発側 | 利用者から見える画面や帳票、データ |
| 3 | 詳細設計書 | 開発側のSE | 開発側のプログラマー | プログラムの中の作り方 |
| 4 | テスト仕様書 | 開発側（受入れは発注側） | テストをする人 | 何をどう確かめれば合格か |
要件定義書は発注側の責任で作る
IPAの「超上流から攻めるIT化の原理原則17ヶ条」には、「要件定義は発注者の責任である」という一条があります。同じく「要件定義書はバイブルであり、事あらばここへ立ち返るもの」という一条もあります。
『でも、発注側だけで書くのは無理…』と思いますよね。実際は、開発側がヒアリングをして下書きを手伝い、発注側が中身を確かめて合意する進め方がよく見られます。
要件定義書・基本設計書・詳細設計書の中身
デジタル庁のDS-100（デジタル・ガバメント推進標準ガイドライン）では、要件定義書に業務要件、機能要件、非機能要件、システム方式を書くとしています。機能要件には、機能、画面、帳票、データ、外部インタフェースに関する事項が入ります。
同じDS-100では、画面や帳票など利用者が直接理解できる基本設計を行ってから、機能を実現する詳細設計を行う、とされています。要件定義書、基本設計書、詳細設計書は、この順番でだんだん細かくなっていくわけです。
要件定義書の中身は要件定義書とは？目的・書く内容・作る流れ、基本設計書は基本設計書とは？書く項目と書き方でくわしく紹介しています。
要件定義書と基本設計書の違い
要件定義書は「何ができればよいか」、基本設計書は「利用者から見てどう動くか」を決めます。要件定義書に書いた要件を、画面や帳票の形に落としこんだのが基本設計書です。
要件定義書と基本設計書は、どちらも発注側が読む文書なので、混ざりやすいですよね。違いを例で見てみましょう。
| 書く内容 | 要件定義書での書き方 | 基本設計書での書き方 |
|---|---|---|
| 検索 | 顧客を名前と電話番号で探せること | 検索画面の項目の並びと、結果一覧の列 |
| 帳票 | 月ごとの売上を印刷できること | 帳票の見た目、出す項目、並び順 |
| 性能 | 混み合う時間帯でも業務が止まらないこと | 画面ごとの応答の目標と、そのための構成 |
IPAのDX SQUARE「要件定義とは？」では、基本設計を「要件定義でまとめた要件を具体化し、業務フローを明確にする工程」と説明しています。この説明からも、基本設計書が要件定義書の続きだと分かります。
要件定義書に画面のレイアウトまで細かく書きこんでしまい、肝心の「業務で何をしたいか」が抜けてしまう失敗です。要件定義書では、まず目的と業務の流れを固めましょう。
非機能の要件は要件定義書で決めておく
要件定義書と設計書の境目で抜けやすいのが、性能やセキュリティなどの非機能の要件です。画面の話に夢中になると、『止まった時にどうするか』は誰も決めていなかった、ということが起きがちなんです。
DS-100では、要件定義書の非機能要件として、規模、性能、信頼性、情報セキュリティ、移行、運用、保守などの事項を挙げています。IPAの非機能要求グレード2018も、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分けています。
これらは基本設計書で細かく形にしますが、「どの程度を目指すか」は要件定義書の段階で合意しておくのが基本です。くわしくは非機能要件とは？要件定義書に書く項目と決め方で紹介しています。
要求定義・機能仕様書との違い
要求は「こうしたい」という希望、要件はそれを整理して合意したものです。機能仕様書は、機能の動きを細かく決めた文書で、要件定義書の一部や、そのあとの文書として作られます。
ここまで読んで、『要求定義書や機能仕様書は、どこに入るの？』と気になった方もいますよね。
IPAのDX SQUAREでは、要求を「ビジネス要求」と「システム化要求」に分け、それを文書にして関係者と合意したものが要件、という趣旨で説明しています。ただし、要求と要件の標準的な定義は存在しない、とも書かれています。
| 文書 | 書くこと | 要件定義書との関係 |
|---|---|---|
| 要求定義書・要求仕様書 | 頼む側の希望や困りごと | 要件定義書のもとになる |
| 要件定義書 | 合意した要件 | 中心となる文書 |
| 機能仕様書 | 機能の動きの細かい決まり | 要件定義書の一部、またはそのあとの文書 |
| 基本設計書・詳細設計書 | 作り方 | 要件定義書を受けて作る |
機能仕様書と要件定義書の違い
機能仕様書は、システムが持つ機能ごとに、何を入力して何が出てくるかを決める文書です。ソフトウェアの用語の国際規格 ISO/IEC/IEEE 24765:2010 でも、functional specification は機能を決める文書で、要求仕様の一部になることが多いとされています。
要件定義書が非機能の要件（性能やセキュリティなど）まで含めた全体を書くのに対して、機能仕様書は機能の部分を深く書く文書、と考えると区別しやすくなります。要求仕様書については要求仕様書とは？要件定義書との違いと書く項目で紹介しています。
要件定義書と仕様書の違いでよくある相談
相談で多いのは「要求定義と要件定義の違い」「仕様書と定義書の違い」「要件定義書からテスト仕様書を作るのは普通か」です。どれも、文書の順番とつながりで考えると答えが見えてきます。
知恵袋には、要件定義書と仕様書の違いについての相談も多く寄せられています。閲覧の多いものを要約してお答えしますね。
相談1：要求定義と要件定義はどう違う？
システム会社の新入社員が、上司に要件定義を勉強するよう言われ、要求定義との違いが分からなくなった、という相談です。
ざっくり言うと、要求は頼む側の「こうしたい」、要件はそれを整理して両者が合意した「これを作る」です。ただ、先ほどのとおり標準的な定義はないので、会社の中での使い方を先輩に確かめておくと安心です。
「この希望は、全部システムで実現するんですか？」
「いや、予算と期間を見て、合意できたものだけが要件になるんだよ」
こんなやり取りの中で、要求が要件に絞られていくイメージです。
相談2：仕様書と定義書の違いが分からない
上流工程を勉強していて、要件定義書や仕様書など「書」の付く文書が多く、どれがどれか分からない、という相談です。
迷ったら、作る順番で並べてみてください。要件定義書が最初、そのあとに基本設計書、詳細設計書と続きます。仕様書は、その途中の文書をまとめて呼ぶ言葉として使われることが多いんです。
相談3：要件定義書からテスト仕様書を作れと言われたけれど、普通のこと？
要件定義書をもとにテスト仕様書とテストデータを作るよう指示され、そのやり方でいいのか不安になった、という相談です。
実は、受入れテストのように「要件を満たしているか」を確かめるテストでは、要件定義書がよりどころになります。DS-100でも、利用者が参加する受入テストを発注側が行う、とされています。ただ、プログラム単位のテストでは設計書も使うので、どのテストの仕様書かを確かめておきましょう。
- 業務の目的や困りごとから書かれているか
- 頼む側と作る側の両方が合意した記録があるか
- 画面や帳票の形まで決めているか
- プログラムの中の処理まで書いているか
- テストの合否の基準として使われているか
要件定義の経験は上流工程の仕事につながる
要件定義書を書いたり読んだりした経験は、上流工程を任される職場で評価されやすいものです。今の担当から一歩進みたい人は、求人の仕事内容を比べてみると道が見えてきます。
要件定義書と仕様書の違いが分かると、打ち合わせで「それは要件の話？設計の話？」と整理できるようになりますよね。この整理ができる人は、チームの中で頼りにされるんです。
今の職場で要件定義の場に同席させてもらうのも、立派な一歩です。そのうえで、要件定義や設計を任される仕事に進みたい方は、求人ごとの担当工程を見比べてみてください。
IT・Webエンジニアの転職（PR）
仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる
要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。
無料ITエンジニアの求人を探す求人の条件・待遇は各求人票と応募先の案内でご確認ください。
よくある質問
要件定義書と仕様書は同じものですか？
同じ意味で使う会社もありますが、一般的には違います。要件定義書は開発の最初に作る「何ができればよいか」の文書で、仕様書は要件定義書や設計書などを含む広い呼び名として使われます。
要件定義書・基本設計書・詳細設計書の順番は？
要件定義書、基本設計書、詳細設計書の順に作ります。要件定義書で決めたことを、基本設計書で利用者から見える形にし、詳細設計書でプログラムの作り方まで落としこみます。
要件定義書は誰が書きますか？
責任を持つのは発注側です。IPAの原理原則17ヶ条にも「要件定義は発注者の責任である」とあります。実際には、開発側が下書きを手伝い、発注側が確かめて合意することが多いです。
機能仕様書と要件定義書の違いは？
要件定義書は非機能の要件まで含めた全体の要件を書く文書で、機能仕様書は機能ごとの動きを細かく決める文書です。機能仕様書は要件定義書の一部として作られることもあります。
まとめ
- 要件定義書は開発の最初に作る「何ができればよいか」の文書
- 仕様書は、要件定義書や設計書を含む広い呼び名として使われる
- 作る順番は要件定義書、基本設計書、詳細設計書
- 要求は希望、要件は合意したもの。機能仕様書は機能を深く書く文書
- 迷ったら、作る順番と読み手で見分ける
コメント