仕様書とは？設計書・要件定義書との違いと発注者が確認すべき観点を解説

システム開発の発注では、仕様書のあいまいさがそのまま追加費用や納品時のもめごとに直結します。仕様書とは、作るシステムの機能や画面、データ、制約条件を具体的に書き出し、発注者と開発会社の認識をそろえる文書です。この記事では、仕様書の定義と基本項目、設計書・要件定義書・RFPとの違い、要求仕様書や機能仕様書といった種類、書き方の手順とテンプレートの扱いを整理します。そのうえで、請負契約と準委任契約で仕様書の役割がどう変わるか、あいまいな仕様書がどんなトラブルを招くかを、発注者の立場から具体的に示します。

まとめ：仕様書は発注者と開発会社の認識をそろえる合意の土台

仕様書は「何を作るか」を機能・画面・データ単位で書き出し、発注者と開発会社が同じ完成イメージを持つための文書です。要件定義書が業務上の要求を確定させる文書、設計書が実装方法を指示する文書であるのに対し、仕様書はその中間で「実現する機能の具体像」を担います。三者は工程と目的で役割分担しており、混同すると発注時の合意点がぼやけます。

発注者にとっての勘どころは、仕様書を単なる技術資料ではなく契約の判断材料として読むことです。請負契約では仕様書が完成の判定基準になり、準委任契約では作業範囲の目安になります。仕様書に「未定」「別途調整」が多く残ったまま着手すると、追加費用や契約不適合の争点になりやすいため、発注前のレビューで合意範囲と検収基準まで確認しておきます。

仕様書とは何か｜定義・目的と作成者・発注者それぞれの関わり方

仕様書は、システムが満たすべき機能や動作を具体的に記述し、開発の指示と検収の基準を兼ねる文書です。まずは定義と目的、書くべき項目、作るタイミングと担当を押さえます。

仕様書の定義と役割｜何をどこまで決め誰の認識をそろえる文書か

仕様書とは、対象システムの機能・画面・入出力データ・性能や制約条件を、開発者が実装できる粒度まで書き下した文書を指します。役割は二つ。ひとつは開発会社への作業指示、もうひとつは完成物が要求どおりかを判定する検収の物差しです。発注者が「使いやすく」とだけ伝えた要望を、「一覧画面は1秒以内に表示」「入力エラーは項目単位で赤字表示」のように検証できる形へ翻訳したものが仕様書だと考えると分かりやすいでしょう。あいまいな言葉を検証可能な記述へ落とし込むことが、この文書の値打ちを決めます。

仕様書に記載する基本項目｜目的・機能・画面・データ・制約条件

仕様書の構成は開発対象で変わりますが、発注者が最低限そろっているか確認したい項目には共通するものがあります。次の要素が具体的に書かれているかを目安にしてください。

• システムの目的と対象業務・利用者の範囲
• 機能一覧と各機能の入力・処理・出力
• 画面構成と画面遷移、項目ごとの入力チェック
• 扱うデータの項目定義と保持期間・件数の想定
• 性能・セキュリティ・外部システム連携などの制約条件
• 対象外とする範囲（何を作らないか）の明示

とくに見落とされがちなのが最後の「対象外の明示」です。作らない範囲を書かないと、発注者は「当然入る」と考え、開発会社は「範囲外」と考える食い違いが起きます。境界線を先に引いておくと、後の追加要望を正式な変更として扱いやすくなります。

仕様書を作成するタイミングと担当｜発注者と開発会社の役割分担

仕様書は、業務上の要求を固める要件定義のあと、外部設計へ移る前後で作られます。発注者の要求を整理する要件定義とは何かという工程を経て、その要求を機能へ落とし込む段階が仕様書の出番です。作成の主体は開発会社ですが、内容を承認する責任は発注者にあります。開発会社が書いた仕様書を発注者がレビューし、認識のずれを潰してから合意する。この承認の一手間を省くと、完成後に「頼んだものと違う」という食い違いが表面化します。

