ITパスポート 2014年 秋期 問25

システムの機能や範囲を明確にするプロセスはどれか【ITパスポート 解説】

正解の理由

解法ステップ

1. 設問のキーワードを探す：今回は「業務の機能を明確に」「情報システム化の範囲とその機能を具体的に明示」。
2. 用語の意味を思い出す：
   • 要件定義：何を作るか（機能や範囲）を決める工程。
   • 外部設計：ユーザーから見える入出力や画面・帳票の設計（高レベルの設計）。
   • 内部設計：内部構造やモジュール・データ構造などの詳細設計。
   • プログラミング：設計に従ってコードを書く作業。
3. 比較して当てはまるものを選ぶ：設問は「何を作るか」を問うているため、要件定義に当てはまる。
4. 確認：設問にある「範囲の明示」「業務の機能を明確にする」は要件定義の説明と一致するかを再確認する。

選択肢別の誤答解説

• ア: 外部設計（external design：ユーザーが見る画面や外部とのやり取りを設計する工程）
  誤りの理由：外部設計は「どの画面で何を表示するか」「どの帳票を出すか」など、ユーザー視点の設計です。業務の機能そのものやシステム化の範囲を決めるのは既に決まった要件に基づいて行うため、設問の「何をシステム化するか」を決める段階とは違います。
• イ: 内部設計（detailed design：システム内部の処理やデータ構造、モジュール設計を行う工程）
  誤りの理由：内部設計は実装のための詳しい設計です。業務機能をどう分割して内部で実現するかを決めますが、「何をシステム化するか」を定義する段階ではありません。
• ウ: プログラミング（programming：設計に基づいて実際にソフトウェアのコードを書く作業）
  誤りの理由：プログラミングは最後の実装作業であり、設問にある「業務の機能を明確にし、範囲を決める」という上流工程とは異なります。
• エ: 要件定義（requirement definition：システムに求められる機能や条件を明確にする工程）
  正解の理由：設問文どおり、業務の機能を明らかにし、システム化する範囲とその機能を具体的に示すのが要件定義の仕事です。したがってここが該当します。

よくある誤解

1. 「要件定義はただ要望を聞くだけ」と思う
   • 誤りです。要件定義は要望を聞くだけでなく、業務を分析して必要な機能や優先度、制約（コスト・期間・法規など）を整理し、実現可能な範囲を決める作業です。
2. 「外部設計＝要件定義」と混同する
   • 外部設計は設計工程の一部で、客観的には「要件定義で決めた機能をどう見せるか」を具体化します。順序としては要件定義 → 外部設計です。
3. 「要件定義はIT部門だけの仕事」と思う
   • 要件定義はユーザー（業務担当者）や経営、開発側が協力して行うべきです。業務の理解がなければ適切な要件は決められません。

補足コラム

• 要件の種類：
  • 機能要件（functional requirements）：システムが「何をするか」（例：受注登録ができる）。
  • 非機能要件（non-functional requirements）：性能や信頼性、セキュリティ、法令対応など「どうあるべきか」（例：1000件/分の処理性能、24時間稼働）。
• 成果物：要件定義の結果は「要件定義書（要件仕様書）」となり、ここに機能一覧、優先順位、業務フロー、非機能要件、範囲（スコープ）などがまとめられます。
• 開発モデルとの関係：ウォーターフォールモデルでは「要件定義 → 外部設計 → 内部設計 → 実装(プログラミング) → テスト」と進みます。アジャイル開発では要件を小さく分けて反復的に決めていくことが多いです。

FAQ