この記事の要約
- OKRが形骸化すると、チームの離職率上昇、意思決定の遅延、プロダクトの迷走という3つの致命的な症状が組織を蝕み始める
- 形骸化の根本原因は「設定時の解像度不足」「運用時の文脈喪失」「振り返り時の学習欠如」という3つの構造的問題にある
- OKRの各フェーズに「定量分析→深掘りインタビュー→プロトタイプ検証」のサイクルを組み込むことで、数値と顧客の声が連動した本質的な成長が実現できる
「今四半期のKR、達成率100%でした….」
こんな報告をした後ふと思うことがあります。
- で、ユーザーは喜んでいるのか？
- チームは成長実感を持てているのか？
- そもそも、この数字を追うことに意味はあったのか？
僕はテック企業でPdMをやっていて、これまで700人以上にユーザーインタビューをしてきました。その経験から考えているのは、OKRが数字だけの管理ツールになった瞬間、組織は緩やかに死んでいくということです。
本記事では、OKRの形骸化がもたらす具体的な症状から、その構造的原因、そして最も重要な「ユーザーリサーチをOKRプロセスにどう組み込むか」までを紹介します。
OKRが形骸化すると組織に起こる3つの致命的症状
症状1：優秀なメンバーから順に離れていく
OKRが形骸化した組織で最初に起こるのは、優秀なメンバーの離職です。
なぜか？それは「数字を達成すること」と「価値を生み出すこと」が乖離するからです。
例えば「MAU20%増」というKRがあったとします。チームは必死に施策を打ちます。プッシュ通知を増やす、ログインボーナスを付ける、メールを大量配信する。確かに数字は上がります。MAUは20%増を達成。
でも現場のエンジニアやデザイナーが「ユーザーは別に喜んでいない。むしろ通知がうざいという声が増えている。ログインボーナス目的の幽霊ユーザーが増えただけ。本質的な課題は何も解決していない。」と思っていたらどうでしょうか？
この状態が続くと以下のような状態に陥ります
- 最初の違和感：「この数字って意味あるの？」という疑問が生まれる
- モチベーション低下：自分の仕事が無意味に感じられ始める
- 形だけの達成：KR達成の祝杯を挙げても、別に喜べない
- 優秀な人から離脱：「もっと”顧客にとって意味のある”仕事がしたい」と転職を決意
特に優秀なメンバーほど、自分の仕事が生み出す価値にこだわります。だから「数字は達成したけど、ユーザーは幸せになっていない」という状況に耐えられない。
結果、スキルの高い人材から順に組織を去り、残るのは「言われた数字を追うだけ」の人材。これがOKR形骸化の最初の症状です。
症状2：意思決定が遅延し、全てが中途半端になる
形骸化の第二の症状は、意思決定の致命的な遅延です。
「数値は達成したけど、次どうする？」
この問いに答えられないのは、数値の背後にある「なぜ」を理解していないからです。結果として以下のような状態になります。
- 施策の優先順位が付けられず「とりあえず全部やろう」となる
- リソースが分散し、どの施策も60点の出来で終わる
- 四半期ごとに方針がコロコロ変わる（意図せずに）
- 競合が1つの施策を100点で実行している間に、10個の施策を30点で実行して負ける
実際、Slackが初期に成功した理由の一つは、「チーム内メッセージ送信数」というKRの裏にある「メールを殺す」という明確なObjectiveを全員が理解していたからです。だから機能追加の判断も「これはメールを減らすか？」という一点で高速に決められました。
症状3：プロダクトが迷走し、競合に顧客が流出する
そして、最も深刻な第三の症状はプロダクトそのものの迷走です。
- 機能は増えるが使われない
- 競合の後追いばかりで差別化要素ゼロ
- ユーザーからの評価と社内評価の乖離（社内では成功、市場では失敗）
- CAC（顧客獲得コスト）回収期間が12ヶ月から24ヶ月に悪化
- LTV（顧客生涯価値）の頭打ちと解約率の上昇
OKRは形骸化する3つの構造的欠陥
欠陥1：設定時の解像度不足——表層的な課題設定の罠
OKR設定時の最大の問題は、課題の解像度が圧倒的に低いことです。
典型的な失敗例：
- 「MAUを上げる」「解約率を下げる」だけの薄っぺらいObjective
- ユーザーセグメントを無視した一律目標（新規も既存も同じKR）
- 競合ベンチマークだけで決めた「他社がやってるから」目標
例えば「解約率を10%から5%に下げる」というKRがあったとします。でも、どのセグメントの、どんな理由による解約を、どう防ぐのかが見えていない。
例えば、SaaSプロダクトの解約理由を定性/定量含めて細かく分解していくと大きな抑えるべきパターンとして以下の3つが見えたとします。
- セグメントA（全体の40%）：初月で主要機能を3回以上使わない → 解約率80%
- セグメントB（全体の35%）：3ヶ月目に利用頻度が半減 → 解約率60%
- セグメントC（全体の25%）：競合への乗り換え → 解約率30%
本当に、ここからさらに”なぜ？”をふかぼっていきますが、このレベルだとしても、ただ「解約率5%」を目指しても打ち手が総花的になるだけです。
欠陥2：運用時の文脈喪失——「なぜ」が消えていく組織
OKRは設定して終わりではありません。むしろ運用フェーズでこそ「なぜこの数字を追うのか」という文脈の共有が重要なのに、多くの組織はここで失敗します。
文脈喪失のパターン：
- キックオフで説明して終わり（3ヶ月後には誰も覚えていない）
- 新メンバーへの文脈共有ゼロ
- 施策とObjectiveの紐付けが曖昧（なぜこの機能がこのOKRに効くのか不明）
- 週次MTGが数字の読み上げ大会（進捗率の確認だけで「So what？」がない）
OKRの「Why」を毎週1-2分でも共有するチームがそうでないチームと比べてチームモチベーションもKR達成率も高いことは想像に難くないでしょう。
欠陥3：振り返り時の学習欠如——同じ失敗を繰り返す愚行
最も致命的なのは、振り返りが「◯×つけて終わり」になることです。
学習欠如の症状：
- 達成/未達成の事実確認のみ（なぜ達成できたかの構造理解なしもしくは浅い）
- 失敗から学習せず、次の四半期も同じミスを繰り返す
- 成功要因を言語化できず、再現性がない「まぐれ当たり」の連続
- 個人の経験が組織の知識にならない（担当者が変わると振り出しに戻る）
ユーザーリサーチをOKRに組み込む実践フレームワーク
ここからが本題です。形骸化を防ぐために、OKRの設定・運用・振り返りの各フェーズにユーザーリサーチをどう組み込むか、具体的な手法を解説します。
【設定フェーズ】3層構造リサーチで課題の解像度を極限まで上げる
Layer 1：定量分析でセグメント別の行動差異を特定
まず、SQLやアナリティクスツールを使ってユーザーの行動パターンを細分化します。
実践例：解約ユーザーの行動パターン分析
- セグメントA（初期離脱組）：登録後7日以内に主要機能を使わない → 解約率85%
- セグメントB（中だるみ組）：2ヶ月目から利用頻度が週3回→週1回に減少 → 解約率65%
- セグメントC（乗り換え組）：競合の新機能リリース後に解約 → 解約率45%
この時点で「一律で解約率を下げる」のではなく、セグメント別にObjectiveを分ける/もしくは特定のセグメントに注力する必要性が明確になりました（分ける/特定セグ注力、はリソース状況に左右されます）。
重要なのは、この段階で定量的な数値の追い込みをロジックツリーを描きながら行うことです。数字をどんどんブレイクダウンして、問題のありどころや伸ばしどころを見つけていきます。
仮説設定や分析についてもは以下の記事を参照してください。
Layer 2：N=5の深掘りインタビューで「なぜ」を構造化
定量で見えたパターンの背後にある理由をインタビューで明らかにします。
インタビュー設計のポイント対象選定：
- 各セグメントから行動の極端な上位/下位ユーザーを2名ずつ
- 解約したユーザー、継続しているが利用頻度が低いユーザー、ヘビーユーザーを混ぜる
質問の例：
- 「なぜ使わなくなったか」ではなく「最後に使った時の状況を詳しく教えてください」
- 「他にどんな方法で同じ課題を解決していますか」（裏タスクの特定）
- 「もし魔法の杖があったら、この状況がどう変わって欲しいですか？」
アウトプット：
ユーザージャーニー上の具体的なペインポイントマップ（どの瞬間に、何に困って、どう行動したか）
各セグメント5名を基準にインタビューを行っていきましょう。
このサイトでは特にユーザーインタビューは重点的に解説しているのでぜひこちらの記事も読んでみてください。
Layer 3：プロトタイプ検証で仮説を確定
インタビューで見えた課題に対する解決の方向性をプロトタイプで検証します。
OKR設定時は簡易的なもので十分です。
検証方法の具体例作成物：
- Figmaで作る3画面程度のモック x 複数
- もしくは既存画面に付箋を貼った「こうなったらどう？」レベルのもの
検証方法：
- 5名×30分のユーザビリティテスト
- NPSを複数プロトタイプ vs 現状のプロダクトで聴取
- 評価が現状のプロダクトを大きく上回らない場合は必ずその理由を深掘り
判断基準：
80%以上が現状のプロトタイプ以上とNPSで評価 → このObjectiveは正しい方向性
【運用フェーズ】週次/月次サイクルに組み込む
OKRは設定したら終わりではありません。運用中も常にユーザーの声を聞き続ける仕組みが必要です。
隔週/月次スプリントレビューへの組み込み（継続的実施）
2週間/1ヶ月のスプリントごとに、以下のサイクルを回します：
| 曜日 | アクション | 具体的な内容 |
|---|---|---|
| 月曜 | 定量チェック | 先週リリース機能の数値確認（利用率、エラー率、完了率） |
| 火曜 | OKRライン未達ユーザーへのクイックインタビュー | 目標値に届いていないユーザー2名に15分ずつヒアリング |
| 水曜 | インサイトまとめ | 定量×定性から仮説を更新、次の打ち手を検討 |
| 木曜 | 優先度調整 | 次スプリントのバックログを見直し |
| 金曜 | 全社共有 | 15分の録画で「今週分かったこと」を配信 |
特に重要なのは「OKRライン未達ユーザー」への即座のアプローチです。例えば「週3回利用」がKRなのに週1回しか使っていないユーザー、「5分以内でタスク完了」がKRなのに15分かかっているユーザーこそ、改善のヒントを持っています。
・未達ユーザー：3日で離脱したユーザー
インタビューで判明した事実例：
- 「最初の設定で15個も入力項目があって疲れた」
- 「何ができるようになるのかイメージが湧かなかった」
- 「他のツールは3クリックで使い始められたのに」
改善施策：
オンボーディングを「必須3項目」と「あとで設定（スキップ可）」に分離
→ 継続率が52%から68%に改善（例）
月次OKRチェックインでの活用
月に1回のOKRレビューでは、進捗率だけでなく「質的な前進」を評価します。
月次レビューの型必須共有項目：
- 今月のユーザーの声3つ（ポジティブ1つ、ネガティブ1つ、想定外1つ）
- OKRライン未達ユーザーから見えた共通課題
- KR未達の場合は必ず「なぜ」の定性調査結果
議論のポイント：
- 数値は上がっているが、ユーザー満足度は上がっているか？
- 未達ユーザーに共通するペインポイントは何か？
- 新たに見えてきた課題は何か？
【振り返りフェーズ】失敗を資産化し、学習を組織知にする
四半期の振り返りこそ、組織の学習能力を決める最重要プロセスです。
四半期レトロスペクティブの型（90分）
1. 数値結果の確認（15分）
- 各KRの達成率
- 予実差異の確認
2. 達成/未達成の構造分析（45分）
- ユーザーセグメント別の反応差（どのセグメントに効いて、どこに効かなかったか）
- OKRライン未達ユーザーの共通パターン（なぜ目標値に届かなかったか）
- 外部要因vs内部要因の切り分け（競合の動き、市場変化、組織課題）
3. 学習の言語化と次期への反映（30分）
- 「○○という仮説は△△の条件下でのみ成立する」形式で整理
- 次期OKRへの具体的な反映ポイント
- 組織のナレッジベースに蓄積
失敗の資産化フォーマット
失敗こそ最高の学習機会です。以下のフォーマットで必ず言語化して共有します。
失敗レポートテンプレート状況：Q2のObjective「新規ユーザーの定着率を50%に向上」に対して
行動：オンボーディングチュートリアルを10ステップから3ステップに簡略化
結果：定着率は35%→38%の微増に留まる（目標未達）
OKRライン未達ユーザーへのインタビューから判明した原因：
- ステップ数の問題ではなく、「何ができるようになるか」のゴールイメージが不明確だった
- ユーザーは「簡単さ」より「確実に価値を感じられること」を求めていた
- 特に定着率30%以下のユーザーは「最初の成功体験」が全くなかった
学習：
- オンボーディングの改善は、ステップ数より「初回成功体験の設計」が重要
- 特にBtoBでは「上司に報告できる成果」を10分以内に作れることが鍵
- OKRライン未達ユーザーこそ、改善の最大のヒントを持っている
次期への反映：
「10分で最初のレポートを作成できる」を新たなKRに設定
今日から実践できるアクション
1. 次回のOKRレビュー前に「OKRライン未達ユーザー」を1名だけインタビューする
目標値に最も届いていないユーザー1名に、30分だけ時間をもらってください。「なぜ使えていないのか」を聞くだけで、数値の裏にある真実が見えてきます。
2. 現在のKRに「なぜこれを追うのか」を50文字で説明する
今すぐ、各KRの横に「なぜこの数値が重要なのか」を書き出してみてください。書けないKRは、そもそも追う意味がない可能性が高いです。
3. 失敗レポートを1つ作成し、Slackで共有する
直近の「未達成KR」を1つ選び、上記のフォーマットで失敗レポートを作成。特に「OKRライン未達ユーザーの声」を必ず含めて、チームのSlackに投稿することで、失敗を隠さない文化の第一歩になります。
4. 週次MTGに「今週聞いたユーザーの声」を1つ追加する
定例会議のアジェンダに「ユーザーの声共有（2分）」を追加。特に「KRの目標値に届いていないユーザーの声」を優先的に共有しましょう。
5. SQLで「KR未達ユーザーの行動パターン」を1つ見つける
新しいプロダクトを担当した時に押さえるべきデータを参考に、KRの目標値に届いていないユーザーの共通行動を可視化してみてください。
Q&A
Q1. OKRライン未達ユーザーにインタビュー依頼しても、応じてくれません。どうすればいいですか？
A1. インセンティブを明確にすることが重要です。「あなたの声で製品が改善される」という価値提供に加えて、Amazonギフト券などの謝礼も検討してください。また、CSチームと連携して、サポート対応の延長として自然にヒアリングする方法も効果的です。それでも難しい場合は、問い合わせログの分析から始めるのも一つの手です。
Q2. 経営層が「達成率だけ見ればいい」と言って、未達ユーザーの声に興味を示しません。
A2. まず「なぜKRが未達だったのか」を未達ユーザーの具体的な声で説明するところから始めてください。例えば「継続率が目標の70%に対して55%だった理由は、未達ユーザーの8割が『初期設定で挫折した』と答えています」のように、数値と声をセットで報告すると、経営層も無視できなくなります。
Q3. OKRとKPIの違いがよく分からず、結局KPI管理になってしまいます。
A3. 最大の違いはObjectiveという「定性的な目標」の存在です。KPIは「何を測るか」ですが、OKRは「なぜそれを目指すのか」という物語があります。例えば「解約率5%」はKPIですが、「ユーザーが毎日ログインしたくなるプロダクトにする」というObjectiveがあって初めてOKRになります。この「なぜ」を見失わないために、ユーザーリサーチが不可欠なんです。
Q4. OKRライン未達ユーザーが多すぎて、誰にインタビューすればいいか分かりません。
A4. 「最も未達度が高いユーザー」と「ギリギリ未達のユーザー」の両極端から始めてください。例えば継続率70%が目標なら、10%で離脱したユーザーと、65%で惜しくも届かなかったユーザーの両方に聞く。この差分から、改善の優先順位が明確になります。また、コホート分析で未達ユーザーをセグメント化してから選ぶのも有効です。
Q5. ユーザーリサーチをやっても、結局声が散発的で一貫性がありません。
A5. それはセグメンテーションが甘い可能性が高いです。「全ユーザー」で見るのではなく、利用頻度、利用歴、企業規模、利用目的などで細かくセグメントを切ってください。特に「OKRライン未達」という共通項を持つユーザー内でさらに細分化すると、驚くほど共通の声が出てきます。また、グランデッド・セオリー・アプローチを使って、散発的な声から共通パターンを抽出する手法も有効です。
参考情報
- Doerr, J. (2018). Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs. Portfolio.
- McChesney, C., Covey, S., & Huling, J. (2012). The 4 Disciplines of Execution. Free Press.
- Cagan, M. (2017). INSPIRED: How to Create Tech Products Customers Love. Silicon Valley Product Group.
- Google re:Work. (2022). “Guide: Set goals with OKRs.” https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/
- McKinsey & Company. (2024). “The State of Organizations 2024: The democratization of work.” McKinsey Global Institute.
- Ries, E. (2011). The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business.
- Torres, T. (2021). Continuous Discovery Habits. Product Talk LLC.
- Olsen, D. (2015). The Lean Product Playbook. Wiley.
コメント