仕様書とは？種類・要件定義書や設計書との違いと確認ポイント

Webサービス・スマホアプリ開発で受け取った「仕様書」を見て、これだけで発注・開発・検収を進めてよいのか迷う担当者は少なくありません。ここで扱うのは、製造業の納入仕様書や建設業の特記仕様書ではなく、ソフトウェア開発における仕様書です。

仕様書は、必ずしも一つの決まった書式の文書ではありません。要件、機能、画面、データ、連携、非機能、テストなどを分けた文書群を指すこともあります。この記事では、文書名ではなく、必要な内容・承認・受入条件・引継ぎ可能性で成果物を判断する方法を解説します。読後には、受領済み資料の不足を見つけ、追加確認や発注条件の整理を始められるようになります。

仕様書は単一の決まった様式ではなく、合意から受入・引継ぎまでを支える文書群として捉えます。

01Section仕様書とは：文書名ではなく、合意・受入に必要な内容で捉える

ソフトウェア開発における仕様書は、「誰に対して、何を、どの条件で提供するか」を関係者間で共有し、設計、実装、テスト、受入、運用保守の判断基準にする文書、または文書群です。

開発のライフサイクルは、構想から開発、運用、保守、廃棄まで続きます。IPA「共通フレーム2013」は、このような工程と役割を整理する共通枠組みです。個別案件の文書名や作成順を定めるものではありませんが、仕様を開発時だけでなく、受入や保守まで見通して扱う必要性を考える参考になります。

仕様書が担う役割と、仕様書だけでは決まらない事項

仕様書の役割は、作る機能を列挙することだけではありません。利用者、対象業務、操作条件、権限、例外時の挙動、外部連携、性能や運用条件を明確にし、「期待どおりか」を判断できる状態をつくることにあります。

一方で、仕様書だけから、契約上の納入物や検収条件、支払条件、権利帰属、契約終了時の引渡し範囲まで判断することはできません。これらは契約書、発注書、見積書、成果物一覧、利用条件などとの照合が必要です。

文書の名前が「仕様書」であるかではなく、次の内容がどこにあり、誰が承認し、更新時にどう管理されるかを確認してください。

02Section要件定義書・要求仕様書・設計書・テスト仕様書の違い

文書名の違いよりも、目的から受入判定までに必要な問いへ答えられているかを確認します。

要件定義書、要求仕様書、設計書、テスト仕様書は、名称だけで厳密に役割を判断できるものではありません。開発手法、契約形態、組織の標準によって、文書の呼び方、粒度、作成順は変わります。大切なのは、それぞれが何を答える文書なのか、目的から受入結果までたどれるかです。

各文書が答える問いを比較する

要件定義は、目的、利用者、業務、対象範囲、優先順位を合意する段階として扱われることが多いものです。工程としての要件定義の進め方は要件定義の解説で、要件の整理方法や確認事項は要件定義書の解説も参考にしてください。

設計書は、合意した要件や仕様を、画面、データ、連携、処理方式、環境構成などの実現方法へ落とし込む文書です。設計書で確認すべき範囲は、基本設計書の解説で詳しく整理しています。

要件定義書と要求仕様書は、分けても統合してもよい

分離型では、要件定義書で「何のために、何が必要か」を決め、要求仕様書で「どの条件で、どう振る舞うか」を具体化します。前者には対象利用者や対象外の業務、後者には入力制約、権限、例外処理、受入条件を記載する例があります。

一方、統合要件書など一つの成果物に、要求、要件、主要な機能条件、受入条件の一部をまとめる場合もあります。小規模案件や反復型開発では、バックログ、受入条件、設計メモ、テスト資産を更新しながら管理することもあります。

重要なのは、分離か統合かではなく、目的、対象範囲、要件、振る舞い、受入条件の記載先と承認対象を、成果物一覧で特定できる状態にすることです。

デジタル社会推進標準ガイドラインには要件定義や調達にまたがる資料が掲載されています。政府情報システム向けの体系のため、民間案件では必須様式ではなく、確認漏れを減らす参考観点として利用します。

要求からテスト結果までを相互参照する

受入時に「実装済み」と説明されても、元の要求や受入条件との関係を確認できなければ、十分な判定材料とはいえません。要求ID、要件ID、機能ID、テストID、または文書名・版数・該当箇所を相互参照し、次の流れを追えるようにします。

業務課題・要求 → 要件 → 仕様・設計 → テスト項目 → テスト結果 → 受入判定

途中で参照が切れる項目は、未決事項、追加テスト、仕様の追記のいずれが必要かを確認します。

権限、例外処理、外部連携、非機能条件は通常操作だけのテストでは漏れやすいため、対応関係を重点的に確認しましょう。

03Section仕様書の種類は、案件条件に応じて選ぶ

資料は細分化すること自体が目的ではありません。案件条件に応じて、確認漏れが生じやすい情報を追加します。

仕様書を細かく分けるほどよいとは限りません。小規模な案件では、一つの文書に機能、画面、受入条件を統合したほうが確認しやすい場合もあります。ただし、複数部門、複雑な権限、外部連携、データ移行、重要な個人データ、高い停止影響がある場合は、情報を独立資料または明確な章として管理したほうが、見落としや変更時の影響調査を減らせます。

