ひとことで言うと#
OKR(Objectives and Key Results)をプロダクト開発に特化して運用する手法。**「何を目指すか」(Objective)と「どうなったら達成と言えるか」(Key Results)**を明確にすることで、チーム全員が「なぜこの機能を作るのか」を理解した状態で開発を進められる。
押さえておきたい用語#
- Objective(オブジェクティブ)
- 定性的でチームを鼓舞する目標のこと。数字は入れず、「朝起きてワクワクする」レベルのインスパイアリングな一文で書く。
- Key Results(キーリザルツ)
- Objectiveの達成度を測る定量的な成果指標のこと。各Oに2〜4個設定し、「〇〇を△△から□□にする」の形式で書く。
- イニシアティブ(施策)
- Key Resultsを動かすための具体的なアクションのこと。OKRが変わらない限り、施策は柔軟に変更してよい。
- スコアリング
- 四半期末にKRの達成度を0.0〜1.0で評価すること。0.6〜0.7が「いい感じ」の着地点。1.0なら目標が低すぎた。
プロダクトOKRの全体像#
こんな悩みに効く#
- 機能を作っても作ってもビジネスの数字が動かない
- 経営層とプロダクトチームで「成功の定義」が違う
- 四半期が終わるたびに「結局何が進んだんだっけ?」となる
基本の使い方#
Objectiveは定性的で、チームを鼓舞する一文。数字は入れない。
良いObjectiveの条件:
- インスパイアリング: 「チームが朝起きてワクワクする」レベル
- 達成可能だがチャレンジング: 60〜70%の達成確度が目安
- 期間が明確: 通常は四半期(3ヶ月)
良い例:
- 「初回ユーザーが迷わず価値を実感できる体験を作る」
- 「エンタープライズ顧客が自信を持って導入を決められる状態にする」
悪い例:
- 「売上を上げる」(曖昧すぎる)
- 「DAUを50,000にする」(数字はKey Resultsに書く)
各Objectiveに2〜4個のKey Resultsを設定する。KRは定量的で、測定可能でなければならない。
Key Resultsの書き方:
- 「〇〇を△△から□□にする」 というフォーマットが基本
- **アウトプット(作ったもの)ではなくアウトカム(もたらした変化)**で書く
例: O「初回ユーザーが迷わず価値を実感できる体験を作る」
- KR1: オンボーディング完了率を40%から70%にする
- KR2: 初日のアクティベーション率を25%から50%にする
- KR3: 初回利用後のNPSを+20から+40にする
OKRが決まったら、KRを動かすための具体的な施策を考える。
ポイント: 施策はOKRの「手段」であり、目的ではない。施策Aを実装してもKRが動かなければ、施策Bに切り替える。OKRが変わらない限り、施策は柔軟に変えてよい。これがロードマップ駆動との最大の違い。
週次チェックイン(15分):
- 各KRの現在値を確認
- 「このままのペースで達成できるか?」を赤黄緑で評価
- ブロッカーがあれば即対処
四半期末スコアリング:
- 各KRを0.0〜1.0でスコアリング
- 0.6〜0.7が「いい感じ」の着地点。1.0なら目標が低すぎた
- スコアは評価に直結させない(チャレンジを促すため)
具体例#
状況: 従業員60名のBtoB SaaS。ARR8,000万円。トライアル転換率と大企業導入が課題。
プロダクトチームのOKR:
O1: トライアルユーザーが「これなしでは仕事にならない」と感じる体験を作る
- KR1: 無料トライアルから有料転換率を12%から25%にする
- KR2: トライアル期間中の週5日以上利用ユーザーを30%から55%にする
- KR3: トライアル終了時の「このツールなしでは困る」回答率を50%以上にする
O2: エンタープライズ顧客の導入障壁をゼロにする
- KR1: セキュリティチェックシートの事前準備率を100%にする
- KR2: 導入決定から全社展開までの期間を平均60日から30日にする
- KR3: 導入担当者のCSAT(顧客満足度)を4.5以上にする
| 指標 | OKR導入前(Q1) | Q3末 |
|---|---|---|
| トライアル→有料転換率 | 12% | 22%(スコア0.7) |
| エンタープライズ導入期間 | 60日 | 38日(スコア0.6) |
| ARR | 8,000万円 | 1.15億円 |
「なぜこの機能を優先するのか」がOKRで明確になり、エンジニアの納得感が大幅に向上した。施策は途中で3回変更したが、OKR自体は変えなかった。
状況: DAU30万人のモバイルパズルゲーム。新規DLは順調だが、7日継続率が18%と低迷。収益の90%を占めるヘビーユーザーの離脱が加速。
プロダクトOKR(Q3):
O: プレイヤーが「毎日開きたくなる」習慣を作る
- KR1: 7日継続率を18%から35%にする
- KR2: DAUあたりの平均セッション数を1.3回から2.0回にする
- KR3: ソーシャル機能利用率を5%から20%にする
施策の変遷:
| 週 | 施策 | KR1への影響 | 判断 |
|---|---|---|---|
| W1-2 | デイリーボーナス強化 | +2%(18→20%) | 効果薄、継続 |
| W3-4 | フレンド対戦機能追加 | +8%(20→28%) | 効果大、加速 |
| W5-8 | ギルド機能+週間チャレンジ | +6%(28→34%) | 目標に接近 |
| 指標 | OKR設定時 | Q3末 |
|---|---|---|
| 7日継続率 | 18% | 34%(スコア0.65) |
| DAUあたりセッション数 | 1.3回 | 1.9回(スコア0.6) |
| ARPDAU | 15円 | 22円 |
施策を柔軟に変えながらもKRは変えなかった。「デイリーボーナスは効かない」という学びをすぐに施策変更に反映できたのは、OKRで判断基準が明確だったから。
状況: 人口15万人の自治体。子育て支援アプリを1年前にリリースしたが、DL数は3,000でアクティブユーザーはわずか400人。「作ったけど使われない」状態。
プロダクトOKR(上半期):
O: 子育て中の保護者が「このアプリがないと不安」と感じる存在になる
- KR1: 月間アクティブユーザー数を400人から2,000人にする
- KR2: 健診予約のアプリ経由率を5%から40%にする
- KR3: 「このアプリは役立っている」アンケート回答を80%以上にする
施策:
- 出生届提出時に窓口でアプリ登録をサポート(チャネル施策)
- 予防接種のリマインド通知(キラー機能)
- 月齢別のお役立ち情報プッシュ配信(エンゲージメント)
| 指標 | OKR設定時 | 6ヶ月後 |
|---|---|---|
| 月間アクティブユーザー | 400人 | 1,850人(スコア0.6) |
| 健診予約アプリ経由率 | 5% | 35%(スコア0.7) |
| 役立っている回答率 | 52% | 84%(スコア0.8) |
| 窓口問い合わせ数 | 月800件 | 月520件(-35%) |
「DL数を増やす」ではなく「役立つ存在になる」をObjectiveにしたことで、使われる機能の開発に集中できた。行政プロジェクトでもOKRは有効。
やりがちな失敗パターン#
- Key Resultsがアウトプット(成果物)になっている — 「検索機能をリリースする」はKRではなくタスク。「検索経由のタスク発見率を30%にする」がKR。作ったものではなく、起きた変化を測る
- OKRが多すぎる — 1チームにObjective 5個、KR 20個は多すぎ。O は2〜3個、KRは各Oに2〜4個が上限。多いと全部中途半端になる
- OKRを人事評価に直結させる — スコアが評価に影響すると、チャレンジングな目標を設定しなくなる。OKRはあくまで方向性を揃えるためのツール。評価は別の仕組みで行う
- 施策をOKRに固定してしまう — 「ガイドツアーを作る」をKRにすると、ガイドツアーが効かなくても変えられない。KRは成果、施策は柔軟の原則を守る
まとめ#
プロダクトOKRは「作る」と「成果を出す」をつなぐ架け橋。Objectiveでチームの情熱に火をつけ、Key Resultsで進捗を客観的に測り、施策は柔軟に変えていく。四半期ごとにこのサイクルを回すことで、「忙しいけど成果が出ない」状態から脱却できる。