設計書の種類一覧｜基本設計・詳細設計の成果物早見表

設計書とは、システムを「何を・どう作り・どう動かすか」を工程ごとに書き分けた文書の集まりです。 基本設計（外部設計）では利用者から見える動きを、詳細設計（内部設計）では作る人が必要とする内部の作りを書きます。

この記事は個々の設計書の書き方ではなく、全体の地図に絞りました。要件定義から運用までの設計書48種類を1枚の一覧表にし、規模別にどれを作るかの目安、成果物どうしの依存関係の図、そのまま使える成果物一覧テンプレートを載せています。

確認環境：Mermaid の図は @mermaid-js/mermaid-cli 12.0.0（mermaid 12.1.0）と Chromium 141 で描画できることを確認し、一覧表の件数とタブ区切りは Python 3.11.15 で原稿の表から生成・集計しました（Ubuntu 24.04、確認日 2026-10-05）。

この記事の結論

• 設計書は「工程」×「誰が読むか」で整理すると、全体が1枚に収まります。
• 基本設計＝外部設計、詳細設計＝内部設計と読み替えて差し支えありません。迷ったら「利用者に見えるか」で振り分けます。
• 小さな開発でも機能一覧・画面レイアウト・テーブル定義書・テスト仕様書・リリース手順書は作ります。大きくなるほど、一覧と方式の文書が増えます。
• 最初に成果物一覧（どの設計書を誰がいつ作るか）を作っておくと、抜けと重複が見えます。

設計書の種類早見表（工程別の件数）

呼び方や区切りは組織によって異なります。名前よりも「何を・誰に向けて書くか」が一致しているかを見ると、別の組織の資料も読み替えられます。

設計書の全体一覧（48種類）

必須度は、規模ごとに「必須」「推奨」「条件つき」「省略可」の4段階で示しています。規模の目安は次のとおりです（人数と期間は例です）。

「条件つき」は、該当する機能（帳票、バッチ、外部連携など）がある場合に作るという意味です。「省略可」は、ほかの文書の1章にまとめるか、コードやツールの出力で代えられるという意味です。

表計算ソフトに貼る場合は、次のタブ区切りを使います（上の表と同じ内容です）。

規模別の集計

上の表を必須度ごとに数えた結果です。

小規模では「必須」が9種類です。機能一覧・画面レイアウト・ER図・テーブル定義書・結合テスト仕様書・リリース手順書など、合意と引き継ぎに欠かせないものが残ります。中規模以上では「省略可」が0になり、大規模では条件つきの4種類を除くほぼすべてが独立した文書になります。

外部設計・内部設計と基本設計・詳細設計の対応

呼び方は2系統ありますが、指している範囲はほぼ重なります。

組織によっては「外部設計・内部設計・プログラム設計」の3段に分け、内部設計を機能の分割まで、プログラム設計を1本ずつのプログラムの手順とすることもあります。その場合は、この記事の詳細設計が後ろの2段にまたがると読み替えてください。

「利用者に見えるか」で振り分ける判断基準

迷ったときは、「発注者や利用部門に確認してもらう必要があるか」と言い換えると判断しやすくなります。確認が必要なら基本設計、開発チームの中で決められるなら詳細設計です。

成果物どうしの依存関係（Mermaid図）

設計書は前の成果物を入力にして作ります。矢印の元が変わると、先も見直しが必要になります。主な23種類の関係を図にしました。

flowchart LR
    subgraph REQ[要件定義]
        R1[要件定義書]
        R2[業務フロー図]
        R4[非機能要件定義書]
    end
    subgraph BD[基本設計 = 外部設計]
        B2[機能一覧]
        B3[画面一覧]
        B4[画面遷移図]
        B5[画面レイアウト]
        B7[ER図]
        B9[外部インターフェース一覧]
        B11[バッチ一覧]
        B15[方式設計書]
        B17[運用設計書]
    end
    subgraph DD[詳細設計 = 内部設計]
        D1[画面項目定義書]
        D3[テーブル定義書]
        D4[CRUD図]
        D6[シーケンス図]
        D8[処理詳細]
        D9[バッチ詳細設計書]
        D10[API詳細仕様書]
        D12[ログ設計書]
    end
    subgraph TS[テスト]
        T2[テスト仕様書]
    end
    subgraph OP[リリース・運用]
        M2[リリース手順書]
        O1[運用手順書]
    end
    R1 --> B2
    R2 --> B2
    R4 --> B15
    R4 --> B17
    B2 --> B3
    B2 --> B11
    B2 --> B9
    B3 --> B4
    B3 --> B5
    R2 --> B7
    B5 --> D1
    B7 --> D3
    B2 --> D4
    D3 --> D4
    D1 --> D8
    D3 --> D8
    D8 --> D6
    B11 --> D9
    B9 --> D10
    B15 --> D12
    D1 --> T2
    D8 --> T2
    D9 --> T2
    D10 --> T2
    B17 --> O1
    B15 --> M2
    D9 --> O1

図の読み取り方を表にまとめます。

矢印が最も多く出ているのは機能一覧（4本）です。機能一覧の番号をほかの設計書から参照しておくと、変更の影響をたどりやすくなります。

成果物一覧テンプレートと記入例

開発の最初に、どの設計書を・誰が・いつまでに作り・誰が確認するかを1枚にします。作らないと決めたものも、理由と一緒に残しておくと後から判断をたどれます。

ID  工程  成果物名    作る／作らない 作らない理由・代わり  形式  作成者 確認者 入力になる成果物    期限  状態

