システム開発の仕様書の書き方・種類・サンプルをご紹介！【2024年最新版】

システム開発に必要な書類は多岐に渡ります。なかでも、仕様書の重要性は高く、仕様書の出来不出来がそのままシステムの完成度につながってしまうと言っても過言ではありません。

システム開発の経験が豊富な方であれば、自分なりの仕様書の作り方をマスターしているでしょう。しかし、経験が少ない方はどのように仕様書を作成すればいいのかわからない場合も多いはずです。

そこで本記事では、システム開発における仕様書の作り方や種類を解説していきます。ぜひ参考にしてください。

仕様書と混同されがちなのが設計書です。どちらもシステム開発に必須のものですが、両者はまったく違います。その違いを知るために、まずは言葉の意味を比較してみましょう。

システム開発における「仕様」とは、システムのあるべき姿を定義すること。そのため、仕様書ではどのようなシステムを実現するのかを説明します。

一方で「設計」は「建築物やシステムに関する構造、形、機能などを定義したもの」（デジタル大辞泉）。仕様書で定義されたシステムをどのような手段で実現していくのかについて記載したものが設計書です。

このように、両者の役割はまったく異なりますが、いずれもシステム開発においては作成しなければならない書類です。

システム開発には、仕様書と設計書が必須ですが、用意しなければならない仕様書・設計書は、それぞれ1種類ではありません。

システム開発は大きく、「要件定義」「基本設計」「詳細設計」の3つのフェーズに分かれます。そして、各フェーズにおいて仕様書・設計書が必要です。

また、仕様書・設計書以外にも作成しなければならない成果物があります。以下からは、各フェーズで作成しなければならない成果物と、仕様書・設計書について解説します。

要件定義の工程で作成する成果物は、要件定義書です。初期段階で作成するシステム開発全体の設計図にあたります。要件定義書を作成しないと、想定していたシステムとまったく別のものができあがってしまう可能性があるため、システム開発には必須と考えてください。

システム開発を外注する場合、発注者側の要望に対して、開発会社のエンジニアがシステムの内容や機能の中身を作成することが一般的です。そのため、発注者側に専門知識は求められません。

要件定義書では、開発するシステムの概要、システムの目的や開発理由、実装する機能、機能を実装するための方法、システムを導入することによる改善点、セキュリティに関する要件などを記載します。

開発するシステムの概要、システムの目的や開発する理由を記載した書類が、要件定義の工程での仕様書です。実装する機能、機能を実装するための方法は設計書にあたる内容となります。

要件定義の次の工程が、基本設計です。要件定義書で設定したシステムを、どのような技術を使って開発するのかなど、システム全体の基本的な仕様を具体的に仕様書に落とし込んでいきます。

基本設計書にどこまでの要素を盛り込むのかについては、プロジェクトごとに異なるでしょう。ただ、業務フローやシステムに搭載する機能の一覧、画面レイアウト、データベース設計、外部システムとの連携仕様については、どのプロジェクトであれ基本設計書に記載します。

システム開発に関する専門知識が必須となるため、開発会社のエンジニアが作成するのが一般的。とはいえ、開発会社任せにはしないようにしましょう。発注者がシステム開発の専門的な知識がないことと同様に、開発会社には発注者の細かな業務内容はわかりません。

そのため、基本設計の工程では発注者と開発者の密なコミュニケーションが求められます。開発会社任せにしてしまうと、自社のニーズを満たさないシステムになってしまう危険もあるでしょう。

システム開発の工程のうち、プログラムを実装する前の工程が詳細設計です。要件定義書と基本設計書をもとに、詳細設計書を作成します。

詳細設計書に記載するのは、システム内部の動作、機能、データベース設計などです。具体的には、データ構造の設計、関係データベースの設計、開発ツール、機能のアルゴリズムなどを記載していきます。

システムのプログラミングを行うプログラマーは、詳細設計書を見ながらシステムを作り上げていくため、どのプログラマーでもひと目で理解できるようにわかりやすい仕様書・設計書を作成しておくことが重要です。

詳細設計の工程で仕様書や設計書を作成するのは、エンジニアを統括するテクニカルディレクターやシステムエンジニア。もちろん、発注者が仕様書や設計書の作成に参加しても構いません。しかし、システム開発の専門知識がないと話が理解できないため、参加しないことが一般的です。

仕様書の種類は1種類ではありません。開発するシステムによっては複数の仕様書が必要な場合もあります。ここからは仕様書の種類を見ていきましょう。

機能仕様書は、システムに実装する機能の要件をまとめたものです。実装する機能、機能が動作する機序、動作環境などを記載していきます。

機能仕様書を作成するのは開発会社ですが、齟齬をなくすために発注者と話し合いながら作成するのが一般的です。機能仕様書は発注者と開発会社との間での機能に関する合意書としての役割もあります。

作成した機能仕様書は、依頼者と開発に携わるすべてのエンジニアと共有します。

詳細設計の工程で作成する仕様書が詳細仕様書です。詳細仕様書はシステムにどのような機能を実装するのかを記載します。

詳細設計書に記載するない内容は、データ構造の設計、関係データベースの設計、開発ツール、機能のアルゴリズムなど。詳細設計書は開発会社が作成し、通常は発注者に開示されません。しかし、詳細仕様書は機能に関する説明書でもあるため、開発会社と依頼者が共同で作成します。

