システム開発の設計書とは？種類と成果物一覧、工程ごとの役割と作り方を解説

「設計書を提出してください」と言われても、何をどこまで出せばいいのか分からない。開発会社から届いた分厚い資料を渡されても、どこを確認すればいいのか判断できない。システム開発に初めて関わる方から、繰り返しいただくご相談です。

設計書は1種類の文書ではありません。工程ごとに複数の成果物があり、それぞれ読み手も目的も異なります。

種類を把握しないまま進めると、確認すべき文書を見落とします。基本設計の段階でしか指摘できない内容を、実装が終わってから気づくことになります。

本記事では、設計書の全体像を工程に沿って整理し、基本設計書と詳細設計書の違い、工程ごとの成果物一覧、誰が作り誰が確認するのか、そしてどこまで作るべきかの判断基準までを順に解説します。

確認したいポイント	結論	詳細
設計書とは何を指す？	要件をどう実現するかを記した文書群	1種類ではなく、工程ごとに複数の成果物がある。読み手も目的も異なる。
どんな種類がある？	基本設計書と詳細設計書の2層	前者は外から見た動き、後者は内部の作り方。それぞれ複数の成果物を含む。
発注者はどこを見る？	基本設計書までは必ず確認する	詳細設計は技術的な内容が中心だが、責任分担と検収条件は確認が必要。
どこまで作るべき？	手法と規模、保守体制で決まる	全部作るのが正解ではない。作らない場合に何を残すかを決めておく。

この記事でわかること

• 設計書が果たす役割と、要件定義書・仕様書との違い
• 基本設計書と詳細設計書の違いと、それぞれに含まれる成果物
• 工程ごとに作られる設計書の一覧と、読み手ごとの確認ポイント
• 誰が作り誰がレビューするか、発注者が確認すべき範囲
• 開発手法や規模に応じた「どこまで作るか」の判断基準

システム開発やAI導入の進め方を、支援内容とあわせて資料にまとめています。 ＞＞ 資料請求はこちら

システム開発における設計書とは

種類の話に入る前に、設計書が何のために存在するのかを整理しておきます。目的が分かれば、確認すべき箇所も見えてきます。

ここでは設計書が果たす役割、似た文書との違い、そして工程の中での位置づけを見ていきます。

設計書は「要件をどう実現するか」を記した文書

設計書とは、要件定義で決まった内容をどのように実現するかを記述した文書です。画面の構成、データの持ち方、処理の流れ、外部システムとの接続方法などを具体化します。

果たす役割は3つあります。実装の指示書として、レビューの対象として、そして保守時の資料としてです。

このうち保守時の利用は見落とされがちですが、最も長く使われます。数年後に改修する担当者にとって、この文書だけが手がかりになります。

要件定義書・仕様書との違い

要件定義書は「何を実現するか」を決める文書です。作成の主体は発注者側で、業務としてどうなりたいかを記述します。

設計書は「どう作るか」を決める文書です。作成の主体は開発側で、要件を実現する手段を具体化します。

仕様書は文脈によって指す対象が変わります。発注時の要求をまとめたものを指す場合もあれば、完成したシステムの動作を記録したものを指す場合もあります。

打ち合わせで「仕様書」という言葉が出たら、どの文書を指しているか確認してください。認識がずれたまま話が進むと、後で必要な文書がないことに気づきます。

工程の中での位置づけ

一般的な開発は、要件定義、基本設計、詳細設計、実装、テスト、運用・保守の順に進みます。設計書は2番目と3番目の工程で作られます。

この工程の区切り方には国際的な枠組みがあります。IPA（情報処理推進機構）は、システムやソフトウェアを企画・開発・運用・廃棄する一連の過程を共通の言葉で整える国際規格SLCPを紹介しており、多様な関係者が共通の土台を持たずに議論すると、合意に時間がかかり作り直しや契約トラブルが発生すると指摘しています。

工程と成果物の呼び方が発注者と開発会社で違うと、それだけで確認漏れが起きます。着手前に、どの工程でどの文書を出すのかを一覧で合意しておいてください。