記入例（架空の備品予約システム、4名・4か月）

ID  工程  成果物名    作る／作らない 作らない理由・代わり  形式  作成者 確認者 入力になる成果物    期限  状態
R1  要件定義    要件定義書   作る  －   文書  佐藤  総務部 －   2026-10-16  確認済み
R2  要件定義    業務フロー図  作る  －   図   佐藤  総務部 －   2026-10-16  確認済み
B2  基本設計    機能一覧    作る  －   表   鈴木  佐藤  R1、R2   2026-10-23  作成中
B3  基本設計    画面一覧    作る  －   表   鈴木  佐藤  B2  2026-10-30  未着手
B5  基本設計    画面レイアウト 作る  －   画面の試作   高橋  総務部 B3  2026-11-13  未着手
B6  基本設計    帳票一覧・帳票レイアウト    作らない    帳票の出力なし（CSV出力はB5に記載）    －   －   －   －   －   －
B7  基本設計    ER図 作る  －   図   田中  鈴木  R2  2026-11-06  未着手
B8  基本設計    テーブル一覧  作らない    テーブルが8個のため、D3の先頭の表で代える  －   －   －   －   －   －
B11 基本設計    バッチ一覧   作る  －   表   田中  鈴木  B2  2026-11-06  未着手
D1  詳細設計    画面項目定義書 作る  －   表   高橋  鈴木  B5  2026-11-27  未着手
D3  詳細設計    テーブル定義書 作る  －   表   田中  鈴木  B7  2026-11-20  未着手
D5  詳細設計    クラス図    作らない    フレームワークの標準の構成に従うため、方式設計書に1図だけ載せる    －   －   －   －   －   －
D12 詳細設計    ログ設計書   作る  －   表   田中  佐藤  B2  2026-11-27  未着手
T3  テスト 結合テスト仕様書    作る  －   表   鈴木  佐藤  B5、D1   2026-12-18  未着手
M2  移行・リリース リリース手順書 作る  －   文書  田中  佐藤  B11、D3  2027-01-15  未着手
O1  運用  運用手順書   作る  －   文書  佐藤  総務部 B11 2027-01-22  未着手

「状態」は、未着手・作成中・確認待ち・確認済みの4つにそろえると集計しやすくなります。「入力になる成果物」にIDを書いておくと、依存関係の図と同じ情報を表で持てます。

省くかどうかの判断基準

省く判断の軸は「読む人が作る人と別か」「後から読まれるか」の2つです。どちらも当てはまらない文書は、まとめるか自動生成に置き換えても支障が出にくくなります。

確かめて分かったこと

• 一覧の48種類のうち、最も多いのは基本設計の18種類でした。利用者・連携先・運用担当と合意する内容が集まる工程なので、一覧の類（画面・テーブル・外部インターフェース・バッチ・コード・メッセージ）がここに並びます。
• 小規模で「必須」としたのは9種類、「省略可」は16種類です。省略可の多くは詳細設計にあり、基本設計の「合意のための文書」は小規模でも残ります。
• 依存関係の図では、機能一覧から4本、非機能要件定義書から2本の矢印が出ています。非機能要件は方式設計書を経由してログ設計書やリリース手順書にも届くので、後から変えると広い範囲に影響します。
• Mermaid の subgraph の名前に「基本設計 = 外部設計」のように記号と空白を含める場合、BD[基本設計 = 外部設計] とIDと表示名を分けて書く形で描画できました。

つまずきやすい点と直し方

よくある質問

Q. 設計書にはどんな種類がありますか？ A. 工程で分けると、要件定義・基本設計・詳細設計・テスト・移行とリリース・運用の6つのまとまりがあります。この記事の一覧では合計48種類を挙げています。

Q. 外部設計と内部設計の違いは何ですか？ A. 利用者や他システムから見える部分を決めるのが外部設計、見えない内部の作りを決めるのが内部設計です。それぞれ基本設計、詳細設計と呼ばれる範囲とほぼ重なります。

Q. 基本設計と詳細設計の成果物の違いは何ですか？ A. 読み手が違います。基本設計の成果物は発注者や利用部門が確認する画面レイアウトや画面遷移図など、詳細設計の成果物は開発者が実装に使うテーブル定義書や処理詳細などです。

Q. 小規模な開発ではどの設計書を省けますか？ A. 一覧だけの文書や内部の図は、ほかの文書にまとめられます。機能一覧・画面レイアウト・ER図・テーブル定義書・結合テスト仕様書・リリース手順書は、規模が小さくても作ると引き継ぎやすくなります。

Q. アジャイル開発でも設計書は必要ですか？ A. 必要なものに絞って作ります。全体をつかむ機能一覧・ER図・システム構成図と、後から読まれる運用・リリースの文書を残し、詳細はコードと自動生成に寄せる分け方がよく使われます。

まとめ

• 設計書は工程（要件定義・基本設計・詳細設計・テスト・移行とリリース・運用）と読み手で整理できます。
• 基本設計＝外部設計、詳細設計＝内部設計で、迷ったら「利用者に見えるか」で振り分けます。
• 48種類の一覧から、規模別の必須度を目安に作るものを選びます。
• 機能一覧・ER図・非機能要件定義書は多くの成果物の入力になるので、先に固めます。
• 成果物一覧テンプレートに、作らないものも理由つきで残します。
• 省く判断は「読む人が作る人と別か」「後から読まれるか」で行います。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。