仕様書とは
仕様書とは、システムやソフトウェアが「何を、どのように実現するか」を、発注側と開発側など関係者全員が同じ理解を持てるように文書にまとめたものです。
言い換えると、「作るものの取り決めを書いた約束事のメモ」です。口頭や打ち合わせだけで進めると、人によって理解が違ったまま開発が進み、完成してから「思っていたものと違う」となりがちです。仕様書はそれを防ぐための共通の基準です。英語では specification（仕様）と呼ばれ、略して「スペック」とも言います。システム開発では、要件定義書・機能仕様書・設計書などの総称として「仕様書」と呼ぶこともあれば、特定の文書を指すこともあり、使われ方には幅があります。
種類と記載項目
システム開発で作られる主な文書と、その役割は次のとおりです。
| 文書 | 主な書き手 | 内容 | 主な読み手 |
|---|---|---|---|
| 要件定義書 | 発注側と開発側で合意 | 何のために、何を実現するか（業務・機能・非機能の要件） | 経営・業務担当・開発 |
| 機能仕様書（外部仕様） | 開発側（発注側が確認） | 画面・帳票・操作・入出力など、利用者から見た振る舞い | 業務担当・開発・テスト |
| 基本設計書 | 開発側 | システム構成、画面設計、データ構造、外部連携 | 発注側の担当・開発 |
| 詳細設計書 | 開発側 | プログラム単位の処理内容 | 開発 |
| API仕様書 | 開発側 | 外部とのデータのやり取りの形式 | 連携先の開発者 |
機能仕様書に一般的に含まれる項目には、次のようなものがあります。
- 機能の一覧と、それぞれの目的
- 画面ごとの入力項目、表示内容、入力チェックのルール
- 画面遷移（どの操作でどの画面へ移るか）
- 計算や判定のルール（料金計算、ステータスの変わり方など）
- エラー時の表示と動作
- 権限（誰がどの操作をできるか）
- 帳票やファイル出力の形式
実務での使い方・具体例
架空の例として、会員向けの予約サイトを開発会社に依頼するケースを考えます。打ち合わせでは「予約のキャンセルができること」で合意していましたが、仕様書に「何日前まで」「キャンセル料は発生するか」「管理者側からもキャンセルできるか」が書かれていなかったため、完成後に追加の改修が必要になりました。
このような行き違いを減らすために、発注側は次の点を意識して仕様書に関わります。
- 業務のルールは発注側が書く・確認する：キャンセル期限や料金計算など、事業の判断にあたる部分は開発側では決められません。
- 例外や異常時のケースを確認する：「満席のとき」「途中で通信が切れたとき」「入力が間違っているとき」にどうなるかを読む。
- 画面のイメージと照らし合わせる：文章だけでは伝わりにくいので、画面のラフや遷移図と一緒に確認する。
- 変更の履歴を残す：合意後に変えた点は、日付と理由とともに記録する。
仕様書は作って終わりではなく、テストの基準にもなります。受入テストでは、仕様書に書かれた動作になっているかを確認するため、曖昧な記述は検収時の争点になりやすい部分です。「使いやすいこと」「高速に表示されること」のような書き方では、合否を判断できません。「検索結果は〇件ずつ表示する」「一覧画面は通常の利用で数秒以内に表示される」のように、確認できる表現に置き換えておくと、テストと検収がスムーズになります。
また、システムの運用が始まった後も、仕様書は保守や改修の基準として使われます。改修のたびに仕様書を更新しておかないと、数年後には実際の動作と文書がずれ、誰も正しい仕様を説明できなくなります。改修の依頼と一緒に、仕様書の更新も作業範囲に含めておくのが望ましいです。
一方、新規事業のMVPのように、仕様が検証を通じて変わることが前提の開発では、最初から細部まで書き込むより、優先度の高い機能の振る舞いに絞った軽量な仕様書と、画面のプロトタイプを組み合わせて進める方が合理的なこともあります。
よくある誤解と注意点
- 「開発会社が書くもの」ではない：業務ルールや優先度は発注側にしか決められません。最低でも内容の確認と承認には関わります。
- 分厚いほど良いわけではない：読まれない仕様書は意味がありません。判断が必要な点が明確に書かれていることが大切です。
- 「当然こうなるはず」は書く：発注側にとって当たり前のことほど、開発側には伝わっていないことがあります。
- 最新版を一つに決める：版が複数出回ると、どれが正しいか分からなくなります。
関連用語
- 基本設計：システムの全体像や画面・データを設計する工程。
- 詳細設計：プログラム単位の処理を設計する工程。
- 画面設計書：画面のレイアウトや項目をまとめた文書。
- 画面遷移図：画面のつながりを図にしたもの。
- ユースケース：利用者がシステムで達成したいことの記述。
- 実践記事：要件定義書の書き方、MVPの軽量な仕様書
Otsumuに相談できること
小規模な改修や、業務ルールがシンプルな開発であれば、開発会社が用意する仕様書を発注側が確認する形で十分に進められます。何をどこまで書けばよいか分からない、開発会社から出てきた仕様書が妥当か判断できない、仕様が固まらず開発を始められない、といった場合は、目的から逆算して必要な機能と仕様を整理するところから支援できます。Otsumuではシステム開発や新規事業の爆速MVPシステム開発の中で、軽量で判断しやすい仕様づくりをお手伝いします。30分の無料相談でご相談ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01