設計書は基本設計書と詳細設計書の2層に分かれる

設計書は大きく2つの層に分かれます。読み手が違うため、書かれている内容も粒度も異なります。

ここでは両者の違いを整理します。

基本設計書は外から見た動きを記述する

基本設計書は、システムを利用者の側から見たときの振る舞いを書きます。どんな画面があり、何を入力すると何が返ってくるのか、どんな帳票が出るのかを記述します。外部設計書とも呼ばれます。

読み手は発注者と利用部門です。専門知識がなくても読める粒度で書かれている必要があります。

この文書に対して発注者が承認することで、作るものが確定します。ここでの確認漏れは、後工程で修正するほど費用が膨らみます。

詳細設計書は内部の作り方を記述する

詳細設計書は、基本設計で決めた動きを実現するための内部構造を書きます。処理をどう分割するか、データをどう受け渡すか、異常時にどう振る舞うかを記述します。内部設計書とも呼ばれます。

読み手は実装するエンジニアです。技術的な内容が中心になるため、発注者が細部まで読み込む必要はありません。

ただし、納品物に含まれるか、どの粒度で合格とするかは契約時に決めておいてください。ここが曖昧だと検収の段階で議論になります。

2つの違いの整理

両者を比較すると次のようになります。

観点	基本設計書	詳細設計書
答える問い	何を（What）作るか	どのように（How）作るか
主な読み手	発注者、利用部門	実装するエンジニア
視点	システムを外から見た動き	システムの内部構造
主な内容	画面、帳票、機能一覧、業務フロー	処理の分割、データ受け渡し、例外処理
発注者の関与	内容を確認して承認する	納品範囲と粒度を契約で決める

設計工程の進め方や開発会社との合意形成について、現状を伺ったうえでお手伝いします。 ＞＞ 相談予約はこちら

工程ごとに作られる設計書と成果物の一覧

「設計書」と一言で呼ばれていますが、実際には複数の成果物の集まりです。案件によって必要なものが変わるため、全体像を知っておくと過不足の判断ができます。

ここでは工程ごとに主な成果物を整理します。

基本設計工程の成果物

利用者の目に触れる範囲を中心に、次のような文書が作られます。

• システム構成図：サーバー、ネットワーク、利用端末の構成
• 業務フロー図：システム導入後の業務の流れ
• 機能一覧：システムが備える機能をID付きで整理
• 画面一覧と画面遷移図：画面の種類と移動の関係
• 画面設計書：レイアウト、表示項目、入力項目
• 帳票一覧と帳票設計書：出力する帳票の様式と条件
• バッチ処理一覧：定時実行する処理の種類とタイミング
• インターフェース一覧：外部システムとの連携方式
• テーブル定義一覧：扱うデータの種類と保存期間
• メッセージ一覧：エラーや確認の表示文言
• 非機能要件定義書：性能、可用性、セキュリティの条件

このうち発注者が必ず確認すべきなのは、業務フロー図、機能一覧、画面設計書、帳票設計書です。業務が回るかどうかは、この4つで判断できます。

詳細設計工程の成果物

基本設計を開発者向けに具体化した文書が中心になります。まったく別の文書を新規に作るというより、粒度を上げる作業です。

モジュール構成図、クラス図、シーケンス図、処理フロー、データ項目定義、例外処理の定義などが該当します。案件によっては状態遷移図やバッチ処理の詳細設計も加わります。

すべてを作る必要はありません。その図がないと実装者が確認しに来る場合にだけ作る、という判断で十分です。

データベース関連の成果物

データの持ち方を定義する文書は、工程をまたいで参照されます。ER図、テーブル定義書、項目定義書、インデックス設計などが含まれます。

既存システムからデータを移す場合は、移行設計書も必要になります。移行対象の範囲、変換のルール、移行後の確認方法を記述します。

データ移行は工数を読み違えやすい領域です。何年分を移すのかを決めていないまま進めると、稼働直前に判明して日程が崩れます。

成果物の全体像

工程ごとに整理すると次のようになります。着手前に、どれを作るかを開発会社と合意してください。

