メインコンテンツまでスキップ

不完全な前提での Requirement Analysis

Context​

多くの現場で Requirement Analysis は、 「要件を洗い出す工程」として理解されている。

しかし運用中のソフトウェアや保守案件では、 要件が完全に揃うことはほとんどない。 仕様は断片的であり、判断の前提は共有されておらず、 関係者の期待も時間とともに変化する。

このような状況で行われる Requirement Analysis は、 要求を集める行為ではなく、 判断を成立させるための前提整理 として扱われる必要がある。

Objective​

本トピックの目的は、 正確な要件定義や完全な仕様合意ではない。

不完全な前提のもとでも、 変更・実装に関する判断を 引き受けられる状態を作ることにある。

Requirement Analysis は、 判断を先送りしないための装置として扱われる。

Minimal Inputs​

Requirement Analysis における最小入力は、 「何を作るか」ではなく、 何を判断の前提として固定するか で構成される。

  • SoT（正の所在）
    要件判断の最終根拠となる情報源

  • Constraints（制約）
    契約・期限・組織・技術的制約

  • Non-Changeables（不可変更）
    今回の判断では変更しないと合意した前提

  • Uncertainties（不確実性）
    現時点で確定できず、仮説として扱う事項

これらが固定されない限り、 要件は常に再解釈可能な状態に置かれる。

Working Model​

Requirement Analysis は、 要件を確定させる工程ではない。

不完全な前提のもとで、 仮説としての要件を扱う作業モデルを持つ。

  • 仮説として扱う要件
  • その仮説を支持する根拠
  • 仮説が崩れる条件
  • 仮説として許容する期限

期限を持たない仮説は、 暗黙の確定事項として扱われやすい。

Tactics​

Requirement Analysis における介入は、 要求を増やすことではない。

  • 判断に必要な前提を先に固定する
  • 未確定要件を仮説として明示する
  • 決めないことを意図的に残す

これらは手順ではなく、 判断可能性を維持するための設計である。

Risks​

Requirement Analysis は、 容易に次の失敗へと転ぶ。

  • 要件が無限に追加され、判断が停止する
  • 仮説が検証されず、前提が固定化する
  • 「まだ要件が足りない」が責任回避に使われる

これらは、 決定回避 や コンテクスト不足 を背景として、 Failure Pattern を誘発する温床となる。

関連する Failure Patterns​

Requirement Analysis は、 以下の Failure Pattern と強く関係する。

AI Collaboration​

AI を Requirement Analysis に利用する場合、 要件そのものよりも、 判断前提を渡すことが重要となる。

  • 何を SoT とするか
  • どの制約を越えてはいけないか
  • 何を変更不可として扱うか
  • どの不確実性を仮説として許容するか

これらが固定されていない場合、 AI はもっともらしい要件を生成するが、 判断を引き受けることはできない。

にHiroshi Kurabayashiが最終更新