【OKR連載①】OKRの議論は、目標管理フォーマットからパフォーマンス管理の運用体系へ移行している

OKRを再び取り上げる企業が増えるたびに、似たような場面が繰り返される。新しいフォーマットが作られ、部門別の目標が入力され、四半期ごとの点検会議が設定される。しかし数カ月が過ぎると、OKRは既存のKPI表の別名になったり、評価シーズンに取り出して見る参考資料へと押しやられたりする。

問題はOKRそのものが流行しているかどうかではない。2026年のパフォーマンス管理の議論で、より重要な問いは別にある。企業が目標をどれだけうまく書くかではなく、戦略優先順位と実行責任、フィードバックのリズム、評価・報酬の関係を一つのシステムの中で説明できるかどうかだ。この点でOKRは、目標管理フォーマットではなくパフォーマンス管理の運用体系の問題へと移行する。

OKRが再び重要になった理由は、フォーマットではなく整合の問題にある

What MattersによるOKRの説明は、OKRをObjectives and Key Results、すなわち目標と主要な結果の組み合わせとして定義している。ここで重要なのは「目標を書く」ことではなく、「進捗状況を追跡し、整合を生み出し、測定可能な目標を中心に集中度を高める」という説明である。OKRは目標文そのものよりも、組織が同じ方向を見ているかを確認する装置に近い。

この違いを見落とすと、OKRはすぐにKPIの別名になる。KPIは運用上の成果を継続的に確認する指標である。売上、採用リードタイム、離職率、研修修了率、顧客応答時間のように、安定的に管理すべき数字がここに含まれる。一方OKRは、組織が一定期間に何を変えたいのか、その変化が実際に起きたのかを判断するための約束である。同じ数字を使っても、使い方が異なる。

What Mattersは、OKRは通常、一つのObjectiveの下に3〜5個のKey Resultsで構成されると説明している。また、定められた期間、一般的には四半期単位で点検するとしている。この構造が伝えるメッセージは明確だ。OKRはすべての業務を入れる器ではなく、その期間に組織が本当に集中すべき変化だけを残す編集装置である。

Googleの事例が示すのは、高い目標よりも共通の方向である

OKRの代表例としてよく挙げられるGoogleは、社内のOKR playbookでOKRを「高い目標を伝え、測定し、達成するためのプロセス」と説明している。この文は、OKRが単なる目標入力フォーマットではなく、コミュニケーションの方法であることを示している。目標が高いという事実より重要なのは、複数のチームが同じ優先順位を置いて動いているかどうかである。

Google playbookはOKRを一つのタイプとしてだけ見ていない。committed OKR、aspirational OKR、cross-team OKRを区分している。committed OKRは文字どおり達成を約束した目標に近く、aspirational OKRは道筋が完全には確認されていない挑戦的な目標に近い。cross-team OKRは複数の組織が共に貢献しなければならない目標を扱う。

この区分は日本企業にも重要な示唆を与える。すべてのOKRを同じ評価基準で見ると、挑戦的な目標は消えてしまう。反対に、すべてのOKRを「挑戦」という名のもとに緩く置くと、実行責任が曖昧になる。したがってOKR運用でまず決めるべきなのは、目標の文言ではなく目標の性格である。必ず達成すべき約束なのか、学習のための挑戦なのか、複数部門が一緒に解くべき課題なのかが変われば、点検の仕方も変わらなければならない。

ただし、Googleの事例をそのまま模倣するのは危険である。当該playbook自体もGoogleのアプローチであり、他の組織のやり方は異なり得ることを前提としている。規模、業種、組織文化、評価制度、リーダーシップの方式が異なる企業で同じフォーマットを持ち込んでも、同じ効果が出るわけではない。事例から取り入れるべきなのは文書形式ではなく、目標を組織間の対話と整合の言語にした方法である。

Microsoftの事例は、OKRがソフトウェアよりも運用リズムであることを示す

Microsoft LearnのViva Goals文書は、OKRフレームワークを活用して組織の戦略的優先順位、スケジュール、目標にチームを結び付けると説明している。また、OKRの状態と進捗を定期的にチェックインすることで、ビジネス成果を推進するとしている。この説明は、HR Techの観点からOKRがどのように製品化されるのかを示している。