仕様書と設計書・要件定義書・RFPの違いを目的と作成工程で整理

仕様書という言葉は、要件定義書や設計書、RFPと混同されがちです。三つの文書は作成する工程と目的が異なります。まず全体像を表で示し、続けて個別の違いを見ていきます。

仕様書と設計書の違い｜What（何を作るか）とHow（どう作るか）

仕様書と設計書の違いは、担当する問いが「何を作るか」か「どう作るか」かで分かれます。仕様書は実現する機能や画面という結果を定義し、設計書はそれを実装する内部構造・処理方式・データベース設計を指示します。設計書はさらに、画面や帳票など外から見える仕様を固める外部設計と、内部の処理を決める内部設計の二層に分けられるのが一般的です。発注者が読み合わせるのは主に仕様書と外部設計の成果物までで、内部設計は開発会社の技術判断に委ねる範囲です。

三者は上流から下流へ「要求→機能→実装方法」と具体度が増していく関係にあります。上流があいまいなまま下流だけ精密に書いても、土台がずれるため手戻りが生じます。

仕様書と要件定義書の違い｜要求の確定と実装指示をどこで分けるか

要件定義書は「業務でこれを実現したい」という発注者側の要求を確定させる文書で、仕様書は「そのためにシステムがこう動く」という実装側の記述です。たとえば「受注から出荷までの二重入力をなくしたい」は要件、「受注データを出荷指示へ自動連携し、欠品時は警告を出す」は仕様にあたります。要件定義書の作り方は要件定義書の書き方と章立てサンプルが参考になるはずです。要求と仕様を同じ文書に混ぜると、発注者が承認すべき要求と、開発会社が判断する実現方法の責任範囲が曖昧になります。

RFP（提案依頼書）との違い｜発注前の要求提示と受注後の仕様確定

RFP（提案依頼書）は、発注先を選ぶ前に発注者が候補各社へ要求と前提条件を提示し、提案と見積りを募るための文書です。仕様書は発注先が決まり、要件をすり合わせたあとに確定します。RFPは「こういう課題を解きたい、どう作れるか提案してほしい」という問いかけ、仕様書は「この機能をこの条件で作る」という合意という違いです。RFPの段階で機能を細かく固めすぎると、各社の提案の幅を狭め、より良い実現方法を引き出しにくくなります。

仕様書の種類｜要求・機能・システム・画面・テストの文書別の役割

仕様書は開発工程ごとに複数の文書に分かれます。発注者がすべてを書く必要はありませんが、どの工程でどの仕様書が出てくるかを知っておくと、レビュー漏れを防げます。

要求仕様書とは｜発注者が求める業務要件と完成条件を明文化する文書

要求仕様書は、発注者が「何を実現したいか」を業務の言葉で書き出す文書です。月間の受注件数、対応が必要な業務フロー、達成したい状態といった、発注者しか持っていない情報を明文化します。この文書があいまいだと、以降の機能仕様書や設計書がいくら精密でも、そもそも解くべき課題を外しかねません。要求仕様書は発注者が主体的に関わるべき数少ない仕様書で、月2万件の注文を想定するのか2百件なのかといった前提数値を、ここで具体的に示しておきます。

機能仕様書とシステム仕様書｜画面や処理の動作を定義する開発の文書

機能仕様書は、要求を満たすためにシステムが提供する個々の機能を、入力・処理・出力の単位で定義します。システム仕様書はより広く、機能に加えて全体の構成・性能・稼働環境まで含めた技術的な仕様をまとめた文書です。両者とも作成の主体は開発会社ですが、発注者は「業務でありえない操作が禁止されているか」「例外処理が想定どおりか」という業務目線でのレビューを担います。開発会社の書いた動作定義を、実際の現場で使えるかどうかで読み返す役回りです。

画面仕様書・テスト仕様書｜UIの詳細と検証手順を記録する文書

