第2章：要件定義の認知プロセス - 曖昧性との戦い

要件定義とは、ビジネスニーズを技術的な仕様に変換するプロセスである。ソフトウェア開発のみならず、インフラ設計、セキュリティ要件、データ基盤設計など、あらゆるITプロジェクトにおいて必要となる。本章では、この普遍的なプロセスにおける思考法を扱う。

本章の目的は、曖昧な要求を「制約・受入基準を含む仕様」として固定し、後工程で再利用できる形に落とすための思考手順を整理することである。

この章の学習目標

• 顧客の言葉で語られた要求を、ユビキタス言語やユーザーストーリーを用いて技術仕様に変換するプロセスを意識して設計できるようになること。
• 技術的・ビジネス・法規制などの隠れた制約条件を、チェックリストや質問テンプレートを通じて体系的に洗い出せるようになること。
• スコープクリープのパターンと影響を理解し、変更管理プロセスの観点から関係者に説明・合意形成ができるようになること。

本章とAI協働の標準手順（SOP）

本章は、AI協働の標準手順（SOP） のうち、主に次の工程に対応する。

• タスク定義（要件定義の目的・利用者・判断点を明確にする）
• 情報分類（入力できる情報/できない情報を切り分ける）
• 入力設計（前提・制約・出力形式を構造化する）
• 検証（要件の一貫性・矛盾・抜け漏れを確認する）
• 反映（要件を成果物として残す）

2.1 顧客の言語と技術の言語の変換機構

ドメイン知識の構造化

顧客が語る要求と、エンジニアが理解する仕様の間には、常に「翻訳」が必要である。この翻訳プロセスを体系的に行うための手法を提供する。

オントロジーマッピング

概念と概念の関係を明確にし、顧客の世界観と技術の世界観を結びつける。

実例：ECサイトの在庫管理システム

• 顧客の言葉：「在庫切れを防ぎたい」
• 技術への変換は次のとおりである。
  • リアルタイム在庫同期
  • 閾値アラート機能
  • 自動発注システムとの連携

ユビキタス言語の構築

プロジェクト全体で使用する共通言語を定義し、誤解を防ぐ。

構築プロセスは次のとおりである。

1. 主要概念の洗い出し
2. 定義の明文化
3. 用語集の作成と共有
4. 継続的な更新と改善

要求の分解と再構成

抽象的な要求を、実装可能な単位に分解する技術。

ユーザーストーリーの解析手法

As a [ユーザーの役割]
I want [実現したいこと]
So that [ビジネス価値]

この形式を使って、要求の本質を抽出する。

コミュニケーションプロトコル

確認質問のテンプレート

1. 具体化質問：「〜の場合はどうなりますか？」
2. 境界確認：「〜は含みますか？含みませんか？」
3. 優先順位確認：「AとBではどちらが重要ですか？」
4. 制約確認：「〜という制限はありますか？」

2.2 隠れた制約条件の発見手法

表面的な要求の背後に潜む、明文化されていない制約を発見する能力は、プロジェクトの成否を左右する。

制約の種類と特性

技術的制約

• 既存システムとの互換性
• パフォーマンス要件
• スケーラビリティ要件

ビジネス制約

• 予算制限
• 期限
• 組織構造

法規制・コンプライアンス制約

• 個人情報保護法
• 業界規制
• 国際標準

制約発見のチェックリスト

システム境界の確認項目は次のとおりである。

• 外部システムとの接続点
• データの入出力
• ユーザーアクセス経路
• バックアップ・リカバリ要件

制約条件の文書化

発見した制約を適切に文書化し、関係者と共有する。

制約は後工程（設計・見積もり・テスト・運用）で参照される。口頭や議事メモのままだと、解釈違いが再発しやすい。最低限、次を1セットで残す。

• 制約（具体値/範囲/単位）
• 根拠（契約/一次情報/計測など）
• 影響範囲（どの要件・設計・運用に効くか）
• 決定/確認者（責任者）と 更新条件（いつ見直すか）

記載例：

制約: 外部APIのレート制限は 100 req/min
根拠: ベンダー公開仕様
影響: バッチ処理は分割実行が必要。ピーク時はキューイングを採用。
決定/確認者: プロダクトオーナー
更新条件: 仕様変更通知時に再確認

未確認の項目は「前提（Assumption）」として切り出し、確認タスクとセットで管理する（付録A：思考ツールテンプレート集 の「前提・未確定事項ログ」参照）。

2.3 スコープクリープの予防的制御

プロジェクトが進むにつれて要件が膨張する「スコープクリープ」を防ぐための思考法。

