要件定義完全ガイド

要件定義の進化：要件を「書く」から「組み立てる」へ

現代的定義

要件定義とは、ビジネスの願いを**「スキーマ（データ構造）」と「テスト（判定ロジック）」に変換し、実装と仕様がズレた瞬間にシステムが「ビルド失敗」**として突き返す、鉄壁の検証環境を構築することです。

1. 「日本語の曖昧さ」を排せよ

日本語での説明だけに頼るのは、解釈が分かれ、再現性がありません。

• 情報の役割分担
  **日本語（ADR・背景）**は、「なぜこの機能が必要か」という図鑑の説明文に留めよ。**コード（Specification）**は、入力・出力・制約といったデータは、OpenAPI や GraphQL という「仕様の実行基盤」で直接定義せよ。

• Executable Specifications（Gherkin / TDD）
  仕様書を読んでからコードを書く、という二段階は無駄を生む。**「仕様そのものが実行される」**形にせよ。仕様がそのままテストとして動くオートマティックな検証にしろ。

2. 「会議という名の周知」から脱出せよ

人間を集めて「周知」するだけでは、変化の速度に追いつきません。

• 型による「事前検証」
  TypeScript や Rust を使え。ドキュメントを読み込む前に、エディタが**「その型はここでは使えない」**と教えてくれる。解釈の余地を型が潰す。

• スキーマ・ドリブン開発
  OpenAPI からコードを自動生成しろ。**「仕様と実装がズレようとしても、生成元が一つだから乖離できない」**レベルの物理的なロックをかけろ。

実践：要件を「検証可能な仕様」として組み立てる

（コード不要とのことなので、ロジックの「急所」だけを示す。）

• 要件は「検証可能な仕様」
  弱点倍率やレベル上限のような制約は、紙に書かずに「定数」や「バリデーター」として埋め込め。システムが自動で判定する。

• 要件は「CI という審判」
  人間が「合っているかな？」と悩むのは、もはや非効率だ。テストが Green なら、それが合格の証だ。CI が「必中」の判定を下す。

パラダイム・シフト：定義から「検証」へ

観点	前時代的な組織	現代の「仕組み駆動」組織
媒体	曖昧な日本語（再現性が低い）	厳密なスキーマ（一意に解釈できる）
検証	人間の目視（見落としが起きる）	CI による自動検証（抜けがない）
変更対応	現場の責任（「混乱状態」になりがち）	リファクタリング（仕様変更をコードで管理）
信頼の源	上司のハンコ（属人的）	テストの Green（再現可能な証拠）

リーダー（トップトレーナー）への最終助言

「ドキュメントは『幻』だが、型とテストは『伝説』の実体だ。エンジニアに解釈をさせるな。自動的に勝利（リリース）へと導く『学習装置（仕組み）』を組み込め。」

要件定義書を厚くするのは、リュックを「対症療法」でいっぱいにして安心しているビギナーと同じです。目指すべきは、エンジニアが一行もドキュメントを読まずとも、コードの定義とテスト結果を見るだけで**「何を作るべきか」を直感で理解し、ミスをしようとすればシステムが「まだその時ではない」と止めてくれる**、最強の開発環境です。