AI時代のプロフェッショナルITエンジニアの思考法

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

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

この章の学習目標

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

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

ドメイン知識の構造化

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

オントロジーマッピング

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

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

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

ユビキタス言語の構築

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

構築プロセス：

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

要求の分解と再構成

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

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

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

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

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

確認質問のテンプレート

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

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

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

制約の種類と特性

技術的制約

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

ビジネス制約

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

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

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

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

システム境界の確認項目：

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

制約条件の文書化

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

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

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

スコープ変更の類型

機能追加型

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

品質向上型

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

技術変更型

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

変更管理プロセス

変更要求の評価基準

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

バッファ管理戦略

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

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

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

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

要件の一貫性チェック

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

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

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

AI出力の検証と統合

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

まとめ

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

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

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

この章のまとめ

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

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

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

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