foundation-okr-writer

OKR ライター

OKR（目標と主要な成果）のセットは、チームが達成に取り組む測定可能な成果へと戦略を落とし込んだ、四半期ごとの成果物です。OKR は、プロジェクト計画、KPI ダッシュボード、業績評価ツール、ロードマップをまとめる枠組みではなく、集中と学習のためのシステムです。適切に運用すれば、優先事項を明確にし、トレードオフを促し、チーム間の連携を可能にし、進捗を示す目に見える証拠を生み出します。うまく運用できないと、ロードマップを演出するだけの活動、報酬制度の抜け道探し、見せかけの精密さにつながります。

このスキルはテンプレートを埋めるものではなく、コーチとして機能します。Doerr（Measure What Matters）、Wodtke（Radical Focus）、Cagan（SVPG のチーム目標）、Castro（成果とアウトプットの違い）、Grove（High Output Management）、Torres（継続的なディスカバリー）、Gothelf と Seiden（Outcomes Over Output）から導かれる実証的なコンセンサスに照らして、OKR セットを作成、レビュー、書き換え、監査します。

対応モード

関与の度合いに応じて、5 つの開始モードを使い分けます。モードはユーザーの表現から判断します。曖昧な場合は Guided をデフォルトにします。応答の冒頭で、検出したモードを明示してください。

• Guided（デフォルト、中程度の関与） - 簡単な診断、ドラフト作成、評価基準に照らした採点、課題の提示を行い、ユーザーに確認を求めます。「X の OKR を書くのを手伝って」のような表現で選択されます。
• One-Shot（低い関与） - 前提条件をすべて明記したうえで、完全な OKR セットを一度に作成します。--oneshot フラグ、または「このコンテキストから OKR をさっと作成して」のような表現で選択されます。
• Sustained Coach（高い関与） - 一度に 1 つの要素を扱う反復的なループを行い、品質基準を満たすまで各ターンで再評価します。「X の OKR を一緒に考えて」のような表現で選択されます。
• Audit Only - ユーザーが既存の OKR を貼り付け、スキルが採点と批評を行います。ユーザーから求められない限り、新しいドラフトは作成しません。「この OKR をレビューして」のような表現で選択されます。
• Rewrite - 問題のある OKR、機能一覧、ロードマップ項目を、成果を重視した OKR に変換します。「この OKR を修正して」または「このロードマップを OKR に変換して」のような表現で選択されます。

使用する場面

• 会社、部門、製品、製品領域、チーム、取り組みのスコープで OKR を計画する
• 上位の OKR や戦略をチームの OKR に落とし込む
• ドラフトの OKR セットの品質をレビューする（Audit Only モード）
• 機能、ロードマップ、取り組みの一覧を成果ベースの OKR に組み替える（Rewrite モード）
• ステークホルダーのレビューに向けて OKR を準備する
• KR が測定可能で、エビデンスに裏付けられているかを確認する

使用しない場面

• ダッシュボードの仕様だけが必要な場合 - measure-dashboard-requirements を使用してください
• イベントトラッキングだけが必要な場合 - measure-instrumentation-spec を使用してください
• 実験だけが必要な場合 - measure-experiment-design を使用してください
• 仮説だけが必要な場合 - define-hypothesis を使用してください
• サイクルが終了しており、エビデンスと学びの統合を含む正式な採点が必要な場合 - measure-okr-grader を使用してください
• チームが純粋に通常業務を行っており、ストレッチ成果ではなく定常状態の KPI を必要としている場合 - OKR は適切な成果物ではありません

手順

OKR の作成またはレビューを求められたら、次の手順に従ってください。

1. モードを検出する ユーザーの表現を読み取り、Guided、One-Shot、Sustained Coach、Audit Only、Rewrite に分類します。明示的なシグナル（--oneshot、「これをレビューして」、「これを修正して」、「コーチして」）を確認してください。曖昧な場合は Guided をデフォルトにします。応答の冒頭で、検出したモードを明示してください。

