OKR、「特性」をわかって使っていますか？——名前だけ輸入すると、いちばん効かない

「うちはOKRです」。そう言う会社が、増えました。でも、うまくいっていないことも多い。よく「それ、実はMBOになってますよね」なんて言われ方をしますが、僕は、論点はそこじゃないと思っています。OKRかMBOか、という手法の対比の問題じゃない。問題は、OKRが何なのか——その“特性”を理解しないまま、名前と型だけを輸入していることです。今日は、その話をします。

「OKRやろうぜ」の、全部の行にツッコミどころがある

これは、昔僕がいた会社の話です。「OKRやろうぜ」と号令がかかって、こう進みました。

• まず、謎の数字が上にドンと置かれる
• それを、KPIツリーでひたすら分解していく
• 最後、個人は、自分の組織に割り振られたKPIツリーを見て、目標をつくる
• そして、その達成具合で評価する

……で、これがOKRだと言う。いや、それ何ですか？と。正直、全部の行にツッコミどころが溢れています。しかも、そのどれもが、OKRの“特性”の、ちょうど真逆なんです。

• 上の数字に“なぜ”がない。OKRのO（Objective）は、本来“こうなっていたい”という状態のはず（この“なぜ”の話は目標数字の「目的」、答えられますか？に書きました）
• ムーンショット——挑戦的な目標——がない。並ぶのは届きそうな数字ばかり。OKRは背伸びを促す設計なのに、です
• 挑戦してほしいはずなのに、達成度で評価する＝査定に直結している。OKRは、挑戦を促すために査定と切り離すのが特性。直結させたら、誰も背伸びしません
• 組織に割り振られたツリーを、個人がただなぞる。OKRの肝である“自分の仕事が、上の目標にどう接続しているか”を、本人が一度も考えていない

名前はOKRでも、やっているのは、ただ数字を分解して割り当てる作業です。器（名前）を新しくしても、特性を使っていなければ、中身は何も変わりません。

OKRが本当に効くのは、“A（アクション）”を足して毎週見るとき

じゃあ、OKRの特性を活かすと、どうなるのか。僕がいちばん効くと思っているのは、そこに“A（Action）”を一段足して見ることです。OKRは頭文字どおり、ObjectiveとKey Result——実はAなんて入っていません。でも僕は、その先に日々の行動（Action）まで繋げて見るようにしていて、勝手に「OKR-A」と呼んでいます。目標や指標だけでなく、そこに繋がる日々の行動までを、ひとつながりで見る、という考え方です。

大事なのは、そのAが、OKRにどう接続しているかを、毎週振り返ること。「今週やったこの行動は、あのKRに、あのOに、ちゃんと繋がっていたか」。これを週次で回す。そして——ここがミソなんですが——その振り返りの場で、ついでに感謝を伝えるんです。僕のチームでは、この場を「マジ謝謝の会」と呼んでいました。

これをやると、帰属意識が上がって、文化ができてくる。（この“感謝を仕組みで回す”話は「忙しくてフィードバックできない」は、順番が逆にも書きました。）

正直に言うと、名前なんて、どうでもいいんです。OKRでもMBOでも。大事なのは、この4つが揃っているか。

• その目標は、何のためにあるのか（目的があるか）
• 自分が「やりたい」と思えているか
• それが、日々の実感につながっているか
• そのモチベーションを、続かせられるか

この4つは、OKRでもMBOでも、どちらにも絶対に要るものです。逆に、4つがなければ、どんな手法を名乗ろうと、ただの“数字の割り当て作業”にしかならない。名前の問題じゃないんです。

良いOは「状態」で書く——売上10億は、Oじゃない

OKRの特性を、もうひとつ。O（Objective）の書き方です。ここが、いちばんズレやすい。

よくある悪いOは、「売上10億」みたいなやつ。でもこれ、Oじゃないんですよね。10億は、KR（Key Result）に書くべき数字です。