画面仕様書は、各画面のレイアウト、項目、ボタン操作、画面遷移、入力チェックを詳細に定義します。テスト仕様書は、完成したシステムが仕様どおり動くかを検証する項目と手順、期待結果を記録する文書です。発注者にとってテスト仕様書は検収の根拠になります。検収時に「どの条件で何を確認したか」がテスト仕様書に残っていれば、後日の不具合対応でも仕様範囲か範囲外かを冷静に切り分けられます。なお、外部連携を担うAPI仕様書のような技術寄りの仕様は、実装工程で開発会社が整備する領域です。

仕様書の書き方｜作成手順とテンプレート構成・伝わる記述のコツ

仕様書は開発会社が書くのが基本ですが、発注者が構造を知っておくと、レビューの精度が上がります。手順、テンプレートの扱い、伝わる書き方の順に見ていきます。

仕様書の書き方の手順｜要求整理から機能定義・レビューまでの流れ

仕様書づくりは、要求を機能へ翻訳し、レビューで穴を埋める流れで進みます。おおまかな手順は次のとおりです。

1. 要件定義の内容を確認し、実現すべき業務要求を洗い出す
2. 要求を機能単位に分解し、入力・処理・出力を書き出す
3. 画面構成とデータ項目、外部連携や制約条件を定義する
4. 対象外の範囲と、未確定事項の決定期限を明記する
5. 発注者と開発会社でレビューし、認識のずれを解消して合意する

手順のなかで手を抜けないのが最後のレビューです。書き上げた分量よりも、発注者と開発会社が同じ理解に到達したかどうかで仕様書の完成度は決まります。未確定事項をゼロにできない場合は、いつまでに誰が決めるかを添えて残します。

テンプレートとフォーマット｜そのまま流用せず調整すべき記載項目

仕様書のテンプレートやフォーマットは、記載漏れを防ぐ出発点になります。ただし、ひな型の見出しを埋めることが目的化すると、自社の業務に不要な項目まで形式的に書き、肝心の固有要件が薄くなります。テンプレートは骨組みとして使い、対象業務の特殊な制約、既存システムとの連携、想定データ量といった、その案件でしか出てこない部分に記述の密度を寄せてください。汎用のひな型ほど、削る判断と足す判断の両方が要ります。

伝わる仕様書のコツと失敗例｜曖昧な表現を残さない具体化の基準

読み手に伝わる仕様書の条件は、解釈の幅を残さないことに尽きます。「速く」「使いやすく」「柔軟に」といった評価語は、人によって基準が異なるため、そのままでは仕様になりません。「一覧表示3秒以内」「1画面の入力項目は10個まで」のように、数値と条件で判定できる形へ言い換えます。よくある失敗は、正常時の動作だけ書いて異常時を書かないことです。入力エラー、通信断、同時更新といった例外の振る舞いを決めておかないと、テスト段階で仕様の空白が一気に噴き出します。

発注・契約における仕様書の扱い｜請負と準委任で変わる責任範囲

仕様書は技術文書であると同時に、契約上の判断材料です。契約形態によって仕様書の重みが変わり、あいまいな仕様書は費用や責任のトラブルに直結します。ここは発注者が主導権を持つべき領域です。

請負契約と準委任契約で変わる仕様書の重み｜完成責任の所在の違い

請負契約では、開発会社が仕様書どおりの完成物を納める義務を負い、仕様書が完成の判定基準になります。準委任契約とは何かという契約形態では、開発会社は善良な管理者として作業を遂行する義務を負い、完成そのものの責任は原則負いません。準委任では仕様書は作業範囲の目安であり、変更が生じても工数の追加で調整するのが一般的です。どちらの契約でも、仕様書に書かれた範囲が費用と責任の起点になる点は共通します。

契約形態を決めてから仕様書を整えるのではなく、どこまで仕様を固められるかを見て契約形態を選ぶ順序が現実的です。要件が動きやすい新規開発では準委任、仕様を確定できる改修では請負、という選び分けになります。

曖昧な仕様書が招くトラブル｜追加費用と契約不適合責任をめぐる争点