工程	主な成果物	主な読み手	発注者の確認
要件定義	要件定義書、業務要件一覧	発注者・開発者	必須
基本設計	業務フロー、機能一覧、画面・帳票設計書	発注者・利用部門	必須
基本設計	システム構成図、IF一覧、非機能要件定義書	情シス・開発者	範囲と条件を確認
詳細設計	モジュール構成、処理フロー、項目定義	実装者	納品範囲を契約で確認
共通	ER図、テーブル定義書、移行設計書	開発者・保守担当	移行範囲を確認

誰が作り、誰がレビューするか

設計書は開発会社が作るもの、と考えられがちですが、発注者が担う役割もあります。ここが曖昧だと、承認したはずの内容で後からもめます。

ここでは役割分担と確認の観点を整理します。

作成と承認の役割分担

設計書を作成するのは開発会社です。一方、内容が業務に合っているかを判断し、承認するのは発注者です。

発注者が「専門的なことは分からないので任せます」と承認すると、実質的に何も確認していない状態になります。後から「思っていたものと違う」と言っても、承認済みの文書が根拠として残ります。

業務の実態を知っているのは発注者だけです。技術的な妥当性は開発会社が担保しますが、業務として成立するかは発注者にしか判断できません。

発注者が確認すべき範囲

基本設計書のうち、次の点は必ず自分で確認してください。

• 業務フローが現場の実態と合っているか（例外処理を含む）
• 画面の項目に、業務で必要な情報がすべて含まれているか
• 帳票の様式が、社外に出せる体裁になっているか
• 権限の設定が、社内のルールと矛盾していないか
• 対象外とされている範囲に、必要な業務が含まれていないか

とくに例外処理は、現場の担当者に直接見てもらってください。マニュアルどおりでない運用は、管理職からは見えません。

レビューで見る3つの観点

レビューは参加者が同じ目線で読むと効果が下がります。役割ごとに観点を分けます。

利用部門は「この業務が回るか」、開発担当は「この内容で作れるか」、テスト担当は「この記述で検証項目を作れるか」を見ます。

テスト担当者が検証項目を作れない設計書は、条件や境界値の記述が不足しているサインです。この観点を入れると、曖昧な記述が見つかります。

検収と契約上の扱いを決めておく

どの設計書が納品物に含まれるのか、どの状態で合格とするのかを契約時に決めます。ここが曖昧だと、検収の段階で「この内容では受け取れない」という議論が発生します。

IPAが公開している情報システム・モデル取引・契約書（第二版）は、工程ごとの成果物や当事者の責任分担を整理する際の参照先として使えます。

粒度の合意は、着手前に見本を1機能分だけ作ってもらう方法が確実です。文章で条件を決めるより、実物を見せてもらうほうが認識がそろいます。

設計内容の確認や開発会社とのやり取りを、発注者側の立場で伴走支援しています。 ＞＞ 相談予約はこちら

設計書の品質を上げる5つのポイント

同じ項目を埋めていても、書き方によって伝わり方は変わります。実装時の問い合わせが多い設計書には、共通する特徴があります。

ここでは工程を問わず効いてくる5点を挙げます。

ポイント1｜読み手を先に決める

同じ内容でも、誰が読むかで書くべき粒度が変わります。業務を知らない外部の開発者に渡すなら前提から書く必要がありますが、社内チームなら不要です。

着手前に「この文書を読んで作業するのは誰か」を言語化してください。ここが決まれば、個々の項目で迷う場面は大きく減ります。

ポイント2｜図と文章の役割を分ける

図は全体の流れや構造を示すのに向いていますが、条件や例外を表すのは苦手です。逆に文章は細かな条件を正確に伝えられますが、全体像は伝わりにくくなります。

図で流れを示し、分岐の条件と例外時の扱いは文章で補う。この役割分担にすると、どちらにも無理をさせずに済みます。

フローチャートの矢印に条件が書かれていない設計書は、実装時に必ず質問が出ます。

ポイント3｜IDで工程間をつなぐ

