story-quality-gate

name	story-quality-gate
description	/brainstorm のユーザーストーリー品質を INVEST 基準で軽量チェックする。proposal.md 生成前にストーリーの構造的品質を確認し、問題があれば対話で改善を促す

Story Quality Gate

Overview

ユーザーストーリーの構造的品質を INVEST 基準で軽量チェックする。

目的: 品質の低いストーリーが /spec に流入するのを防ぐ。 タイミング: /brainstorm の要件確定後、proposal.md 生成前。 原則: ブロッキングゲートではない。Warn を出すが、ユーザー判断で進行可能。

INVEST チェック（6項目）

各ユーザーストーリーに対して Pass / Warn を判定する。

I - Independent（独立性）

他のストーリーへの暗黙の依存がないか。

• Pass: ストーリー単体で意味が通る
• Warn: 「〜の後に」「〜が完了したら」等、他ストーリーへの暗黙の前提がある

Warn 例: 「ログイン後にプロフィールを編集したい」
  → ログイン機能が暗黙の前提。依存関係を明示するか、分離を検討
Pass 例: 「ユーザーとして、プロフィールを編集したい」
  → 認証済みであることは前提条件として明記可能

N - Negotiable（交渉可能性）

実装手段の指定がなく、ゴールが記述されているか。

• Pass: 「何を達成したいか」が記述されている
• Warn: 「Redis を使って」「React Hook Form で」等の技術指定がある

Warn 例: 「Zustand を使って状態管理したい」
  → 技術指定。/brainstorm では「複数画面で状態を共有したい」が適切
Pass 例: 「商品をカートに入れて、別の画面でも確認したい」

V - Valuable（価値）

「なぜなら」の理由がユーザーまたはビジネスの価値を示しているか。

• Pass: 具体的なユーザー価値またはビジネス価値がある
• Warn: 技術的理由のみ、または理由が欠落

Warn 例: 「コードの可読性を上げたい」
  → 技術的理由のみ。ユーザー/ビジネス価値が不明
Pass 例: 「注文履歴を確認したい。なぜなら過去の購入を再注文できるから」

E - Estimatable（見積可能性）

サイズ感が推定できるだけの情報があるか。

• Pass: 何をどの範囲で変更するか想像できる
• Warn: 範囲が不明確、または技術調査（スパイク）が必要

Warn 例: 「パフォーマンスを改善したい」
  → どの画面？どの操作？目標値は？範囲が不明
Pass 例: 「商品一覧の初回表示を高速化したい」

S - Small（小ささ）

1つのストーリーに複数の独立した変更が混在していないか。

• Pass: 1つの焦点を持つストーリー
• Warn: 「〜と〜と〜を」のように複数の独立した目標が混在

Warn 例: 「ユーザー登録、ログイン、パスワードリセットを実装したい」
  → 3つの独立した機能。分割を検討
Pass 例: 「新規ユーザーとして、メールアドレスで登録したい」

T - Testable（テスト可能性）

測定不能な曖昧表現がないか。

• Pass: 具体的な状態変化や観測可能な結果がある
• Warn: 「適切に」「快適に」「正しく」等の測定不能表現がある

Warn 例: 「エラーを適切にハンドリングしたい」
  → 「適切に」は測定不能。具体的なエラー表示内容が必要
Pass 例: 「入力エラー時にフィールド横にエラーメッセージを表示したい」

適用ルール

1. 全項目 Pass → そのまま proposal.md 生成に進む
2. Warn が 1-2 個 → Warn 内容をユーザーに提示し、改善するか・このまま進めるか質問する
3. Warn が 3 個以上 → ストーリーの見直しを推奨する（ただしユーザー判断で進行可能）

提示形式

ストーリー品質チェック結果:

「ユーザーとして、〇〇したい。なぜなら△△だから」
  I: Pass  N: Pass  V: Pass  E: Warn  S: Pass  T: Warn

⚠ E（見積可能性）: 対象範囲が不明確です。どの画面/機能が対象ですか？
⚠ T（テスト可能性）: 「快適に」は測定が難しいです。具体的な基準はありますか？

→ このまま進めますか？ それとも修正しますか？

対話の流れを壊さない

• チェック結果は対話の最後にまとめて提示する（質問の途中で割り込まない）
• Warn の提示は質問形式にする（チェックリストの押しつけではなく、対話の延長として）
• ユーザーが「このまま進める」と言えば、Warn を proposal.md の「未解決の疑問点」に転記して進む