仕様書の書き方とサンプル｜要求・機能・外部仕様書の違いと、項目の決め方【2026年】

2024-04-12 2026-10-08

仕様書を書くことになったものの、何をどこまで書けばよいのかが分からない。開発会社から「仕様書をください」と言われたが、要件定義書との違いもはっきりしない。はじめてシステムを発注する場面では、よくある状態です。

仕様書には、要求仕様書、機能仕様書、技術仕様書、外部仕様書などがあります。名称や含める内容は会社やプロジェクトによって異なるため、この記事では既存のサンプルに沿って、それぞれに書く内容を整理します。

この記事では、Enlyt（エンライト）で作成した仕様書や図のサンプルを紹介しながら、作成時に検討したい主な項目を種類ごとに整理しました。あわせて、図をどこまで載せるか、生成AIに渡すときに何を決めておくか、書き上げた仕様書を自分で点検する方法もまとめています。

Enlytではフルスクラッチ開発から、LINEなどの既存プラットフォームのカスタマイズや拡張・ミニアプリ化、パッケージ開発まで、柔軟な開発が可能です。この記事で紹介するような「仕様書」などがなくても、要件やアウトプットで丁寧に整理・可視化することで、認識のズレや追加費用を最小限に抑えることができる体制になっております。受注前の無料コンサルティングもご用意しております。

仕様書とは

仕様書は、作るシステムが満たすべき内容を文章にした資料です。発注側と開発側が同じものを想像できている状態を作るために書きます。

仕様書の目的

仕様書の目的は3つに整理できます。

• 関わる人が同じ完成形を思い浮かべられるようにすること
• 何を作って何を作らないかの線を引くこと
• 完成したものが約束どおりかを確かめる基準を残すこと

目的の3つ目が見落とされがちです。検収の段階で「これは仕様に入っていたのか」が揉めるのは、判断の基準が文書に残っていないためです。

仕様書と、要件定義書・要求仕様書・設計書の違い

似た名前の文書が並ぶので、最初に整理しておきます。

この呼び分けは、会社やプロジェクトによって幅があります。「仕様書」と言われたときに、要求仕様書を指しているのか外部仕様書を指しているのかで、求められるものが変わります。話が噛み合わないと感じたら、名前ではなく「誰が読む資料か」「何を決める資料か」を確認すると早く揃います。

要求定義と要件定義の線引きについては、「要求定義」と「要件定義」の違いで詳しく扱っています。発注側として要件定義をどう依頼するかは、発注前に整理すべき5つの論点と依頼方法をご覧ください。

仕様書の種類と書き方

ここからは種類ごとに、Enlytで作成したサンプルと、検討したい項目を示します。画像は資料の一部であり、下の表にはサンプルに写っていない項目も含めています。項目はそのまま目次として使える形で並べたので、すべてを埋める必要はなく、案件に関係のない行は落として構いません。

要求仕様書

発注側が主体となって整理する資料です。システムの話に入る前に、何に困っていて、何が解決できれば成功なのかを書きます。自力で完成させる必要はなく、開発会社と相談しながら固めていく形でも構いません。

下のサンプルは、背景、プロダクトの内容、要求、対象とする環境、主な機能などを一覧にした資料の例です。

「やらないこと」の行を用意しておくと、後から機能が膨らんだときに、当初の約束がどこまでだったかを確認できます。

内部仕様書

開発側が中心になって書く資料です。発注側が全部を読み込む必要はありませんが、機能仕様書のほうは内容の確認を求められることがあります。

この記事では機能仕様書と技術仕様書をこの見出しの下で紹介します。ただし、機能仕様書には利用者から見た動きも含まれ、外部仕様書と内容が重なる場合があります。どちらに書くかは、プロジェクトごとの決めごとです。

機能仕様書

ひとつひとつの機能が、どういう条件で、何を受け取って、どう動いて、何を返すのかを書きます。発注側が読んで「違う」と気づけるのは、たいていこの資料です。