要件、機能、画面、テーブル、テスト項目にIDを振り、対応関係を追える状態にします。要件定義書のRQ-001が、機能一覧のFN-003に対応し、テスト仕様書のTC-012で検証される、という形です。

要件が変わったときに、影響する設計書とテスト項目をIDで特定できることが目的です。文書名や見出しで探す運用は、規模が大きくなると成立しません。

ポイント4｜判断の理由を1行残す

設計上の選択をした箇所には、なぜそうしたのかを添えます。「性能要件を満たすため一括取得としている」「既存システムの制約により非同期にできない」といった内容です。

この1行があるかどうかで、数年後の改修時にかかる調査時間が変わります。理由が分からない実装は、触ってよいか判断できず、そのまま残り続けます。

ポイント5｜対象外を明記する

書いていないものは対象外である、という了解は成立しません。発注者は「当然含まれる」と考え、開発者は「書いていないので含まない」と考えます。

各設計書に、今回対応しないことを1行でよいので書き添えます。「スマートフォン対応は今回対象外とする」の1行が、後の追加費用の議論を防ぎます。

設計書はどこまで作るべきか

設計書は多いほどよいわけではありません。作りすぎるとコードと二重管理になり、更新が止まって誤った情報として残ります。

ここでは、どこまで作るかを決める判断軸を整理します。

開発手法による違い

ウォーターフォールでは、設計書を確定させてから実装に進みます。工程ごとに成果物が定義され、承認をもって次に進む形です。

アジャイルでは、全体を最初に固めず、必要になった時点で詳細化します。ただし文書を作らないわけではなく、目的や成功指標は最初に決めます。

どちらの手法でも、判断の理由と例外の扱いは残す必要があります。変わるのは詳細化のタイミングであり、記録の必要性ではありません。

規模と保守体制による違い

関わる人数が多いほど、文書の必要性は上がります。3人のチームで口頭で共有できていた内容も、20人になれば書かないと伝わりません。

保守を外部に委託する場合も、文書がないと引き継げません。逆に、作った本人が長く保守し続ける前提なら、詳細な文書の優先度は下がります。

判断の基準は「担当者が入れ替わったときに成立するか」です。入れ替わりが起きない前提の設計は、いずれ破綻します。

作らない判断が成立する条件

詳細設計書を作らない選択も、条件がそろえば成立します。実装者が業務を理解している、チームが小さく口頭で共有できる、コードが読みやすく保守も同じチームが担う、といった場合です。

ただし、この条件は時間とともに崩れます。担当者の異動、チームの拡大、保守の外部委託が起きた時点で、文書がないことが問題になります。

最低限残すもの

文書量を絞る場合でも、次の情報は残してください。コードを読んでも復元できないためです。

• システム全体の構成と、外部システムとの接続関係
• データの持ち方（テーブル定義とER図）
• 設計上の判断と、その理由
• 例外時の振る舞いと、判断の基準
• 暫定対応である箇所と、いつ見直すか

逆に、処理を1行ずつ日本語に置き換えた記述は不要です。コードを変えるたびに設計書も直す必要が生じ、いずれ更新が止まります。

設計書の標準化や社内ドキュメント運用の見直しも支援しています。資料でご確認いただけます。 ＞＞ 資料請求はこちら

設計書をめぐって起きやすい4つのトラブル

設計書に関する問題は、内容そのものより運用に起因することが多くあります。着手前に対策を決めておけば防げます。

ここでは4つ挙げます。

実物と設計書が合わなくなる

開発中の仕様変更が設計書に反映されず、稼働後には実物と食い違っている状態です。保守担当者が設計書を信じて改修すると、想定外の不具合が起きます。

変更作業の完了条件に、設計書の更新を含めてください。コードの修正と文書の更新をセットで扱えば、片方だけが進む状態を防げます。

引き継ぎができない

設計書はあるが、判断の理由が書かれていないため、なぜその作りになっているのかが分からない状態です。触ってよいか判断できず、改修が止まります。

動作はコードを読めば分かりますが、意図は書き残さない限り失われます。理由の記述は、設計書で最も価値の高い部分です。

検収の段階でもめる

