外部設計とは？内部設計との違いと成果物、発注者が承認すべき観点を解説

外部設計とは、要件定義で決めた「何を作るか」を、利用者から見える画面や帳票、他システムとの連携といった形に落とし込む設計工程です。基本設計と呼ばれることも多く、この後の内部設計（詳細設計）とセットで語られます。この記事では、外部設計と内部設計の違い、外部設計書に書く成果物とサンプル項目、そして発注する側がレビューで何を承認すべきかまでを、開発を外注する立場の視点で整理します。設計工程を開発会社に丸投げせず、要所で正しく判断するための手引きとして読んでください。

まとめ｜外部設計の位置づけと発注者が押さえる要点

外部設計は、要件定義の次に置かれる工程で、システムの外から見える部分を決めます。画面レイアウト、入力チェック、帳票、他システムとのインターフェース、データの持ち方の論理設計までがここに含まれます。呼称は会社によって揺れ、外部設計を「基本設計」、内部設計を「詳細設計」と呼ぶ現場が多数派です。

内部設計との一番の違いは、決める対象が「利用者に見えるか、見えないか」です。外部設計は利用者と発注者が確認できる範囲、内部設計はプログラムの内部構造で開発会社の領分になります。発注側が主導すべきは外部設計です。画面や業務ルールは業務を知る側にしか決められません。

外部設計の成果物は、外部設計書（基本設計書）としてまとまります。発注側はこの文書をレビューし、承認して初めて内部設計へ進む流れです。ここで画面や帳票の確認を開発会社任せにすると、製造やテストの段階で「想定と違う」が噴出し、設計へ戻る手戻りが工数を押し上げます。設計工程を含めて上流から伴走できる開発会社を選べるかが、後工程の炎上を防ぐ分かれ目です。工程全体の中での位置づけはシステム開発の工程で確認できます。

外部設計とは何か、要件定義から詳細設計へと続く設計工程の中での位置づけ

外部設計は、システム開発の工程の中で要件定義の直後に来ます。要件定義が「業務でこういうことを実現したい」という要求をまとめる段階だとすれば、外部設計はそれを「こういう画面・帳票・連携で実現する」という具体像に変換する段階です。

外部設計の定義と、システムの外から見える範囲を決めるという役割

外部設計とは、システムを利用する人や連携する他システムから見える範囲を設計する工程です。ログイン画面にどの項目を置くか、検索結果を何件ずつ表示するか、月次の請求書をどんなレイアウトの帳票で出すか、外部の決済サービスとどんなデータをやり取りするか。こうした「境界（インターフェース）」の設計が外部設計の中心です。

要件定義との違いは具体度にあります。要件定義は「請求書を発行できること」までを決め、外部設計は「A4縦・税区分ごとに小計を出す・押印欄あり」というレイアウトまで踏み込む段階です。要件定義の進め方は要件定義とはで整理しているので、前段の成果物とあわせて読むと工程のつながりが掴めます。

外部設計が基本設計と呼ばれる理由と、詳細設計・内部設計との呼称の対応

外部設計は、多くの現場で「基本設計」と同じ意味で使われます。ウォーターフォール開発の工程を「基本設計→詳細設計」と2段で描く流儀と、「外部設計→内部設計」と描く流儀があり、両者はほぼ重なります。基本設計＝外部設計、詳細設計＝内部設計、と対応づけて読めば混乱しません。

ただし完全な同義ではない点に注意が必要です。会社によっては、基本設計に外部設計と一部の内部設計を含め、詳細設計をプログラム設計だけに絞ることがあります。契約書や見積書に「基本設計」とだけ書かれている場合は、そこに画面設計や外部インターフェース設計が含まれるのかを着工前に確認してください。呼び方の背景や基本設計側からの整理は基本設計とは何かで補足しています。

外部設計と内部設計の違いと、外部設計を構成する3種類の設計区分

外部設計と内部設計は、決める対象と、決める主体が異なります。ここを取り違えると、発注側がどこまで口を出すべきかの線引きがぶれます。

外部設計と内部設計の対象範囲の違いと、それぞれを主導する担当者