スコープ変更の類型

機能追加型

「ついでにこの機能も」という形で追加される要求。

品質向上型

「もっと速く」「もっと使いやすく」という形で高まる要求。

技術変更型

「最新の技術を使いたい」という形で変更される要求。

変更管理プロセス

変更要求の評価基準

1. ビジネス価値
2. 実装コスト
3. リスク
4. 他機能への影響

バッファ管理戦略

予期せぬ変更に対応するための余裕を、計画的に確保する。

バッファは「どこに余裕を持たせるか」を明示して確保する。暗黙のバッファは、スコープクリープに吸収されやすい。

• スコープバッファ: Must/Should を切り分け、Should を後ろ倒し可能にする
• スケジュールバッファ: 不確実性が高いタスクに検証期間を追加する
• 品質バッファ: 自動テスト/レビューの最低限を固定し、削るのは最後にする

判断基準（例）：

• 期限固定の場合は、スコープ/品質/コストのうち「何を動かすか」を先に合意する
• 変更要求が頻出する場合は、要件の優先度と変更管理の入口（誰が承認するか）を先に固定する

運用上の注意：

• バッファを使った場合は理由を記録し、次回の見積もり・計画に反映する

2.4 AIを活用した要件定義の高度化

生成AIによる要件分析支援

AIを活用して要件の一貫性をチェックし、潜在的な問題を発見する。

要件の一貫性チェック

以下の要件を分析し、矛盾や不整合がないか確認してください。
1. システムは24時間365日稼働する
2. 毎週日曜日の深夜にメンテナンスを行う
3. ユーザーはいつでもデータにアクセスできる

プロンプトエンジニアリングの実践

効果的な質問設計により、AIから有益な洞察を引き出す。

AI出力の検証と統合

AIの提案を鵜呑みにせず、ドメイン知識で検証し、プロジェクトに統合する。

SOP適用例：要件定義を成果物へ落とす

要件定義でAIを使うときは、AI協働の標準手順（SOP） を「要件を成果物に反映し、記録する」まで通すことが重要である。特に「AIから良さそうな要件案が出た」時点で止めず、次の対応関係を意識して進める。

このうち「7. 反映（チケット化・受入基準まで）」と「8. 記録」を省略すると、後工程の設計・開発・運用での手戻りが増えやすい。

まとめ

要件定義は、プロジェクトの成功を左右する重要なフェーズである。顧客の言語と技術の言語を適切に変換し、隠れた制約を発見し、スコープを制御する能力は、AIツールを活用しながらも、人間のエンジニアが持つべき本質的なスキルである。

要点：

• 要求を「顧客言語 → 技術仕様」に翻訳するために、用語・境界・受入基準を成果物として固定する。
• 隠れた制約（技術/ビジネス/法規制など）を、質問テンプレートやチェックリストで体系的に洗い出す。
• 変更を前提に、スコープ・優先順位・意思決定ログを揃えて合意形成する。

次章では、これらの要件を基に、どのようにアーキテクチャを設計していくかを探求する。

次に読む： 第3章：アーキテクチャ設計の意思決定 / 目次（トップ）

この章のまとめとチェックリスト

この章のまとめ

• 顧客の言語と技術の言語の橋渡し、隠れた制約条件の発見、スコープクリープの制御といった要件定義の本質的な課題を整理した。
• AIを要件分析支援に活用する際のメリットと限界を示し、「AIの提案を鵜呑みにせず、人間の判断で検証・統合する」プロセスを提示した。
• 第1章で紹介した抽象化・トレードオフ・負債評価といった思考フレームが、要件定義フェーズでどのように活きるかを具体化した。

この章を読み終えたら確認したいこと

• 最近扱った要件（または想定シナリオ）について、顧客の表現と技術要件への変換例を自分なりに 1 つ書き出してみたか。
• 要件の背後にある制約条件や前提を、チェックリスト的に洗い出す習慣を持てているか。
• AIに要件レビューをさせた場合、その出力に対して「どの部分を採用し、どこに注意すべきか」を自分の判断で整理できるか。

関連する付録・テンプレート

• 要件定義の整理やレビューには、付録A：思考ツールテンプレート集 に含まれるステークホルダー分析や要件確認チェックリストが有用である。
• 要件定義フェーズでの思考プロセスの適用例は、付録B：ケーススタディ の該当ケースを参照することで、より具体的にイメージできる。
• 汎用スキル（問題設定/構造化/検証）の補完関係は、前作（論理思考ガイド）との接続 を参照してほしい。