要件定義から外部設計・内部設計へ
要件定義・外部設計・内部設計・ソフトウェア方式設計で「誰が何を決めるか」を区別し、成果物や作業内容を問う選択肢を見分けられるようになる。インタビューの留意点とトレーサビリティの意味も答えられるようになる。
試験では「この作業・成果物はどの工程のものか」という仕分け問題が、選択肢の言い回しだけを変えて何度も出ます。実務でも、顧客に承認をもらう範囲と開発側で決める範囲を分けておくことが、手戻りを防ぐ基本になります。
このレッスンで稽古する（用語チェック・過去問）結論：工程は「何を作るか」→「どう見えるか」→「どう作るか」の順
システム開発の上流工程は、要件定義（何を作るかを決める）→外部設計（利用者から見た姿を決める）→内部設計（開発者がどう実現するかを決める） の順に進みます。工程が後になるほど利用者の視点から離れ、コンピュータ側の視点に近づきます。試験問題の多くは、この順番と視点の違いさえ押さえれば解けます。
flowchart LR
A["要件定義：何を作るか"] --> B["外部設計：利用者から見える姿"] --> C["内部設計：どう実現するか"] --> D["プログラム設計"] --> E["プログラム開発"] --> F["テスト"] --> G["運用・保守"]
たとえ（注文住宅）：要件定義は「4人家族で、在宅勤務の部屋がほしい」という要望の整理にあたります。外部設計は施主に見せてサインをもらう間取り図や外観図、内部設計は施主が見ない配管・配線・構造計算です。
要求分析のインタビュー：事実と推測を分けて聞く
要求分析（利用者の困りごとや要望を聞き出して整理する作業）では、回答が事実なのか、相手の推測なのかを区別して記録するのが正解です。「月に100件くらいだと思う」は推測なので、実績データで確認する必要があります。
誤りの選択肢は、次のような言い切りで作られています。
- 対象者を「現場の担当者に限る」→ 管理者など、立場の違う人にも聞くべきです
- 質問用紙の事前配布を「避ける」→ 事前に渡すと相手が準備でき、むしろ有効です
- 質問を「はい／いいえで答えられるものに限る」→ 自由に話してもらう質問も必要です
機能要件と非機能要件：画面レイアウトは機能要件
要件は「何ができるか」を表す機能要件と、「どれくらいの品質で動くか」を表す非機能要件に分かれます。機能要件定義の成果物の代表例は画面レイアウトです。
| 区分 | 決めること | 例 |
|---|---|---|
| 機能要件 | 利用者が使う機能そのもの | 画面レイアウト、帳票、入力・出力する項目、処理内容 |
| 非機能要件 | 性能・信頼性・運用面などの品質 | 応答時間、稼働率、セキュリティ、災害対応策、移行手順 |
| （別工程の事項） | 作り方の方針 | システム開発方式 |
移行手順・災害対応策・開発方式は、いずれも機能要件の成果物ではありません。
外部設計と内部設計の違い（最頻出の仕分け）
外部設計は利用者の視点で、内部設計は開発者（コンピュータ）の視点で行う設計です。外部設計の成果物は利用者が見て確認できるので、外部設計を終えるときには画面レイアウトなどについて顧客の承認を受けます。内部設計の成果物は技術的な内容なので、顧客の承認対象にはなりません。
| 観点 | 外部設計 | 内部設計 |
|---|---|---|
| 視点 | 利用者側から見た設計 | 開発者（コンピュータ）側から見た設計 |
| 主な作業 | 画面設計、帳票設計、コード設計、外部とのインタフェース設計 | プログラムへの分割、処理方式・チェック方式の決定 |
| データの扱い | データ項目を洗い出し、論理データ構造を決める | 物理データ構造（実際の格納方法）を決める |
| 顧客の承認 | 受ける（画面レイアウトなど） | 原則受けない |
| 間違えやすい成果物 | — | 物理データベース仕様、プログラムの流れ図 |
- 業務分析は外部設計より前の、要件定義の作業です
- システム開発計画は設計より前の、計画段階の成果物です
- システムを複数のプログラムに分割する作業は内部設計で行います（外部設計ではありません）
論理データ構造は「どんなデータ項目を、どのような関係で持つか」という利用者側から見た形を指します。物理データ構造は「ディスク上にどう格納し、どうアクセスするか」という実装寄りの形を指します。
利用部門が深く関わる工程は「最初と最後」
システムを使う部署（利用部門）が深く関与すべき工程は、基本計画・外部設計・テスト・運用保守です。要件を決める段階、自分たちが見る画面を決める段階、実際に使えるかを確かめる段階、使い続ける段階、と覚えます。内部設計・プログラム設計・プログラム開発は開発側の技術的な工程なので、利用部門は深くは関わりません。
ソフトウェア方式設計：要件を「構造」に変換する工程
ソフトウェア方式設計は、決定済みのソフトウェア要件を「どう実現するか」の最上位の構造に変換し、ソフトウェアを構成する部品（ソフトウェアコンポーネント）を識別する工程です。おおむね、従来の呼び方の「内部設計」にあたります。顧客と仕様を決める工程ではなく、1行単位まで詳しく決める工程でもありません。
開発プロセスの流れ（共通フレームや JIS X 0160 の呼び方）の中での位置づけは次のとおりです。
| プロセス | 何をするか | 選択肢での言い回し |
|---|---|---|
| ソフトウェア要件定義 | ソフトウェアに求めることを決める | 「顧客に意見を求めて仕様を決定」「要求内容を図表にまとめ段階的に詳細化して分析」 |
| ソフトウェア方式設計 | 要件を最上位の構造に変換し、コンポーネントを識別する | 「最上位レベルの構造」「コンポーネントを識別」「要件をどう実現させるか決める」 |
| ソフトウェア詳細設計 | コンポーネントの中身を、コーディングできるところまで詳しくする | 「1行の処理まで明確になるよう詳細化」 |
| ソフトウェア構築 | コーディングと単体テスト | 「プログラムを作成する」 |
| ソフトウェア結合 | コンポーネントを組み合わせてテストする | 「結合してテストする」 |
ソフトウェア方式設計で行う具体的なタスクには、次のものがあります。タスクの一覧を見せて「どのプロセスか」を問う形式でも出題されます。
- 外部インタフェースと、コンポーネント間のインタフェースの最上位レベルの設計
- データベースの最上位レベルの設計
- ソフトウェア結合のための暫定的なテスト要求事項とスケジュールの定義
タスクの文中に「最上位レベル」とあれば、方式設計だと判断できます。詳細設計は「最上位」ではなく「詳細」、結合プロセスは「暫定的に定義する」側ではなく実際に結合する側です。
トレーサビリティ：要件を後から追跡できること
トレーサビリティ（追跡可能性）は、定義した要件や変更要求が、設計・実装・テストのどこにどう反映されたかを後からたどれる性質です。荷物の追跡番号から配送の経過を確認できるのと同じイメージです。
| 用語 | 意味 |
|---|---|
| トレーサビリティ | 要件から実装までの経過を追跡できること |
| インターオペラビリティ | 異なるシステム同士が連携して動けること（相互運用性） |
| ユーザビリティ | 利用者にとっての使いやすさ |
| セキュリティ | 不正アクセスなどから情報を守ること |
問題文に「経過を明らかにできる」「追跡」とあれば、トレーサビリティを選びます。
試験での問われ方
- 工程の仕分け：「外部設計で承認を受けるもの」「外部設計の作業」を問い、内部設計の成果物（物理DB仕様・流れ図・プログラム設計）や要件定義の作業（業務分析）を混ぜてきます
- 視点の逆転：「外部設計はコンピュータ側から見た設計」のように、利用者側とコンピュータ側を入れ替えた誤文が出ます
- 方式設計の言い換え：同じ問題が「最上位レベルの構造に変換」と「要件をどう実現させるか決める」の2通りの言い回しで出ます
- 極端な断定：インタビューの問題は、「限る」「避ける」と言い切った選択肢がほぼ不正解です
要点（試験直前に読む）
- 外部設計は利用者視点（画面・帳票・論理データ構造）、内部設計は開発者視点（プログラム分割・物理データ構造・処理方式）。
- 外部設計を終えるときに顧客から承認を受けるのは画面レイアウト。物理DB仕様・流れ図・開発計画は承認対象ではない。
- ソフトウェア方式設計は、要件を最上位の構造に変換してコンポーネントを識別する工程。インタフェースやDBの「最上位レベルの設計」もここで行う。
- 利用部門が深く関わるのは、基本計画・外部設計・テスト・運用保守。
- 機能要件定義の成果物は画面レイアウト。移行手順や災害対応策は非機能要件の事項。
- インタビューでは事実と推測を区別する。トレーサビリティは要件から実装までの経過を追跡できること。
ひっかけ
- 「外部設計はコンピュータ側から見た設計」のように視点を入れ替えた文 → 外部＝利用者、内部＝コンピュータに戻して判定する。
- 外部設計の作業として「業務分析」「物理データ設計」「プログラム設計」が並ぶ → 業務分析は要件定義、残りの2つは内部設計なので、正解は帳票設計や画面設計。
- 方式設計の問題で「顧客に意見を求めて仕様を決定」「1行の処理まで詳細化」が並ぶ → 前者は要件定義、後者は詳細設計。正解は「最上位の構造」「どう実現させるか」。
- インタビューで「担当者に限る」「事前配布を避ける」「はい／いいえに限る」 → 言い切った選択肢は誤り。事実と推測の区別が正解。
- トレーサビリティの問題でインターオペラビリティ・ユーザビリティが並ぶ → 「経過を明らかにする・追跡」とあればトレーサビリティ。
用語（18）
システムで何を実現するかを、利用者と合意して文書にまとめる工程。
⚠ 外部設計は、決まった要件を画面や帳票などの見える形に落とし込む次の工程。
インタビューなどで利用者の要望や課題を集め、整理する作業。
画面・帳票・処理内容など、システムが何をできるかを定めた要件。
⚠ 非機能要件は性能や信頼性などの品質面。災害対応策や移行手順はこちら。
応答時間・稼働率・セキュリティ・運用・移行など、機能以外の品質を定めた要件。
⚠ 機能要件は「何ができるか」。画面レイアウトは機能要件の成果物。
画面・帳票・コード・論理データ構造など、利用者から見える仕様を決める設計工程。
⚠ 内部設計はコンピュータ側の視点。顧客の承認を受けるのは外部設計の成果物。
外部設計の内容をどう実現するかを、プログラム分割・物理データ構造・処理方式などの形で決める工程。
⚠ 外部設計と視点が逆。「プログラムに分割」はこちらの作業。
プログラムの内部構造や処理手順を、コーディングできる粒度まで決める工程。
⚠ 外部設計の作業ではない。流れ図はこの工程の成果物。
画面上の項目の配置や表示内容を決めたもので、利用者が確認できる代表的な成果物。
⚠ 物理データベース仕様は内部設計の成果物で、顧客の承認対象ではない。
請求書や一覧表など、出力する書類の項目と書式を決める外部設計の作業。
⚠ 物理データ設計・プログラム設計は内部設計の作業。
どんなデータ項目をどのような関係で持つかを、格納方法を考えずに表した構造。
⚠ 物理データ構造は実際の格納方法。論理は外部設計、物理は内部設計で決める。
データを記憶装置にどう格納し、どうアクセスするかまで決めた構造。
⚠ 論理データ構造（外部設計）と取り違えない。物理は内部設計。
ソフトウェア要件を最上位の構造に変換し、構成要素（コンポーネント）とそのインタフェースを決めるプロセス。
⚠ 要件定義は仕様を決める工程、詳細設計は1行単位まで詳しくする工程。「最上位レベル」とあれば方式設計。
各コンポーネントの中身を、コーディングできる細かさまで決めるプロセス。
⚠ 方式設計は全体の構造と部品分けまで。詳細設計はその部品の内部を決める。
ソフトウェアを構成する、ひとまとまりの機能を持った部品。
作成したコンポーネントを組み合わせ、正しく連携するかをテストするプロセス。
⚠ 結合テストの暫定的な要求事項を定義するのは、前の工程である方式設計。
要件や変更要求が設計・実装・テストにどう反映されたかを、後からたどれる性質。
⚠ インターオペラビリティは相互運用性、ユーザビリティは使いやすさ。「経過を追える」はトレーサビリティ。
異なるシステムや製品同士がデータをやり取りして一緒に動ける性質。
⚠ トレーサビリティ（追跡できること）と名前の響きが似ているので注意。
利用者が目的を、迷わず効率よく満足して達成できる使いやすさ。
⚠ トレーサビリティとは無関係の品質特性。
このレッスンの過去問
- 要求分析のインタビュー実施上の留意点基本情報技術者試験 科目A免除 修了試験 20220123 実施分 問45
- 機能要件定義の成果物(画面レイアウト)基本情報技術者試験 科目A免除 修了試験 201001 実施分 問64
- システム開発工程における利用部門の関与基本情報技術者試験 科目A免除 修了試験 200907 実施分 問53
- 外部設計の成果物と承認対象平成29年度 春期 基本情報技術者試験 午前 問46
- 外部設計と内部設計の作業内容の違い基本情報技術者試験 科目A免除 修了試験 20130127 実施分 問52
- ソフトウェア方式設計で行う作業平成30年度 春期 基本情報技術者試験 午前 問47
- トレーサビリティの定義平成22年度 秋期 基本情報技術者試験 午前 問65