下のサンプルは、問い合わせ画面について、入力項目と表示項目を定義した例です。画面単位で機能を具体化すると、確認する側も見落としに気づきやすくなります。

抜けやすい項目のひとつが「エラー時の動き」です。正常に進んだときの流れだけを書いて、入力を間違えたとき、通信が失敗したとき、同じ操作が二重に行われたときの扱いが抜けます。そこは開発側の判断で埋められることになり、後から「そういう動きだと思っていなかった」が出ます。

技術仕様書

どういう技術で、どういう構成で作るのかを書きます。発注側がすべてを理解する必要はありませんが、将来ほかの会社に引き継ぐときに効いてくる資料です。

下のサンプルは、クラウドと社内のインフラがどうつながっているかを示したシステム構成図の例です。技術仕様書には、こうした図を含めることがあります。

バージョンまで書き残しておくと、数年後にサポート終了の期限を調べるときに役立ちます。レガシーシステムは作り直すべきかでも触れていますが、何の上で動いているか分からないシステムは、改修も引き継ぎも難しくなります。

外部仕様書

利用者から見た動きと、他のシステムとのやりとりを書きます。画面に何が出て、どこを押すと何が起きるのか。発注側が内容を確認しやすい資料です。

下のサンプルは、在庫を確認するときのやりとりの順序を表した図の例です。どちらがいつ何を送るのかを並べると、文章だけよりも早く確認できます。

画面まわりをさらに詳しく書く資料として、画面設計書があります。Enlytで使っているフォーマットと作り方はソフトウェア開発における画面設計書にまとめています。

各種類の仕様書が果たす役割

資料を順番に完成させていくというより、「何に困っているか」「利用者から見てどう動くか」「どう作るか」を段階的に具体化していく作業です。必要に応じて前の段階に戻ることもあります。

ただし、前の段階が曖昧なまま先に進むと、後の段階で辻褄を合わせることになり、そこで工数が増えます。戻る前提で進めることと、曖昧なまま進めることは別です。

仕様書に載せる図は、どこまで必要か

文章だけの仕様書は、読む人によって解釈が分かれます。かといって、きれいな図を揃えることが目的ではありません。発注側が確認するうえで、効き目のある順に並べます。

画面遷移図

画面を四角で描いて、矢印でつなぐだけの図です。手書きでも構いません。これがあると、行き止まりになっている画面や、戻る手段がない流れに気づけます。画面や分岐が増えると、文章だけで把握するのは難しくなります。

画面のイメージ

どこに何が並ぶかを示した下書きです。配色やフォントを決めるものではなく、情報の並び順と操作の位置を確認するためのものです。完成品に近い見た目にすると、デザインの話になってしまい、肝心の項目の抜けが見つからなくなります。

データのやりとりを表す図

外部のシステムと連携する場合に、どちらがいつ何を送るのかを矢印で表します。連携の相手が複数あるときや、処理の順番に決まりがあるときは、文章より図のほうが早く通じます。

図を描かずに表で済ませられる場面

入力項目の一覧、権限の割り当て、メッセージの文言。この3つは表のほうが確認しやすく、修正も簡単です。項目が増えたときに、図だと描き直しが発生します。

図は、描くこと自体に時間がかかります。画面中心のシステムでは、画面遷移図と画面のイメージの2つから始めると整理しやすくなります。

仕様書を作成するためのステップ

ステップ1　情報を集める

現場で実際にどう作業しているかを聞きます。マニュアルに書かれている手順と、実際の手順が違っていることは珍しくありません。例外的な処理や、特定の担当者だけが知っている判断は、この段階で拾っておかないと後から出てきます。

ステップ2　関係者と認識を合わせる

複数の部署が使うシステムでは、部署ごとに優先したいものが違います。全部を盛り込むと、どれも中途半端になります。最初の段階で、誰が最終的に優先順位を決めるのかを決めておきます。

合意の記録の残し方については、なぜシステム開発は「合意したはず」なのに揉めるのかで扱っています。

ステップ3　下書きを作る