じゃあ良いOは何かというと、“状態”で書くものです。たとえば——「シェア1%を取って、業界の中で“あー、〇〇の会社ね！”と言われている」。これがO。そして、その状態に近づいているかを測る指標として、KRに「シェア1%」「売上10億」が入る。

ポイントは、Oを見たときに、“情景”が浮かぶかどうかです。「あ、そうなったら嬉しいですよね！！」と、絵が見える。数字だけのOには、これがない。（目標を“状態”で定義する話は「定性目標」なんて、存在しないに書きました。）

OKRの正体は「接続の可視化」——だから、ジョブ型で生まれた

ここまでの特性を、ひとことでまとめると、OKRの正体は“接続の可視化”です。自分の仕事（A）が、指標（KR）を通じて、目指す状態（O）に、どう繋がっているのか。それを見えるようにする道具。

だから、OKRが生まれた土壌を見ると、腑に落ちます。OKRは、インテルで生まれ、Googleで広く知られるようになった道具です。どちらも、ジョブ型の組織ですよね。ジョブ型では、一人ひとりの“ジョブ（役割）”がはっきり定義されている。だからこそ、「自分のこのジョブは、組織の目標にどう接続しているのか」を知ることに、大きな意味がある。“接続の可視化”という特性が、まさに効く土壌なんです。

逆に言うと、ジョブがきっちり定義されていない土壌に、OKRだけを名前で持ち込むと、この“接続を知りたい”という動機が働きにくい。結果、冒頭のように「上の数字を分解して割り当てるだけ」に逆戻りする。手法が悪いのではなく、特性と土壌が噛み合っていないんです。

（じゃあ、評価との接続はどうするの？——これも、よく聞かれる論点です。挑戦を促すなら査定と切り離すべき。でも、切り離したら何で評価するの？と。僕は、OKRを“接続の可視化”として使い、評価・給与は最終的にMBOで“貢献”を見せて接続する、という二階建てはあり得ると思っています。ただ、これも唯一解じゃない。どう接続するかも含めて、結局は次の話——「で、どうありたいの？」から逆算して、自分たちの形に決めればいいんです。）

結局、「で、何がしたいの？」

特性を理解して使う。これはこれで、大事です。でも最後に、それ以上に大事な、身も蓋もない話を。

OKRのやりたいことも、MBOのやりたいことも、バリュー評価のやりたいことも、どれもすごく大事です。一長一短で、優劣なんてない。でも——そんなことより、「で、あなたは何がしたいの？」という話だと思うんですよね。

世の中には、美しいフレームワークが溢れています。でも冷静に見ると、あれって、物事をきれいに分解しただけなんです。分解のパターンなら、自分で作ろうと思えば、いくらでも作れる。だからフレームワークは、もっと可変でいいし、自由でいい。輸入した型に、自分たちを無理やり合わせにいく必要なんてない。

誤解しないでほしいのは、「特性を理解しろ」と「自由に変えていい」は、矛盾しない、ということです。道具の意図を知らずに壊すのは、事故。わかった上で、自分たちに合わせて崩すのは、設計。この記事で言いたいのは、後者になろう、という話です。

大事なのは、型の名前でも、型そのものでもなく、目的のほうです。何のために、その目標を置くのか。そこさえ握れていれば、特性を理解した上で、OKRだろうがMBOだろうが、自分たちの形に変えて使えばいい。

おわりに

OKRがうまくいかないのは、たいてい「特性を理解しないまま、名前と型だけを輸入している」からです。OKRの正体は“接続の可視化”で、効くのは、足したアクション（A）を毎週OKRに接続して振り返り、ついでに感謝を交わす——そういう、泥くさい運用のほう。そして、その手前で握っておくべきなのは、いつだって「で、何がしたいのか」という目的です。

コレドウがAIで支えているのも、この“型を埋める”作業ではなく、目標に目的と実感を宿して、日々回し続けるところです。（プロダクトの詳細はこちら）OKRもMBOも部品にすぎない、という全体像はパフォーマンスマネジメントとはにまとめています。