2. エンパワードチーム診断を実施する（新しいドラフトを作成しない Audit Only では省略） 次の点を簡潔に尋ねてください。

   • 今サイクルに向けて、機能、プロジェクト、日程はすでに確定していますか？
   • KR が進まない場合、チームはサイクルの途中で取り組みを変更できますか？
   • 何を構築するかを決めるのは、このチームですか、それとも別の人ですか？

   回答を empowerment_signal: empowered | feature-team | mixed | unknown として記録します。これは後続の手順で出力の枠組みに影響します。feature-team のシグナルがある場合でも、作業を拒否してはいけません。その代わり、成果物に Disclosure セクションを追加する計画を立ててください。

3. OKRが適切な成果物かどうかを判断する 依頼の本質がプロジェクト計画、KPIダッシュボード、ローンチチェックリスト、仮説、実験、またはステータス報告である場合は、適切なpm-skillまたはチェーンに案内します。OKRではない作業に、無理にOKRの形式を当てはめないでください。

4. 運用コンテキストを分類する スコープ（company | department | product | product-area | team | initiative）、サイクル（quarter | half | annual | launch window | custom）、レベル、およびOKRの種類（committed | aspirational | learning | operational_health | compliance_or_safety）を記録します。コンテキストが不足している場合、サイクルは四半期をデフォルトとします。

5. 戦略的意図を抽出または推測する このOKRセットの動機となる親目標、戦略の柱、顧客の課題、またはビジネス上の圧力を特定します。何も提示されていない場合は、ドラフトの作成前に一度だけ尋ねます。

6. 成果と作業を切り分ける 機能、タスク、プロジェクト、ローンチ、採用人数、活動件数はイニシアチブに移します。OKRは世の中で何が変わるかを示し、イニシアチブはその変化を起こすための賭けです。Castroのリトマス試験を適用します。「バックログに入れられるものは成果ではありません」。

7. Objectiveを作成または改善する Objectiveは定性的で、具体的かつ方向性を示し、サイクルに適したものにします。プロジェクトではなく、望ましい状態の変化を表し、戦略につながるようにします。指標を含めず（数値はKRに記載します）、成果物内で意味を定義しない限り、空虚な形容詞は避けます。

8. Key Resultsを作成または改善する 各KRには、指標の定義、ベースライン（不明な場合はrecommended-to-measure）、目標、期限、エビデンスの情報源、必要に応じてオーナー、指標クラス（leading | lagging | guardrail | health | evidence_generation）、および確信度（high | medium | low | unknown）を含めます。最適化によって対になる指標に悪影響が及ぶ可能性がある場合（エンゲージメント対品質、成長対リテンション、速度対信頼性）は、ガードレールKRを含めます。

   次のセクションにある制約ルールを適用します。

9. イニシアチブを賭けとして整理する 各イニシアチブには、影響を与えることが期待されるKRと、その期待の根拠となる仮定を記載します。イニシアチブは仮説であり、確約ではありません。イニシアチブをKRとして列挙しないでください。

10. OKR品質監査を実施する 以下のルーブリックに照らしてドラフトを評価します。問題を付録に埋もれさせず、該当箇所に記載します。riskまたはfailの評価には、それぞれ具体的な推奨事項を含めます。

11. 必要に応じて、エンパワーメントされたチームに関する開示を適用する empowerment_signal == feature-teamまたはmixedの場合は、開示セクションを追加します。「このOKRセットは、事前に確約された作業を成果につながる賭けとして位置づけています。作業をリリースしても指標が変化しなければ、それは学びであり、デリバリーの失敗ではありません。このサイクルでチームが動かせるのは、リリースを継続することです。OKRが動かせるのは、次のサイクルの計画を更新することです。」シグナルがempoweredの場合は、このセクションを完全に省略します。

12. 未解決の質問を提示する コンテキストからスキルでは解決できず、ユーザーが判断する必要のある事項を記録します。例：サイクル終了後まで続くKRの測定期間、イニシアチブの段階分けの判断、コホートの定義範囲。

13. 信頼できる情報源を記載する この成果物は計画の入力であり、正式なOKRシステムではありません。source_of_truthフィールドに、ユーザーが実際に使用しているOKRトラッカー（会社のOKRドキュメント、Confluenceページ、ダッシュボード、専用プラットフォーム、スプレッドシート、または最新のステータスを管理している場所）を指定します。

14. そのまま使える形に仕上げる 最終成果物からスキルの指示に関するコメントをすべて削除します。最終出力は読者向けのものにしてください。

プロジェクトメモリー契約

