ITパスポート 2009年 春期 問25

システム開発における要件定義プロセス【ITパスポート 解説】

正解の理由

• 要件定義：これから実現すべき要求や条件を整理・文書化し、関係者の合意を得る工程。
• 利害関係者（ステークホルダー）：プロジェクトの成果や進め方に影響を受ける人や組織（例：業務担当者、経営、ユーザー、ベンダーなど）。

解法ステップ

1. 問題文で「要件定義プロセス」を探す。要件定義は「何を作るか（機能・範囲）を決め、合意する」工程であると覚える。
2. 各選択肢のキーワードを確認する。例えば「合意」「範囲と機能を明確に」など要件定義に当てはまる語があるかを見る。
3. 要件定義と似た工程（企画、設計、実装、テスト）を区別する。各選択肢がどの工程に対応するかを対応付ける。
4. 要件定義に一致する表現を含む選択肢を選ぶ。上記手順でアが一致することが分かる。

選択肢別の誤答解説

• イ: 「経営事業の目的、目標を達成するために必要なシステムの要求事項をまとめ、そのシステム化の方針と実現計画を策定する。」
  → これは企画やシステム化計画に近い説明です。経営目標や方針を踏まえて「何を目指すか」を決める段階で、要件定義より上位の活動（システム企画や基本計画）を示しています。よって要件定義そのものの説明ではありません。
• ウ: 「システム要件とソフトウェア要件を定義し、システム方式とソフトウェア方式を設計して、システム及びソフトウェア製品を構築する。」
  → 要件を定義した後に「方式設計」や「構築（実装）」まで含んでいます。要件定義は設計・構築の前段階なので、工程範囲が広すぎます。特に「構築する」は実装工程の説明です。
• エ: 「ソフトウェア要件どおりにソフトウェアが実現されていることやシステム要件どおりにシステムが実現されていることをテストする。」
  → これはテスト工程の説明です。要件どおりになっているか確認する活動であり、要件定義ではありません。テストは実装後の検証フェーズです。

よくある誤解

1. 要件定義は「設計」と同じと思い込む。
   → 要件定義は「何をするか」を決める段階で、設計は「どう実現するか」を決める段階です。役割が違います。
2. 要件定義はIT部門だけが決めればよい。
   → 要件定義では業務担当者や経営、ユーザーなど多くの利害関係者の合意が必要です。孤立した決定は失敗の原因になります。
3. 要件定義で細かい画面設計やコード仕様まで決めるべきだ。
   → 詳細な画面やコード設計は詳細設計・実装工程で行います。要件定義は業務フローや機能、非機能要件（例：性能、可用性）など上位の要求に焦点を当てます。

補足コラム

• 要件定義の主な成果物（アウトプット）
  • 要件定義書（何を実現するかを整理した文書）
  • 業務フロー図（現行と改善後の流れ）
  • 機能一覧（優先順位や必須／任意の区別）
  • 非機能要件（性能、可用性、セキュリティ、運用性など）
• 非機能要件とは：システムの「動き方」に関する要求です。例：「同時100ユーザーで処理できる」「月間ダウンタイムは5分以内」など。機能要件（何ができるか）と合わせて要件定義で整理します。
• 合意（ステークホルダーの承認）がないと、後で仕様変更や追加費用が発生しやすくなります。要件定義は「後戻りを減らすための投資」と考えましょう。

FAQ