# Success Failure Criteria

> 施策・実装・設計の成功条件と失敗条件を測定可能な形で定義する。「なんとなくうまくいった」を排除し、判断基準を事前に確定する場面で使う。

- Skill: `thinkyou0714/success-failure-criteria` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/success-failure-criteria`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/success-failure-criteria/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/success-failure-criteria

---


## 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% 以上」）
4. 失敗条件をロールバック発動基準として定義する（docs/CONTEXT.md のロールバック条件を参照）
5. 「完了の定義（Done）」をチェックリスト形式で作成する
6. 計測方法が存在しない指標は「計測手段の構築が必要」として明示する
7. 定量化が難しい指標は定性的な判断基準と判断者を明示する

## Guardrails

- 測定不可能な基準を「成功条件」にしない
- 失敗条件の「発動基準」が曖昧なまま終わらない
- ロールバック方針を省略しない
- 「成功したかどうかは見てみないとわからない」で終わらない
- 基準の最終確定は人間が行う（AI が勝手に決めない）
- 成功条件を緩めて「成功」にしやすくしない

## LAB Cross-Check

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動化の成功・失敗を計測できる仕組みがあるか |
| データ / 認証 / ログ | — | event_logs / audit_log で計測できるか |
| 実装 / 運用フロー | — | 完了定義に運用テストが含まれているか |
| 非エンジニア理解可能性 | — | 基準が 非エンジニアにも説明できる形か |
| 会員共有 / 再利用耐性 | — | 基準シートの構造が他ケースに転用できるか |
| 他LLM移植耐性 | — | 基準定義が Claude 固有の形式に依存していないか |

状態は OK / 注意 / NG / 対象外 で記入すること。

## Handoff Notes

- **要件**: 達成すべき成功条件の一覧（必須条件）
- **成功条件**: 上記シートの「必須条件」を転記
- **失敗条件**: 上記シートの「失敗条件」を転記（ロールバック発動基準）
- **実行範囲**: 計測対象のファイル・DB・ログ
- **影響範囲**: 計測が波及するシステム・機能
- **ロールバック方針**: 失敗条件発動時の具体的な戻し手順
- **コスト比較**: 計測基盤の構築コスト vs 計測なしで進むリスクコスト

## Further Reading

- `issue-framing` — 成功・失敗条件定義前の論点整理
- `boundary-check` — スコープ確定後に成功条件を定義する
- `implementation-gate` skill（lab-implementation-flow）— 実装前に成功条件を確認
- [docs/CONTEXT.md](../../../docs/CONTEXT.md) — 主力プロダクトの成功条件・ロールバック条件の定義
- [docs/TASKS.md](../../../docs/TASKS.md) — 現在のタスクの完了定義