しかしここでも核心はツールではない。ソフトウェアは目標を見えるようにし、進捗状況を記録し、チェックインのリズムを支援できる。しかし、どの目標が戦略優先順位なのか、目標の衝突が生じたとき誰が調整するのか、達成率を評価と報酬にどう解釈するのかは、ツールが代わりに決めることはできない。

Microsoftの事例がHR担当者に与えるメッセージは明確である。OKRツールを導入する前に、運用上の問いを先に整理しなければならない。第一に、全社目標とチーム目標の接続ルールは何か。第二に、四半期中の目標変更は誰が承認するのか。第三に、チェックインミーティングは報告会議なのか、障害物を取り除く会議なのか。第四に、OKR達成率は評価点なのか、成果対話の根拠なのか。

この問いなしにシステムだけを導入すれば、OKRはより速い入力フォーマットになるだけである。反対に、問いが整理された組織では、単純なスプレッドシートでも運用体系になり得る。OKRの成否はソリューション購入よりも、意思決定ルールと会議リズムに近い。

日本企業の論点は評価反映の有無よりも責任配分である

日本企業でOKRの議論が難しくなる地点は、評価と報酬である。実務担当者はよく尋ねる。「OKRを評価に反映すべきか」。この問いは重要だが、ここで直ちに賛否へ進むと議論が狭くなる。より先に問うべきなのは、「このOKRはどのような責任を説明するためのものか」である。

Committed OKRは、約束した実行責任に近い。この場合、達成の有無と未達の理由は成果対話において重要な資料になり得る。Aspirational OKRは、不確実な挑戦と学習の性格が強い。達成率だけで評価すれば、メンバーは安全な目標を選ぶようになる。Cross-team OKRは部門間の依存性が大きい。この目標を個人評価に単純配分すると、協業よりも責任回避が大きくなり得る。

したがって、OKRと評価・報酬の関係を一つの原則に固定することは難しい。日本企業が決めるべきなのは、「反映する/反映しない」ではなく、OKRのタイプ別の解釈ルールである。あるOKRは成果責任の根拠になり、あるOKRは学習と戦略修正の根拠になり、あるOKRは組織間の調整責任を確認する資料になる。

HR部門の役割もここで変わる。OKRフォーマットを配布する管理者ではなく、目標タイプ、チェックインのリズム、リーダーのフィードバック基準、評価での参照方法、例外処理の原則を設計する運用者にならなければならない。パフォーマンス管理制度が評価シーズンだけに作動しないようにするには、OKRは四半期を通じて繰り返される対話構造と結び付かなければならない。

今回の連載は、OKRを制度、リーダーシップ、データの接続問題として追跡する

HR Lensは今回のOKR連載を、単なる概念説明として扱わない。第一の軸はKPIとOKRの違いである。KPIが安定的な運用指標であるなら、OKRは戦略的変化と優先順位を扱う。両者は代替関係ではなく、共に設計すべき関係である。

第二の軸は書き方である。良いObjectiveは格好のよい文章ではなく、選択を明らかにする。良いKey Resultは活動ではなく結果を示す。「研修実施」や「会議運営」は実行リストに近い。研修後にどのような行動、能力、成果、異動が変わったのかを示すとき、KRになる。

第三の軸は失敗要因である。OKRが失敗する組織は、たいてい目標を作りすぎ、経営陣の優先順位が頻繁に変わり、チェックインミーティングを報告会議にしてしまう。評価・報酬との関係を整理しないまま、達成率だけを残す場合も多い。

第四の軸はリーダーシップとデータである。OKRはHR制度であると同時に、リーダーシップシステムでもある。リーダーが優先順位を明確にせず、部門間の目標衝突を調整しなければ、OKRは現場の負担として残る。今後はPeople AnalyticsとAIが目標の進捗状況を要約し、危険信号を捉えられるようになるかもしれないが、その解釈責任は依然として人と組織に残る。

今回の連載の基準は一つである。OKRを導入したかではなく、OKRが組織の成果対話を変えたか。目標がより多く入力されたかではなく、何をあきらめ、何に集中するのかがより明確になったか。この問いに答えられなければ、OKRはまた一つの制度名になる。答えられるなら、OKRはパフォーマンス管理の中心を評価から実行と学習へ移す契機になり得る。