最終更新日：2026年7月25日

fe fe-technology system-development

まず結論

外部設計と内部設計は、誰の視点で設計するか で切り分けます。

基本情報技術者試験では、次のように見ると判断しやすくなります。

工程 視点 決めること
外部設計 利用者・業務側から見える部分 画面、帳票、コード、論理データ、機能
内部設計 開発者・システム内部の実装 プログラム構造、物理データ、ファイル編成、レコードレイアウト

特に、論理データ設計 は外部設計で扱われることがあります。

論理データ設計
  → 必要なデータ項目を洗い出す
  → データ同士の関係や構造を決める

一方で、ファイル編成、記憶媒体、アクセス時間、容量、レコードレイアウトなどは、より実装に近いため、内部設計・物理設計寄りです。

直感的な説明

外部設計と内部設計は、家づくりで考えると分かりやすいです。

家を建てるとき、まず住む人から見える部分を決めます。

部屋の配置
玄関の位置
窓の場所
キッチンの使い方
収納の大きさ

これは、利用者から見える設計です。

システム開発でいうと、外部設計に近いです。

一方で、実際に家を建てるためには、内部の構造も決める必要があります。

柱の構造
配線の通し方
配管の配置
使う材料
施工方法

これは、作る側・実装する側の設計です。

システム開発でいうと、内部設計に近いです。

つまり、

外部設計 = 利用者からどう見えるかを決める
内部設計 = システム内部でどう作るかを決める

と考えると、初めてでもイメージしやすくなります。

定義・仕組み

外部設計は、要件定義で決めた内容をもとに、利用者から見たシステムの機能や入出力を具体化する工程です。

代表的には、次のようなものを決めます。

外部設計で扱うもの 内容
機能設計 システムが利用者に提供する機能を決める
画面設計 入力画面や表示画面の内容を決める
帳票設計 出力する帳票やレポートの形式を決める
コード設計 商品コード、社員番号などのコード体系を決める
論理データ設計 必要なデータ項目やデータ構造を決める

内部設計は、外部設計で決めた内容を、実際にプログラムとして作れるように分解する工程です。

代表的には、次のようなものを決めます。

内部設計で扱うもの 内容
プログラム構造 どのプログラムやモジュールに分けるかを決める
モジュール設計 各処理の役割や呼び出し関係を決める
物理データ設計 データをどのように保存・配置するかを決める
ファイル設計 ファイル編成、媒体、アクセス方法などを決める
レコード設計 レコードレイアウトや項目の物理配置を決める

ここで大切なのは、論理 と 物理 の違いです。

種類 見るポイント
論理データ設計 何のデータが必要か、データ同士がどう関係するか
物理データ設計 どの媒体に、どの形式で、どれくらいの容量で保存するか

論理データ設計は、業務で必要なデータを整理する段階です。

物理データ設計は、それを実際にコンピュータ上でどう持つかを決める段階です。

このテーマは、基本情報技術者試験の「システム開発技術」と関係する内容です。公式の出題範囲やシラバスは、IPA：基本情報技術者試験 から確認できます。

科目Aでどう出る？

科目Aでは、外部設計・内部設計・論理データ設計・物理データ設計の作業内容を選ぶ問題が出やすいです。

判断するときは、説明文が 利用者から見える内容 なのか、実装のための内部的な内容 なのかを見ます。

説明の中心 対応する工程
データ項目の洗い出し 外部設計・論理データ設計
データ構造の決定 外部設計・論理データ設計
画面や帳票の設計 外部設計
コード体系の決定 外部設計
データファイル編成の決定 内部設計・物理データ設計
媒体の決定 内部設計・物理データ設計
アクセス時間や容量の見積り 内部設計・物理データ設計
レコードレイアウトの決定 内部設計・物理設計寄り

特に、次の切り分けはよく使えます。

データ項目を洗い出す
データ同士の構造を決める
  → 論理データ設計

ファイル編成を決める
媒体や容量を決める
アクセス時間を見積もる
  → 物理データ設計・内部設計

「論理」とある場合は、まず 業務上どんなデータが必要か を考えます。

「物理」とある場合は、コンピュータ上でどう保存するか を考えます。

どんな場面で使う？

問題文では、外部設計と内部設計という用語を直接選ぶより、開発工程の流れや設計書の内容を読む場面で役立ちます。

例えば、次のような流れです。

要件定義
  ↓
外部設計
  ↓
内部設計
  ↓
プログラミング
  ↓
テスト

外部設計では、利用者と確認しやすい内容を具体化します。

どんな画面が必要か
どんな帳票を出すか
どんなデータ項目を扱うか
どんな機能を提供するか

内部設計では、開発者が実装できるように、システム内部の構造へ落とし込みます。

どのプログラムに分けるか
どのファイルに保存するか
どのようなレコード構造にするか
どのようにアクセスするか

長文問題で読むときは、次の視点が役立ちます。

1. 利用者に見える内容か
2. 開発者が実装するための内容か
3. データの意味や関係を決めているか
4. データの保存方法や性能を決めているか

利用者と確認する内容なら外部設計寄り、プログラムやファイルの作り方なら内部設計寄りです。

よくある誤解・混同

誤解1：外部設計を「社外向けの設計」だと思う

外部設計の「外部」は、会社の外という意味ではありません。

ここでの外部は、システムの外側から見た設計 という意味です。

つまり、利用者から見える機能、画面、帳票、データなどを決める工程です。

外部設計 = 利用者から見える部分の設計

誤解2：内部設計を「重要な設計」とだけ覚える

内部設計は、単に重要な設計という意味ではありません。

外部設計で決めた内容を、実際に作れるようにシステム内部へ落とし込む工程です。

内部設計 = 開発者が実装するための設計

プログラム構造、モジュール分割、ファイル編成、レコード構造などが中心になります。

誤解3：論理データ設計と物理データ設計を混同する

論理データ設計と物理データ設計は、名前が似ているため混同しやすいです。

設計 判断の合図
論理データ設計 データ項目、データ構造、データ同士の関係
物理データ設計 ファイル、媒体、容量、アクセス時間、レコードレイアウト

論理データ設計は、業務で必要なデータを整理します。

物理データ設計は、それをコンピュータ上でどう保存するかを決めます。

誤解4：レコードレイアウトを論理データ設計だと思う

レコードレイアウトは、データをファイルやデータベース上でどのように並べるかという、実装に近い話です。

そのため、外部設計の論理データ設計というより、内部設計・物理設計寄りに考えます。

データ項目の洗い出し
  → 論理データ設計

レコードレイアウトの決定
  → 内部設計・物理設計寄り

誤解5：容量見積りを論理データ設計だと思う

容量見積りは、データを実際に保存するときの量や性能を考える話です。

そのため、物理データ設計や内部設計寄りです。

どんなデータが必要か
  → 論理

どれくらいの容量が必要か
  → 物理

まとめ（試験直前用）

  • 外部設計は、利用者から見える機能・画面・帳票・論理データを決める
  • 内部設計は、開発者が実装するためのプログラム構造や物理データを決める
  • データ項目の洗い出し・データ構造の決定 は論理データ設計
  • ファイル編成・媒体・容量・アクセス時間 は物理データ設計寄り
  • 「外部」は社外ではなく、システムの外側から見えるという意味

© 2024-2026 stemtazoo. All rights reserved.