外部設計は利用者から見える仕様、内部設計はプログラムの内部構造を扱います。外部設計は発注者やエンドユーザーの意向を反映して固め、内部設計は開発会社のエンジニアが実装の都合で決めます。対象と主導者は次の表のとおりです。

境界がわかりやすいのは、決済や外部API連携の設計です。どのサービスと、どんな項目を、どのタイミングでやり取りするかは外部設計で決めます。一方、そのデータを内部でどのクラスに持たせるかは内部設計です。発注側は前者に責任を持ち、後者は開発会社を信頼して任せる、という役割分担になります。

外部設計に含まれる方式設計・機能設計・非機能設計という3区分

外部設計は、大きく3つの設計に分かれます。全体の作り方を決める方式設計、個々の機能を決める機能設計、性能や運用の条件を決める非機能設計です。1つに偏らせず、この3区分で漏れを点検すると設計の抜けを防げます。とくに方式設計では、システム全体の構造をシステム構成図として1枚に描き、機器や外部連携の関係を可視化します。

• 方式設計：システム全体の構成やアーキテクチャ、他システムとの連携方式、採用技術の方針を決める
• 機能設計：画面レイアウト、入力チェック、帳票、メッセージ、データの論理構造など、機能ごとの見え方と動きを決める
• 非機能設計：応答速度・同時接続数・稼働率・セキュリティ・バックアップといった、機能以外の品質条件を決める

抜けやすいのは非機能設計です。画面や帳票は目に見えるため議論されますが、「ピーク時に何人が同時に使うか」「障害時にどこまで戻せるか」は設計時に見落とされがちで、本番稼働後に性能不足として表面化します。外部設計のレビューでは、非機能の条件が数値で書かれているかを必ず確認してください。

外部設計フェーズの成果物と、外部設計書に書く項目・サンプルの型

外部設計の到達点は、外部設計書としてまとまった文書一式です。何が成果物として出てくるはずかを知っておくと、レビューで抜けを見つけられます。

外部設計書に含まれる主な成果物と、それぞれに書き込む内容の一覧

外部設計書は1冊の分厚い文書ではなく、複数の設計書の集合です。案件によって取捨はありますが、代表的な成果物は次のとおりです。上から順に、利用者に近い設計から内部寄りの設計へと並びます。

このうち発注側が最も丁寧に見るべきは、画面設計書と帳票設計書です。日々その画面を操作し、その帳票を取引先に渡すのは発注側だからです。データ設計書の論理ER図は、内部設計で物理的なテーブル定義へ落ちていきます。工程全体でどの成果物がどの段階に出るかはシステム開発の工程の成果物一覧とあわせて確認すると位置づけが明確になります。

外部設計書のサンプル項目と、画面設計書に書く項目の型と書き方

外部設計書のサンプルを探す目的の多くは、画面設計書に何を書けばよいかを知りたい、という点にあります。画面設計書は、1画面につき次の項目をそろえると実務で通用する型になります。

1. 画面ID・画面名（一覧で管理番号を振る）
2. 画面レイアウト（項目の配置とラベル）
3. 項目定義（各入力欄の桁数・必須任意・入力チェック）
4. ボタン動作（押下時の遷移先と処理）
5. 権限（どのユーザー種別に表示するか）

ひな型は書式を整えるための道具であって、目的ではありません。テンプレートの空欄を埋めることに気を取られると、肝心の入力チェックや権限の抜けを見落とします。サンプルはあくまで項目の漏れを防ぐチェックリストとして使い、中身の妥当性は業務に照らして自分で判断してください。

発注者が外部設計フェーズで承認すべき観点と、外注で破綻する条件

外部設計の知識は、開発会社の成果物を正しくレビューし、承認の判断を下すために使ってこそ意味があります。ここでは玉虫色を避け、どこを見て、どういう案件なら着工を見送るべきかを言い切ります。

発注側が外部設計のレビューで必ず確認すべき点と、承認を急ぐと起きる手戻り

外部設計書のレビューで発注側が握るべきは、業務判断が必要な箇所です。具体的には、画面に出す項目の過不足、入力チェックの条件、承認や差し戻しの業務フロー、帳票の記載項目、そして扱う金額や日付の丸め方といったルールです。これらは業務を知る側にしか正誤を判定できません。

