success-failure-criterialisted

## Purpose 「終わったかどうか」「成功したかどうか」の基準が曖昧なまま進むことで生じる、 判断の先送りと手戻りを防ぐ。 成功・失敗の基準を事前に定義することで、施工AI への handoff 品質を上げる。 ## Use When - 実装・施策の開始前 - OKR・KPI を具体化したい場合 - 施工AIへ渡す handoff に成功条件を含めたい場合 - 「完了」の定義が曖昧なまま議論が続いている場合 - ロールバック判断の基準を事前に決めておきたい場合 - issue-framing または boundary-check の後 ## Inputs 以下を準備すること。不足している場合は推測せず、不足を明示する。 - **対象**: 成功・失敗条件を定義する施策・機能・設計 - **目的**: この施策で実現したいこと - **タイムライン**: いつまでに成功・失敗を判断するか - **計測手段**: 何でデータを取れるか（event_logs / Slack / Stripe 等） - **既存の成功定義**: すでに何らかの基準がある場合はその内容 ## Output Contract 以下の順で出力すること。順序を変えない。 1. **論点**: この施策の成功・失敗を分ける核心指標は何か 2. **根拠**: その論点をそう判断した理由 3. **成功・失敗基準シート**: 定量・定性の両面で定義（後述フォーマット） 4. **含意**: 定義した基準が示す「本当に達成したいこと」の解釈 5. **改善案**: 基準を現実的・測定可能な形に改善する提案 6. **代替案**: 別の測定方法・別の成功定義の可能性 7. **判断材料**: 基準の確定に必要な人間の意思決定事項 ### 成功・失敗基準シート フォーマット ```text ## 成功条件 ### 必須条件（全て満たすこと） | 指標 | 基準値 | 計測方法 | 判定タイミング | |---|---|---|---| | （指標名） | （閾値） | （計測手段） | （いつ判定か） | ### 推奨条件（満たせば理想） | 指標 | 基準値 | 計測方法 | 判定タイミング | |---|---|---|---| ## 失敗条件（発動すればロールバック or 停止） | 指標 | 発動基準 | 計測方法 | 判定タイミング | ロールバック方針 | |---|---|---|---|---| ## 完了定義（Done の定義） - （チェックリスト形式） ``` ## Review Lens - **目的妥当性**: 定義した基準が本来の目的に対して有意か - **範囲の過不足**: 重要な指標が抜けていないか。測定不可能な指標を含んでいないか - **中長期リスク**: 短期の成功が長期の失敗を隠していないか - **LAB全体との整合性**: LMS の成功指標と自動化・B2B の方針が矛盾しないか - **非エンジニア理解可能性**: 基準が非技術者にも説明できる形か - **他LLM移植耐性**: 基準の定義が Claude 固有の解釈に依存していないか ## Instructions 1. 対象の目的を1文で再確認する（目的がずれていれば issue-framing へ戻る） 2. 成功条件を「必須」と「推奨」に分けて定義する 3. 各条件を「測定可能な形」で記述する（「うまくいった」ではなく「○○が XX%