第2章：要件定義の認知プロセス - 曖昧性との戦い
要件定義とは、ビジネスニーズを技術的な仕様に変換するプロセスであり、ソフトウェア開発のみならず、インフラ設計、セキュリティ要件、データ基盤設計など、あらゆるITプロジェクトにおいて必要となる。本章では、この普遍的なプロセスにおける思考法を扱う。
2.1 顧客の言語と技術の言語の変換機構
ドメイン知識の構造化
顧客が語る要求と、エンジニアが理解する仕様の間には、常に「翻訳」が必要である。この翻訳プロセスを体系的に行うための手法を提供する。
オントロジーマッピング
概念と概念の関係を明確にし、顧客の世界観と技術の世界観を結びつける。
実例：ECサイトの在庫管理システム
- 顧客の言葉：「在庫切れを防ぎたい」
- 技術への変換：
- リアルタイム在庫同期
- 閾値アラート機能
- 自動発注システムとの連携
ユビキタス言語の構築
プロジェクト全体で使用する共通言語を定義し、誤解を防ぐ。
構築プロセス：
- 主要概念の洗い出し
- 定義の明文化
- 用語集の作成と共有
- 継続的な更新と改善
要求の分解と再構成
抽象的な要求を、実装可能な単位に分解する技術。
ユーザーストーリーの解析手法
As a [ユーザーの役割]
I want [実現したいこと]
So that [ビジネス価値]
この形式を使って、要求の本質を抽出する。
コミュニケーションプロトコル
確認質問のテンプレート
- 具体化質問：「〜の場合はどうなりますか？」
- 境界確認：「〜は含みますか？含みませんか？」
- 優先順位確認：「AとBではどちらが重要ですか？」
- 制約確認：「〜という制限はありますか？」
2.2 隠れた制約条件の発見手法
表面的な要求の背後に潜む、明文化されていない制約を発見する能力は、プロジェクトの成否を左右する。
制約の種類と特性
技術的制約
- 既存システムとの互換性
- パフォーマンス要件
- スケーラビリティ要件
ビジネス制約
- 予算制限
- 期限
- 組織構造
法規制・コンプライアンス制約
- 個人情報保護法
- 業界規制
- 国際標準
制約発見のチェックリスト
システム境界の確認項目：
- 外部システムとの接続点
- データの入出力
- ユーザーアクセス経路
- バックアップ・リカバリ要件
制約条件の文書化
発見した制約を適切に文書化し、関係者と共有する。
2.3 スコープクリープの予防的制御
プロジェクトが進むにつれて要件が膨張する「スコープクリープ」を防ぐための思考法。
スコープ変更の類型
機能追加型
「ついでにこの機能も」という形で追加される要求。
品質向上型
「もっと速く」「もっと使いやすく」という形で高まる要求。
技術変更型
「最新の技術を使いたい」という形で変更される要求。
変更管理プロセス
変更要求の評価基準
- ビジネス価値
- 実装コスト
- リスク
- 他機能への影響
バッファ管理戦略
予期せぬ変更に対応するための余裕を、計画的に確保する。
2.4 AIを活用した要件定義の高度化
生成AIによる要件分析支援
AIを活用して要件の一貫性をチェックし、潜在的な問題を発見する。
要件の一貫性チェック
以下の要件を分析し、矛盾や不整合がないか確認してください：
1. システムは24時間365日稼働する
2. 毎週日曜日の深夜にメンテナンスを行う
3. ユーザーはいつでもデータにアクセスできる
プロンプトエンジニアリングの実践
効果的な質問設計により、AIから有益な洞察を引き出す。
AI出力の検証と統合
AIの提案を鵜呑みにせず、ドメイン知識で検証し、プロジェクトに統合する。
まとめ
要件定義は、プロジェクトの成功を左右する重要なフェーズである。顧客の言語と技術の言語を適切に変換し、隠れた制約を発見し、スコープを制御する能力は、AIツールを活用しながらも、人間のエンジニアが持つべき本質的なスキルである。
次章では、これらの要件を基に、どのようにアーキテクチャを設計していくかを探求する。