承認を急ぐと、決まって後工程で跳ね返ります。画面設計書をよく見ずに承認し、製造が終わってから「この画面に必要な項目がない」と気づけば、設計・製造・テストをまとめてやり直すことになります。外部設計での修正なら書類の直しで済むものが、製造後には数倍の工数へと膨らむのが実情です。設計レビューに業務担当者の時間を確保することは、後工程の保険です。急いで承認印を押す前に、実際の業務でその画面と帳票が回るかを頭の中で一度動かしてください。

外部設計を外注するとき破綻する条件と、発注側が内製で握るべき判断

外部設計を丸ごと開発会社に任せて破綻するのは、発注側の業務担当が設計レビューに一度も出てこない案件です。要件定義書だけを渡し、あとは設計書が上がってくるのを待つ進め方では、業務の暗黙ルールが設計に反映されません。次の兆候が2つ以上そろう案件は、着工を見送るか設計体制を組み直すべきです。

• 外部設計の期間が全体日程の1割未満に圧縮されている
• 画面設計書のレビュー会に発注側の業務担当が招集されていない
• 非機能要件（性能・同時接続・稼働率）が数値で書かれていない

逆に、発注側が内製で握るべき判断もはっきりしています。業務フロー、画面項目、帳票のレイアウト、他システム連携で渡すデータの範囲は、開発会社に代わりに決めさせてはいけません。ここを外注に委ねると、後から「業務に合わない」が必ず出ます。設計体制に不安があるなら、要件定義から設計・製造まで一貫して伴走できる開発会社を選ぶのが結果的に安く付きます。工程全体をどう任せるかの判断はシステム開発の工程で、発注側の関与度とあわせて確認してください。

よくある質問

外部設計について、検索で多く見られる疑問に簡潔に答えます。

外部設計とは何ですか？

外部設計とは、要件定義で決めた要求を、画面・帳票・他システム連携といった利用者から見える形に落とし込む設計工程です。基本設計と呼ばれることも多く、システム開発の工程では要件定義の直後、内部設計（詳細設計）の前に位置します。利用者と発注者が確認できる範囲を決めるのが役割です。

外部設計と内部設計の違いは何ですか？

決める対象が「利用者から見えるか、見えないか」で分かれます。外部設計は画面・帳票・外部連携など見える仕様を、内部設計はクラス構造や処理ロジックなど見えない内部構造を決める工程です。外部設計は発注側の業務判断が必要で、内部設計は開発会社が主体になる、という主導者の違いもあります。

外部設計と基本設計は同じですか？

ほぼ同じ意味で使われます。多くの現場で外部設計＝基本設計、内部設計＝詳細設計と対応します。ただし会社によって基本設計の範囲に一部の内部設計を含める例もあるため、契約書に「基本設計」とある場合は画面設計や外部インターフェース設計が含まれるかを着工前に確認すると安全です。

外部設計書にはどんな成果物や項目が含まれますか？

画面設計書、帳票設計書、外部インターフェース設計書、論理ER図などのデータ設計書、バッチ処理設計書、非機能要件定義書などが含まれます。発注側がとくに丁寧に確認すべきは、日々操作する画面設計書と、取引先に渡す帳票設計書です。案件によって成果物の取捨はあります。

システムの外部設計を完了するとき、顧客が承認するのはどれですか？

顧客（発注者）が承認するのは、外部設計書一式、とくに画面設計書・帳票設計書・外部インターフェース設計書といった外部仕様を定めた成果物です。内部設計書やプログラム仕様は開発会社の領分で、発注者の承認対象には含めないのが一般的です。承認をもって次の内部設計工程へ進みます。

関連記事

• システム開発の工程：外部設計を含む7フェーズ全体の成果物と工数比率を発注者目線で俯瞰できます。
• 要件定義とは：外部設計の前工程である要件定義の進め方と成果物を確認できます。
• 基本設計とは何か：外部設計と同義で使われる基本設計を、基盤づくりの観点から補えます。