いきなり清書を目指さず、項目を並べたところで一度止めます。前の章の項目一覧を目次として置き、埋められるところから書いていきます。埋まらない行は、空欄のままにせず「未定」と書いて、いつ誰が決めるのかを添えておきます。空欄は読む人によって「書き忘れ」とも「不要」とも受け取られます。

ステップ4　レビューを受ける

書いた本人は、書いていないことに気づけません。現場の担当者、システムに詳しい人、決裁する人。立場の違う人に読んでもらいます。

読んでもらうときは「問題ないか確認してください」ではなく、「この画面で、この操作をしたときにどうなると読めますか」と聞くほうが、解釈のずれが表に出ます。

ステップ5　確定して承認をもらう

どの版が正とされているのかを、文書の中に書いておきます。版数、更新日、更新した内容。これがないと、メールに添付された複数の版のどれが最新か分からなくなります。

何で書くか。フォーマットの選び方

仕様書の中身と同じくらい、何で書くかも進み方に影響します。関わる人が開けて、変更の履歴が追えることが条件になります。

Markdownで書く場合

仕様書として書くときは、構造を決めておくと読みやすくなります。見出しの階層で機能を分解し、入力項目や権限の割り当ては表に、受け入れの条件はチェックリストにする。この3つを決めておけば、書く人が替わっても形が揃います。コードや設定値を載せるときは、コードブロックに入れると記号が変換されずに済みます。

テキストで書くので、Gitなどの履歴管理と組み合わせると、誰がどこを変えたかを追いやすくなります。記法そのものについてはマークダウンの書き方で解説しているので、はじめて使う場合はそちらをご覧ください。

表計算ソフトや文書ツールで書く場合

項目数が多い一覧を扱うなら表計算ソフトが扱いやすく、文章の分量が多いなら文書ツールのほうが読みやすくなります。社内で共有する相手が使い慣れているかどうかが、実際には大きく効きます。

選ぶときの基準

• 関わる全員が、追加の契約なしで開けるか
• 誰がいつどこを変えたかが残るか
• 同時に複数人が編集できるか
• 開発会社との間で、そのまま共有できるか

履歴の残し方や共有の方法、課題管理ツールとの使い分けはアジャイル開発に設計書は不要かで詳しく扱っています。

良い仕様書を作成するためのヒント

5W1Hを意識して作成する

誰が、いつ、どこで、何を、なぜ、どうやって。この6つのうち、仕様書で抜けやすいのは「誰が」と「なぜ」です。

「誰が」が抜けると、権限の設計が後回しになります。「なぜ」が抜けると、途中で仕様を変えるかどうかの判断ができなくなります。目的が書いてあれば、「この機能は目的に沿っているか」で判断できます。

変更管理とバージョン管理

仕様は変わります。変更そのものを禁じるより、変わったときの手順を先に決めておくほうが現実的です。誰が変更を申し出て、誰が承認し、どこに記録するのか。

変更がスケジュールと費用にどう跳ね返るかを含めた管理の仕方は、スコープ管理が崩れる本当の原因で扱っています。

読み手に合わせて書き分ける

技術仕様書を現場の担当者に読んでもらっても、確認は進みません。逆に、開発者に要求仕様書だけを渡しても作れません。同じ内容を1つの文書に詰め込むのではなく、読む人ごとに資料を分けるほうが、結果的に確認が早く終わります。

仕様書作成時の落とし穴とその回避方法

落とし穴1　曖昧な言葉が残っている

「など」「等」「適宜」「必要に応じて」「わかりやすく」。これらが残っていると、読む人の経験によって解釈が分かれます。数量と挙動に置き換えられるものは、置き換えておきます。

曖昧な表現をどう具体に直すかは、書き換えの実例を含めて仕様書は渡したのに、なぜ違うものが上がってくるのかにまとめています。

落とし穴2　関係者の期待がずれている

部署によって、このシステムで解決したいことが違う。この状態のまま進むと、完成してから「思っていたものと違う」が出ます。最初の段階で全員を集めて、何を優先するかを決めておきます。

