仕様書 しようしょ

---

仕様書とは

仕様書（スペック・スペシフィケーション） とは、システムやソフトウェアを開発するうえで「何を・どう作るか」を文書化したものです。発注者（お客さん側）と開発者（ベンダー側）が共通認識を持つための”約束の書類”であり、開発プロジェクトの根幹を支えます。

仕様書には大きく分けて「何を作るか（要件）」と「どう作るか（設計）」の2種類があります。前者を要件定義書・要求仕様書、後者を設計仕様書と呼ぶことが多く、プロジェクトの工程が進むにつれて段階的に詳細化されていきます。

仕様書が不十分だと、開発中に「言った・言わない」のトラブルが多発し、手戻りコストが膨らみます。逆に丁寧に作られた仕様書はプロジェクトの品質・コスト・納期（QCD）すべてに好影響をもたらします。発注者にとっても「自分たちが何を欲しいかを整理する機会」として非常に重要です。

---

仕様書の種類と役割

システム開発の流れに沿って、仕様書は段階的に作成されます。

名称	作成タイミング	主な内容	主な作成者
要求仕様書（RFP含む）	発注前〜要件定義	ビジネス要件・目的・制約条件	発注者（お客さん）
要件定義書	要件定義フェーズ	機能要件・非機能要件の確定	発注者＋ベンダー
基本設計書（外部設計書）	設計フェーズ前半	画面・帳票・データの外側の定義	ベンダー
詳細設計書（内部設計書）	設計フェーズ後半	プログラム内部のロジック定義	ベンダー（SE・PG）
テスト仕様書	テストフェーズ	テストケース・合否基準	ベンダー＋発注者

機能要件と非機能要件の違い

仕様書を読む・書くうえで最重要の区別がこれです。

• 機能要件：「〜できること」。例）ユーザーがIDとパスワードでログインできる
• 非機能要件：「どの程度か・どんな条件か」。例）1,000人同時アクセスに耐えること、24時間365日稼働すること、レスポンスは3秒以内

非機能要件は発注者が見落としがちですが、後から追加すると費用が跳ね上がるため、最初の仕様書に必ず盛り込むことが鉄則です。

語呂合わせ：仕様書の三大確認ポイント「誰が・何を・いつまでに」

仕様書レビューでは「誰が（アクター）・何を（機能）・いつまでに（性能・期限）」の3点を確認する習慣をつけると漏れが防げます。

---

歴史と背景

• 1960年代：大型コンピューターの登場とともに、ソフトウェア開発が本格化。口頭だけでは管理できなくなり、文書化の必要性が高まる
• 1970年代：ウォーターフォール開発モデルが普及。「要件定義→設計→実装→テスト」の各フェーズに対応する仕様書体系が確立される
• 1980〜90年代：IEEEが仕様書の国際標準（IEEE 830など）を制定。品質管理の観点から仕様書の標準化が進む
• 2000年代：アジャイル開発の台頭により「厚い仕様書より動くソフトウェアを」という考え方も広まる。ただし発注・契約には依然として仕様書が必要
• 2010年代以降：クラウドサービスやSaaSの普及で「仕様書レスの開発」も増えたが、大規模システムや官公庁案件では詳細な仕様書が引き続き必須

---

仕様書の位置づけ：開発工程全体の中で

開発プロジェクトにおける仕様書の流れを図解します。

発注者が特に押さえるべき仕様書：要件定義書

発注者の立場で最も重要なのが要件定義書です。ここで合意した内容が開発の”基準”となり、後から変更するほどコストが増大します。一般的に、要件定義フェーズの変更コストを1とすると、テスト後の変更は10〜100倍かかると言われています。

---

関連する規格・RFC

規格番号	内容
IEEE 830	ソフトウェア要件仕様（SRS）の推奨プラクティス。要件定義書の国際標準
ISO/IEC/IEEE 29148	システム・ソフトウェア要件のエンジニアリングプロセス国際規格

---

関連用語

• 要件定義 — 発注者とベンダーが「何を作るか」を合意する最重要フェーズ
• RFP（提案依頼書） — ベンダーに提案を求めるための発注前文書
• ウォーターフォール開発 — 仕様書を段階的に整備しながら進める伝統的な開発手法
• アジャイル開発 — 仕様を柔軟に変えながら短サイクルで進める現代的な開発手法
• 基本設計 — 要件定義の後に行う、システムの外部仕様を定める設計フェーズ
• テスト仕様書 — 動作確認のためのテストケースと合否基準をまとめた文書
• 検収 — 発注者が納品物を仕様書と照らし合わせて確認・承認するプロセス
• 非機能要件 — 性能・可用性・セキュリティなど「どの程度か」を定める要件