対象試験と出題頻度
外部設計（基本設計）は、ITパスポート・基本情報技術者・応用情報技術者の3区分すべてで出題される、開発工程の中核テーマです。
「要件定義との境界」「内部設計との違い」「成果物の種類」が定番の問われ方で、ソフトウェアライフサイクルプロセスと絡めた工程順序の問題でも頻出します。
詳細をクリックして確認
ITパスポート
基本情報技術者
応用情報技術者
★★★★☆
ランクA（重要）必ず覚えておくべき
用語の定義
情報処理試験を勉強していると、「外部設計と基本設計って同じ？要件定義や内部設計とどこで線を引くの？」と混乱しがちです。
外部設計（External Design / 基本設計）とは、一言で言うと
「要件定義の内容を受けて、利用者から見えるシステムの「外観」を決める工程」
のことです。
イメージとしては、「注文住宅の間取り図づくり」です。
施主（ユーザー）と建築士（設計者）が「玄関の位置」「部屋の数」「窓の大きさ」など、住む人から見える部分を決めていきます。柱の太さや配管の経路といった裏側の話はまだ出てきません。
外部設計でも同じく、画面・帳票・データの並びなど「ユーザーが触れる部分」だけを先に固めます。
プログラム内部の構造は次工程の内部設計（詳細設計）で扱います。
📊 外部設計（基本設計）の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | External Design（基本設計：Basic Design） |
| 共通フレームでの位置づけ | ソフトウェア方式設計に相当 |
| 視点 | ユーザー視点（利用者から見える部分） |
| 主な成果物 | 画面設計書、帳票設計書、論理データ設計書、外部インタフェース仕様書 |
| 前後の工程 | 前：要件定義／後：内部設計（詳細設計） |
解説
ウォーターフォールモデルで開発を進める場合、要件定義で「何を作るか」が固まったあと、いきなりコードを書き始めるわけにはいきません。
利用者と開発者の間で「どんな画面が出るのか」「どんな帳票が印刷されるのか」を合意しないと、後戻りの規模が大きくなるからです。
そこで、要件定義と実装の間に「ユーザー視点の設計」と「開発者視点の設計」を分けて挟み込む構造が一般化しました。
前者が外部設計、後者が内部設計です。
開発工程における位置づけ
工程の流れを図にすると、外部設計が「ユーザーと開発者の橋渡し役」であることが明確になります。
開発工程と視点の切り替わり
① 要件定義
何を作るか
② 外部設計
（基本設計）
外観を決める
③ 内部設計
（詳細設計）
中身を決める
④ 実装
コードを書く
⑤ テスト
検証する
外部設計の主な作業と成果物
外部設計で行う作業は、大きく4つに分けて整理すると覚えやすいです。
| 作業区分 | 具体的な内容 |
|---|---|
| 画面・帳票設計 | 画面レイアウト、画面遷移、操作方法、帳票の項目・書式を決める |
| 論理データ設計 | データ項目を洗い出し、エンティティ・属性・関連を整理する（論理データ構造） |
| 外部インタフェース設計 | 他システムとのデータ接続仕様、ファイル連携方式、API仕様を決める |
| サブシステム分割 | システム全体をいくつかのサブシステムに分割し、機能配置を決める |
これらの工程が完了したタイミングで、利用者部門の責任者から成果物の承認を受けるのが原則です。
（経験上、どうでもよいことで返却されることが多い…）
承認されるのは「画面レイアウト」のような利用者から見える成果物であり、内部設計の成果物（物理データベース仕様など）は対象外です。
外部設計と内部設計の対比
| 観点 | 外部設計（基本設計） | 内部設計（詳細設計） |
|---|---|---|
| 視点 | 利用者の立場 | 開発者の立場 |
| データ設計 | 論理データ構造を決定 | 物理データベース仕様を決定 |
| 機能分割 | サブシステムへ分割 | プログラム単位・モジュールへ分割 |
| 主な成果物 | 画面設計書／帳票設計書／論理ER図 | モジュール仕様書／物理ER図／プログラム構造図 |
では、この工程が試験でどのように出題されるか見ていきましょう。
💡 外部設計の核心を3行で
・要件定義の内容を受け、ユーザーから見える部分（画面・帳票・論理データ・外部I/F）を決める工程
・共通フレームでは「ソフトウェア方式設計」に相当する位置づけ
・成果物は利用者部門の承認を経て、次の内部設計（詳細設計）へ引き継がれる
試験ではこう出る！
外部設計はFE・APの午前で、開発工程のどこに何が入るかを問う形式で繰り返し出題されています。出題パターンは大きく3つに分かれます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE H24秋 問50 |
外部設計を完了させるとき、承認を受けるものを選ぶ問題。 | ・正解は「画面レイアウト」 ・「物理データベース仕様」「モジュール構造」は内部設計の成果物でひっかけ |
| FE H19春 問40 |
外部設計と内部設計の説明として正しいものを選ぶ問題。 | ・「外部設計＝論理データ構造／内部設計＝物理データベース」が正解の組み合わせ |
| FE H17春 問42 |
「システム開発者の立場で進める設計」を選ぶ問題。 | ・正解は内部設計 ・外部設計が「利用者の立場」であることが対比で問われる |
| AP H23秋 問44 |
内部設計書のデザインレビューの目的を問う問題。 | ・正解は「外部設計書との一貫性の検証と要件定義の内容を満たしていることの確認」 |
📝 IPA試験での出題パターン
パターン1：「成果物の振り分け」
FE H24秋のように、複数の成果物の中から外部設計工程のものを選ばせる形式。「画面レイアウト・帳票仕様・論理データ構造」は外部設計、「物理データベース仕様・モジュール構造図」は内部設計と二択で覚えてください。
パターン2：「視点の対比」
「利用者の立場で行う設計はどれか」「開発者の立場で行う設計はどれか」と聞かれます。利用者＝外部、開発者＝内部の対応を反射的に答えられるようにしておくのがポイントです。
パターン3：「工程順序・レビュー」
AP H23秋のように、「内部設計レビューでは外部設計書との一貫性を確認する」といった上流工程との整合性が問われます。後工程は前工程の内容を満たしているかを必ず確認する、という前後関係を押さえれば解けます。
なお共通フレーム上は「ソフトウェア方式設計」「ソフトウェア詳細設計」という名称で出ることもあります。外部設計＝ソフトウェア方式設計、内部設計＝ソフトウェア詳細設計の読み替えだけ押さえておけば、試験ではここまででOKです。深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ソフトウェア開発における「外部設計（基本設計）」の説明として、最も適切なものはどれでしょうか？
- A. プログラムをモジュールに分割し、各モジュールの内部処理ロジックや物理データベースの仕様を決定する工程である。
- B. 利用者の業務上の要求や課題を整理し、システム化の対象範囲と必要な機能を洗い出す工程である。
- C. 要件定義を踏まえ、利用者の立場から画面レイアウト・帳票・論理データ構造・外部インタフェースなど「見える部分」を設計する工程である。
正解と解説を見る
正解：C
解説：
外部設計（基本設計）は、要件定義の成果を引き継ぎ、利用者の立場から見える要素（画面・帳票・論理データ・外部インタフェース）を決める工程です。利用者部門の承認を受けて初めて完了し、次の内部設計に引き継がれます。
選択肢Aは内部設計（詳細設計）の説明です。モジュール分割や物理DB仕様の決定は開発者視点の作業であり、外部設計ではなく後工程に分類されます。選択肢Bは要件定義の説明です。システム化の対象範囲や必要機能の洗い出しは外部設計より前の工程で行われ、その成果を踏まえて外部設計が始まります。
よくある質問（FAQ）
Q. 「外部設計」と「基本設計」は完全に同じ意味ですか？
IPA試験ではほぼ同義として扱われます。教科書的には「外部設計＝ユーザー視点の設計」、企業の現場では「基本設計」と呼ぶケースが多い、という慣習の違いです。共通フレームでは「ソフトウェア方式設計」という第三の呼び方もあります。試験で問題文に「基本設計」と書かれていたら、外部設計と読み替えて解いて差し支えありません。
Q. アジャイル開発でも外部設計はありますか？
アジャイル開発では「外部設計フェーズ」という独立した工程は持ちません。スプリントごとに小さな単位で要件・設計・実装・テストを繰り返すため、画面設計や論理データ設計はユーザーストーリーの実装と並行して行われます。ただし「ユーザーから見える部分を先に合意してから内部実装に入る」という発想自体は共通で、ペーパープロトタイピングなどで代替されることが多いです。
Q. 外部設計の成果物レビューには誰が参加しますか？
利用者部門の責任者・業務担当者・プロジェクトマネージャ・設計担当者が中心です。利用者から見える部分を確定する工程のため、実際にシステムを使う業務担当者の参加が欠かせません。実装者（プログラマ）は通常この段階では中心的な役割を持たず、内部設計レビューから本格的に関与します。
Q. 非機能要件（性能・セキュリティなど）は外部設計で扱いますか？
扱う部分と扱わない部分があります。応答時間の目標値や同時接続ユーザー数の上限といった「ユーザーが体感する性能」は外部設計で具体化します。一方、それを実現するためのキャッシュ戦略やDBインデックス設計は内部設計の領域です。「ユーザーが見える形で約束する数値」が外部設計、「その数値を裏で実現する仕組み」が内部設計、と切り分けると整理しやすいです。