落とし穴3　変更の記録が残っていない

打ち合わせの場で口頭で決めたことが、文書に反映されないまま進む。後になって、どちらが言ったかの話になります。決まったことは、その日のうちに文書へ反映します。

落とし穴4　レビューの機会が足りない

開発が終わってから確認すると、直すのに大きな手間がかかります。仕様の段階で複数回、見てもらう場を作っておきます。

落とし穴5　細かく書きすぎている

すべてを決め切ろうとすると、作成に時間がかかるうえ、小さな変更のたびに文書の修正が発生します。判断が分かれると困るところは細かく、任せてよいところは方針だけ。この濃淡を意識すると、維持できる分量に収まります。

どこを細かく書くかの目安は、「違う作りになっていたら困るか」です。困るなら書く、困らないなら任せる。この判断を書く前にしておくと、分量が決まります。

生成AIに仕様を渡すときに決めておくこと

AIにコードを書かせる場面が増えていますが、渡す仕様が曖昧だと、出てくるものも揺れます。生成AIも文脈から内容を補いますが、その補い方が意図と一致するとは限りません。入力と出力、制約、対象外、エラー時の扱いを明記し、生成された内容が仕様を満たしているかをレビューとテストで確かめます。

渡す前に、次を確かめておきます。

• 入力と出力の具体例があるか。言葉で説明するより、実際の値を1組示すほうが伝わります
• 前提が書かれているか。使っている言語とバージョン、既存のコードの構造、守るべき命名の決まり
• やらないことが書かれているか。書かないと、親切のつもりで余計なものが足されます
• エラー時にどうするかが書かれているか
• 正常時と異常時の入力例、そして期待する結果があるか
• 何を確認できれば完成とするか、受け入れの条件があるか
• 顧客情報や機密情報を入力する場合、利用するAIサービスの取り扱い条件を確認しているか

もうひとつ、残しておきたいのが判断の理由です。生成されたコードは残りますが、なぜその作りにしたのかは残りません。仕様書に理由を書いておくと、後から見直すときに手がかりになります。この点はAI駆動開発の品質はどこで決まるかでも扱っています。

発注前に、自分で点検するチェックリスト

書き上げた仕様書を開発会社に渡す前に、自分で通してみる項目です。順番に見ていけば、抜けやすいところが分かります。

• 目的と、何ができたら成功なのかが書いてあるか
• 今回やらないことが書いてあるか
• 使う人の種類と、それぞれに許可する操作が書いてあるか
• すべての入力項目に、必須か任意か、桁数、入力できる形式が書いてあるか
• 正常に進んだときだけでなく、失敗したときの動きが書いてあるか
• 既存システムとの連携について、相手、やりとりする項目、タイミングが書いてあるか
• 「など」「適宜」「必要に応じて」が残っていないか
• 同時に使う人数、扱うデータの量、応答の目安といった数量が書いてあるか
• 誰がいつまでに決裁するのかが書いてあるか
• 仕様が変わったときの手順が決まっているか
• どの版が最新かが、文書を見れば分かるか

全部が埋まっている必要はありません。埋まっていない項目があること自体より、埋まっていないと気づかないまま発注することのほうが、後の手戻りにつながります。

提案を複数社から受け取って比べる段階に進む場合は、RFPの書き方と、提案が比較できなくなる本当の原因も参考になります。

仕様書を判断に使う場面

仕様書は、書いて終わりの資料ではありません。開発が進んでから出てくる判断に使えます。

途中で機能を追加したいという話が出たとき、要求仕様書に「やらないこと」と優先順位が書いてあれば、当初の範囲と比べて決められます。書いていなければ、その場の勢いで決まるか、判断が保留になって進みが止まります。

効いてくるのは資料の厚さではなく、判断の基準が文書に残っているかどうかです。何を優先すると決めたのかが書いてあれば、後から出てきた要望を入れるかどうかを、同じものさしで検討できます。

これまでに手がけた開発の内容と進め方は開発実績の一覧にまとめています。

よくある質問

