最終更新日:2026年9月10日
fe fe-technology system-development
まず結論
外部設計と内部設計は、誰の視点で設計するか で切り分けます。
基本情報技術者試験では、次のように見ると判断しやすくなります。
| 工程 | 視点 | 決めること |
|---|---|---|
| 企画・計画 | 開発全体 | 開発方針、体制、日程、費用など |
| 外部設計 | 利用者・業務側から見える部分 | 画面、帳票、コード、論理データ、機能 |
| 内部設計 | 開発者・システム内部の実装 | プログラム構造、物理データ、ファイル編成、レコードレイアウト |
| プログラム設計 | 個々のプログラム内部 | 処理手順、アルゴリズム、流れ図など |
特に、論理データ設計 は外部設計で扱われることがあります。
論理データ設計
→ 必要なデータ項目を洗い出す
→ データ同士の関係や構造を決める
一方で、ファイル編成、記憶媒体、アクセス時間、容量、レコードレイアウトなどは、より実装に近いため、内部設計・物理設計寄りです。
試験では、次の対応を覚えておくと選択肢を切りやすくなります。
画面・帳票
→ 外部設計
物理データベース仕様
→ 内部設計
プログラム流れ図
→ プログラム設計
システム開発計画
→ 企画・計画
直感的な説明
外部設計と内部設計は、家づくりで考えると分かりやすいです。
家を建てるとき、まず住む人から見える部分を決めます。
部屋の配置
玄関の位置
窓の場所
キッチンの使い方
収納の大きさ
これは、利用者から見える設計です。
システム開発でいうと、外部設計に近いです。
一方で、実際に家を建てるためには、内部の構造も決める必要があります。
柱の構造
配線の通し方
配管の配置
使う材料
施工方法
これは、作る側・実装する側の設計です。
システム開発でいうと、内部設計に近いです。
さらに、個々の作業手順まで具体化する段階がプログラム設計に相当します。
つまり、
外部設計 = 利用者からどう見えるかを決める
内部設計 = システム内部でどう作るかを決める
プログラム設計 = 個々の処理をどう進めるかを決める
と考えると、初めてでもイメージしやすくなります。
定義・仕組み
外部設計は、要件定義で決めた内容をもとに、利用者から見たシステムの機能や入出力を具体化する工程です。
代表的には、次のようなものを決めます。
| 外部設計で扱うもの | 内容 |
|---|---|
| 機能設計 | システムが利用者に提供する機能を決める |
| 画面設計 | 入力画面や表示画面の内容を決める |
| 帳票設計 | 出力する帳票やレポートの形式を決める |
| コード設計 | 商品コード、社員番号などのコード体系を決める |
| 論理データ設計 | 必要なデータ項目やデータ構造を決める |
内部設計は、外部設計で決めた内容を、実際にプログラムとして作れるように分解する工程です。
代表的には、次のようなものを決めます。
| 内部設計で扱うもの | 内容 |
|---|---|
| プログラム構造 | どのプログラムやモジュールに分けるかを決める |
| モジュール設計 | 各処理の役割や呼び出し関係を決める |
| 物理データ設計 | データをどのように保存・配置するかを決める |
| ファイル設計 | ファイル編成、媒体、アクセス方法などを決める |
| レコード設計 | レコードレイアウトや項目の物理配置を決める |
プログラム設計では、内部設計で分けられたプログラムやモジュールについて、さらに具体的な処理手順を決めます。
どの順番で処理するか
どこで条件分岐するか
どの処理を繰り返すか
このような内容を流れ図や疑似言語などで具体化する段階です。
ここで大切なのは、論理 と 物理 の違いです。
| 種類 | 見るポイント |
|---|---|
| 論理データ設計 | 何のデータが必要か、データ同士がどう関係するか |
| 物理データ設計 | どの媒体に、どの形式で、どれくらいの容量で保存するか |
論理データ設計は、業務で必要なデータを整理する段階です。
物理データ設計は、それを実際にコンピュータ上でどう持つかを決める段階です。
このテーマは、基本情報技術者試験の「システム開発技術」と関係する内容です。公式の出題範囲やシラバスは、IPA:基本情報技術者試験 から確認できます。
科目Aでどう出る?
科目Aでは、外部設計・内部設計・論理データ設計・物理データ設計・プログラム設計の作業内容を選ぶ問題が出やすいです。
判断するときは、説明文が 利用者から見える内容 なのか、実装のための内部的な内容 なのか、個々のプログラムの処理手順 なのかを見ます。
| 説明の中心 | 対応する工程 |
|---|---|
| 開発方針、体制、日程など | 企画・計画 |
| データ項目の洗い出し | 外部設計・論理データ設計 |
| データ構造の決定 | 外部設計・論理データ設計 |
| 画面や帳票の設計 | 外部設計 |
| コード体系の決定 | 外部設計 |
| データファイル編成の決定 | 内部設計・物理データ設計 |
| 物理データベース仕様 | 内部設計・物理データ設計 |
| 媒体の決定 | 内部設計・物理データ設計 |
| アクセス時間や容量の見積り | 内部設計・物理データ設計 |
| レコードレイアウトの決定 | 内部設計・物理設計寄り |
| プログラムの処理手順・流れ図 | プログラム設計 |
特に、次の切り分けはよく使えます。
データ項目を洗い出す
データ同士の構造を決める
→ 論理データ設計
ファイル編成を決める
媒体や容量を決める
アクセス時間を見積もる
→ 物理データ設計・内部設計
処理手順や分岐を決める
→ プログラム設計
「論理」とある場合は、まず 業務上どんなデータが必要か を考えます。
「物理」とある場合は、コンピュータ上でどう保存するか を考えます。
「流れ図」「処理手順」なら、個々のプログラムを具体化するプログラム設計を考えます。
どんな場面で使う?
問題文では、外部設計と内部設計という用語を直接選ぶより、開発工程の流れや設計書の内容を読む場面で役立ちます。
例えば、次のような流れです。
企画・計画
↓
要件定義
↓
外部設計
↓
内部設計
↓
プログラム設計
↓
プログラミング
↓
テスト
外部設計では、利用者と確認しやすい内容を具体化します。
どんな画面が必要か
どんな帳票を出すか
どんなデータ項目を扱うか
どんな機能を提供するか
内部設計では、開発者が実装できるように、システム内部の構造へ落とし込みます。
どのプログラムに分けるか
どのファイルに保存するか
どのようなレコード構造にするか
どのようにアクセスするか
プログラム設計では、さらに個々の処理へ落とし込みます。
どの順序で処理するか
どこで分岐するか
どこで繰り返すか
長文問題で読むときは、次の視点が役立ちます。
1. 利用者に見える内容か
2. 開発者が実装するための内容か
3. 個々のプログラムの処理手順か
4. データの意味や関係を決めているか
5. データの保存方法や性能を決めているか
利用者と確認する内容なら外部設計寄り、プログラムやファイルの作り方なら内部設計寄り、具体的な処理の流れならプログラム設計です。
よくある誤解・混同
誤解1:外部設計を「社外向けの設計」だと思う
外部設計の「外部」は、会社の外という意味ではありません。
ここでの外部は、システムの外側から見た設計 という意味です。
つまり、利用者から見える機能、画面、帳票、データなどを決める工程です。
外部設計 = 利用者から見える部分の設計
誤解2:内部設計を「重要な設計」とだけ覚える
内部設計は、単に重要な設計という意味ではありません。
外部設計で決めた内容を、実際に作れるようにシステム内部へ落とし込む工程です。
内部設計 = 開発者が実装するための設計
プログラム構造、モジュール分割、ファイル編成、レコード構造などが中心になります。
誤解3:論理データ設計と物理データ設計を混同する
論理データ設計と物理データ設計は、名前が似ているため混同しやすいです。
| 設計 | 判断の合図 |
|---|---|
| 論理データ設計 | データ項目、データ構造、データ同士の関係 |
| 物理データ設計 | ファイル、媒体、容量、アクセス時間、レコードレイアウト |
論理データ設計は、業務で必要なデータを整理します。
物理データ設計は、それをコンピュータ上でどう保存するかを決めます。
誤解4:レコードレイアウトを論理データ設計だと思う
レコードレイアウトは、データをファイルやデータベース上でどのように並べるかという、実装に近い話です。
そのため、外部設計の論理データ設計というより、内部設計・物理設計寄りに考えます。
データ項目の洗い出し
→ 論理データ設計
レコードレイアウトの決定
→ 内部設計・物理設計寄り
誤解5:容量見積りを論理データ設計だと思う
容量見積りは、データを実際に保存するときの量や性能を考える話です。
そのため、物理データ設計や内部設計寄りです。
どんなデータが必要か
→ 論理
どれくらいの容量が必要か
→ 物理
誤解6:外部設計とプログラム設計を混同する
外部設計でもプログラム設計でも「設計」という言葉が出てくるため、工程名だけでは迷いやすいです。
判断するときは、成果物を見ます。
画面レイアウト
→ 利用者が見る
→ 外部設計
プログラム流れ図
→ プログラム内部の処理手順
→ プログラム設計
画面に何を表示するか と プログラムがどう処理するか を分けて考えるのがポイントです。
誤解7:システム開発計画を設計工程だと思う
システム開発計画は、個々の画面やプログラムを設計するための成果物ではありません。
開発全体の方針、体制、日程、費用などを決める、より上流の企画・計画段階の内容です。
開発全体をどう進めるか
→ 企画・計画
利用者にどう見せるか
→ 外部設計
内部でどう実現するか
→ 内部設計
個々の処理をどう進めるか
→ プログラム設計
まとめ(試験直前用)
- 外部設計は、利用者から見える機能・画面・帳票・論理データを決める
- 内部設計は、開発者が実装するためのプログラム構造や物理データを決める
- プログラム設計は、個々のプログラムの処理手順や流れ図を決める
- 画面レイアウト → 外部設計、物理データベース仕様 → 内部設計、プログラム流れ図 → プログラム設計
- システム開発計画は、外部設計より前の企画・計画段階
- 「外部」は社外ではなく、システムの外側から見えるという意味