要件定義プロセス

3行要約（速習ポイント）

• 1システム化計画に基づき、ユーザーがシステムを使って何をできるようにするかを確定する。
• 2業務要件（新業務フロー・規程）とシステム要件（機能・データ・画面・非機能）を分離して定義する。
• 3開発途中の仕様変更（スコープクリープ）を防ぐための「要件トレーサビリティ」を確保する。

概念・アーキテクチャ図解

バランスよく網羅すべき要件の分類

概要・背景・本質

要件定義は、発注者側の要求を明確な仕様へと落とし込む超上流の最終関門です。ここで業務要件の曖昧さや例外処理の検討漏れがあると、後工程（結合テストや受入テスト）で致命的な手戻りとなって爆発します。ITストラテジストは、ユーザー部門のわがままを全て受け入れるのではなく、費用対効果と業務標準化の観点から厳格にトリアージします。

コア概念と着眼点

• 利害関係者の特定：経営陣、現場オペレーター、管理者、外部取引先など多角的な視点
• 業務要件の明確化：新業務フロー（BPR後のTo-Be）、例外処理手順、権限管理
• 機能要件 vs 非機能要件：画面・帳票・計算ロジック（機能）と、性能・可用性・セキュリティ（非機能）
• 合意文書化：要件定義書を正として業務部門長と正式サインオフを実施

ITストラテジスト試験（午後I記述・午後II論文）での論述ポイント

午後Iの設問で「要件定義の漏れによって生じたトラブルの原因」を問われる問題が頻出。午後II小論文では、『業務部門間で対立した要件を、経営戦略への貢献度とコスト影響を数値化して提示することで納得させ、合意を取り付けた』という調整プロセスを論述すると試験官の共感を呼ぶ。

小論文で使える実践フレーズ・キーワード

関連するITストラテジスト重要用語

『要件定義プロセス』が出題された関連過去問演習