Good Small Company

思索 > KPIとOKRの違いは「プロセス」ではなく「前提」にある

KPIとOKRの違いは「プロセス」ではなく「前提」にある

2026-01-10

KPIとOKRが噛み合わない本当の理由

 OKRを取り入れようとすると、ほぼ必ず起きることがあります。それは、既存の目標管理とのコンフリクトです。それは「目標が多すぎる」「運用が煩雑になる」という声に始まり、「(既存と)どちらを優先すれば良いのか判断つかない」に辿り着いていきます。

 なお、ここでいう既存の目標管理は伝統的なMBOもあれば、プロダクトマネジメント上必要なKGI/KPIなども含みます。たいていの場合、何らかの目標管理があるはずです。ですから、必ずといって良いほど先の問題は起きることになるのです。

 こうした反応は、業種や組織規模を問いません。営業が強い組織でも起きますし、プロダクトを中心とした組織でも起きます。ひとえに「目標」という仕組みがある以上、直面することです。そこで、「運用設計を見直そう」「目標を絞ろう」「やれるチームはやろう」として、対応することもよくあるかと思います。

 しかし、実際に先の対応を取ったとしても、OKR自体への違和感は消えないまま残り続けます。ここで起きている問題は単なる量の問題ではないからです。この違和感は、OKRを「理解していない」から起きているのではなく、OKRを見るときの前提が、まだ切り替わっていないことから生まれています。

問題は「同じ前提のまま」違う種類の目標を読んでいること

 目標の仕組みの背景には、「前提」があります。その目標制度の、いや、組織がもとより抱えている前提が控えているのです。その前提をもとに、目標の仕組みは作られています。組織として何を大事にしたいか、何を評価するか、という前提が機能するように、目標という制度を作っています。

 つまり、既存の目標制度とOKRが手段ややり方として衝突しているのではなく、それぞれが置いている「前提」が噛み合っていないのです。もちろん、組織やチームの持っている「前提」とは、既存目標制度と対応する「これまでの前提」です。その目線のままOKRを捉えたとき、OKRとは「単に目標が増えただけ」に見えるのです。しかも、本筋の活動とは関係のない、余計なものとしてです。

 既存の目標、KPIに代表される「前提」には次のような価値観があるように思います(もちろん、組織によってどこに強弱がついているかは異なります)。

  • はやく成果をあげる人が優秀

  • 達成できるかどうかが評価軸

  • 正解はあらかじめ定義されている

  • 未確定な状態はリスクである

 この前提では、目標とは達成すべきゴールです。ですから、目標は少なく、明確で、優先順位がはっきりしていることが望ましいと言えます。この見方自体は何も間違っていませんね。ビジネスにフォーカスをあてていくにあたっては当然の前提と言えます。問題は、この前提のままOKRを読み始めてしまうことにあります。

 なお、ここまで扱ってきた「前提」とは「位相」という言葉にも置き換えられます。位相とは、同じ物事であっても、どんな前提・目的・向き合い方で扱っているかによって意味が異なってくる、ものの見方・世界観と言えます。位相によってプロダクトづくりが変わってくる話は別でも書いています。

アジャイルを壊しているのは、私たちの「正しさ」だった (二つの位相問題)

OKRで "迫りたいもの" は何なのか?

 KPIの位相のままOKRに向き合うと、OKRもまた達成すべきゴールとして解釈されてしまいます。すると現場では、相手にするゴールが増えることになります。目指すものが不明確になり、優先順位を問わなければならなくなります。これが冒頭で述べた目標が混雑した状態です。

 本来、OKRで扱いたいことは、KPIと同じ位相ではないはずです(同じであるならば、それこそ既存の目標の仕組みに混ぜ込んで、優先順位をつけるべきでしょう)。KPIだけでは捉えきれないことがある。ビジネスフォーカスだけでは抜け落ちていくものがある。それらは、目先のこととしては黙殺できるかもしれないが、後から厄介な問題にかたちを変えて現れてくるものです。

 プロダクトづくりで言えば、例えば「ユーザー」「チーム」「プロダクト」の観点です。

 いずれも、いますぐに何らかの対処をせずとも、ビジネス自体は止まりません。収益とは、昨日までの活動によって生み出される結果であるからです。ユーザーの声を多少聞いていなかったとしても、チームの状態が放置されていたとしても、プロダクトの変更容易性が損なわれていたとしても、明日にも滅びるわけではないのです。しかし、どう考えても、後から問題となって返ってくるものです。

