ITパスポート 令和3年度 問14:システム戦略に関する問題
ソフトウェアライフサイクルを,企画プロセス,要件定義プロセス,開発プロセス,運用プロセスに分けるとき,システム化計画を踏まえて,利用者及び他の利害関係者が必要とするシステムの機能を明確にし,合意を形成するプロセスはどれか。
- a企画プロセス
- b要件定義プロセス正答
- c開発プロセス
- d運用プロセス
AI解説(初心者・標準・上級)
理解度に合わせて3レベルの解説を無料で読めます。
答えは b「要件定義プロセス」 です。
システム作りは料理に似ています。「①どんな料理を作るか考える(企画)→②みんなの"こういうのが欲しい"を聞いてメニューを決める(要件定義)→③実際に作る(開発)→④お店で出し続ける(運用)」の順です。
この問題は「みんなが必要な機能をはっきりさせて、"これでOK"と全員で合意する"」段階を聞いています。それが②の要件定義です。
👉 覚え方:要件定義="何が欲しいか"を決めて合意する段階。作る前の打ち合わせ!
なぜこれが正解か
正解は b。ソフトウェアライフサイクルにおける要件定義プロセスは、システム化計画(企画)を踏まえ、利用者および他の利害関係者(ステークホルダ)が必要とするシステムの機能・要求を明確にし、合意を形成する工程。問題文の説明と一致する。
各選択肢の解説
- a 企画プロセス:経営上の課題からシステム化の構想・全体計画を立てる、最上流の工程。要件の詳細合意はまだ。
- c 開発プロセス:合意された要件をもとに設計・プログラミング・テストを行う工程。
- d 運用プロセス:完成したシステムを稼働させ、保守・監視する工程。
覚え方・ひっかけ注意
流れは「企画→要件定義→開発→運用→保守」。「利用者の要求を明確化し合意形成」というキーワードが出たら要件定義。企画は"やるか/構想"、要件定義は"何を作るか/合意"と切り分ける。
共通フレームと要件定義の位置づけ
ソフトウェアライフサイクルは共通フレーム(SLCP:Software Life Cycle Process)(IPA策定・ISO/IEC 12207をベースに日本語化)で体系化され、企画・要件定義・開発・運用・保守の各プロセスを共通用語で定義する。要件定義プロセスでは業務要件から機能要件(システムが「何をするか」:登録・検索・帳票出力等の機能)と非機能要件(「どの程度のレベルで」:性能・可用性・セキュリティ・操作性・保守性・移行性・環境・経済性の8カテゴリ)を抽出・整理し、利害関係者の合意(要件定義書への署名)を得る。IPAは非機能要求グレード(2010年公開)でこれら8カテゴリを詳細化した評価シートを提供しており、実務でのRFP作成や要件定義書の品質チェックに使われる。要件定義フェーズでの欠陥修正コストはテストフェーズの10〜100倍とされ(IBMの研究等)、上流品質の重要性が際立つ。
要件を引き出す技法と実務
要求収集技法にはヒアリング(インタビュー)・ワークショップ(ユーザー参加型の合同作業)・プロトタイピング(試作画面を見せながら要件を固める)・観察法(実際の業務を観察してサイレント要件を発見)・ユースケース記述(ユーザーとシステムのやり取りをシナリオで記述)がある。得られた要件はトレーサビリティマトリクス(要件ID⇔設計⇔テストケースの対応表)で管理し、後工程で「この要件はどのテストで検証するか」を追跡可能にする。非機能要件の抜けは本番稼働後のパフォーマンス障害・セキュリティインシデントの直接原因となるため、専門の非機能要件レビューが必要。
開発手法による要件定義の違い
ウォーターフォールでは要件を最初期に全て固定して下流工程へ渡すが、変更コストが高いため要件の不確かさがリスクになる。アジャイル(Scrum)ではプロダクトバックログとして要件を優先順位付きリストで管理し、スプリント(通常2週間)ごとに実装・検証・フィードバックを繰り返して要件を反復的に詳細化・変更する。現代のシステム開発では要件定義を「最初に完全に確定する成果物」ではなく「継続的に更新される生きた仕様」として扱うスタンスが主流になっている。
上位資格への接続
基本情報技術者では機能要件・非機能要件の識別・ウォーターフォールとアジャイルの要件管理の違い・SLCP(共通フレーム)の全体像が出題される。応用情報以上ではRFP(提案依頼書)の作成方法・SLA(サービスレベル合意)の内容・要件定義の発注者責任(共通フレームでは要件定義は発注者主導で行うとされる)が問われる。PM(プロジェクトマネジメント)系の資格(PMP・ITIL等)でも要件定義フェーズのガバナンスが重要テーマ。
選択肢の発展補足
企画プロセス(選択肢a)は「システム化構想策定・システム化計画策定」の2工程からなり、経営課題からシステム投資を正当化するビジネスケースを作る。ここでの判断ミスは要件定義で修正できないため、経営レベルの意思決定プロセスが重要。開発プロセス(選択肢c)はさらに要件定義(ソフトウェア要件)→外部設計(概要設計)→内部設計(詳細設計)→製造(コーディング)→テスト(単体/結合/システム/受入)に分解される。運用プロセス(選択肢d)では障害対応・定期メンテナンス・ユーザーサポート・SLAの監視・変更管理が主要業務。
出典:IPA(情報処理推進機構)公式 ITパスポート試験 令和3年度 問14/ 公的機関配布資料につき出典明記の上引用。解説は合格ナビによる独自AI解説です。