仕様書は発注側と開発会社のどちらが書きますか

種類によって分かれます。要求仕様書は発注側が主体となって整理します。外部仕様書と内部仕様書は、開発会社が中心になって書き、発注側が確認する形が多くなります。要件定義書は両者で作ります。発注側だけで完成させてから相談する必要はありません。

仕様書がなくても開発を依頼できますか

依頼はできます。ただし、何を作るかが決まっていない状態では、金額も期間も幅のある見積もりになります。要件を固める工程を先に切り出して契約する進め方もあるので、相談の段階で聞いてみてください。

どれくらいの分量が適切ですか

枚数の目安はありません。判断の基準は「違う作りになっていたら困るところが、全部書いてあるか」です。困らないところまで書き込むと、維持できなくなります。

仕様書と設計書はどう違いますか

仕様書は「何をどう動かすか」を、設計書は「どう実装するか」を書きます。ただし呼び分けは会社によって幅があり、同じ資料を別の名前で呼んでいることもあります。名前で判断せず、中身を確認するほうが確実です。

作った後の更新はどうすればよいですか

改修のたびに更新するのが理想ですが、現実には追いつかないことがあります。その場合でも、どこが現状と違うのかだけは記録に残しておきます。資料と実物がずれたまま年数が経つと、次に手を入れるときに調査からやり直すことになります。

AIに仕様書を書かせてもよいですか

下書きを作る用途なら使えます。ただし、現場の例外的な運用や、社内でしか通じない判断は、AIには分かりません。生成された文章をそのまま渡すのではなく、現場に確認して埋める工程は残ります。

Enlytの仕様書の作り方

Enlytでは、仕様書を作る前の段階から相談を受けています。何を解決したいのかを伺い、どこまでを今回の対象にするのかを一緒に整理したうえで、必要な資料を揃える順番です。受注前の無料コンサルティングとして行っています。現行システムの詳細な調査が必要な場合は、調査の範囲や費用についてもご相談時に確認します。

資料が残っていないシステムの改修や、他社が開発したシステムの引き継ぎについては、プロダクト引き継ぎ・改善サービスとして、ソースコードを確認して仕様を読み解き、資料を作成するところから対応しています。

対応範囲と進め方はサービス紹介ページに、これまでの開発は開発実績の一覧にまとめています。進め方を先に知りたい場合はお役立ち資料もご利用ください。

まとめ

仕様書と呼ばれるものには複数の種類があり、整理する人も、作る時期も、書く内容も違います。いま自分が用意すべきものがどれかを決めるところから始めると、何を書けばよいかが見えてきます。

項目は、この記事の表をそのまま目次として使えます。埋まらない行は空欄にせず「未定」と書いて、いつ誰が決めるのかを添えてください。空欄は、書き忘れとも不要とも受け取られます。

そして、書き上げたら点検のチェックリストを通してみてください。曖昧な言葉が残っていないか、失敗したときの動きが書いてあるか、数量が書いてあるか。ここで見つかる抜けは、発注してから見つかるものより、はるかに安く直せます。

関連記事

• 仕様書は渡したのに、なぜ違うものが上がってくるのか｜解釈のズレを生む構造と防ぎ方
• 【わかりやすい】ソフトウェア開発における画面設計書
• 【徹底解説】アジャイル開発に設計書は不要か？
• 【わかりやすい】マークダウンの書き方って？
• システム開発の要件定義はどう依頼する？発注前に整理すべき5つの論点
• 「要求定義」と「要件定義」の違いは？
• RFP（提案依頼書）とは？書き方・記載項目
• なぜシステム開発は「合意したはず」なのに揉めるのか
• スコープ管理が崩れる本当の原因
• AI駆動開発の品質はどこで決まるか

久保 利彦

株式会社Enlyt代表取締役CEO。 50名規模・億円単位の開発プロジェクトにおけるPM経験を持つ実行型リーダー。 「作れるか」ではなく「事業として回り続けるか」を重視した開発を信条とし、クライアントの中長期的な成長に寄り添う支援を行っている。

View More