詳細設計（内部設計）とは？基本設計との違いと実務

詳細設計（内部設計）とは

詳細設計とは、基本設計で決めた画面や機能を、プログラマーが迷わず実装できる粒度まで分解し、システム内部の構造や処理の流れを定める工程です。内部設計とも呼ばれます。

平易に言えば、基本設計が「お客様から見える完成形」を決めるのに対し、詳細設計は「それを裏側でどう動かすか」を決める作業です。たとえば「注文ボタンを押すと注文が確定する」という基本設計の内容を、「在庫を確認し、足りなければエラーを返し、足りれば在庫を減らして注文データを登録し、確認メールを送る」という処理の手順に分解します。

英語ではDetailed Design（DD）と略されることがあります。プログラム設計、モジュール設計と呼ばれる工程とも重なります。

詳細設計で扱う内容

詳細設計の成果物は、主に開発チーム内部で使われる資料です。代表的なものは次のとおりです。

モジュール構成：システムをどんな部品（クラスやコンポーネント）に分けるか
処理フロー：各機能の処理手順、分岐条件、エラー時の扱い
テーブル定義：データベースのテーブル、カラム、型、制約、インデックス
API仕様：画面とサーバー、またはシステム間でやり取りするデータの形式
共通処理：ログ出力、認証、例外処理など、全体で使い回す仕組み
単体テスト観点：各部品が正しく動くことを確かめる条件

基本設計との違いを整理すると次のようになります。

観点	基本設計（外部設計）	詳細設計（内部設計）
主な読み手	発注側、業務担当者	開発者
決めること	画面、帳票、連携、データ項目	処理手順、構造、テーブル定義
確認方法	画面イメージや業務シナリオで確認	コードレビューや単体テストで確認
変更の影響	見積もりや納期に直結	主に開発チーム内で吸収

実務での使い方・具体例

ある会員制サービスで「退会機能」を作るとします。基本設計では「マイページに退会ボタンを置き、確認画面を経て退会完了画面を表示する」と決まりました。詳細設計では、次のような論点を詰めます。

退会時に会員データを物理的に削除するのか、退会フラグを立てて残すのか
継続課金中の会員はどう扱うか（決済サービス側の解約処理をどの順番で呼ぶか）
退会後に同じメールアドレスで再登録できるか
処理の途中で失敗した場合、どの状態に戻すか
退会の記録をどこにログとして残すか

これらは画面からは見えませんが、運用や法令対応に大きく影響します。特に1と3は、個人情報の保持方針という発注側が決めるべき事項です。詳細設計は開発者の領域とはいえ、このように業務判断が必要な論点が混ざっていることがあり、開発会社から質問が来たら優先的に回答することが大切です。

最近の開発現場では、詳細設計を独立した分厚い文書として作らず、設計の要点をチケットやコードのコメント、API定義ファイルに残すやり方も増えています。重要なのは文書の形式ではなく、後から別の開発者が読んでも意図が分かる状態になっていることです。

よくある誤解と注意点

「詳細設計書は納品物に必ず含まれる」と思い込む。 開発会社によっては詳細設計を文書化せず、コードとテストを正とする場合があります。保守を別の会社に引き継ぐ可能性があるなら、どの資料を納品してもらうかを契約時に明記しておくべきです。

詳細設計を省けば安く早くなるという考え。 小規模で単純な機能なら簡略化は可能ですが、決済や権限、データ移行のように失敗の影響が大きい部分を設計せずに実装すると、テスト段階で手戻りが膨らみます。

詳細設計は発注側に関係ないと考える。 内容を逐一レビューする必要はありませんが、性能やセキュリティ、障害時の挙動といった非機能の方針は詳細設計で具体化されます。「同時に何人が使っても遅くならない前提か」「処理が失敗したとき利用者には何が表示されるか」といった問いを投げるだけでも、設計の考慮漏れを早めに見つけられます。

基本設計の変更を詳細設計で吸収しようとする。 画面や業務ルールに関わる変更は、詳細設計の段階で黙って直すのではなく、基本設計に戻って合意し直すのが原則です。そうしないと、発注側の理解と実際の動きがずれていきます。

Otsumuに相談できること

Otsumuは構想から開発・運用まで一気通貫で担うため、詳細設計で生じる業務判断の論点を早めに洗い出し、発注側に分かる言葉で確認しながら進めます。将来の保守や内製化を見据えて、どの設計情報を残すべきかの整理もお手伝いできます。

開発の進め方はシステム開発のページをご覧ください。設計資料の妥当性に不安がある場合も、30分の無料相談でご相談いただけます。

執筆：Otsumu株式会社／編集日 2026.10.01

詳細設計（内部設計）とは？基本設計との違いと実務