Goal validation

Purpose

「目標が立派だが、上位目的とつながっていない／測れない」まま走り出すリスクを防ぐ。 目標を目的・指標・前提に分解し、追う価値があるかを判断できる状態にする。

Use When

• 新しい施策・事業の目標を設定するとき
• KGI / KPI を見直すとき
• 「この目標、本当に意味があるのか」と疑問が出たとき
• 複数チームの目標が食い違っているとき

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 目標案: 達成したい状態（数値があれば数値で）
• 上位目的: その目標が貢献する事業・戦略上の狙い
• 期限: いつまでに達成したいか
• 制約: 予算・人員・技術・市場の制約（わかる範囲で）

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: この目標で最も曖昧／危ういのはどこか
2. 根拠: その論点をそう判断した理由
3. 目的整合性: 上位目的と目標のつながり（飛躍がないか）
4. 含意: この目標を追うことの中長期的な意味・副作用
5. 改善案: 目標をより検証可能・有効にする修正案
6. 代替案: 別の目標の置き方（指標を変える／対象を変える）
7. 判断材料: 目標確定のために人間が確認すべき情報

Review Lens

• 目的妥当性: 目標達成が本当に上位目的に効くか
• 範囲の過不足: 目標が広すぎ／狭すぎないか
• 中長期リスク: 短期目標が長期の負債を生まないか
• LAB全体との整合性: LMS / 自動化 / B2B 展開と整合しているか
• 非エンジニア理解可能性: 非エンジニアの関係者に説明できるか
• 他LLM移植耐性: Claude 固有の解釈に依存していないか

Instructions

1. 目標を「目的・指標・対象・期限」に分解する
2. 上位目的から目標までの因果（なぜこれが効くか）を1行で書く
3. 指標が測定可能か（誰が・どう測るか）を確認する
4. 達成しても目的に効かない「バニティ指標」でないか点検する
5. 前提（市場・需要・前提条件）を列挙し、未検証のものを明示する
6. 不明な前提は推測せず、仮定を明示して進める

Guardrails

• 推測で前提を埋めない。不明は「前提: ○○と仮定」と明示する
• 目標を1案に閉じない。指標の置き方の選択肢を残す
• 測定コスト（指標を測る工数）を省略しない
• 「やる」結論を急がない。判断は人間に委ねる

LAB Cross-Check

観点	状態	備考
自動化フロー	—	指標計測を自動化できるか／手動か
データ / 認証 / ログ	—	指標データの取得経路・権限を確認したか
実装 / 運用フロー	—	目標が実装・運用の現実と整合するか
非エンジニア理解可能性	—	目標を関係者に説明できるか
会員共有 / 再利用耐性	—	目標設計が他施策にも転用できるか
他LLM移植耐性	—	判断が Claude 固有に依存していないか

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

Handoff Notes

施工AI（Claude Code / Cursor 等）へ渡す前に以下を確定させること。

• 要件: 確定した目標・指標・期限
• 成功条件: 目標達成を判定する測定可能な基準
• 失敗条件: 撤退・見直しのトリガー
• 実行範囲: 指標計測のために触れてよいデータ・画面
• 影響範囲: 目標変更が波及する施策・チーム
• ロールバック方針: 目標が機能しない場合の戻し方
• コスト比較: 指標計測・運用の工数概算

Further Reading

• success-failure-criteria skill — 成功・失敗条件を測定可能にする
• strategy-assessment skill — 実行中の戦略を査定する
• judgment-gates.md — 判断ゲートとの整合性
• docs/CONTEXT.md — 事業文脈