最小セットに追加する資料を選ぶ

全案件で最低限明確にしたいのは、対象・対象外、主要機能、権限、例外、受入条件、変更履歴です。そのうえで、機能・画面、データ、API・外部連携、非機能・運用、テストの情報を、案件条件に応じて追加します。

外部連携やデータ移行がある案件では、接続先、認証方式、送受信データ、実行タイミング、失敗時の通知・再送・再処理の担当を確認します。画面仕様の注記だけで済ませると、連携先との責任分界や試験条件が曖昧になるおそれがあります。

非機能要件と個人データは、機能仕様に埋もれさせない

非機能要件には、性能だけでなく、可用性、継続性、セキュリティ、運用保守性、移行性などが含まれます。必要な水準は、利用者数、停止影響、扱う情報、外部公開の有無、外部連携、社内規程によって変わります。

IPAの非機能要求グレードは、性能、可用性、運用保守性などの検討観点を整理する際の補助資料です。アーカイブ資料のため、現行の制度要件や最新のセキュリティ水準を判断する根拠としてではなく、確認漏れを減らす観点整理に限定して参照してください。

個人データを扱う委託では、仕様だけでなく、取扱範囲、アクセス権、再委託、ログ、保持・削除、事故時の連絡、取扱状況の把握を、運用・契約にまたがって確認する必要があります。個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」は、委託先選定、委託契約、委託先における取扱状況の把握に関する確認先です。

04Section発注者が行う依頼・承認・検収・引継ぎ確認

仕様書の確認は納品時だけでなく、依頼・承認・変更・検収・引継ぎの各段階で行います。

仕様書の品質は、納品時だけで決まりません。依頼前に何を整理したか、見積・発注条件に何を含めたか、承認・変更・検収でどの証跡を残したかによって、後から確認できる範囲が変わります。IPA「共通フレーム2013に基づく調達管理ガイド」も、調達仕様書作成、供給者選定、進捗管理、受入れにおける合意形成を扱っています。

見積・発注条件では、作業範囲を分離して比べる

見積を比較するときは、総額だけで仕様書作成の範囲を判断しないことが重要です。画面数、外部連携数、関係部門数、既存資料の品質、扱うデータ、停止影響、支援範囲が異なると、同じ「開発費」でも含まれる作業は変わります。各社の見積書で、次の作業を「含まれる／含まれない／前提条件付き／追加見積」のどれかにそろえて確認します。

成果物ごとに、責任者・証跡・保管場所を決める

承認や検収の漏れを防ぐには、成果物単位で責任分界を可視化します。作成者だけでなく、発注者側の確認者、承認時期、受入証跡、正本の保管場所と閲覧権限を決めておくと、変更後や引継ぎ時にも確認しやすくなります。

05Section保守・委託先変更に備える成果物管理

仕様書は、現行の動作を理解し、変更影響を調べ、回帰テストの範囲を考える基礎になります。しかし、仕様書を保管しているだけで、別の委託先や後任担当者へ移管できるとは限りません。コード、環境、アカウント、データ、運用手順を含めて、実際に利用できる状態かを確認する必要があります。

資料不足やアクセス不能は、改修時の再調査、障害対応の遅れ、テスト漏れにつながるおそれがあります。委託先への依存が高まる要因と、その見直し方は、ベンダーロックインの解説も参考にしてください。

文書が存在していても、実装や運用と乖離している、正本や最新版が不明、後任が閲覧できない場合は、移管に必要な情報として十分ではありません。変更時に何を更新するか、誰が正本を管理するか、どこで閲覧権限を管理するかを定めることが重要です。

NISC「政府機関等における情報システム運用継続計画ガイドライン」は、復旧優先度、構成要素、運用体制、事前対策を検討する観点を示しています。政府機関等向けの資料であるため、民間案件への適用義務ではなく、運用継続や復旧の確認漏れを減らす補助観点として参照してください。

06Section仕様書サンプル・テンプレートを使うときの確認ポイント

仕様書サンプルやテンプレートは、必要な観点を思い出すための出発点として役立ちます。ただし、見出しをすべて埋めること自体が目的ではありません。案件固有の対象外、権限、例外、外部連携の失敗時、受入条件、未決事項、変更履歴を具体化できなければ、テンプレートを使っても認識違いは残ります。

書き方に迷ったときは、曖昧な表現を「対象者」「条件」「期待する結果」「判定方法」に分解します。たとえば「管理者は利用者を管理できる」ではなく、誰が管理者になれるのか、作成・変更・停止のどこまでできるのか、権限がない利用者には何を表示するのか、どの状態をもって受入可能とするのかを確認します。

仕様書や発注条件の整理から相談したい場合

受領済みの資料に不足がある場合や、開発範囲・成果物・受入条件を整理したうえで依頼先を比較したい場合は、Webアプリ・SaaS開発の支援会社を確認できます。支援範囲、成果物、保守・引継ぎ条件を同じ前提で比較してください。

Webアプリ・SaaS開発4593社掲載

Webアプリ・SaaS開発の支援会社を見る