3-1 要件定義の位置づけ

Role of Requirements Definition

要件定義はプロジェクトの成否を左右する最も重要なフェーズである。 プロジェクト失敗の多くは要件定義の問題に起因する。本節では、要件定義の 目的と重要性、そしてプロジェクト全体における位置づけを明確にする。

1. 要件定義とは

1.1 要件の定義

要件（Requirement）とは、システムが満たすべき条件や能力のことである。 IEEE 610.12では「ユーザーが問題を解決するため、または目的を達成するために 必要とする条件や能力」と定義されている。

要件の種類 説明 例
ビジネス要件 組織が達成したい上位目標 売上10%向上、業務効率化
ステークホルダー要件 ユーザーや関係者のニーズ 操作が簡単、レスポンスが速い
ソリューション要件 システムの機能・性能 機能要件＋非機能要件
移行要件 現行から新システムへの移行条件 データ移行、並行稼働期間

1.2 機能要件と非機能要件

ソリューション要件は、機能要件と非機能要件に分類される。 機能要件は「何ができるか」、非機能要件は「どのようにできるか」を定義する。

分類 定義 例
機能要件 システムが提供する機能・振る舞い 注文登録、在庫検索、レポート出力
非機能要件 機能の品質特性、制約条件 性能、信頼性、セキュリティ、保守性
非機能要件の重要性
非機能要件は機能要件と比較して軽視されがちだが、システムの使い勝手や 運用に大きく影響する。「動くけど遅い」「使いにくい」システムは、 非機能要件の定義不足が原因であることが多い。

2. 要件定義の重要性

2.1 プロジェクト失敗と要件定義

多くの調査研究により、プロジェクト失敗の主要因として要件定義の問題が 挙げられている。Standish Groupの調査では、プロジェクト失敗要因のトップ3に 「不完全な要件」「要件の頻繁な変更」「ユーザー関与の不足」が入っている。

要件定義の問題 プロジェクトへの影響
要件の曖昧さ 解釈の相違による手戻り、紛争
要件の漏れ 後工程での追加作業、スケジュール遅延
要件の頻繁な変更 スコープクリープ、コスト増大
優先順位の不明確さ 重要機能の未実装、不要機能への投資
ステークホルダー間の不一致 対立、意思決定の遅延

2.2 1:10:100の法則

欠陥の修正コストは、発見が遅れるほど指数関数的に増大する。 要件定義フェーズで発見・修正するコストを1とすると、設計フェーズでは10倍、 実装・テストフェーズでは100倍のコストがかかるとされている。

後工程での手戻りは致命的
要件定義の不備を運用開始後に発見した場合、修正には膨大なコストがかかる。 「要件定義に時間をかけすぎている」という批判があっても、 この段階での投資は後工程でのリスク低減につながることを認識すべきである。

3. 要件定義のプロセス

3.1 要件定義の全体像

要件定義は一般的に、要件の引き出し（Elicitation）、要件の分析（Analysis）、 要件の仕様化（Specification）、要件の検証（Validation）の4つの活動で構成される。

活動 目的 主な技法
引き出し（Elicitation） ステークホルダーからニーズを収集 インタビュー、ワークショップ、観察
分析（Analysis） 要件の整理、詳細化、優先順位付け モデリング、プロトタイピング
仕様化（Specification） 要件を文書として記録 SRS作成、ユースケース記述
検証（Validation） 要件の正確性・完全性の確認 レビュー、ウォークスルー

3.2 反復的なプロセス

要件定義は直線的なプロセスではなく、反復的に実施される。 引き出しで得た情報を分析し、分析結果をもとに追加の引き出しを行い、 仕様化と検証を繰り返して要件を洗練させていく。

要件定義プロセス

図1: 要件定義プロセスの反復

アジャイルでの要件定義
アジャイル開発では、要件定義を事前に完了させるのではなく、 各イテレーションで継続的に要件を詳細化する。ただし、プロダクトビジョンや 高レベルの要件はプロジェクト初期に定義することが重要である。

4. 要件定義の成果物

4.1 主要な成果物

要件定義工程では複数の成果物を作成する。

成果物 内容 利用者
ビジネス要件書 プロジェクトの目的、目標、成功基準 経営層、スポンサー
ステークホルダー要件書 各ステークホルダーのニーズ プロジェクトチーム、ユーザー
ソフトウェア要件仕様書（SRS） 機能要件・非機能要件の詳細 開発チーム、テストチーム
要件トレーサビリティマトリックス 要件と成果物の追跡表 PM、品質保証

4.2 良い要件の特性（SMART）

良い要件は、以下の特性を持つべきである。これらは「SMART」基準と呼ばれる。

特性 説明 悪い例 → 良い例
Specific（具体的） 曖昧さがない 「速い」→「3秒以内に応答」
Measurable（測定可能） 達成を確認できる 「使いやすい」→「3クリック以内で完了」
Achievable（達成可能） 技術的・コスト的に実現可能 「全データを即時反映」→「5分以内に反映」
Relevant（関連性） ビジネス目標と関連 不要機能の排除
Traceable（追跡可能） 出所と影響範囲が明確 要件IDと紐付け

要件レビューのチェックポイント

要件レビューでは以下の観点をチェックする： 完全性（すべての要件が記載されているか）、 一貫性（矛盾がないか）、 明確性（解釈の余地がないか）、 検証可能性（テストで確認できるか）、 実現可能性（技術的・予算的に可能か）。

5. 要件定義の課題と対策

5.1 よくある課題

要件定義では様々な課題に直面することが多い。

課題 原因 対策
ユーザーが要件を言語化できない 業務の暗黙知、ITリテラシー不足 プロトタイプ、観察、ファシリテーション
ステークホルダー間の意見対立 立場や利害の相違 優先順位付けワークショップ、経営判断
要件の肥大化 「あれもこれも」症候群 MoSCoW法、MVP思考
技術制約の見落とし 技術者の早期関与不足 技術者の要件定義参画
MoSCoW法
要件の優先順位付け手法。Must have（必須）、Should have（重要）、 Could have（あれば良い）、Won't have（今回は対象外）に分類する。 限られたリソースで最大の価値を提供するために有効である。
次のステップ
要件定義の位置づけを理解したら、次は「3-2 要件の引き出し」で ステークホルダーからニーズを収集する具体的な技法を学習しよう。
参考文献
[1] IEEE (1990). IEEE Standard Glossary of Software Engineering Terminology.
[2] IIBA (2015). BABOK Guide 3.0.
[3] Standish Group (2020). CHAOS Report.