システム開発の仕様書作成を任されたものの、何から手をつければよいか分からず、記載項目や書き方に迷うことは少なくありません。仕様書は、発注者が求める業務上の動きと、開発側が実装する機能をすり合わせるための資料です。
この記事では、仕様書と要件定義書・設計書の違いを整理したうえで、架空の社内備品申請システムを例に、要求、機能、画面、非機能要件の書き方を紹介します。本文中の例はそのまま転用するための完成仕様ではありません。自社の業務と利用条件に合わせて、関係者と内容を確認してください。
この記事でわかること
・ 仕様書の役割と、要件定義書・設計書との関係
・ エンジニアに意図が伝わる具体的な書き方
・ 要求、機能、画面、非機能要件をつなげた記載例
システム開発における仕様書とは？設計書との役割の違いを解説
システム開発における仕様書は、開発するシステムの機能や性能、操作方法、画面デザインといった、実装すべき内容を具体的に定義した文書です。
プロジェクト関係者全員がシステムの全体像とゴールを共有し、認識のズレを防ぐための重要な役割を担います。
仕様書があることで、開発者は何を実装すれば良いかが明確になり、発注者は要望が正しく反映されているかを確認できます。
このように、仕様書はプロジェクトの品質を担保し、円滑な進行を支える基盤となるのです。
仕様書と混同されやすい他の文書との違いを理解することで、その役割はより明確になります。
システム開発の全工程については「システム開発の全工程の流れ」で詳しく紹介しています。
仕様書の目的とプロジェクトにおける重要性
仕様書の目的は、関係者の間で実現する内容と確認方法について共通認識を持つことです。条件や例外を具体的に書くことで、要件の抜けや解釈の違いに早めに気づき、手戻りを減らせます。
テストや受け入れの段階では、合意した仕様と実際の動作を照らし合わせます。ただし、文書を作るだけで品質が保証されるわけではありません。レビュー、変更管理、テストも必要です。テストの種類は「システム開発のテスト工程」で詳しく紹介しています。
混同しやすい「要件定義書」との違いとは
要件定義書は、解決したい業務課題、利用者、対象範囲、必要な機能や品質、制約を整理し、何を実現するかを合意する文書です。仕様書では、そこで合意した要件を、個々の画面、入力条件、処理結果、例外時の動作などへ具体化します。
例えば「備品申請を管理したい」という要件に対し、仕様書では「申請者は品目・数量・希望日を入力し、承認者は申請を承認または差し戻せる」のように動作を記述します。両者の項目は重なることもあり、文書の名前や分け方はプロジェクトごとに異なります。要件定義の進め方は「システム開発の要件定義」も参考にしてください。
「設計書」との明確な違いと作成されるタイミング
仕様書はシステムに求める振る舞いや条件を示し、設計書はそれをどう実現するかを示す資料として区別することがあります。例えば、申請の承認条件や画面での表示は外から確認できる仕様、データの保存構造や内部の処理方法は設計上の判断に当たります。
ただし、この区別は一律ではありません。基本設計書が画面仕様や外部連携仕様を兼ねるプロジェクトもあります。作成順序を文書名だけで決めず、要件の合意、外部から見える動作の確認、内部設計という流れで、誰が何をレビューするかを定めましょう。
システム開発で作成される代表的な仕様書の種類
仕様書には対象や目的に応じた複数の呼び方があります。以下では要求仕様書、機能仕様書、外部仕様書を例に説明しますが、名称や記載範囲は開発会社や手法によって異なります。実案件では文書の目次と責任者を確認し、同じ内容を別々の資料で矛盾して管理しないことが大切です。
要求仕様書：ユーザーの要望を明確化し合意形成するための書類
要求仕様書は、利用者や発注者が解決したい課題と必要な条件を整理する資料です。対象業務、利用者、要求の優先度、必要な機能と性能・セキュリティなどを、発注側と開発側で確認します。
何を実現するかが曖昧なまま詳細な実装に進むと、後から認識のずれが生じます。まず業務上の目的と受け入れの観点を共有し、未決事項は担当者と確認期限を明記してください。
機能仕様書：システムが実装すべき機能や動作を具体的に定義する書類
機能仕様書は、合意した要求を機能ごとの動作へ具体化する資料です。例えば備品申請機能であれば、入力する項目、必須・任意の条件、承認・差し戻し後の状態、エラー時の表示などを記述します。
機能IDを付けて要求や画面の項目と結びつけると、レビューやテストで追跡しやすくなります。開発の参照資料になりますが、これだけで実装のすべてを指示できるわけではありません。
外部仕様書：ユーザーから見えるシステムの動きや他システム連携を定める書類
外部仕様書は、利用者や他システムから見える振る舞いを整理する資料です。画面の表示・操作・遷移、帳票、外部システムとのデータ連携などが対象になります。例えば画面仕様には項目、ボタンの動作、入力エラー時の表示を記載します。
API（システム同士が情報をやり取りする仕組み）の仕様では、扱うデータ、送受信の条件、エラー時の対応を決めます。機能仕様書や基本設計書と記載内容が重なることもあるため、同じ条件をどの資料で正式に管理するか合意してください。
エンジニアに正しく伝わる！わかりやすい仕様書を作成する5つのポイント
仕様書は、ただ項目を埋めるだけでは十分ではありません。
開発を担当するエンジニアや関係者が内容を誤解なく、正確に理解できるような書き方を工夫することがプロジェクト成功の鍵を握ります。
誰が読んでも同じ解釈ができる具体性、専門用語に頼らない平易な表現、そして視覚的な理解を助ける図表の活用などが、わかりやすい仕様書を作成するための重要な要素です。
ここでは、エンジニアに意図が正しく伝わり、開発をスムーズに進めるための5つの具体的なポイントを解説します。
ポイント1：開発の目的とゴールを冒頭で明確に共有する
仕様書の冒頭で、このシステムを開発する目的、背景、そして達成したいゴールを明確に記載します。
なぜこのシステムが必要なのか、どのような課題を解決するのかという全体像を共有することで、開発者は個々の機能が持つ意味を理解しやすくなります。
目的が分かっていれば、仕様に書かれていない細かな部分の実装方法を判断する際に、より的確な選択ができるようになります。
単なる作業指示書ではなく、プロジェクトの成功に向けた共通認識を形成するための第一歩です。
ポイント2：誰が読んでも解釈がぶれない具体的な表現を心がける
「できるだけ速く」「多くのデータを扱える」「分かりやすい画面」といった表現は、人によって解釈が変わります。速度なら対象画面、想定する利用人数、測定条件、目標値を決め、入力なら必須項目、文字数、エラー時の動作を示します。
例えば「通常の業務環境で申請一覧を開いた場合、測定条件を合意したうえで表示時間の目標を3秒以内とする」のように記述します。3秒という値は説明用の例であり、実際の目標は利用条件と業務上の必要性から決めてください。
ポイント3：専門用語には初出時に短い説明を添える
仕様書はエンジニアだけでなく、業務担当者や承認者も読みます。専門用語をすべて削る必要はありませんが、初めて出るときに短い説明を添えましょう。例えば「API（システム間でデータをやり取りする仕組み）」のように表記します。
社内だけで通じる略語や製品固有の呼び方は、用語一覧を作ると読み手の誤解を減らせます。
ポイント4：図や表を効果的に活用し、視覚的な理解を促す
画面のレイアウトや処理の分岐は、文章だけでは伝わりにくい場合があります。必要に応じて画面イメージ、画面遷移図、業務フロー図、表を併用し、図中の項目と本文の機能IDを対応させましょう。
図は説明の補助です。ボタンを押した後の処理やエラー条件など、図だけでは読み取れない内容は文章でも記述してください。
ポイント5：変更履歴を必ず記録し、常に最新版を維持管理する
システム開発プロジェクトにおいて、仕様の変更はつきものです。
重要なのは、いつ、誰が、どの部分を、なぜ変更したのかという履歴を必ず記録し、関係者全員が常に最新版の仕様書を参照できる状態を維持することです。
変更管理が徹底されていないと、古い仕様に基づいて開発を進めてしまうといった致命的なミスにつながります。
バージョン管理システムを利用したり、文書内に変更履歴のセクションを設けたりするなど、管理ルールを明確に定めて運用することが不可欠です。
【項目別】システム開発の仕様書サンプルと記載例
ここからは架空の「社内備品申請システム」を共通の題材にして、要求、機能、画面、非機能要件の書き方を示します。REQ-001、F-001、S-001のようなIDを付け、業務上の要求がどの機能・画面に反映されるかを追える構成にします。
以下は記載方法を示すための例です。業務ルール、数値、権限、運用時間は実案件の関係者と確認したうえで決めてください。
要求仕様書のサンプル：社内備品申請の目的と必要な機能
要求ID：REQ-001
対象業務：社内備品の申請と承認
背景：申請をメールで受け付けており、承認状況や過去の履歴を一覧で確認できない。
目的：申請の状況を見えるようにし、転記や確認の手間を減らす。
機能要件（例）
・申請者は、品目、数量、希望日、申請理由を入力して申請できる。
・承認者は、申請を承認または差し戻しでき、申請者は結果を確認できる。
・申請者と承認者は、自分の権限に応じて申請履歴を検索できる。
非機能要件（例）
・申請内容の閲覧・変更を役割ごとに制限する。
・承認や差し戻しの日時と実行者を記録する。
受け入れの観点：申請、承認または差し戻し、結果確認までの業務を実際の担当者が試せること。
機能仕様書のサンプル：備品申請登録の入力条件と処理
要求との対応：REQ-001
機能ID：F-001
機能名：備品申請登録
概要：申請者が入力した備品の申請を登録し、承認待ちの状態にする。
画面項目：品目（必須）、数量（必須・1以上の整数）、希望日（必須）、申請理由（任意）。
処理：①申請者が入力し「申請する」を選ぶ。②必須項目と数量の形式を確認する。③条件を満たせば申請を登録し、状態を「承認待ち」にして受付番号を表示する。
例外：品目が空欄の場合は「品目を入力してください」と表示し、内容を登録しない。数量が1未満または整数以外の場合も、理由を表示して修正を求める。
承認者への通知方法や二重送信時の扱いは、この例では未定です。実案件では決定してから仕様へ追加してください。
画面仕様のサンプル：備品申請画面の項目と遷移
要求・機能との対応：REQ-001／F-001
画面ID：S-001
画面名：備品申請画面
表示項目：品目、数量、希望日、申請理由、「申請する」ボタン。
画面の動作：「申請する」を選ぶとF-001の入力確認を実行する。条件を満たせば受付番号と「申請を受け付けました」を表示し、申請一覧へ移動できるようにする。
入力エラー：エラーのある項目の近くに理由を表示し、利用者が入力済みの値は保持する。
画面遷移：申請一覧→備品申請画面（S-001）→申請受付結果／申請一覧。
実際の案件では、画面レイアウト図を別途作成し、表示順序や操作方法を利用者と確認します。この記事に画面レイアウト図の添付はありません。
非機能要件のサンプル：権限・性能・記録条件
非機能要件ID：NFR-001（権限）
申請者は自分の申請を閲覧し、承認者は担当する申請を閲覧・承認・差し戻しできる。管理者の閲覧範囲は業務部門と別途合意する。
非機能要件ID：NFR-002（記録）
申請の登録・承認・差し戻しについて、実行者、日時、対象の受付番号を記録する。保存期間と閲覧権限は運用方針に沿って定める。
非機能要件ID：NFR-003（性能）
申請一覧画面の応答目標は、同時利用人数、データ件数、ネットワーク、測定方法を決めてから数値で記載する。「速く表示する」だけでは検証できない。
システム内でパスワードを管理する場合は、平文や復号可能な形で保存せず、適切なパスワードハッシュ方式を採用する。既存の認証基盤を利用する場合は、その責任分担を別途定める。
本文の記載例を自社の仕様書に落とし込む3つの手順
上記の例はダウンロードできる完成テンプレートではなく、仕様書の記載方法を示す本文内のサンプルです。自社の業務に利用する場合は、以下の順番で項目を整理し、関係者の合意を取ってください。形式はWord、Excel、共同編集ツールなどから、更新・承認しやすいものを選べます。
手順1：目的・利用者・対象範囲と前提を冒頭に書く
最初に、業務上の目的、利用者、対象となる業務、対象外の業務、既存システムとの関係をまとめます。例えば備品申請の例なら、申請と承認は対象でも、発注先への自動注文は対象外かもしれません。曖昧なままにせず、発注者と開発者が同じ範囲を想定しているか確認します。
文章中心の説明にはWordなどを使い、画面や機能の一覧は別表にしても構いません。資料を分ける場合は、どれが正式版か分かるようにしてください。
手順2：要求・機能・画面をIDと確認条件で結びつける
要求のREQ-001、機能のF-001、画面のS-001を対応づけ、項目ごとに担当者、優先度、確認方法を記録します。条件と例外がある機能は、正常時だけでなくエラー時や権限がない場合の動作も確認しましょう。
一覧をExcelなどで管理する場合、ID、概要、詳細、決定者、状態、最終更新日を列として設けると探しやすくなります。数式やマクロは必須ではありません。
手順3：変更履歴と承認方法を決め、最新版を共有する
仕様書を更新するときは、変更した箇所、理由、影響する機能、承認者、承認日を記録します。変更後は、画面やテストの内容も合わせて見直してください。
共同編集ツールやMarkdown（文章を簡単な記号で整える書き方）を利用する場合でも、誰が正式版を承認したか分かる運用が必要です。GitHubなどの履歴管理は手段の一つであり、全てのプロジェクトで必須ではありません。
システム開発の仕様書作成に関するよくある質問
仕様書の項目、設計書との関係、サンプルの使い方について、よくある疑問を整理します。文書の名称と粒度は開発体制によって変わるため、自社の案件で何を合意する必要があるかを確認してください。
Q. そもそもシステム開発の仕様書には、どのような項目を記載すればよいのでしょうか？
共通して確認したいのは、目的と対象範囲、利用者、機能、入力・処理・表示の条件、非機能要件、例外時の動作、受け入れ条件、変更履歴です。画面や外部連携があれば、その内容も対象になります。
どこまでを一つの文書へ記載するかは案件によって異なります。本文の架空の記載例を参考に、必要な項目を関係者と決めてください。
Q. 仕様書と設計書では、どちらを先に作成するのが一般的な流れですか？
一般には、実現したい要求を先に整理し、その内容を画面や処理の仕様・設計に落とし込みます。ただし「仕様書」が要求仕様書を指す場合も、基本設計書の内容を指す場合もあります。そのため、文書の名前だけで順番を固定することはできません。
各工程で何を確定し、誰がレビューするかを決めることが大切です。全体の流れは「システム開発の手順」も参考にしてください。
Q. 品質の高い仕様書のサンプルを参考に、効率的に作成するコツはありますか？
本文のREQ-001、F-001、S-001、NFR-001～003を自社の業務に置き換え、誰が使い、どの条件で何が起こるかを順に確認してください。曖昧な条件には具体例や受け入れ方法を加えます。
見た目を整えるよりも、未決事項を明らかにし、発注者と開発者が同じ内容で合意することを優先します。
まとめ
仕様書は、発注者と開発者が実現する内容を確認し、変更や受け入れの基準を共有するための資料です。要求仕様、機能仕様、画面仕様などの名前や分け方は案件によって異なるため、文書名よりも記載項目と責任者を確認しましょう。
この記事の社内備品申請システムの例では、要求、機能、画面、非機能要件をIDで結びつけました。自社の業務に置き換える際は、数値や権限などの条件を実態に合わせて決め、関係者のレビューと変更管理を続けることが重要です。
