この記事の結論
- 仕様書とは、成果物や製品・システムが満たすべき条件・仕様（機能・性能・構造など）を明文化した文書のこと。
- IT・製造・Web制作など業界によって指す内容の粒度が異なる。
- 「設計書」は仕様を実現する方法（How）を示す文書であり、仕様書（What）とは役割が異なる。
- 「要件定義書」は最上流でユーザー側の要望を整理する文書で、仕様書はそれを開発側の言葉に落とし込んだもの。
- 仕様書には機能仕様書・外部仕様書・内部仕様書・製品仕様書など複数の種類がある。
仕様書とは何か｜基本の定義
仕様書とは、ある製品・システム・サービス・成果物が「何を満たすべきか」を明文化した文書の総称です。機能、性能、構造、寸法、材質、動作条件など、対象物の仕様（スペック）を第三者が読んでも理解できる形で記述します。
仕様書の目的は、発注者と受注者、あるいは開発チーム内のメンバー同士で「作るべきものの認識」を一致させることにあります。仕様書が曖昧だと、完成物が期待と異なるという手戻りが発生しやすくなるため、実務上は極めて重要な文書と位置づけられています。
業界によって異なる「仕様書」の使われ方
「仕様書」という言葉は業界によってニュアンスが異なります。同じ言葉でも指している内容の粒度・対象が変わるため、文脈に応じた理解が必要です。
IT・システム開発における仕様書
IT業界では、システムが持つべき機能や画面遷移、データ構造、APIの入出力などを記述した文書を指します。後述する「機能仕様書」「外部仕様書」「内部仕様書」など、開発工程に応じて複数の種類に細分化されるのが特徴です。
製造業における仕様書
製造業では、製品の寸法・材質・性能値・許容誤差など、モノとしての具体的なスペックを定めた文書を指します。図面とセットで運用されることが多く、品質保証や検査基準の根拠にもなります。
Web制作における仕様書
Web制作では、サイトの構成・機能要件・レスポンシブ対応方針・CMSの仕様などをまとめた文書を指すことが一般的です。デザインカンプや要件定義書とセットで用いられ、制作範囲の合意形成に使われます。
建設業における仕様書
建設業では、工事の施工内容・使用材料・工法・数量などを定めた文書を指します。設計図面とセットで運用され、施主・施工会社・監理者の間で工事範囲や品質基準の認識を合わせる役割を持ちます。公共工事では発注者側が定める「共通仕様書」と、個別案件ごとの「特記仕様書」に分かれるのが特徴です。
仕様書と設計書・要件定義書・提案書の違い
実務で混同されやすい4つの文書について、目的と役割の違いを整理します。それぞれ「誰の視点で」「何を」記述するかが異なります。
| 文書名 | 主な視点 | 記載内容 | 作成タイミング |
|---|---|---|---|
| 要件定義書 | 発注者・利用者 | 実現したいこと（What／Why） | 企画〜上流工程 |
| 仕様書 | 開発者・作り手 | 満たすべき仕様（What） | 要件定義後 |
| 設計書 | 開発者・実装者 | 実現する方法（How） | 仕様確定後 |
| 提案書 | 受注希望側 | 解決策の提案・見積り | 要件定義前後 |
簡単に言えば、要件定義書は「何を実現したいか」、仕様書は「何を満たすべきか」、設計書は「どう作るか」を記述する文書です。提案書はこれらとは別軸で、受注前に解決策や見積りを提示する営業的な文書という位置づけになります。
開発工程における位置づけ
一般的なシステム開発の流れでは、以下の順序で文書が作成されます。
- ①要件定義（要件定義書）→ ユーザー側の要望を整理
- ②仕様策定（仕様書）→ 要望を機能・性能として具体化
- ③設計（設計書）→ 仕様を実現する構造・処理方法を決定
- ④実装・製造 → 設計に基づいて開発・製造
- ⑤テスト・検証 → 仕様書の内容を満たしているか確認
仕様書の種類
仕様書には対象や粒度によっていくつかの種類があります。代表的なものを整理します。
| 種類 | 概要 | 主な読み手 |
|---|---|---|
| システム仕様書 | システム全体の構成・機能・性能を定めた文書 | 開発チーム全体 |
| 機能仕様書 | 個々の機能の動作・条件分岐を詳細に定義 | 実装担当者 |
| 外部仕様書 | 利用者から見える画面・操作性など外部から見た仕様 | 発注者・利用者 |
| 内部仕様書 | プログラム内部の処理・データ構造など実装レベルの仕様 | 開発者 |
| 製品仕様書 | 製品の寸法・材質・性能値などモノとしてのスペック | 製造・品質保証担当 |
| 業務仕様書 | 業務フローや運用ルールをまとめた仕様 | 業務担当者・運用チーム |
外部仕様書は「利用者にとってどう見えるか・どう動くか」を記述するのに対し、内部仕様書は「内部でどう処理しているか」を記述する点が大きな違いです。両者はセットで整備されることが多く、外部仕様書のみを発注者と合意し、内部仕様書は開発チーム内部の実装ガイドとして使う運用も一般的です。
仕様書の書き方・記載すべき項目
仕様書を作成する際に押さえておきたい基本構成項目です。対象がシステムか製品かによって多少項目は変わりますが、共通する骨格は以下の通りです。
- 文書の目的・対象範囲（スコープ）
- 用語定義（関係者間で解釈がずれやすい用語の統一）
- 機能一覧・機能ごとの詳細仕様
- 非機能要件（性能・可用性・セキュリティなど）
- 画面・帳票・データ項目の仕様
- 前提条件・制約事項
- 入出力の条件と例外処理
- 関連文書との参照関係（要件定義書・設計書との対応）
- 改訂履歴（バージョン管理）
- 承認欄（作成者・確認者・承認者）
書き方のポイント
仕様書は「読み手によって解釈がぶれない」ことが最も重要です。曖昧な形容詞（「早く」「使いやすく」など）を避け、可能な限り数値・条件・図表で具体化することが基本になります。また、テンプレートを流用する場合も、対象プロジェクトの規模に応じて項目を取捨選択し、過不足のない粒度に調整することが実務上のコツです。
仕様書のテンプレート例（記入例）
機能仕様書を例に、実際の記載イメージを示します。項目名と記載内容の対応をつかむことで、自社テンプレートを作成する際の土台にできます。
| 項目 | 記載例 |
|---|---|
| 機能名 | ユーザー登録機能 |
| 概要 | 会員がメールアドレスとパスワードでアカウントを作成する機能 |
| 入力項目 | 氏名／メールアドレス／パスワード（8文字以上・英数字混在） |
| 処理条件 | メールアドレスの重複チェック後、確認メールを送信 |
| 出力・遷移先 | 登録完了画面へ遷移し、確認メールを送信 |
| 例外処理 | メールアドレス重複時はエラーメッセージを表示し再入力を促す |
このように、1機能につき「概要・入力・処理条件・出力・例外処理」をセットで記載すると、実装者が仕様書だけを見て開発を進められる粒度になります。
仕様書作成時によくある失敗パターン
仕様書の質が低いと、後工程での手戻りやトラブルに直結します。特に多い失敗パターンを3つ紹介します。
- 曖昧な表現に頼ってしまう：「使いやすく」「高速に」など主観的な表現のみで、判断基準となる数値や条件が示されていないケース。実装者やテスト担当者が独自解釈で進めてしまい、完成後の認識齟齬につながります。
- 例外処理の記載漏れ：正常系の仕様しか書かれておらず、エラー時・異常時の挙動が未定義のまま実装が進んでしまうケース。テスト工程で初めて仕様の不備が発覚しやすい失敗パターンです。
- 関連文書との不整合：要件定義書や設計書との対応関係を明記しないまま更新を重ねた結果、どの文書が最新の正とみなされるか分からなくなるケース。改訂履歴・参照関係の管理不足が主な原因です。
よくある質問
- 仕様書と設計書はどちらを先に作りますか？
- 一般的には仕様書を先に確定し、その内容を実現する方法として設計書を作成します。仕様（What）が固まらないまま設計（How）を進めると手戻りの原因になります。
- 仕様書がないとどんな問題が起きますか？
- 発注者と開発側の認識がずれたまま進行し、完成後に「思っていたものと違う」という手戻りが発生しやすくなります。検収時のトラブルの多くは仕様書の不備・不足が原因とされています。
- 要件定義書と仕様書を1つにまとめてもよいですか？
- 小規模プロジェクトでは一体化して運用されることもあります。ただし規模が大きくなるほど、視点（利用者側／開発者側）の違いから分けて管理した方が認識齟齬を防ぎやすくなります。
- 外部仕様書と内部仕様書は必ず両方必要ですか？
- 必須ではありませんが、発注者との合意には外部仕様書、開発チーム内の実装統一には内部仕様書があると、後工程での認識違いを減らせます。プロジェクト規模に応じて判断されます。
- 仕様書に決まったフォーマットはありますか？
- 業界共通の絶対的な標準フォーマットはありませんが、社内テンプレートや業界団体が公開しているガイドラインを土台にするケースが一般的です。
- 仕様書は誰が作成するのが一般的ですか？
- システム開発ではSE・PMなど開発側の担当者が作成することが多く、製造業では設計担当や品質保証部門が作成します。ただし発注者側がレビュー・承認する体制を取るのが一般的です。
- 仕様書の変更が発生した場合、どう管理すればよいですか？
- 改訂履歴欄にバージョン・変更日・変更内容・承認者を記録し、旧版との差分が追えるようにするのが基本です。関連する設計書やテストケースへの影響範囲も併せて確認します。
- 仕様書と契約書の関係はどうなっていますか？
- 仕様書は契約の付属文書として扱われることが多く、契約時に合意した仕様書の内容が、検収基準や瑕疵担保責任の判断根拠になるケースがあります。
まとめ
仕様書は、成果物が満たすべき条件を明文化し、関係者間の認識を一致させるための文書です。要件定義書・設計書・提案書とは役割が異なり、それぞれ「誰の視点で」「何を」記述するかを理解しておくことが、実務での使い分けの第一歩になります。
仕様書には外部仕様書・内部仕様書・機能仕様書など複数の種類があり、プロジェクトの規模や対象に応じて必要な文書を選択・整備することが、手戻りの少ない開発・製造プロセスにつながります。
研究をシェア！
