当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。
システム開発の現場に入ると、『基本設計書』『詳細設計書』『画面設計書』と、設計書という名前の文書がいくつも出てきますよね。どれが何のための文書なのか、最初は迷う方も多いはずです。
結論から言うと、設計書は「要件定義で決めたことを、どう作るかに置きかえた文書」です。種類が多く見えても、開発の流れのどこで作り、どのテストで確かめるかを押さえれば迷わなくなります。
この記事を読めば、設計書の意味と種類、そして開発の流れの中での位置が一枚の地図のように分かります。
設計書とは？システム開発で何のために作る文書か
設計書とは、システムやソフトウェアを「どう作るか」を書いた文書です。要件定義書が「何を作るか」を決めた文書なのに対し、設計書はそれを実現する作り方を決めます。
『仕様書と設計書って、同じものじゃないの？』と思った方もいるかもしれません。実は、現場でも言葉の使い方はけっこう混ざっています。
ソフトウェアの用語を集めた国際規格 ISO/IEC/IEEE 24765:2010 では、design description を「システムやコンポーネントの設計を記述した文書」としています。同義語として design document と design specification が挙げられています。
つまり英語では、設計書を「設計の仕様書」と呼ぶこともあるわけです。日本語の「設計書」と「仕様書」の線引きがあいまいなのも、無理はないんです。
要件定義書・仕様書・設計書の関係
IT のシステム開発では、文書がおおむね次の順番で作られます。名前は会社やプロジェクトで変わるので、役割の目安として見てください。
| 文書 | 主に答える問い | 主に書く人 | 主に読む人 |
|---|---|---|---|
| 要件定義書 | 何を作るか・何ができればよいか | 発注側（開発側が手伝うことも） | 発注側・開発側の両方 |
| 基本設計書 | 利用者から見てどう動くか | 開発側のSE | 発注側・開発側 |
| 詳細設計書 | 中の処理をどう作るか | 開発側のSE | プログラマー・テスト担当 |
| テスト仕様書 | どう確かめるか | 開発側・テスト担当 | 開発側・発注側 |
仕様書そのものの意味や、設計書との違いは仕様書とは？意味と目的、設計書・要件定義書との違いと仕様書と設計書の違いでくわしく紹介しています。
IPAとデジタル庁の資料での「設計」
IPAのDX SQUARE「要件定義とは？」では、基本設計を「要件定義でまとめた要件を具体化し、業務フローを明確にする工程」と説明しています。必要な機能やソフトウェア構成を決め、外部インタフェースを整理する工程とされています。
デジタル庁のデジタル・ガバメント推進標準ガイドライン（DS-100）では、設計の順番がこう書かれています。
画面、帳票等の利用者にとって直接的に理解することができる基本設計を行った後に、機能を実現するための詳細設計を行うものとする。
出典：デジタル庁 DS-100 デジタル・ガバメント推進標準ガイドライン
利用者に見える部分を先に決めて、そのあとで中の作りを決める。設計書を読む時も、この順番を頭に入れておくと内容がつかみやすくなります。
設計書の種類は？よく作られる設計書の一覧
設計書の種類は、大きく「基本設計書」と「詳細設計書」の2段階に分かれます。そのうえで、画面・帳票・データ・外部との連携・処理といった部品ごとに、別の設計書を作ることが多いです。
『設計書の種類が多すぎて、どれを作ればいいか分からない』という声はよく聞きます。ただ、全部をそろえる決まりがあるわけではありません。
プロジェクトの大きさや契約の中身で、作る設計書は変わります。まずは代表的なものを並べてみますね。
| 設計書の種類 | 主に書くこと | 主に作る段階 |
|---|---|---|
| 基本設計書（外部設計書と呼ぶ会社も） | 機能の一覧、画面や帳票の構成、データの全体像、外部との連携 | 基本設計 |
| 画面設計書 | 画面のレイアウト、入力項目、ボタンの動き、画面遷移 | 基本設計 |
| 帳票設計書 | 印刷や出力する書類の項目と配置 | 基本設計 |
| テーブル定義書・データベース設計書 | テーブルや項目の名前、型、関係 | 基本設計から詳細設計 |
| インタフェース設計書・API仕様書 | 他のシステムとやり取りするデータの形と手順 | 基本設計から詳細設計 |
| 詳細設計書（内部設計書と呼ぶ会社も） | 処理の流れ、モジュールの分け方、データの受け渡し | 詳細設計 |
| バッチ処理の設計書 | 夜間などにまとめて動く処理の手順と条件 | 詳細設計 |
| インフラ・ネットワークの設計書 | サーバーやネットワークの構成、性能、信頼性 | 基盤の設計 |
厚生労働省の職業情報提供サイト job tag（2025年時点の掲載）でも、受託開発のSEの仕事として、基本設計ではデータベースの設計や外部システムとの連携、画面構成を固めると紹介されています。詳細設計では、データ形式やファイル形式、内部処理の方法、操作画面の詳細を決め、処理の流れを細分化した設計書を作るとされています。
基本設計書と詳細設計書
設計書の中心になるのが、この2つです。基本設計書は利用者や発注側にも読んでもらう文書で、詳細設計書は主にプログラムを書く人が読む文書です。
書く項目や書き方は基本設計書とは？書く項目と書き方と詳細設計書とは？基本設計書との違いと書き方で一つずつ紹介しています。
ソフトウェアの組み立て方を書く設計書
ソフトウェアの設計書には、プログラムをどんな部品（モジュール）に分け、部品同士がどうつながるかを書いた文書もあります。会社によっては「構造設計書」「方式設計書」「アーキテクチャ設計書」などと呼ばれます。
IPAの共通フレーム2013には、「ソフトウェア方式設計プロセス」という工程名があります。ソフトウェア全体の組み立て方を決める段階で、その結果をまとめた文書がこの種の設計書にあたります。
ちなみに建築で「構造設計書」と言うと、建物の柱や梁の強さを確かめる文書のことです。同じ言葉でも分野で中身が違うので、検索する時は「ソフトウェア」を足すと探しやすくなります。
インフラの設計書
アプリだけでなく、サーバーやネットワークにも設計書があります。job tag（2025年時点の掲載）の基盤システムのSEの説明では、設計の工程で作る設計書の主な内容を「機能、構成、性能、信頼性、予算、開発工程」としています。
どの設計書を納品物にするかは、契約やプロジェクトの計画で決まるのが一般的です。迷った時は、契約書や作業計画書の「成果物」の欄を見てみてください。
設計書を「V字の地図」に並べると、役割が一目で分かる
設計書は、テスト工程とペアで見ると役割がはっきりします。要件定義書は受入れのテスト、基本設計書は結合や総合のテスト、詳細設計書は単体テストで、それぞれ正しく作れたかを確かめます。
『設計書を書いても、誰がどう使うのかピンとこない』という方もいますよね。そこで、開発の流れを左から右へ並べた「V字の地図」で見てみましょう。
左側を上から下へ「決める」工程が進み、いちばん下でプログラムを作ります。そこから右側を下から上へ「確かめる」工程が進んでいきます。
決める工程と確かめる工程の対応表
次の表は、編集部が一般的な開発の流れをまとめたものです。工程の名前は、IPAの共通フレーム2013にある工程名も併せて載せました。
| 決める工程（左側） | 作る文書 | 共通フレーム2013の工程名の例 | 確かめる工程（右側） |
|---|---|---|---|
| 要件定義 | 要件定義書 | 要件定義プロセス、システム要件定義プロセス | 受入れテスト・総合テスト |
| 基本設計 | 基本設計書・画面設計書など | システム方式設計プロセス、ソフトウェア方式設計プロセス | 結合テスト・総合テスト |
| 詳細設計 | 詳細設計書・テーブル定義書など | ソフトウェア詳細設計プロセス | 単体テスト |
| 実装 | プログラム | ソフトウェア構築プロセス | （プログラムそのもの） |
右側のテストの名前は、組織によって違います。デジタル庁のDS-100では、開発事業者に「単体テスト、結合テスト及び総合テスト」の計画書の案を求め、そのあと発注側が利用者と一緒に「受入テスト」を行うと定めています。
JSTQBのFoundation Levelシラバス（Version 2023V4.0.J02）では、テストレベルをコンポーネントテスト（ユニットテスト）、コンポーネント統合テスト、システムテスト、システム統合テスト、受け入れテストの5つとしています。呼び名は違っても、「小さい単位から順に確かめる」考え方は同じです。
V字の地図から分かる、設計書に書くべきこと
この地図を見ると、設計書は「あとで確かめられる形」で書く必要があると分かります。単体テストの担当者は詳細設計書を見てテストケースを作り、結合テストの担当者は基本設計書を見て画面や連携の動きを確かめるからです。
例えば詳細設計書に「金額を正しく計算する」とだけ書いてあったら、どうでしょう。テストする人は『正しいって、何が正しいの？』と困ってしまいますよね。
- 入力と出力が具体的に書かれているか
- 条件ごとの動き（正常な時・エラーの時）が書かれているか
- 数値の上限や桁数、並び順などが決まっているか
- どの要件を実現する設計なのか、元の要件をたどれるか
テスト側の文書の書き方はテスト仕様書とは？や単体テスト仕様書の書き方で紹介しています。
土木や建築の「設計書」とは意味が違う
公共工事や国の契約では、「設計書」は仕様書と並んで、予定価格の見積もりや検査の元になる書類として出てきます。システム開発の設計書とは役目が違い、「設計図書」という似た言葉もあります。
『設計書とは』で調べると、土木の話が出てきて戸惑った方もいるはずです。同じ「設計書」でも、ITと土木では使われ方が違うんです。
法令に出てくる「設計書」
国の契約のルールを定めた予算決算及び会計令の第79条には、予定価格を「当該事項に関する仕様書、設計書等によつて予定し」という書き方があります。工事や調達の値段を見積もる時の元になる書類として、仕様書と並んで設計書が出てきます。
地方自治法施行令の第167条の15第2項でも、契約の検査は「契約書、仕様書及び設計書その他の関係書類」に基づいて行うとされています。
公共工事の「設計図書」
土木工事共通仕様書（案）令和8年3月では、設計図書を「仕様書、契約図面、現場説明書及び現場説明に対する質問回答書をいう」と定義し、土木工事では工事数量総括表を含むとしています。
ITの設計書と、土木の設計書・設計図書を並べると、次のようになります。
| 比べる点 | システム開発の設計書 | 土木・建築の設計書・設計図書 |
|---|---|---|
| 何のための文書か | 作り方を決めて、プログラムを作る人に伝える | 工事の内容を決め、契約や見積もり、検査の元にする |
| 主な中身 | 画面、データ、処理の流れ | 図面、仕様書、数量、現場説明 |
| 契約との関係 | 成果物の一つになることが多い | 設計図書は契約図書の一部 |
| 主な読み手 | SE、プログラマー、テスト担当 | 受注者、監督職員、検査する人 |
公共工事の設計図書の範囲や優先順位は設計図書とは？仕様書・図面・現場説明書の関係で紹介しています。土木の共通仕様書そのものは土木工事共通仕様書（国土交通省）とはが入り口です。
システムの設計書を探したい時は「設計書 システム開発」「設計書 ソフトウェア」のように、分野の言葉を足すと土木の情報と混ざりにくくなります。
設計書についてよくある相談
よく読まれている相談は「システム設計書とプログラム設計書の違い」「設計書どおりに作ったのに直された」「設計書を作らない会社もあるのか」の3つです。どれも、設計書が誰のための文書かを考えると答えが見えてきます。
知恵袋にも、設計書についての相談がたくさん寄せられています。閲覧の多いものを要約して、編集部の考えをお答えしますね。
相談1：システム設計書とプログラム設計書は何が違う？
『システム設計書とプログラム設計書、名前は似ているけど何が違うの？』という相談です。
ざっくり言うと、システム設計書はシステム全体の作りを、プログラム設計書は一つひとつのプログラムの中身を書いた文書です。V字の地図で言えば、前者は基本設計に近く、後者は詳細設計に近い位置にあります。
ただ、どこまでをどの文書に書くかは会社ごとに違います。社内の過去の設計書を一つ開いて、目次を見比べてみるのがいちばんの近道です。
相談2：設計書どおりに作ったのに、直すように言われた
『設計書のとおりにプログラムを作ったのに、思っていたのと違うと言われた』という相談です。悔しい気持ちになりますよね。
こうしたズレは、設計書に書かれていないことや、あいまいに書かれていたことが原因で起きることが多いです。設計書どおりに作るのは正しい進め方なので、自分を責める必要はありません。
次からは、読んで迷った所をメモして、作り始める前に書いた人へ確かめてみてください。例えばこんなふうに聞くと伝わりやすいです。
「この画面で、入力が空のまま登録ボタンを押した時はどうしますか？」
相談3：設計書を作らない会社って普通？
『外部設計書や詳細設計書などを作らない会社って当たり前なの？』という相談です。
開発の進め方や規模によって、文書の量はかなり変わります。小さなチームで、短い間隔で作っては直す進め方なら、大きな設計書を作らずにメモや画面の試作で済ませることもあります。
ただ、何も残っていないと、あとから入った人や保守する人が困ります。文書の形は軽くても、「何を決めたか」を残しておくのが大事です。
「急ぎだから」と設計書を後回しにして、作り終えてからまとめて書こうとするケースがあります。決めた理由を忘れてしまい、結局プログラムを読み直して書くことになりがちです。決めたその日に、一行でも残しておきましょう。
初めて設計書を任された時の進め方
初めて設計書を書く時は、ゼロから書かずに、社内の過去の設計書と要件定義書を横に置いて始めるのがいちばんです。書いたら、読み手に早めに見てもらいましょう。
『入社2年目で、いきなり設計書を任された…』という方もいますよね。job tag（2025年時点の掲載）では、受託開発のSEは一般的に3年目頃には一人で詳細設計を書けるようになり、5年目頃には基本設計を含め開発全体ができるようになると紹介されています。
つまり、最初は分からなくて当たり前なんです。次の手順で少しずつ進めてみてください。
- 要件定義書を読み、自分が担当する機能の範囲に線を引く
- 社内の過去の設計書を探し、目次と書き方の約束を写す
- 画面・データ・処理のうち、どれを書く設計書かを決める
- 決まっていない所を一覧にして、先輩や発注側に確かめる
- 半分ほど書けた段階で、読み手に一度見てもらう
どの設計書から読めばいいか
既存のシステムを直す仕事なら、書く前に今の設計書を読むことになります。読む順番は、V字の地図の上から下が分かりやすいです。
| 読む順番 | 読む文書 | 読む時に見る所 |
|---|---|---|
| 1 | 要件定義書 | そもそも何のためのシステムか |
| 2 | 基本設計書 | 画面の一覧とデータの全体像 |
| 3 | 画面設計書・テーブル定義書 | 自分が直す画面とデータ |
| 4 | 詳細設計書 | 直す処理の流れと条件 |
書き方のコツは設計書の書き方｜読み手に伝わる構成と表現のコツ、ひな形の使い分けは設計書のテンプレート・サンプルで紹介しています。
設計書を書く経験は、次の仕事にもつながる
要件定義書や設計書を書いた経験は、上流工程を任される職場で評価されやすい経験です。今の担当工程から一歩進みたい方は、求人の仕事内容で「基本設計」「要件定義」がどう書かれているかを比べてみると、進む道が見えてきます。
もちろん、今の職場で設計の担当を少しずつ広げていく道も十分ありです。上流工程に進む道筋は上流工程とは？でまとめています。
IT・Webエンジニアの転職（PR）
仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる
要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。
無料ITエンジニアの求人を探す求人の条件・待遇は各求人票と応募先の案内でご確認ください。
よくある質問
設計書とは、簡単に言うと何ですか？
システムやソフトウェアを「どう作るか」を書いた文書です。要件定義書で決めた「何を作るか」を、画面・データ・処理などの作り方に置きかえて書きます。
設計書の種類はいくつありますか？
決まった数はありません。大きくは基本設計書と詳細設計書の2段階で、そのうえで画面設計書、帳票設計書、テーブル定義書、インタフェース設計書などを必要に応じて作ります。どれを作るかは契約やプロジェクトの計画で決まります。
基本設計書と詳細設計書は誰が読むのですか？
基本設計書は発注側と開発側の両方が読み、利用者から見た動きを確かめます。詳細設計書は主にプログラマーやテスト担当が読み、プログラムの中身を作る時やテストを考える時に使います。
土木の設計書とシステムの設計書は同じものですか？
違います。国の契約のルールでは、設計書は仕様書と並んで予定価格の見積もりや検査の元になる書類として出てきます。システム開発の設計書は、プログラムの作り方を決める文書です。
設計書はExcelとWordのどちらで作るものですか？
どちらで作っても構いません。表で管理する項目が多い設計書はExcel、文章で説明する部分が多い設計書はWordやMarkdownが使いやすいです。社内で決まった形式があれば、それに合わせましょう。
まとめ
- 設計書は、要件定義で決めたことを「どう作るか」に置きかえた文書
- 種類は基本設計書と詳細設計書の2段階を軸に、画面・データ・連携などの設計書を足していく
- V字の地図で見ると、設計書はそれぞれテスト工程とペアになっている
- 土木や建築の「設計書」「設計図書」は、契約や見積もりの元になる書類で中身が違う
- 初めて書く時は、要件定義書と過去の設計書を横に置いて始める
コメント