システム仕様書とは？書く範囲と、要件定義書・設計書との関係

当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。

システム仕様書とは？まず「どこまで書くか」を決める

『システム仕様書って、決まった書式があるんじゃないの？』と思いますよね。実は、システム仕様書という名前の決まった様式があるわけではないんです。

ITの仕様書は、作る段階ごとにいくつもの文書に分かれています。そのどれを指して「システム仕様書」と呼ぶかは、会社やプロジェクトで違います。

例えば「システム仕様書を出して」と言われたら、こう聞き返してみてください。

「要件定義の段階の資料ですか？それとも、画面や処理の設計まで入った資料ですか？」

これだけで、書く量も書く人も大きく変わります。仕様書という言葉そのものの意味は、仕様書とは？で紹介しています。

プログラムの仕様書とソフトウェアの仕様書

プログラムの仕様書は、1本1本のプログラムが「何を受け取り、何をして、何を返すか」を書いた物です。システム全体から見ると、一番細かい段階の文書にあたります。

ソフトウェアの仕様書は、もう少し広い言い方です。システムの中のソフトウェア部分について、要件や設計をまとめた物を指すことが多いです。

『細かい違いはいいから、結局何を書けばいいの？』という方も多いはずです。次の4層の考え方を使うと、どの文書でも書く範囲を決めやすくなりますよ。

システム仕様書の範囲は「業務・機能・データ・運用」の4層で決める

編集部では、システム仕様書の範囲を4つの層に分けてみました。上の層ほど使う人に近く、下の層ほどシステムの中や、公開後の運用に近いイメージです。

業務の層：システムの外から書き始める

仕様書はつい機能から書きたくなりますが、最初は業務の層から書くのがおすすめです。今の仕事の流れが分からないと、どの機能が必要かも決められないからです。

例えば「申込を受けてから請求するまで、誰が何をしているか」を、紙やExcelでのやり方のまま書き出してみてください。そこで手間がかかっている所が、システムに任せたい所になります。

機能とデータの層：画面とデータを一緒に考える

機能の層では、システムが何をするかと、画面や帳票の形を決めます。データの層では、その機能が使う情報と、他のシステムとの受け渡しを決めます。

『画面だけ決めればいいかな』と思いがちですが、画面とデータは表裏の関係です。画面に出したい項目が、どの情報から来るのかを一緒に書いておきましょう。

運用の層：書き漏れやすいからこそ先に決める

運用の層は、使える時間帯や止まった時の対応、バックアップ、問い合わせ窓口などです。機能の話に比べて後回しにされやすく、公開してから困る原因になりがちなんです。

運用を含む機能以外の決まりの書き方は、非機能要件とは？で詳しく紹介しています。

要件定義書・設計書・テスト仕様書との関係

ここが一番分かりにくい所ですよね。IPAの共通フレーム2013では、システム開発の作業を段階ごとのプロセスに分けて並べています。

共通フレーム2013は、構想から開発、運用、保守、廃棄までのライフサイクルを通して必要な作業や役割を規定した共通の枠組みです。「関係する人々が同じ言葉を話す」ための物とされています。

システムとソフトウェアで仕様が2段になる

共通フレーム2013の段階を見ると、「システム」と「ソフトウェア」でそれぞれ要件定義と方式設計があることが分かります。システム全体の仕様を決めてから、その中のソフトウェアの仕様を決める、という2段の作りなんです。

小さな開発では、この2段を1冊にまとめることもよくあります。大きな開発ほど分けて書く、と考えておけば大丈夫です。

ソフトウェアアーキテクチャの設計書は「方式設計」にあたる

ソフトウェアアーキテクチャの設計書という言葉もよく聞きますよね。これは、ソフトウェアをどんな部品に分けて、部品同士をどうつなぐかを決める文書です。

共通フレーム2013でいえば、ソフトウェア方式設計プロセスで決める中身に近いです。ソフトウェア開発の設計書の中でも、全体の骨組みを決める大事な1冊です。

デジタル庁のDS-100でも、画面や帳票など利用者が直接理解できる基本設計を行った後に、機能を実現するための詳細設計を行う、としています。設計書の種類と役割は設計書とは？で、要件定義書の中身は要件定義書とは？で詳しく紹介しています。

テスト仕様書は「決めた通りか」を確かめる

設計書まで書けたら、それぞれの段階に対応するテストで、決めた通りに動くかを確かめます。DS-100では、設計・開発事業者に単体テスト、結合テスト及び総合テストのテスト計画書の案の作成を求め、受入テストは利用者が参加して行うとしています。

テスト仕様書の書き方は、テスト仕様書とは？を見てみてください。

公的な手引きや規格で見るシステム仕様書の項目

『項目を一から考えるのは大変…』と感じますよね。実は、公的な手引きや規格に、書く項目の手がかりがまとまっているんです。

デジタル庁DS-100の要件定義書の項目

デジタル庁のDS-100（2026年6月12日決定）では、要件定義書の記載内容を、原則として次の4つとしています。システム要件定義書の目次を作る時の参考になります。

