「基本設計は終わりました。次は詳細設計に入ります」と開発会社から報告を受けたとき、発注側は何を確認して承認しているだろうか。設計書を受け取っても中身が読めず、雰囲気で押印してしまう。その結果、稼働直前に「そういう仕様だったのか」となる。
この記事は、システムを発注する側が基本設計と詳細設計をどう扱えばよいかを整理したものである。上位の解説記事はエンジニア向けに「設計者が何を作るか」を書いているが、ここでは受託開発会社として設計工程を回す立場から、発注側が何を見て、何を承認し、何を見なくてよいかを書く。
この記事でわかること
Photo by Daniel McCullough on Unsplash
- 基本設計と詳細設計の違いを、成果物と「決まること」で切り分ける
- 発注側がレビューすべきなのは基本設計だけである理由
- 基本設計で決め残すと、後工程で何が起きるか（手戻りの構造）
- 設計フェーズを承認するときのチェックリスト
- 請負契約・準委任契約と設計工程の関係
結論：発注側は基本設計だけを見る。詳細設計は見なくてよい
Photo by Jeswin Thomas on Unsplash
先に結論を書く。
| 工程 | 誰のための文書か | 発注側の関与 |
|---|---|---|
| 要件定義 | 発注側と開発会社の合意 | 主体的に決める |
| 基本設計 | 発注側が業務として成立するか確認する | レビューして承認する |
| 詳細設計 | 開発会社の中で実装者に渡すための文書 | 原則見なくてよい |
| 実装・テスト | 開発会社 | 受入テストで確認する |
詳細設計書を発注側がレビューしても、判断できる材料がほとんど無い。クラス構成やテーブル定義の妥当性は、業務知識ではなく技術知識で判断する領域である。見ても分からない文書を承認フローに入れると、承認が形骸化して基本設計のレビューまで雑になる。これが実務上いちばん避けたい状態である。
ただし例外が2つある。将来の内製化や他社への引き継ぎを想定している場合と、ベンダーロックインを避けたい場合は、詳細設計書の存在と品質を成果物として確認する価値がある（中身の技術的妥当性ではなく、引き継げる粒度で書かれているか）。
基本設計と詳細設計の違い
Photo by Vooglam Eyewear on Unsplash
決まることの違い
| 基本設計（外部設計） | 詳細設計（内部設計） | |
|---|---|---|
| 立場 | 使う人から見た設計 | 作る人から見た設計 |
| 決めること | 画面の構成と項目、帳票のレイアウト、業務の流れ、他システムとの連携、データの持ち方の大枠 | プログラムの構造、処理の手順、クラス・関数の分割、テーブルの物理設計 |
| 問い | この画面で業務が回るか | この設計で実装できるか |
| 変更の影響 | 業務が変わる | 実装方法が変わるだけ |
| 主な成果物 | 画面設計書、帳票設計書、業務フロー、機能一覧、ER図（論理）、外部インターフェース仕様 | クラス図、シーケンス図、モジュール仕様、テーブル定義（物理）、バッチ処理仕様 |
「外部設計」「内部設計」という呼び方も同じ意味で使われる。外部＝システムの外から見える部分、内部＝外からは見えない作りの部分と考えると分かりやすい。
発注側にとっての違い
決定的なのは「変更の影響」の行である。
- 基本設計の変更＝業務が変わる。だから発注側が判断しなければならない
- 詳細設計の変更＝実装方法が変わるだけ。開発会社の裁量でよい
この線引きが、レビュー範囲を決める根拠になる。
基本設計で発注側がレビューすべき5点
設計書を全ページ読む必要はない。次の5点に絞る。
1. 画面に、業務で必要な項目が全部あるか
これは業務担当者にしか判断できない。実際に入力する人・見る人に見せるのが唯一確実な方法である。管理職だけでレビューすると、現場で毎日使う項目の抜けに気づかない。
確認の仕方：画面設計書を見ながら、直近1か月の実際の伝票を3枚持ってきて、この画面に入力できるかを試す。仮の例ではなく実データでやること。例外的な取引ほど抜けやすい。
2. 業務の例外パターンが設計に入っているか
正常系は誰でも確認する。抜けるのは例外である。
- 途中で取り消す・差し戻す場合
- 承認者が不在の場合
- 過去の伝票を修正する場合
- 締め処理をやり直す場合
- 通常と違う単価・条件で取引する場合
これらが設計書に無ければ、「そのときは手作業で」になる。手作業になること自体は判断としてありうるが、稼働後に判明するのではなく、いま決めるべきである。
3. 他システムとの連携がどこまで自動か
連携仕様は基本設計で確定させる。ここが曖昧なまま進むと、稼働直前に「CSVを手で作って取り込む」運用が発生する。
確認する項目：連携するデータの種類、頻度（リアルタイム／日次／月次）、失敗したときにどうなるか、誰が気づくか。「失敗したときに誰が気づくか」が決まっていない連携は、必ず気づかれないまま止まる。
4. 帳票が、そのまま社外に出せる形か
請求書・納品書など社外に出る帳票は、レイアウトの細部が業務要件である。ロゴ位置、印影欄、単位、端数処理、消費税の表示方法。紙に印刷して確認する。画面上のプレビューだと気づかない問題が出る。
5. 誰が何を見られるかが設計に反映されているか
要件定義で決めた権限区分が、画面設計に落ちているかを確認する。権限は後から足すとテスト工数がそのままかかるため、基本設計の段階で確定させたい。権限を含む非機能要件の決め方は非機能要件とはにまとめている。
基本設計で決め残すと何が起きるか
手戻りの費用構造を、工程別に整理する。同じ変更でも、気づく時期が遅いほど戻る工程が増える。
| 変更に気づいた時期 | 戻る工程 | 発注側の実務的な打ち手 |
|---|---|---|
| 基本設計レビュー中 | 基本設計のみ | その場で直す。追加費用は発生しないことが多い |
| 詳細設計中 | 基本設計 → 詳細設計 | 変更管理の対象。小さければ吸収されることもある |
| 実装中 | 基本設計 → 詳細設計 → 実装 | ほぼ確実に追加費用と納期調整 |
| 結合テスト以降 | 上記＋テストのやり直し | スケジュールを延ばすか、機能を落とすかの判断になる |
| 受入テスト | 上記＋関連機能の再確認 | 稼働延期の検討に入る |
重要なのは、費用が線形に増えるのではなく、戻る工程の数だけ増えるという点である。だから基本設計のレビューに時間を使うのが最も安い。実務的には、基本設計レビューに現場担当者の時間を2〜3日確保するほうが、後工程の手戻り1件を防ぐより安く済む。
工程全体の費用・期間の配分はシステム開発とは｜工程・期間・費用の配分で扱っている。
設計フェーズを承認するときのチェックリスト
基本設計の完了を承認する前に、次を確認する。1つでも「いいえ」があるなら、承認を保留してよい。
- 画面設計を、実際にその画面を使う担当者が確認したか
- 実データ（直近の伝票・帳票）で入力・出力を試したか
- 例外パターン（取消・差戻し・修正・締め直し）が設計に含まれているか
- 他システム連携の頻度・失敗時の扱い・気づく人が決まっているか
- 社外に出る帳票を紙に印刷して確認したか
- 権限区分が画面設計に反映されているか
- 要件定義書の項目と設計書の対応が追えるか（どの要件がどの画面になったか）
- 設計変更が発生したときの手続き（誰が承認し、費用と納期をどう扱うか）が合意されているか
- 詳細設計以降の成果物の納品範囲が契約上明確か
最後の2つは設計そのものではないが、ここで確認しておかないと後で必ず問題になる。特に設計変更の手続きは、変更が実際に起きてから決めようとすると利害が対立して決まらない。
契約形態と設計工程の関係
設計工程をどの契約形態で進めるかは、手戻りの扱いに直結する。
| 契約形態 | 設計工程での意味 | 注意点 |
|---|---|---|
| 準委任 | 作業時間に対して支払う。要件が固まりきっていない前提で進められる | 成果物の完成義務は無い。何をもって完了とするかを別途決める必要がある |
| 請負 | 成果物の完成に対して支払う。仕様変更は原則として追加費用 | 仕様が固まっていない段階で請負にすると、開発会社が安全側に見積もるため高くなる |
実務では、要件定義・基本設計を準委任、詳細設計以降を請負とする分け方が多い。要件が動く可能性が高い工程を準委任にすることで、変更のたびに契約変更をする手間を避けられる。
ただしこの分け方には落とし穴がある。準委任のまま基本設計を終えると、「完了した」の基準が無い。前掲のチェックリストのような完了条件を、契約時に合意しておく必要がある。契約形態の選び方は請負と準委任の違い、要件定義フェーズの契約は要件定義と準委任契約で詳しく扱っている。
よくある誤解
「基本設計は開発会社が作るものだから、任せておけばいい」 — 作るのは開発会社だが、業務として成立するかを判断できるのは発注側だけである。開発会社は「要件定義書に書いてあることを設計に落とす」ことはできるが、書かれていない業務慣行は知らない。
「詳細設計まで見ないと不安」 — 見ても判断材料が無い。不安の正体が「ちゃんと作られているか」であれば、詳細設計書のレビューではなく、テスト計画と進捗の見え方を確認するほうが有効である。
「基本設計と詳細設計は必ず分かれている」 — 小規模開発やアジャイル型では、明確に分けないこともある。分けないこと自体は問題ではないが、その場合も「発注側が業務として承認する場」は必要である。名前が無いだけで、機能としては残さなければならない。
「設計書は詳しいほどよい」 — 詳しさより、要件との対応が追えるかが重要である。要件定義書のどの項目がどの画面になったかを追えない設計書は、量が多くてもレビューできない。
まとめ
- 基本設計＝使う人から見た設計、詳細設計＝作る人から見た設計
- 基本設計の変更は業務が変わるため発注側が判断する。詳細設計の変更は実装方法の話なので開発会社の裁量でよい
- 発注側がレビューするのは基本設計の5点（画面項目・例外パターン・連携・帳票・権限）
- レビューは実データと現場担当者で行う。仮の例と管理職だけでは抜けが出る
- 手戻り費用は戻る工程の数だけ増える。基本設計レビューに時間を使うのが最も安い
- 準委任で基本設計を進めるなら、完了条件を契約時に決める