開発会社が主導となり作成する機能仕様書や詳細仕様書とは異なり、要求仕様書は依頼者が作成します。記載内容はシステム開発に対する発注者の要求・要望のほか、予算、納期などです。

要求仕様書をもとに開発会社は体制を構築し、発注者にスケジュールを提出します。発注者と開発者が話し合いながら、要求仕様書をもとに要件定義の工程を進めていくという流れです。

機能仕様書には、機能に関する合意書の役割があります。そのため、開発会社が中心に作成しますが、視点は依頼者から見たものでなければなりません。機能仕様書に記載するべき項目は、以下の通りです。

・目次
・はじめに
・用語説明
・シナリオ
・システムの概略
・機能策定方針（対象外）
・機能の概要
・機能仕様
・非機能仕様
・データ仕様
・セキュリティ仕様

機能仕様書に記載する項目は、非常に多岐に渡るため、全ファイルのサンプルを示すのは難しいです。あくまでも一例として参考にしてください。

開発会社に開発を依頼するシステム要件を明文化したものが、要求依頼書です。「このようなシステムが欲しい」という要求をまとめたものです。

以下は、総務省の「自治体クラウド開発実証事業」における要求依頼書の項目です。

1． 件名
2． 利用期間
3． 本業務の目的
4． 本業務の基本的な考え方
5． 業務におけるサービス利用の範囲
6． 作業内容
（1） 利用開始支援作業
（2） サービス利用に係る支援作業
7． 利用開始支援に係る納品物等
8． 業務サービス要件
（1） 業務要件
（2） 出力物要件
（3） 外部インタフェース要件
（4） 業務パッケージ要件
9． ネットワーク要件
10． 規模要件
（1） クライアント端末・プリンタ・その他周辺機器等
（2） 拠点（サービスを利用する拠点）
（3） データ量及びオンラインリクエスト件数
11． 信頼性等要件
（1） 信頼性要件
ア． サービスにおける信頼性
イ． データ等格納サーバおよびその設置場所等に係る信頼性
（2） 拡張性要件
（3） 上位互換性要件
12． サービスレベル
13． 情報セキュリティ要件
（1） 権限要件
（2） 情報セキュリティ対策
14． テスト要件
15． 移行要件
（1） システム移行要件
（2） データ移行要件
（3） 教育に係る要件
16． 運用・保守要件
17． 作業体制及び方法
（1） 作業体制
（2） 作業の進め方
18． 特記事項

最後に、わかりやすい仕様書とわかりにくい仕様書の特徴をお伝えします。実際に仕様書を作成するときの参考にしてください。

わかりやすい仕様書には、必ずイメージ図や図表が使われています。文字情報だけでは直感的に理解しにくく、イメージがうまく伝わらないからです。イメージ図や図表は、開発するシステム像をプロジェクトメンバーと共有する際に役立つでしょう。

また、シーケンス図が使われているのも、わかりやすい仕様書の特徴です。シーケンス図は、クラスやオブジェクト、コンポーネント間のやり取りを時間軸に沿って表現した図のことを言います。仕様書にシーケンス図が使われていることにより、システムの処理概要をひと目で把握することが可能になります。

さらに、理解しやすい正しい日本語を使用し、用語がきちんと統一されているのもわかりやすい仕様書の共通点です。

イメージ図や図表が使われていない仕様書は、非常にわかりにくいです。文字情報や口頭の説明だけでイメージを共有することは難しいでしょう。

日本人同士でもイメージを正確に共有することは困難ですが、プロジェクトメンバーに海外の方もいる場合はより困難になってしまいます。イメージの共有が図られないまま開発が進んでしまうと、トラブルが起きやすくコミュニケーションコストも余計にかかってしまうでしょう。

また、不確定要素が数多く残っている仕様書は、総じてわかりにくいです。あいまいな記述のまま開発が進んでしまうと、認識の齟齬が原因となり、トラブルも起きやすくなります。品質の低下を招いてしまうため、仕様書の段階から確定している要素は可能な限り記載するようにしてください。

システム開発の仕様書を作成する際、最も重要なポイントはシステムの目的を明確化することです。

仕様書の段階で、目的を明確化しておかないと、開発の途中で仕様変更が生じやすく、工数も増加してしまいます。工数が増加することで開発期間も長くなり、コストがかさんでしまう可能性もあるでしょう。

また、当初の納期に間に合わなくなってしまう可能性もあります。納期にギリギリ間に合うようでも、テスト期間が十分に取れなかったばかりに、納品されたシステムが不具合だらけになってしまうことも十分考えられます。

ゴールのイメージがずれてしまわないように、仕様書の段階でシステムの目的を明確にしてください。

とはいえ、「仕様書を作成する時間がない」「初めてでよくわからない」といった人は多いのではないでしょうか。アイミツでは、コンシェルジュがあなたの理想とするシステム開発を１からサポート致します！

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

システム開発における仕様書の種類や書き方をお伝えしました。

仕様書はシステム開発の成否のカギとなると言っても過言ではありません。仕様書の作成に失敗してしまうと、高確率でシステム開発も失敗に終わるでしょう。

こう聞くと「自社では仕様書を作成できない」と思う方も多いかもしれません。しかし、要求仕様書を含めて作成依頼できる開発会社もあります。外注先に心当たりがない方は、ぜひアイミツにご相談ください。10万件以上の利用実績を持つアイミツが、ニーズや納期、ご予算に沿って開発会社をご紹介いたします。