.claude/pm-skills.local.md が存在する場合にのみ有効です。ファイルがない場合は、このセクション全体を無視し、上記の説明どおりに動作してください。

• 読み取り： phase、active_initiative、および過去の decision 成果物を読み取り、目的がすでに確定した内容と整合するようにします。確定済みの内容を言い換えることはありません。
• 書き込み： OKR セットを decision 成果物として書き込みます。
• 姿勢： 記入案を提示し、書き込む前に確認を待ちます。ただし、memory_auto_append: true が設定されている場合は、追記して書き込んだ内容を伝えます。
• 書き込みの規律： 書き込む直前にファイルを再読み込みします。提案の作成に使ったコピーから書き込んではいけません。その間にファイルが変更されていた場合は、現在の状態に自分の記入内容をマージし、上書きするのではなく、再度提案してください。自分の記入内容だけを追加し、その他のすべてのフィールドとセクションはバイト単位で同一のままにしてください。実行時にこれを強制する仕組みはなく、ファイルは Git で無視されるため、不注意にファイル全体を書き込むと、別のセッションの作業が失われ、復元できなくなります。

メモリーは、ベースラインや目標値を補うものではありません。記録内容にかかわらず、捏造を拒否する方針は変わりません。

制約ルール（必須／禁止）

これらのルールは譲れません。このスキルは、どのモードでもすべてのルールを適用します。

• 必須： 機能、タスク、マイルストーン、活動回数ではなく、成果（顧客行動の変化、事業 KPI の変動、運用健全性の変化）を測定してください。
• 禁止： ベースライン、目標値、現在値、ベンチマークを暗黙に捏造してはいけません。不明な値は assumption、placeholder、recommended-to-measure、または not-enough-evidence と明記してください。
• 禁止： OKR スコアを個人の評価や報酬の判断材料として使ってはいけません。ユーザーがこれを依頼した場合は断り、その理由を説明してください。
• 必須： 成長、速度、量を促す KR には、少なくとも 1 つのガードレールまたは逆指標となる KR を含めてください。
• 必須： 0.6～0.7 が最適となるのは、意欲的な OKR の場合のみとしてください。コミットメント、コンプライアンス、安全性、信頼性、契約に関する KR の目標値は 1.0 としてください。
• 必須： OKR はチーム単位を標準としてください。個人 OKR が求められた場合は警告し、目標の引き下げや不正確な精密さを招くリスクを説明してください。
• 禁止： 唯一の正式な情報源になってはいけません。ユーザーが実際に使用している OKR トラッカーを示す source_of_truth のポインターを必ず含めてください。
• 必須： 機能開発チームの兆候がある場合は、権限委譲されたチームに関する開示を適用してください。ユーザーの依頼を拒否してはいけません。表現を調整してください。

品質監査ルーブリック

このスキルは、作成またはレビューするすべての OKR セットにこのルーブリックを適用します。各基準を pass、risk、または fail とし、理由を 1 行で示します。

• 戦略との適合性：戦略、上位 OKR、または顧客課題との明確なつながりがある
• Objective の質：具体的で定性的であり、トレードオフの判断に役立つ（スローガン、タスク、指標の寄せ集め、プロジェクト名ではない）
• KR の成果の質：タスク、機能、マイルストーンではなく、成果や行動の変化を測定している
• 測定の質：ベースライン、目標値、期限、エビデンスソースが記載されている（またはプレースホルダーとして明記されている）
• プロダクトへの影響力：チームがその成果に現実的に影響を与えられる
• 集中度：Objective は 1～3 個、各 Objective の KR は 2～4 個
• ガードレール：最適化を目的とする KR について、品質、信頼性、またはリスクを考慮している
• 整合性：親、同僚、依存関係が明確である
• 運用リズム：サイクル、チェックイン、レビューの節目が明示されている
• 完全性：報酬との連動がなく、データを捏造していない
• 権限委譲されたチームに関する開示：機能開発チームの兆候がある場合は含め、権限委譲されている場合は省略する

スキルが検出するアンチパターン

このスキルは以下をスキャンし、拒否するか、書き換えるか、fail の監査評価を付けて明示します。

