システム開発を外部に発注することになり、打ち合わせを重ねてきたある日、担当エンジニアからこう言われたとします。「今週中に仕様書を作成しますので、内容をご確認ください」。
そのとき、多くの発注者担当者が感じる反応は一つです。「仕様書って、何をどこまで確認すればいいんだろう？」
要件定義書という言葉は聞いたことがある。でも仕様書との違いはよくわからない。自分が確認すべきことなのか、それとも専門家に任せておけばいいのか。誤解したままサインしてしまったらどうなるのか。こうした不安を抱えながら仕様書を受け取る発注者は、実は少なくありません。
本記事では、「システム開発における仕様書とは何か」を発注者の目線で解説します。要件定義書との違いから、仕様書に書かれている項目の読み方、そして発注者がどこを確認すればトラブルを防げるか、具体的なチェックポイント5つにまとめました。
仕様書は開発者だけが読むものではありません。発注者も内容を理解し、能動的に確認できることが、プロジェクトの成功に直結します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
システム開発の仕様書とは何か
仕様書とは、開発するシステムが「どのように動くか」を詳細に記述した文書です。システムの機能・画面・データの流れ・処理ロジックなどが具体的に書き記されており、開発チームが実装の際に参照する「設計の基本文書」として機能します。
発注者と開発会社が「何を作るか」の認識を一致させるための合意文書でもあります。この認識の一致がなければ、完成したシステムが「思っていたものと違う」という状況が生まれます。
仕様書の主な種類
仕様書には大きく3種類があります。
要求仕様書は、発注者側が「何を実現したいか」を整理した文書です。業務上の課題やシステムへの要望を記載し、開発会社への最初のインプットになります。「こんなシステムが欲しい」という要求を文書化したものと理解してください。
外部仕様書（機能仕様書）は、開発会社が要求仕様書を受けて作成します。システムがどのように振る舞うかを「ユーザー目線」で定義します。画面の構成・操作の流れ・入力できる情報・表示される内容などが書かれており、発注者が受け取る仕様書の多くはこの種類です。
内部仕様書（技術仕様書）は、開発者が実装の際に使う技術的な設計書です。プログラムの処理ロジックやデータ構造が記載されており、基本的に発注者が詳細を読む必要はありません。
発注者が確認すべき仕様書は、主に外部仕様書です。「自分が話した要求どおりにシステムが動くか」を確認するための文書です。
要件定義書と仕様書の違い
「要件定義書」と「仕様書」は、混同されがちな2つの文書です。しかし、作成タイミング・作成主体・目的がそれぞれ異なります。
比較項目 | 要件定義書 | 仕様書（外部仕様書） |
|---|---|---|
作成タイミング | 開発フェーズの前半 | 要件定義の後 |
主な作成者 | 開発会社（発注者と共同で作成することも） | 開発会社 |
内容の焦点 | 「何を実現したいか」（What） | 「どのように実現するか」（How） |
粒度 | 業務レベルの要求 | 機能・画面レベルの詳細 |
簡単に言うと、要件定義書は「発注者が言いたかったことを整理した文書」、仕様書は「それを具体的なシステムの動きに落とし込んだ文書」です。
なお、AIを活用したシステム開発の場合、要件定義の内容や難易度が通常とは異なります。AI開発の要件定義で押さえるべきポイントも合わせてご参照ください。
発注者が自分で作る文書はどれか
発注者が最初に準備する文書は「要求仕様書（または要件定義書）」です。「業務上の課題」「実現したいこと」「絶対に必要な機能」「予算やスケジュールの制約」などを発注者側でまとめ、開発会社に渡します。
外部仕様書は、このインプットを受けた開発会社が作成します。発注者はその内容が「自分の要求と一致しているか」を確認する役割を担います。
仕様書に書かれている主な項目
外部仕様書を受け取ったとき、何が書いてあるかを理解しておくと確認がしやすくなります。代表的な項目を整理しておきます。
機能要件
システムが「何をするか」を定義した部分です。
- 画面一覧と画面遷移: どんな画面があり、ボタンを押すとどこに移動するか
- 入力項目と操作フロー: 各画面でユーザーが何を入力し、どんな操作ができるか
- データ処理の内容: 入力されたデータがどのように処理・保存・表示されるか
非機能要件
システムの「性能や条件」を定義した部分です。機能以外の要件で、後から問題になりやすい項目でもあります。
- 性能要件: 1000人が同時にアクセスしても問題ないか、検索結果が何秒以内に表示されるか
- セキュリティ要件: ログイン認証の方法、データの暗号化、アクセス権限の設定
- 運用要件: バックアップの頻度、システムのメンテナンス時間、障害時の対応手順
その他の記載項目
- 用語定義: 文書中で使われる専門用語・略語の説明
- 前提条件: このシステムが想定している環境や条件（例：PCブラウザからのみアクセス可能）
- 制約事項: 対応しない機能・スコープ外の内容（例：スマートフォンアプリは含まない）
制約事項と前提条件は特に重要です。「ここまでは含まない」という境界線が明記されているかを確認することで、認識齟齬を防ぐことができます。
発注者が仕様書を確認するときの5つのポイント
仕様書は読み込むほど専門的な知識が必要になりますが、発注者が注目すべきポイントはある程度絞ることができます。以下の5つの観点から確認を進めると、重要な見落としを防ぎやすくなります。
ポイント1: 要求との整合性—「自分が言ったことが書かれているか」
最も基本的な確認です。要件定義の打ち合わせで共有した要求が、仕様書に反映されているかを確認します。
確認の手順として、打ち合わせのメモや要件定義書と仕様書を並べて照合するのが効果的です。「この機能は依頼したが仕様書に記載がない」「この動作は意図したものと違う」といった齟齬を早い段階で発見できます。
発注者からよく出るコメントとして「聞いてみたら確かに伝えていたが、仕様書への反映が漏れていた」というケースがあります。口頭での依頼は仕様書に必ず明文化されているか確認しましょう。
ポイント2: 用語の明確さ—「曖昧な言葉が残っていないか」
仕様書の中に「適切に」「なるべく早く」「十分な」といった主観的・抽象的な表現が残っている場合、開発者と発注者で解釈が異なるリスクがあります。
「素早く表示する」ではなく「3秒以内に表示する」といった具体的な数値や条件に置き換えられているかを確認してください。専門用語には補足説明が付いているか、自分が理解できない言葉が使われていないかも確認ポイントです。
「わかるとは思いますが、念のためこの用語の意味を教えてもらえますか？」という姿勢で開発会社に確認することを恐れないでください。
ポイント3: 前提条件・制約事項の確認—「スコープ外が明記されているか」
仕様書には「対応する機能」だけでなく「対応しない機能」が明記されている必要があります。「対応しない」という境界線が不明確だと、後から「あれも入っていると思っていた」というトラブルが発生します。
確認する際は「〇〇はスコープ外とありますが、これは最初から追加費用が発生することを理解した上で合意していますか？」という形で、意識的にスコープ外の内容を確認してください。
制約事項欄が空白、または「詳細は別途協議」という記載のみの場合は、具体的な内容の追記を求めましょう。
ポイント4: 非機能要件—「性能・セキュリティの要件が数値化されているか」
非機能要件はシステム公開後に問題になりやすい領域です。具体的な数値・基準が記載されているかを確認してください。
確認すべき主な項目は以下のとおりです。
- レスポンス時間: 「○秒以内に処理が完了すること」という基準
- 同時接続数: 「○人が同時にアクセスしても正常に動作すること」
- データ保護: 個人情報の取り扱い、アクセス権限の設定方法
- バックアップ頻度: データの定期保全の頻度と復旧手順
非機能要件が「要件定義書の内容に準拠」「別途定義」といった記載にとどまっている場合、具体的な基準を追記してもらうよう依頼してください。
ポイント5: 仕様変更の手順—「変更が発生したときのプロセスが書かれているか」
開発中に「やっぱりこの機能を変えたい」という変更依頼が発生することは珍しくありません。そのとき、どのようなプロセスで変更を依頼し、費用や納期への影響はどう扱われるのかが仕様書（または契約書）に明記されているか確認してください。
「仕様変更申請書を提出し、影響範囲をアセスメントしてから追加費用・工数を合意する」といった手順が決まっていると、後の「言った・言わない」トラブルを防げます。
変更プロセスが決まっていない場合は、プロジェクト開始前に開発会社と変更管理のルールを合意しておくことをすすめします。
よくある仕様書のトラブルと対処法
仕様書に関連して、発注者がプロジェクト中に遭遇しやすいトラブルを3つ挙げます。いずれも事前の確認で防ぐことができます。
トラブル1: 「言った・言わない」による手戻り
打ち合わせで口頭で伝えた要求が仕様書に反映されておらず、開発完了後に気づくケースです。「○○機能を入れてほしいと言ったはず」「その要件は承っていません」という認識の齟齬が手戻りと追加費用を生み出します。
対処法: 打ち合わせ後は必ず議事録を取り、「この内容が仕様書に反映されること」を確認してから次の工程に進む習慣をつけましょう。仕様書への反映が確認できた段階で承認サインをするのが基本です。
トラブル2: 非機能要件が後から問題になる
公開後に「予想以上のアクセスがあったらシステムが遅くなった」「個人情報の取り扱いで指摘を受けた」といった問題が発生するケースです。非機能要件は機能ほど目立ちませんが、公開後のシステム品質に直結します。
対処法: ポイント4で示した非機能要件の確認項目を参照し、仕様書に数値化された非機能要件が記載されているかを確認してください。記載が曖昧な場合は、開発着手前に具体的な基準を合意しておくことが重要です。
トラブル3: スコープ外の追加費用が後から発生する
「A機能とB機能はできました。でもC機能は仕様書に含まれていないため、追加費用が発生します」と言われるケースです。発注者が「当然含まれている」と思っていた機能がスコープ外だったという認識齟齬です。
対処法: 仕様書の制約事項・スコープ外の欄を必ず確認し、「これは含まれていないが大丈夫か」と一つひとつ確認する姿勢が重要です。「含まれていると思っていた」は防ぐことができます。
まとめ—仕様書を「武器」にする
仕様書は、開発者が参照するだけの難しい技術文書ではありません。発注者が「依頼した内容が正しく実現されるか」を確認するための権利書でもあります。
発注者が仕様書を確認するときに押さえるべき5つのポイントをまとめます。
- 要求との整合性: 打ち合わせで伝えた要求が漏れなく反映されているか
- 用語の明確さ: 曖昧な表現が残っておらず、数値・条件が具体的か
- 前提条件・制約事項: スコープ外が明記されており、認識が一致しているか
- 非機能要件: 性能・セキュリティの基準が数値化されているか
- 仕様変更の手順: 変更が生じたときのプロセスが明確になっているか
これらを確認した上で仕様書に承認サインをすることで、「思っていたものと違う」「後から追加費用が発生する」といったトラブルを大幅に減らすことができます。
システム開発における書類の役割は、仕様書だけではありません。発注前のベンダー選定に関してはRFPを活用したベンダー評価の進め方を、開発完了後の確認フローについてはシステム開発の検収を非エンジニアが行うための実践ガイドもご参照ください。