OKRを取り入れる真の狙い

 ことプロダクトの運営においては持続的に価値を提供し続けられることが問われます。ユーザー、チーム、プロダクトのどの面も置き去りにはできません。むしろ、これらの三つの観点を健全にし、向上させていくことがプロダクト事業にとっての競争優位に繋がることになります。それこそ、私たちが手にしたい成果なのではないでしょうか。

 そうした観点が既存の目標の仕組みによって、はるか後景に押しやられてしまう。だからこそ、OKRでそれを引き戻したいのです。成果に近づくて手がかりならば、同じ視界に入れて捉えたいものたちになるはずです。

 そう、OKRとKPIでは位相が異なるのです。OKRでは、「こうすればこう結果が出る」という因果の数を増やすことではなく、ことユーザーにとっての価値を模索しかたちにしていくことを意図したいのです(そしてそれを持続できるように、チームとプロダクトという観点もあわせ持つわけです)。

 先の既存の目標と対比するとOKRは、

  • 正解がまだ定まっていない

  • どの方向が良いか分からない

  • 試すことで、理解を正していく

という状態に向き合うための枠組みと捉えられます。ここでの価値は、「達成」そのものではなく、

  • 何を試したか

  • 何が分かったか

  • 前提がどう変わったか

にあります。

 ここまで振り切ると、「それってOKRの主旨なんだっけ...?」と思われるかたもいるはずです。そう、必ずしもOKRは価値の探索やチーム・プロダクトの向上を念頭に置いた概念というわけではありませんよね。ここで狙いたいのはあくまで「既存の目標制度からこぼれ落ちるが、プロダクト運営上どう考えても重要なこと」を引き上げることなのです。

 そういう意味で、必ずしもOKRである必要もありません。プロダクトゴールでも構いません。別の概念でも結構です。要は意図が実現できるかです。ただ、OKRならば一般的な認知を踏まえると、既存の目標制度に対する「アンチテーゼ」の役割を背負わせやすいのです。

KPIとOKRの違いとは「プロセス」ではなく「位相」

 多くの組織では、「OKR=単に追うべき目標が増えた」という読み違いが起きやすい状況にあります。それはなぜでしょうか。

 その理由は、これまでの組織のあり方が「確実性を高めること」に焦点をあててきたからです。いかに効率良く、最短距離で確実にゴールに到達するか。このゲームのプレイに最適化してきた業務、プロセス、評価の下では、不確実な状態とは避けるべきものになります。ゆえに、

  • 正解がない状態

  • 仮のまま進む状態

  • 成果がまだ見えない状態

これらにどう向き合えば良いか分からなず、心理的にも負荷が高くなるのです。

 そのため、OKRで扱う「(これまでの明確な目標に比べたら)謎な目標」に対することがストレスになり、「目標が多すぎる」「運用が煩雑になる」という声で現れてくるようになります。

 実際には、本当のところ何が負荷なのかもよく分からないままの可能性もあります。OKRに伴うプロセスやルールといった「かたち」のほうが目につき、「新たな運用が増えた=負荷になっている」という理解に辿り着いてしまっている場合もあるでしょう。

 問題の本質は、やり方や方法が増えることではなく、これまでの位相(前提)のまま、新たな位相で扱いたいこと(例えば、ユーザー・チーム・プロダクトの視点)、その仕組み(OKR)を見てしまうところにあるのです。この位相違いのまま進んでしまうと、ハレーションへと至ります。

「私たちは何を獲得したいのか」に立ち返ること

 ここまでくると、はっきりしてきます。KPIとOKRが噛み合わないのは、

  • どちらが優れているか

  • どちらを採用すべきか

という話ではありません。今回はOKRが邪魔モノのほうで書きましたが、逆にKPIのほうが悪者になる場合もあるでしょう。どちらが良い悪いではありません。

 重要なのは、どの位相(前提)で、どの仕組みを利用するのか、その認識と切り替えが必要だということです(本稿ではこの運用については割愛しますが、不確実性への踏み込みについては書籍「アジャイルなプロダクトづくり」が参考なればと思います。書籍紹介スライド)。扱っている前提が違う。その違いを区別しない限り、目標は増え続け、「管理が増えた」という感覚だけが残り続けることになります。

 むしろ、目標が増えた、という感覚は健全な違和感、反応です(目標を絞ろう、明確にしよう、という感覚が動いている)。それは「位相」違いが起きている、置き去りになっていることを示しているのに他なりません。

 「OKRかKPIか」ではなく、私たちは何を獲得したいのか、に立ち返りましょう。その意図にあった方法を選べればそれで良いのです。

市谷のnote

open_in_new