• 機能提供のKR（「YをAからBに増やす」ではなく「Xをリリースする」）— 成果KRに書き換え、機能はイニシアチブに移す
• タスク件数のKR（学びの成果を伴わない「インタビューを10件完了する」など）— 書き換えるか、エビデンス生成タイプに移す
• 見栄えだけの指標を使ったKR（顧客やビジネスの価値を伴わずに指標が改善する）— フラグを付け、代替案を提案する
• 活動目標（目標が変化ではなく作業を表している）— 書き換える
• 指標を詰め込んだ目標（複数のKPIをつなぎ合わせただけの目標）— 書き換える
• OKRが多すぎる（目標が3つを超える、または目標ごとのKRが4つを超える）— 強制的に優先順位を付ける
• 形だけのカスケード（オーナーシップの論理がないまま、上位のKRをそのままローカルにコピーする）— ネットワーク型の連携に書き換える
• ロードマップのラッパー（OKRがロードマップを再フォーマットしただけ）— 全面的な Rewrite モード
• ベースラインの欠落（目標値を解釈できない）— recommended-to-measure としてマークする
• エビデンスソースの欠落（スコアの出所が誰にもわからない）— not-enough-evidence としてマークする
• 遅行指標のみのプロダクトOKR（プロダクトの成果がないまま、チームが売上を担当する）— 先行指標となるプロダクト成果のKRを追加する
• ガードレールの欠落（最適化によって品質、信頼、継続率が損なわれる可能性がある）— ガードレールKRを追加する
• 報酬との連動（人々が目標を低く設定したり、学びを隠したりするようになる）— 拒否し、理由を説明する
• 個人OKRをデフォルトにすること — チームOKRをデフォルトとし、個人OKRが求められた場合は警告する
• 根拠のないベンチマーク（エビデンスのない一律の目標値）— フラグを付け、出典を確認する
• PMF以前の過剰な指標化（学びが本当の目標なのに、定量的な精密さを装う）— 学習OKRに書き換える

出力要件（v1.0.0）

• 必須セクションを標準順で全て含める：Context、Objective、Key Results、Initiatives as Bets、Guardrails and Health Checks、Alignment Notes、Quality Audit、Open Questions、Suggested Next Step
• empowerment_signal == feature-team | mixed の場合は Disclosure セクションを含め、empowered の場合は省略する
• すべてのKRに、指標の定義、ベースライン（またはプレースホルダーとしてマーク）、目標値、期限、エビデンスソース、指標クラス、確信度を含める
• イニシアチブはKRとは別に記載し、どのKRの達成を目指すものか明示する
• 最適化型の主要KRには、少なくとも1つのガードレールKRを設ける
• 真実の情報源を示す注記を含め、スキル以外の場所を参照する
• 品質監査では、すべての評価基準を対象とし、合格／リスク／不合格を明示する
• Markdown のみで出力する。JSON は使用しない
• 基盤の分類：frontmatter に phase: フィールドを含めず、classification: foundation を使用する

品質チェックリスト

最終確定する前に、以下を確認します。

• モードが検出され、応答の冒頭に明記されている
• 起草時にエンパワードチームの診断を実施し、シグナルを記録している
• 必須セクションが標準順で全て含まれている
• feature-team シグナルがある場合、Disclosure セクションが含まれている
• すべてのKRに、指標、ベースライン（またはプレースホルダー）、目標値、期限、エビデンスソース、指標クラス、確信度がある
• 最適化型の主要KRには、少なくとも1つのガードレールKRがある
• 真実の情報源を示す注記がある
• ベースラインや目標値を捏造していない。不足値は明示的に記載している
• 報酬と連動させる表現がない
• 品質監査を実施し、合格／リスク／不合格を明示している
• アンチパターンの一覧をスキャンし、検出したアンチパターンにフラグを付けるか、書き換えている
• OKRの種類を分類している（committed | aspirational | learning | operational_health | compliance_or_safety）
• スキルの指示に関する解説を最終成果物から削除している
• Markdown のみで、JSON を出力していない

例

references/EXAMPLE.md を参照してください。storevine のサンプルスレッド（Campaigns チーム、2026年第3四半期）で作成したOKR一式を示しています。実際のチーム横断の連携依存関係があるエンパワードチームのプロダクトコンテキストで、Guided モードを実演しています。併用する measure-okr-grader スキルがサイクル終了時のスコアリングを担当し、両者を合わせて四半期の全プロセスをカバーします。