DS-100では、未確定な要件はリスクになり得ることに気をつけ、その旨を要件定義書で明らかにする、ともしています。分からない所を空欄のままにせず「未定」と書いておくのは、この考え方にも合っています。

非機能要求グレード2018の6つの大項目

IPAの非機能要求グレード2018では、機能以外の要求を6つの大項目に分けています。運用の層を書く時に、抜けがないか確かめる表として使えます。

要求仕様の国際規格とJIS

ソフトウェアの要求仕様書（SRS）の書き方には、国際規格もあります。古くはIEEE 830-1998がよく知られ、今は後継のISO/IEC/IEEE 29148に引き継がれています。

日本では、JIS X 0166:2021が要求エンジニアリングの規格です。目次には、利害関係者の要件の仕様（StRS）、システムの要件の仕様（SyRS）、ソフトウェアの要件の仕様（SRS）の内容が並んでいます。ここでも、システムとソフトウェアで仕様を分けて考えていることが分かりますね。

自治体システムの標準仕様書とは

「標準仕様書」と「システム」の組み合わせで調べると、自治体のシステムの話が出てくることがあります。これは、地方公共団体情報システムの標準化に関する法律（令和3年法律第40号）にもとづく取り組みです。

住民基本台帳や税、児童手当など20の業務について、国が標準仕様書を作り、自治体はそれに合ったシステムを使うことになっています。総務省の資料では、標準仕様書の構成として業務フローと、機能・画面・帳票・データ・連携の要件が挙げられていました。

ここでも、業務・機能・データといった層で書かれているのが分かります。詳しくは自治体システム標準化の標準仕様書とはで紹介しています。

設計書のGit管理と、仕様書の版の付け方

『最新版はどのフォルダ？』『ファイル名の日付が違う物が3つある…』という経験、ありませんか。仕様書の版がばらばらになると、古い仕様で作ってしまう原因になります。

設計書をGitで管理するという方法

最近は、設計書をプログラムと同じように、Gitで管理するチームもあります。文字で書ける形式、例えばMarkdownで設計書を書いておくと、どこを誰がいつ直したかの記録がそのまま残ります。

設計書のGit管理にはいい所が多い一方、合う文書と合わない文書があります。

Markdownで設計書を書くコツは、仕様書・設計書をMarkdownで書くで紹介しています。

Gitを使わない時の版の付け方

ExcelやWordで管理する場合も、決まりを1つ作るだけで迷いはぐっと減ります。

仕様変更の伝え方と版の付け方は、仕様書の変更管理でもっと詳しく紹介しています。

システム仕様書でよくある相談

よく見かける相談を、内容をまとめた形で紹介します。

相談1：プログラム仕様書には何を書けばいい？

プログラム仕様書というものに、どういうことを書けばいいのか分からない、という相談です。

プログラム仕様書は、1本のプログラムについて、次の項目を書くのが一般的です。

職場に決まった書式があれば、まずはそれに従いましょう。書式が無い時は、この5つから始めれば大きく外れることはありません。

相談2：要求仕様書と要件定義書は何が違う？

SEのヒアリングにもとづいて仕様書を作る時、要求仕様書と要件定義書はどう違うのか、という相談もあります。

IPAの解説では、要求を文書化し、関係者と合意した物が要件だという趣旨の説明がされています。ただ、要求と要件の標準的な定義は無いとも書かれているんです。職場でどう呼び分けているかを先に確かめるのが一番です。

相談3：「仕様書はない、ソースを読めばいい」と言われた

ソフトウェアの現場で『仕様書はない。ソースを読めばいい』と言われたが、それでいいのか、という悩みも見かけます。

ソースコードは「どう動くか」は教えてくれますが、「なぜそう決めたか」「本当はどう動くべきか」までは教えてくれません。ソースから設計書を起こす方法もあるので、困った時はソースコードから設計書を作るを見てみてください。

相談4：プログラム仕様書の文書管理がうまくいかない

最新のフォルダを決めても、なかなか守られない、という相談です。

決まりを守ってもらうには、決まりを少なくするのがコツです。「最新版はここだけ」「直したら変更の記録に1行」の2つだけでも、続けると効果が出ますよ。

システムの仕様を書く経験を仕事に活かす

業務の話を聞いて、4つの層に分けて仕様書にまとめる力は、上流工程を任される職場で評価されやすい力です。

今の現場で設計書やテスト仕様書を書きながら、少しずつ要件定義に関わっていくのも立派な道です。そのうえで、今の担当工程から一歩進みたい方は、求人の仕事内容を比べてみると道が見えてきますよ。仕様書を書く仕事の中身は、仕様書を書く仕事とは？で紹介しています。

機能ごとの仕様の書き方をもっと知りたい方は、機能仕様書とは？も見てみてください。

よくある質問

まとめ

あわせて読みたい

仕様書とは？意味と目的、設計書・要件定義書との違い

要件定義書とは？目的・書く内容・作る流れをやさしく解説

設計書とは？システム開発の設計書の種類と役割