基本設計と詳細設計の違いを一言で言うと、
基本設計 = 「何を作るか」を決める
詳細設計 = 「どう作るか」を決める
です。
システム開発では、要求を徐々に具体化していきます。
全体像
一般的には以下の流れです。
要件定義
↓
基本設計（外部設計）
↓
詳細設計（内部設計）
↓
実装
↓
テスト
基本設計（外部設計）
基本設計は、
ユーザーや業務から見たシステムの仕様を決める工程
です。
利用者・業務担当・顧客と認識を合わせるための設計です。
基本設計で決めること
例えば販売管理システムなら：
どんな画面があるか
どんな入力項目があるか
ボタンを押すと何が起きるか
どんな帳票を出すか
権限はどうするか
他システムと何を連携するか
エラーメッセージは何を出すか
など。
基本設計の成果物
代表例：
画面設計書
画面遷移図
API一覧
テーブル一覧
帳票設計
業務フロー
IF設計
権限設計
非機能要件整理
PlantUMLなら：
業務フロー図
シーケンス図
コンテキスト図
DFD
などがよく登場します。
基本設計の特徴
① 顧客と会話できる粒度
顧客が読める必要があります。
そのため：
実装コード
クラス構造
アルゴリズム詳細
までは通常書きません。
② 「振る舞い」を決める
例えば：
受注確定ボタン押下
↓
在庫引当
↓
配送依頼作成
↓
メール送信
のような業務動作。
詳細設計（内部設計）
詳細設計は、
実装者がコードを書けるレベルまで分解する工程
です。
プログラマ向け設計です。
詳細設計で決めること
例えば：
クラス設計
メソッド設計
SQL
テーブル定義詳細
API request/response詳細
エラーハンドリング
排他制御
キャッシュ戦略
トランザクション境界
バッチ処理仕様
ログ出力内容
など。
詳細設計の成果物
代表例：
クラス図
シーケンス図
テーブル定義
API詳細仕様
SQL設計
処理フロー
状態遷移
擬似コード
C++なら：
ヘッダ設計
ownership設計
RAII責務
interface segregation
virtualの責務
スレッド同期
などもここに入ります。
例で比較
基本設計
ログイン画面がある
ID/PW入力
認証失敗時はエラー表示
詳細設計
AuthService::login()
- SHA-256でhash化
- usersテーブル検索
- bcrypt比較
- JWT生成
- session cache保存
ここまで落ちる。
なぜ分けるのか
理由は、
① 顧客と実装者では関心が違う
顧客：
業務が回るか？
開発者：
実装できるか？
性能は？
保守性は？
② 抽象度を分離するため
いきなり詳細設計に行くと：
要件漏れ
作り込み
無駄実装
が増えます。
逆に基本設計だけだと：
実装者ごとに解釈がブレる
実際の現場では曖昧
ここは重要です。
現実には：
基本設計と詳細設計が混ざる
アジャイルでは境界が薄い
小規模開発では同時進行
も多いです。
特に最近は：
API First
DDD
マイクロサービス
Agile
などで、
「基本設計→詳細設計」
を完全分離しないケースも増えています。
あなたの関心領域だと重要な違い
あなたが取り組んでいる：
ClickHouse
CQRS
Kafka
C++
OLTP/OLAP分離
投資バックテスト高速化
のような領域では、
基本設計で：
OLTPとOLAPを分離する
Kafkaでイベント連携する
を決め、
詳細設計で：
Kafka topic設計
partition key
ClickHouse ORDER BY
MergeTree設計
C++ ownership
キャッシュ粒度
まで落とします。
つまり：
基本設計 = アーキテクチャ方針
詳細設計 = 実装可能な具体化
という役割になります。
よくある失敗
基本設計なのに詳細に入りすぎる
例：
変数名
関数名
if文
まで議論する。
これは設計レビューが破綻しやすい。
詳細設計が浅すぎる
例：
適当にRepository作る
だけ。
すると実装者ごとの差異が爆発します。
一番重要な本質
本質は、
「責務の分離」
です。
基本設計：
何を保証するシステムか
詳細設計：
どう実現するか
を分離することで、
顧客
PM
アーキテクト
実装者
テスター
が会話しやすくなります。