納品された設計書の粒度が想定と違い、受け取れるかどうかで議論になる状態です。契約書に「設計書一式」としか書かれていないと、判断の根拠がありません。

契約時に、成果物の名称と合格の条件を一覧で決めてください。見本を1機能分作ってもらい、それを基準にする方法が確実です。

レビューが形骸化する

分厚い設計書を渡され、期限までに確認できず、そのまま承認してしまう状態です。後から問題が見つかっても、承認済みという事実が残ります。

全部を読もうとせず、確認する箇所を絞ってください。業務フロー、画面項目、帳票、権限、対象外の5点に絞れば、限られた時間でも判断できます。

疑問が出た箇所は口頭で解消せず、設計書に反映してもらいます。口頭の回答は記録に残りません。

生成AIを使った設計書の作成と保守

設計書の作成は、同じ形式の記述を機能の数だけ繰り返す作業です。この性質は生成AIと相性がよく、下書きと点検の工程で時間を削減できます。

ここでは3つの使い方と、任せてはいけない範囲を整理します。

上流の文書から下流の草案を作る

要件定義書から基本設計の機能一覧を、基本設計書から詳細設計の草案を作らせる使い方です。工程をまたぐ転記と具体化の作業を任せられます。

指示文には、出力する項目、記述の粒度、そして「元の文書に書かれていない仕様を追加しない」という条件を必ず入れてください。この条件を省くと、確認していない仕様がもっともらしく書かれます。

文書どうしの整合性を点検する

要件定義書と基本設計書、基本設計書と詳細設計書を渡し、「対応する記述がない要件を挙げる」「矛盾する記述を指摘する」といった点検を依頼します。

人が複数の文書を突き合わせる作業は見落としが出ますが、機械的な照合なら漏れが減ります。IDが振られていれば、対応関係の確認も自動化できます。

既存システムの文書化に使う

設計書が残っていない既存システムを改修する場合、ソースコードを渡して処理の流れやデータの構造を文書化させる方法があります。現行仕様の把握が目的なら効果が出ます。

ただし、なぜそうなっているかという意図は復元できません。当時の判断理由はコードにも残っていないためです。分かるのは動作までと考えてください。

なお、ソースコードを外部サービスに入力してよいかは、契約と社内規程で事前に確認が必要です。

生成AIに任せてはいけない範囲

設計方針の決定は人が行います。どの単位で処理を分割するか、性能とわかりやすさのどちらを優先するかは、システムの特性と運用体制を踏まえた判断です。

業務として成立するかの判断も同様です。現場の実態と例外的な運用を知っているのは、発注者側の担当者だけです。

業務でのAI活用を広く整理した内容は、業務効率化アイデア55選｜部門別30＋AI15＋明日から3つで成果を出す方法でも紹介しています。要件定義書や詳細設計書の書き方は、ネクストスケールのブログ一覧に掲載している個別の記事もあわせてご覧ください。

まとめ

システム開発の設計書は、要件をどう実現するかを記した文書群です。1種類ではなく、工程ごとに複数の成果物があり、それぞれ読み手も目的も異なります。

大きくは、外から見た動きを書く基本設計書と、内部の作り方を書く詳細設計書の2層に分かれます。発注者が必ず確認すべきなのは基本設計書、とくに業務フロー、機能一覧、画面設計書、帳票設計書の4つです。

作成するのは開発会社ですが、業務として成立するかを判断するのは発注者です。「専門的なことは分からないので任せます」という承認は、実質的に何も確認していないのと同じ結果になります。

品質を上げるには、読み手を先に決める、図と文章の役割を分ける、IDで工程間をつなぐ、判断の理由を残す、対象外を明記する、の5点を押さえてください。

そして、どこまで作るかは手法・規模・保守体制で決まります。全部作るのが正解ではありません。文書量を絞る場合でも、構成、データの持ち方、判断の理由、例外の扱いだけは残してください。

システム開発やAI導入を、どこから・どの順番で進めるべきか。現状を伺ったうえで、具体的な進め方をご提案します。 ＞＞ 相談予約はこちら