/brainstorm のユーザーストーリー品質を INVEST 基準で軽量チェックする。proposal.md 生成前にストーリーの構造的品質を確認し、問題があれば対話で改善を促す
ユーザーストーリーの構造的品質を INVEST 基準で軽量チェックする。
目的: 品質の低いストーリーが /spec に流入するのを防ぐ。 タイミング: /brainstorm の要件確定後、proposal.md 生成前。 原則: ブロッキングゲートではない。Warn を出すが、ユーザー判断で進行可能。
各ユーザーストーリーに対して Pass / Warn を判定する。
他のストーリーへの暗黙の依存がないか。
Warn 例: 「ログイン後にプロフィールを編集したい」
→ ログイン機能が暗黙の前提。依存関係を明示するか、分離を検討
Pass 例: 「ユーザーとして、プロフィールを編集したい」
→ 認証済みであることは前提条件として明記可能
実装手段の指定がなく、ゴールが記述されているか。
Warn 例: 「Zustand を使って状態管理したい」
→ 技術指定。/brainstorm では「複数画面で状態を共有したい」が適切
Pass 例: 「商品をカートに入れて、別の画面でも確認したい」
「なぜなら」の理由がユーザーまたはビジネスの価値を示しているか。
Warn 例: 「コードの可読性を上げたい」
→ 技術的理由のみ。ユーザー/ビジネス価値が不明
Pass 例: 「注文履歴を確認したい。なぜなら過去の購入を再注文できるから」
サイズ感が推定できるだけの情報があるか。
Warn 例: 「パフォーマンスを改善したい」
→ どの画面？どの操作？目標値は？範囲が不明
Pass 例: 「商品一覧の初回表示を高速化したい」
1つのストーリーに複数の独立した変更が混在していないか。
Warn 例: 「ユーザー登録、ログイン、パスワードリセットを実装したい」
→ 3つの独立した機能。分割を検討
Pass 例: 「新規ユーザーとして、メールアドレスで登録したい」
測定不能な曖昧表現がないか。
Warn 例: 「エラーを適切にハンドリングしたい」
→ 「適切に」は測定不能。具体的なエラー表示内容が必要
Pass 例: 「入力エラー時にフィールド横にエラーメッセージを表示したい」
ストーリー品質チェック結果:
「ユーザーとして、〇〇したい。なぜなら△△だから」
I: Pass N: Pass V: Pass E: Warn S: Pass T: Warn
⚠ E（見積可能性）: 対象範囲が不明確です。どの画面/機能が対象ですか？
⚠ T（テスト可能性）: 「快適に」は測定が難しいです。具体的な基準はありますか？
→ このまま進めますか？ それとも修正しますか？