基本情報 平成30年度 春期 問65：ストラテジ系に関する問題

答えは a です。

要件定義＝「誰が」「何を」「どんな制約で」必要としているかを洗い出す段階。

• 利害関係者（ユーザ、業務部門、運用部門、経営層など）を識別
• 彼らのニーズ・要望・制約を識別

この段階で見落とすと、後で「これじゃない！」と作り直しになります。

👉 覚え方：要件定義＝関係者全員のニーズと制約の棚卸し！

ほかの選択肢：b システム化方針・実施計画立案＝企画フェーズ（システム化計画）／c システム方式設計＝設計フェーズ／d ソフトウェアの方式設計＝設計フェーズ。

なぜこれが正解か

正解は a。要件定義プロセスでは、システムと関わる利害関係者（ステークホルダ）を識別し、彼らのニーズ・要望・制約条件を抽出・分析・整理する。これが要件定義の本質的な出発点。識別された要件は「業務要件」「機能要件」「非機能要件」に分類され、後工程の設計の基礎となる。

各選択肢の解説

• a 利害関係者の識別、ニーズ・要望・制約の識別：要件定義 → 正解。
• b 事業目的達成のためのシステム化方針・実施計画立案：企画プロセス（システム化計画）。
• c システム機能・能力定義、システム方式設計（HW/SW実現方式確立）：設計プロセス。
• d 利害関係者要件を満たすソフトウェア製品・サービスの方式設計と適格性確認：ソフトウェア要件定義・方式設計フェーズ。

覚え方・ひっかけ注意

要件と仕様は別物：

• 要件（requirement）：利害関係者が「何を求めているか」（WHAT）。
• 仕様（specification）：要件を満たすシステムが「どう実現するか」（HOW）。

要件定義の典型成果物：要件定義書、業務フロー図、概念モデル、ユースケース、機能一覧、非機能要件一覧。

要件の分類

機能要件（functional requirements）

• システムが何をするか。業務処理、データ操作、計算、出力。
• ユースケース、機能一覧、入出力定義で表現。

非機能要件（non-functional requirements）

• IPA非機能要求グレードで6大項目：(1)可用性 (2)性能・拡張性 (3)運用・保守性 (4)移行性 (5)セキュリティ (6)システム環境・エコロジー。
• 数値目標（SLA）として定義：稼働率99.9%、応答時間2秒、ピーク同時接続数10000等。

要件抽出手法

• ヒアリング：個別/集団インタビュー。
• ワークショップ：利害関係者参加型の発散・収束。
• 観察：業務現場での実際の作業観察（コンテキスチュアル・インクワイアリ）。
• アンケート：定量データ収集。
• 文書分析：既存マニュアル、業務手順書、システムドキュメント。
• プロトタイピング：早期試作で要件具体化。
• ジョブ・トゥ・ビー・ダン（JTBD）：顧客が「片付けたい仕事」を起点に要件抽出。

モデリング技法

• UML：ユースケース図、アクティビティ図、シーケンス図、クラス図、状態遷移図。
• BPMN（Business Process Model and Notation）：業務プロセスモデリング。
• ER図：データモデリング。
• DFD（Data Flow Diagram）：データ流れ図。
• ユーザストーリーマッピング：アジャイル開発の要件可視化。

利害関係者の分類

• 直接利用者：エンドユーザ、業務担当者。
• 間接利用者：管理者、監督者、経営層。
• 運用・保守関係者：システム運用、ヘルプデスク、開発・保守ベンダ。
• 外部関係者：顧客、取引先、規制当局、株主。
• マネジメント：プロジェクトスポンサ、ステアリングコミッティ。

ステークホルダ分析として影響力×関心度マトリックスで優先度評価。

要件定義の標準・規格

• ISO/IEC/IEEE 29148：要件工学プロセス国際規格。
• BABOK（Business Analysis Body of Knowledge）：IIBA、ビジネスアナリシスの体系。
• 共通フレーム2013（SLCP-JCF）：日本のSLCPローカライズ。

要件定義の品質特性（IEEE 830/29148）

• 正確性：事実に基づく。
• 明確性：曖昧でない。
• 一貫性：矛盾がない。
• 完全性：抜け漏れない。
• 検証可能性：テスト可能。
• 追跡可能性：源泉が明確、後工程までトレース可能。

試験での位置づけ

FE「ストラテジ／システム開発技術」分野で頻出。応用情報・ITストラテジスト・SA・SM では中核知識。要件定義の品質はプロジェクト成功の70-80%を決めるとされ、CHAOS Reportでも失敗原因のトップに常に挙がる。

アジャイル開発における要件定義

• プロダクトバックログ：要件一覧、優先度順。
• ユーザストーリー：「〜として、〜できる、〜のため」フォーマット。
• エピック→ストーリー→タスク：階層分解。
• 継続的洗練（grooming/refinement）：スプリント毎に要件を詳細化。
• MVP（Minimum Viable Product）：早期検証可能な最小構成。

選択肢の発展補足

bの企画プロセスは要件定義より上流で、経営戦略との整合を取り、システム化全体の方向性を決める段階。EA（エンタープライズアーキテクチャ）で全社のIT戦略と整合させる。cのシステム方式設計は要件定義の後、要件をどう実現するか（システム/ハードウェア/ソフトウェアの分担、技術選定）を決める。dのソフトウェア方式設計はシステム方式設計の下位で、ソフトウェア内の構造設計（モジュール分割、I/F定義）を決める。