あいまいな仕様書は、費用と責任の両面でもめごとの火種になります。典型は「入っていると思った機能が範囲外だった」という追加費用の対立です。仕様書に対象外を書いていないと、発注者は当然の機能、開発会社は追加開発と主張し、平行線になります。請負契約では、納品物が仕様を満たさない場合に契約不適合責任を問えますが、その「満たすべき仕様」が仕様書に書かれていなければ、そもそも責任を主張する根拠が持てません。あいまいさは発注者の不利にはたらくと考え、着手前に未確定項目を減らしておくべきです。「ケースバイケース」で先送りにした項目こそ、後で最も高くつきます。

発注者が仕様書レビューで確認すべき観点｜合意形成と検収の判断基準

発注者が仕様書をレビューするときは、技術の細部よりも、業務が回るか・検収できるか・範囲が明確かの三点を見ます。想定した業務フローが機能として反映されているか、完成をどの条件で合格とするか、対象外の範囲が書かれているか。この三点があいまいなまま合意すると、後工程で必ず跳ね返ります。自社にレビューの体制がなく判断に不安がある場合は、要件定義から仕様の確定までを伴走する業務システム開発の相談窓口のような外部の専門家を、発注者側の立場で入れる方法もあります。仕様の確定は、開発の速さより先に固めるべき起点です。

よくある質問

仕様書とは何か、そして発注・契約の観点でよく寄せられる質問に回答します。

仕様書は発注者と開発会社のどちらが作成するのですか？

文書を書き起こす主体は開発会社が一般的です。ただし、要求仕様書のように「何を実現したいか」を定義する部分は、発注者しか持たない情報を含むため、発注者が主体的に関わります。開発会社が作成した仕様書を発注者がレビューして承認する、という分担が実務では多く見られます。承認の責任は発注者にある点を押さえておいてください。

仕様書と要件定義書はどう使い分ければよいですか？

要件定義書は「業務でこれを実現したい」という要求を確定する文書、仕様書は「そのためにシステムがこう動く」という実装の記述です。要求と実装方法を同じ文書に混ぜると、発注者が承認すべき範囲と開発会社が判断する範囲の境目が曖昧になります。工程としては要件定義書が先、仕様書がその後という順序で作られます。

仕様書がないままシステム開発を進めるとどうなりますか？

完成物の判定基準がないため、「頼んだものと違う」という食い違いが起きても、どちらの認識が正しいかを示す根拠が持てません。請負契約では契約不適合責任を問う土台も失われます。小規模でも、機能一覧と対象外の範囲、検収の合格条件だけは文書で残しておくと、後のトラブルを大きく減らせます。

仕様書のテンプレートはそのまま使ってよいですか？

骨組みとしては役立ちますが、そのまま埋めるだけの使い方はおすすめしません。汎用のひな型には自社に不要な項目が含まれる一方、案件固有の制約や既存システム連携といった肝心な部分が抜けやすいためです。テンプレートで抜け漏れを防ぎつつ、固有要件に記述の密度を寄せる使い方が現実的です。

API仕様書やテスト仕様書はどの工程で必要になりますか？

テスト仕様書は完成物を検証するテスト工程で、検収の根拠として使います。API仕様書は外部システムとの連携を実装する工程で、開発会社が整備する技術寄りの文書です。発注者が直接書くことは少ないものの、テスト仕様書は検収の物差しになるため、どの条件で何を確認したかは把握しておくと安心です。

関連記事

• システム開発の工程とは？7フェーズの成果物と工数比率を解説：仕様書が作られる要件定義〜設計の工程を全体像で確認できます。
• システム構成図とは？種類と書き方・発注者が確認すべき観点：仕様書とあわせて発注者がレビューする設計成果物の読み方を解説します。
• システム開発とは？種類・工程・依頼方法までの全体像：仕様書を含む発注全体の流れを俯瞰したい方向けの入門記事です。
• レベニューシェアとは？システム開発での仕組みと契約書：分配の対象範囲を仕様で定義する前提として契約形態を確認できます。