当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。
分厚い仕様書を渡されて、『どこから読めばいいの？』と固まってしまった経験はありませんか。初めての仕様書は、文字が多くて頭に入りにくいですよね。
結論から言うと、仕様書は頭から順に読むより「目的と範囲」「数字と条件」「例外と変更」「検査と納品」の4ステップで読むと、要点がつかみやすくなります。
この記事では、その4ステップと、設計書にも使える読み方のコツを紹介します。
仕様書は頭から全部読まなくていい
仕様書は、最初に全体の地図をつかみ、次に自分に関係する所を深く読むのが近道です。目次と最初の章を読むだけで、どこに何が書いてあるかが見えてきます。
『全部読まないと仕事にならないのでは？』と不安になりますよね。もちろん最後には必要な所を全部読みます。
ただ、順番を決めずに読むと、大事な決めごとを読み流してしまいやすいんです。
例えば国土交通省の公共建築工事標準仕様書（建築工事編）令和7年版は、全23章です。1.1.1では、2章以降の各章は1章と併せて適用する、としています。
つまり、どの章を読む時も1章の共通事項が前提になるわけです。こうした「全体に効く決まり」が、最初の章に置かれていることはよくあります。
公共建築工事標準仕様書の1章には、共通事項、工事関係図書、工事現場管理、材料、施工、工事検査及び技術検査、完成図等の節が並んでいます。どの工事にも関わる決まりを先に置いている、という作りが目次から分かりますよね。
- 表紙と改定履歴：いつの版か、何が変わったか
- 目次：どこに何が書いてあるか
- 最初の章：用語の決まりと、全体に効くルール
仕様書を読む4ステップ
読む順番は「目的と範囲」「数字と条件」「例外と変更」「検査と納品」の4つです。1回で全部を理解しようとせず、ステップごとにメモを取りながら進めます。
この記事で使う4ステップを、表にまとめました。
| ステップ | 読む所 | つかむこと | 読みながら書くメモ |
|---|---|---|---|
| 1 目的と範囲 | 表紙、目的、適用範囲、対象外 | 何のための仕様書で、どこまでが対象か | 対象と対象外を1行ずつ |
| 2 数字と条件 | 数量、寸法、性能、期限、回数 | 守るべき値と、その条件 | 数字と単位、条件をそのまま書き写す |
| 3 例外と変更 | 「ただし」「特記による」、改定履歴 | 標準と違う所、後から変わった所 | 例外の場所と内容 |
| 4 検査と納品 | 検査、試験、納品物、提出書類 | 何をそろえたら完了か | 完了の条件の一覧 |
読みながら作る確認メモの例
4ステップで読みながら、気づいたことをメモにしておくと、あとで質問や確認がしやすくなります。編集部が作った架空の例です。
| 場所 | 書いてあること | 気になった所 | 確かめる相手 |
|---|---|---|---|
| 2章 範囲 | 申請と承認が対象。給与計算は対象外 | 勤怠の集計表の出力は対象か | 発注側の担当 |
| 3章 性能 | 一覧はふだん使う時間帯に待たせない | 「待たせない」の目安が無い | 設計の担当 |
| 5章 変更履歴 | 承認の段数を変更 | どの画面に影響するか | 設計の担当 |
| 7章 検査 | 受入れテストの合格で検収 | 合格の基準はどこに書くか | 発注側の担当 |
メモは「場所」「書いてあること」「気になった所」を分けて書くのがポイントです。自分の考えと仕様書の文を混ぜないようにしておくと、質問の時に誤解が生まれません。
ステップ1：目的と範囲
最初に「何のための仕様書か」「どこまでが対象か」をつかみます。対象外に書かれていることも、同じくらい大事です。
社内システムの仕様書なら、「勤怠の申請と承認が対象。給与計算は対象外」のような一文があるはずです。ここを読み飛ばすと、頼まれていない所まで作ってしまうことも。
ステップ2：数字と条件
数量や寸法、性能、期限などの数字は、条件とセットで読みます。数字だけを抜き出すと、どんな時の値かが分からなくなるからです。
公共建築工事標準仕様書では、「特記による。特記がなければ、表による」という書き方がよく出てきます。この場合、表の数字は特記が無い時の値です。
ITの仕様書なら「月末の締めの日は、通常の倍の申請が来ても止まらないこと」のように、数字に条件が付いていることがあります。数字と一緒に「いつ」「どんな時」を書き写しておくと、読み違いが減りますよ。
ステップ3：例外と変更
「ただし」「を除く」「特記による」が出てきたら、そこは例外の入口です。印を付けておきましょう。
公共工事では、特記仕様書や質問回答書が標準仕様書より優先されます。順番は設計図書とは？仕様書・図面・現場説明書の関係で詳しく紹介しています。
ステップ4：検査と納品
最後に、何がそろったら完了かを確かめます。検査の方法、納品物、提出する書類がその中心です。
公共の調達では、予算決算及び会計令の第101条の4で、検査は契約書や仕様書などに基づいて行うとされています。完了の条件は仕様書に書かれている、と考えて読むのがコツなんです。
システム開発なら、受入れテストの方法や、納品するプログラムと書類の一覧がここに当たります。『作り終わったのに、書類が足りなくて検収されない』とならないよう、早めに一覧を作っておきましょう。
語尾で決まりの強さを見分けるコツ
仕様書の読み方のコツは、語尾に注目することです。「しなければならない」は必須、「することが望ましい」はおすすめ、「してもよい」は選んでよい、と強さが違います。
『この書き方って、守らないといけないの？』と迷うこと、ありますよね。規格を書く時のルールを定めた JIS Z 8301:2019 では、語尾ごとに意味を決めています。
| 語尾の例 | 意味 | 読み方 |
|---|---|---|
| しなければならない、する、とする、による | 要求 | 守る決まり |
| してはならない | 禁止 | やってはいけない |
| することが望ましい | 推奨 | できるだけそうする |
| してもよい | 許容 | 選んでよい |
| する必要がない | 不必要 | しなくてよい |
すべての仕様書がこのルールで書かれているわけではありません。ただ、公的な仕様書や規格の多くは似た書き方なので、知っておくと読むスピードが上がりますよ。
「望ましい」を必須だと思い込んで、手間をかけすぎてしまうことです。逆に「による」を参考程度と読んでしまうこともあります。迷った語尾は、書いた人に確かめておきましょう。
同じ規格の説明では、「すべきである」「すべきでない」は使わず、「できる」「できない」も原則として使わない、としています。読む側としては、こうした言葉が出てきたら「どの強さの決まりか」を確かめる目印になりますね。
JIS Z 8301 では、「十分に強い」のように確かめられない表現は使わない、とも説明されています。読んでいてあいまいな言葉を見つけたら、それは質問すべき所のサインです。
設計書の読み方とコツ
システム開発の設計書は、要件定義書から基本設計書、詳細設計書へと細かくなっていきます。上の書類から順に読むと、なぜその作りなのかが分かりやすくなります。
設計書の読み方も、基本は仕様書と同じです。違うのは、書類が段階で分かれているところですね。
デジタル庁のデジタル・ガバメント推進標準ガイドラインでは、画面や帳票など利用者が直接理解できる基本設計を行った後に、機能を実現するための詳細設計を行う、としています。
| 書類 | まず見る所 | 読み方のコツ |
|---|---|---|
| 要件定義書 | 業務要件、機能要件、非機能要件 | 何のために作るかをつかむ |
| 基本設計書 | 画面、帳票、機能の一覧 | 利用者から見える動きを追う |
| 詳細設計書 | 処理の流れ、データの扱い | 自分の担当する機能を深く読む |
デジタル庁のガイドラインでは、未確定な要件はその旨を要件定義書で明らかにするとしています。「未定」「TBD」と書かれた所は、読み飛ばさずに一覧にしておきましょう。
設計書の読み方のコツは、1つの機能を入口から出口まで追うことです。例えば「登録ボタンを押したら、どの画面の値が、どのデータに保存されるか」を、書類をまたいでたどってみてください。
- 担当する機能の目的を一言で言える
- 入力、処理、出力、例外の流れを説明できる
- 未定の所と、決める人が分かっている
- 分からない所を質問の一覧にまとめた
仕様書の読み方でよくある相談
相談で多いのは「設計書の種類の違い」「書いてあるとおりに作ったのに注意された」「要件定義書からテストを作れと言われた」の3つです。どれも、書類の上下の関係を知ると見通しが立ちます。
よく寄せられる相談を、内容をまとめた形で紹介します。
相談1：システム設計書とプログラム設計書は何が違う？
システム設計書とプログラム設計書の違いを教えてほしい、という相談です。
呼び方は会社ごとに違いますが、システム全体の作りを書くのがシステム設計書、1つ1つのプログラムの中身を書くのがプログラム設計書、と分けることが多いです。読む時は、システム全体の書類から先に目を通すと迷いにくいですよ。
相談2：設計書どおりに作ったのに注意された
設計書に書いてあるとおりに作ったのに、上司に注意されてしまった、という相談もあります。
設計書に書かれていない前提や、目的と合わない所があったのかもしれません。読んでいて「これで目的に合うかな」と感じたら、作る前に質問してみてください。
「この画面、設計書では一覧だけですが、要件定義書では絞り込みも必要とあります。どちらに合わせますか」
こんな聞き方なら、根拠がはっきりして相手も答えやすくなります。
相談3：要件定義書からテスト仕様書を作れと言われた
要件定義書からテスト仕様書とテストデータを作るように言われたが、そんなやり方はふつうなのか、という相談も見かけます。
JSTQBのシラバスでは、テスト分析はテストベースを分析してテスト条件を見つける作業だとしています。要件定義書や設計書は、そのテストベースになり得る書類なんです。
読む時は、要件の1行ごとに「どうなれば満たしたと言えるか」を書き添えてみてください。それがそのまま、テストで確かめる条件の下書きになりますよ。
仕様書を読める人は、どこでも頼りにされる
仕様書を正しく読み、分からない所を質問にできる力は、システム開発でも工事でも求められます。書く側に回る時の土台にもなります。
IPAの「超上流から攻めるIT化の原理原則17ヶ条」には、「要件定義書はバイブルであり，事あらばここへ立ち返るもの」という一文があります。迷った時に立ち返れる書類を読み込めている人は、チームの中でも頼りにされますよね。
読む力がついてきたら、次は書く側です。仕様書の書き方や仕様書に書く項目と目次も合わせて読んでみてください。
今の職場で経験を積むのも、資格の勉強をしてから動くのも、どちらも正当な道です。そのうえで、要件定義や設計を任される仕事に進みたい方は、求人の仕事内容を比べてみると道が見えてきますよ。
IT・Webエンジニアの転職（PR）
仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる
要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。
無料ITエンジニアの求人を探す求人の条件・待遇は各求人票と応募先の案内でご確認ください。
よくある質問
仕様書はどこから読めばいいですか？
表紙と改定履歴、目次、最初の章の3か所から読むのがおすすめです。全体の地図をつかんでから、自分に関係する章を深く読みましょう。
仕様書の読み方のコツは何ですか？
目的と範囲、数字と条件、例外と変更、検査と納品の4ステップで読むことです。語尾で決まりの強さを見分けると、さらに読みやすくなります。
設計書の読み方のコツはありますか？
要件定義書、基本設計書、詳細設計書の順に、上の書類から読むことです。1つの機能を入口から出口まで書類をまたいで追うと、作りがつかめます。
仕様書を早く読めるようになるには？
同じ種類の仕様書を何本か読み、目次の並び方に慣れることです。どこに何が書いてあるかの見当がつくと、必要な所へすぐにたどり着けるようになります。
分からない所があった時はどうすればいいですか？
どの書類のどこが分からないのかを書き出して、書いた人や担当者に質問しましょう。自分の解釈で進めると、あとで手戻りになりやすいです。
まとめ
- 仕様書は表紙・目次・最初の章から全体をつかむ
- 目的と範囲、数字と条件、例外と変更、検査と納品の4ステップで読む
- 語尾で決まりの強さを見分ける
- 設計書は上の書類から順に、1つの機能を追って読む
- 分からない所は質問の一覧にして確かめる
コメント