mcpField
S
setting-okrs-goals

setting-okrs-goals

github.com/refoundai生産性1.4k2.0k 回インストール15 週間前に更新
リポジトリ

setting-okrs-goals について

55人のプロダクトリーダーの知見をもとに、プロダクトチームの目標設定を支援するスキルです。戦略から測定可能なOKRを組み立て、目標計画で起こりやすい問題も示します。

主な機能

  1. 01目標設定の背景とレベルの確認
  2. 02OKRと戦略の接続
  3. 03測定可能な成果指標の作成
  4. 04定量・定性・財務指標のバランス
  5. 05目標設定でよくある問題の把握

活用シーン

  1. 01会社・チーム・個人のOKR作成
  2. 02主要な結果がタスクになっていないか確認
  3. 03チーム目標を会社の優先事項に整合
  4. 04四半期の目標設定プロセスを計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/refoundai/lenny-skills --skill setting-okrs-goals

インストール後、Claude Code で/setting-okrs-goalsを入力して読み込まれたか確認します。

同梱ファイルreferences/guest-insights.md

詳細

OKR と目標の設定

55 人のプロダクトリーダーから得たフレームワークと知見を活用し、ユーザーが効果的な目標と主要な結果を作成できるよう支援します。

支援の進め方

ユーザーから OKR や目標設定について相談された場合:

  1. 状況を把握する - 会社の成長段階、チームの規模、既存の目標があるのか、ゼロから始めるのかを尋ねます
  2. レベルを明確にする - 会社、部門、チーム、個人のどの目標なのかを確認します
  3. 戦略を確認する - 目標を設定する前に、明確な戦略があることを確認します(目標は戦略の出発点ではなく、到達点であるべきです)
  4. 構成を整える - よくある落とし穴を避けながら、人を鼓舞する目標と測定可能な主要な結果を作成できるよう支援します

基本原則

目標は会社の目標から一段階以内に置く

Matt LeMay:「会社の目標から一段階以上離れてはいけません。何層にもわたる連鎖で目標が見えなくなるのを防ぎましょう。」チームの目標が組織内の階層を何段も下ったところに埋もれるのではなく、会社の主要目標に直接結び付くようにします。

目標だけでなく、仕組みを作る

Lane Shackleton:「目標に執着するのではなく、そこにたどり着くための仕組みに執着しましょう。」一度きりの OKR の目標を、定期的な顧客ミーティングなど、長期的な感覚を養う継続的な「常時稼働」の仕組みに置き換えます。

OKR は戦略と実行をつなぐ

Christina Wodtke:「主なメリットは、戦略だけでは得られない、OKR を通じた具体的なアクションが数多く生まれることです。」OKR を活用して抽象的な戦略を四半期ごとの具体的な数値に落とし込み、四半期末の評価を通じて学習サイクルを生み出します。

3 つの主要な結果で多角的に捉える

Christina Wodtke:「3 つがいいと思います。非常に明確な数値のもの、品質のように少し曖昧なもの、そして金額に関するものです。」定量的、定性的、財務的な指標のバランスを取り、成功を包括的に把握します。

比率ではなく、絶対数を使う

Archie Abrams:「比率やパーセンテージは、分母を減らすことで『操作』できてしまうため、危険な指標です。」不正な数値操作を防ぐため、目標を「コンバージョン率」から「特定の状態に到達したユーザーの絶対数」に切り替えます。

野心的な目標が新たな考え方を促す

Daniel Lereya:「野心的な目標を立てると、違った考え方ができるようになります。実現可能かどうかわからない場合でも、私たちはそうするのが大好きです。」ただ「もっと頑張る」だけでは達成できない目標を設定し、「より賢く働く」ことや根本的な見直しを促します。

戦略の議論と OKR の議論を分ける

Lane Shackleton:「OKR は戦略そのものではありません。戦略の議論と OKR の議論を切り離すことが重要です。」OKR の計画に先立ち、戦略について話し合う場を別に設けて、「何をするか」の陰に「なぜするか」が隠れないようにします。

計画にかける時間を抑える

Lane Shackleton:「計画の 10%ルールです。実行期間の 10%を超えて計画に費やさないようにしましょう。」四半期の計画であれば、計画プロセスに費やす時間は約 1 週間以内にします。

アウトプットではなく、成果に注目する

Marty Cagan:「本物のプロダクトチームでは、問題を実際に解決したときに成功を祝います。だからこそ、プロダクトチームが重視するのはアウトプットではなく成果だと言うのです。」機能をリリースしたかではなく、問題を解決できたかによって成功を定義します。

目標はコミュニケーションの手段

Molly Graham:「会社の目標は 3 つを超える必要はありません。最も重要なことを人々に知ってもらうためのものです。」目標はシンプルにし、優先順位を明確にして、すべての目標に担当者を 1 人だけ割り当てます。

ユーザーを支援するための質問

  • 「今、会社が最も重視している目標は何ですか?このチームの目標はそれとどう結び付いていますか?」
  • 「成功したかどうかをどのように判断しますか?どの具体的な数値が変化すればよいですか?」
  • 「この目標は、障害を乗り越えてチームの意欲を保てるほど人を鼓舞するものですか?」
  • 「主要な結果は成果(成功したと判断する方法)ですか、それともタスク(やることのリスト)ですか?」
  • 「この目標に向けた進捗を『常時稼働』にするために、どんな仕組みを作れますか?」
  • 「この目標を達成してもユーザー体験を損なった場合、それでも成功と言えますか?」

よくある指摘事項

  • タスクになっている主要な成果 - 主要な成果は、完了すべき活動のチェックリストではなく、測定可能な成果にする必要があります
  • 目標が多すぎる - 企業の目標は3つ以内にする必要があります。それ以上になると焦点が分散し、優先順位の取捨選択ができなくなります
  • 曖昧な目標 - 目標は、ありきたりな企業用語ではなく、朝起きるのが楽しみになるようなものにする必要があります
  • 戦略を立てる前に設定された目標 - 具体的な戦略がなければ、OKRは誤った精密さを装った無意味な演習になります
  • 単一の指標への過度な偏重 - この偏重により、数値を動かすというだけで、顧客に不利益をもたらす機能を維持する動機が生まれる可能性があります

詳細

55人のゲストから得た74件の洞察については、references/guest-insights.mdをご覧ください。

関連スキル

  • ノーススターメトリクスの策定
  • プロダクトビジョンの定義
  • ロードマップの優先順位付け
  • ステークホルダー間の合意形成

コメント