OKR入門｜Objectiveと Key Resultsで四半期目標を運用する基本

目標は、立てた。期初の会議で、今期チームが目指すことを言葉にし、資料にもまとめた。ところが期末になって振り返ると、「で、結局どうだったんだっけ」で終わってしまう。期中は誰もその目標を見返さず、メンバーそれぞれが立てた目標が、チームの方針や会社の方向とどうつながっているのかも、いざ聞かれると説明できない。進捗会議で「今どこまで来てる？」と問われても、数字で答えられない——リーダーになって目標を立てる立場になると、多くの人がこの「立てっぱなし」の壁にぶつかります。

OKR（オーケーアール）とは、この壁を越えるための目標運用の型です。「Objectives and Key Results（目標と主要な結果）」の略で、目指す状態（Objective）と、その達成を測る指標（Key Results）を組にして、四半期ごとに結びつけて運用します（出典：freee「OKRとは」）。ポイントは「立てて終わり」にしないこと。立てる→期中に確認する→期末に採点する→次のサイクルへ引き継ぐ、まで回して初めて機能します。本講座は、この「OKR の枠組みと四半期運用」だけに絞ります。1つの良い目標を達成基準が明確な言葉にするコツ（SMART）は目標設定の基本、指標そのものの設計やKPIツリーの作り込み、最終ゴールの数値化（KGI）、そして確認と改善を仕事全体で回し続ける土台（PDCA）は、それぞれの講座が正本です。本講座はそこには深入りせず、必要な場面でそちらへ送ります。

この講座を終えると、次の3つができるようになります。OKR の構造（Objective＝目指す状態／Key Results＝達成を測る指標）と、KPI・SMART・KGI との役割の違いを説明できること。自チームの四半期 OKR を「Objective 1つ＋Key Results 2〜3つ」の形で作成できること。そして、期末に各 Key Result の達成度を採点し、結果を次サイクルの OKR に引き継ぐ運用を実行できることです。覚えて帰る型は「目指す状態（Objective）を1つ → 測る指標（Key Results）を2〜3つ → 四半期で確認・採点・引き継ぎ」。本講座では、ある問い合わせ対応チームが四半期 OKR を1セット作り、期末に採点して次サイクルへ引き継ぐ場面を、全章を通して追いかけます。

OKRとは何か——目指す状態と達成を測る指標

OKRは「目指す状態（Objective）」と「達成を測る指標（Key Results）」の組

OKR は2つの部品でできています。1つ目が Objective＝目指す状態です。「何を目指すか」「何を成したいか」という、チームが向かう先を言葉で示したもので、数値化された定量目標ではなく、定性的な到達点として書きます（出典：freee「OKRとは」）。2つ目が Key Results＝達成を測る指標です。Objective で掲げた状態に「どれだけ近づけたか」を測る、定量的で測定可能な指標を指します（出典：Wikipedia「OKR」）。

共通例の問い合わせ対応チームで考えてみましょう。このチームの Objective を「ユーザーが“すぐ解決した”と感じる窓口になる」と置きます。これは方向を示す言葉で、それ自体は数字ではありません。一方の Key Results は、その達成を測れる指標として、（例）「一次回答までの時間」「自己解決率」「問い合わせ後の満足度」のように置きます（具体的な目標値は説明のための例で、実際の数字はチームの状況に合わせて決めます）。目指す状態を言葉で1つ、それを測る指標を複数——この分け方が OKR の骨格です。

Objective は数を絞るのが原則です。Google の運用ガイドでは、組織のOKRを設定するときに「目標を3〜5個に絞り、それぞれの目標について成果指標を3個ほど設定する」とされ、目標が多すぎるとチームの負担になって集中力が分散すると注意しています（出典：Google re:Work「OKRを設定する」）。本講座は導入として、まずは自チームで「Objective 1つ＋Key Results 2〜3つ」の最小セットから始めることを勧めます（一般には1つの Objective に Key Results 3〜5つとされます。出典：Google re:Work／Wikipedia）。少なく始めて、慣れてから増やせば十分です。

四半期という短い周期で立て直すから、期中も見返せる

OKR のもう1つの特徴が、短い周期で運用することです。一般的なサイクルは1〜4か月で、多くは四半期ごとに設定し、見直します（出典：freee「OKRとは」）。なぜ短い周期なのか。事業や組織の状況は動くからです。四半期ごとに立て直すことで、新しい情報を反映したり、達成できそうにない目標を取り下げたり、有望な目標にリソースを集中したりといった軌道修正が、その都度できるようになります（出典：Google re:Work「OKRを設定する」）。

「立てっぱなし」になりがちな年間目標と違い、短い周期だからこそ期中も見返す前提になります。頻繁に目標と進捗を確認し合うことは、メンバー同士のコミュニケーションのきっかけにもなります（出典：freee「OKRとは」）。問い合わせ対応チームなら、1年先ではなく「この四半期に、すぐ解決と感じてもらえる窓口にどこまで近づくか」を区切って追う。期が変われば、状況に合わせて Objective も Key Results も立て直す。これが OKR の回し方です。

Objectiveに数字を詰めない／Key Resultsを作業リストにしないというつまずき

OKR を作るとき、最初につまずきやすいのが2点あります。1つは、Objective に数字を詰め込んで「ただの数値目標」にしてしまうこと。Objective は本来、向かう先を示す定性的な言葉です。ここに「一次回答時間を◯分にする」と数字を入れてしまうと、それは目指す状態ではなく測る指標（Key Results）の中身になってしまい、「何のために」が抜け落ちます。もう1つは逆に、Key Results を「やることの羅列＝作業リスト」にしてしまうこと。Google のガイドは、成果指標は「行動」ではなく「行動の成果」を書くべきだとし、「相談する」「支援する」「分析する」のような行動の言葉ではなく、「3月7日までに顧客満足度を公表する」のように結果で書くよう求めています（出典：Google re:Work「OKRを設定する」）。「マニュアルを作る」はタスク、「自己解決率がどう変わったか」が成果——この違いを押さえると、Key Results が締まります。

なお、OKR の原型は、元インテルCEOのアンドルー・グローヴ（Andy Grove）が1970年代に導入し、著書『High Output Management』で文書化したものです。インテルにいたジョン・ドーア（John Doerr）がこれを学び、後に1999年、創業間もない Google に紹介しました。Google の文化の中心となったことで、OKR は広く知られるようになりました（出典：Wikipedia「OKR」／Google re:Work「OKRを設定する」）。「大企業の特別な手法」と身構える必要はありません。目指す状態と測る指標を組にして短く回す、という考え方そのものは、数名のチームでもそのまま使えます。

この章の確認（演習）

自チームについて、「今、目指したい状態」を1文で書いてみてください（数字を入れず、向かう先を言葉で）。次に、その状態に近づけたと言えるかどうかを測れそうな指標を2〜3つ仮置きします。書けたら、Objective に数字が混ざっていないか、Key Results が「やること（作業）」ではなく「結果（成果）」になっているかを、自分で点検してみましょう。

OKRと他の目標の使い分け——KPI・SMART・KGIとの違い

OKRは「挑戦して目指す状態」、KPIは「定常的に監視する指標」

OKR の話をすると、必ず出てくるのが「KPI と何が違うの？」という疑問です。KPI（Key Performance Indicator＝重要業績評価指標）は、最終的なゴールを達成するために、その過程が順調かどうかを測るための数値です（出典：freee「KPIとは」）。両者は目的が違います。OKR は1〜3か月で見直す、達成目安が60〜70%になるような挑戦的な目標です。一方の KPI は、月次・週次など継続的に管理し、100%達成（必達）を目指します（出典：freee「OKRとは」「KPIとは」）。

問い合わせ対応チームで切り分けてみましょう。毎日モニターに出して見張り続ける「窓口の稼働率」のような指標は、定常的に監視する KPI です。これに対し、今期だけ挑戦して引き上げたい「自己解決率」は、OKR の Key Result に置く——同じ「指標」でも、常に見張りたいものは KPI、今期挑戦して伸ばしたいものは OKR、と役割で振り分けます。OKR の Key Results に KPI 的な指標を“借りて”載せることはありますが、その目的が「挑戦」なのか「監視」なのかを意識すると、迷いません。

ここでつまずきやすいのが、監視用の KPI を片っ端から OKR に積んでしまうことです。そうすると OKR が「いつものダッシュボードのコピー」になり、今期どこに挑戦するのかが見えなくなります。指標そのものの設計や、KGI から KPI をツリー状に分解する作り込みは本講座の範囲を超えるので、深く学びたい場合はKPIツリーの作り方へ進んでください。本講座では「OKR に載せる（挑戦）／KPI として監視し続ける」の線引きだけ、できるようにします。

SMARTは目標の言葉を磨く型、KGIは事業の最終ゴールの数字

もう2つ、隣り合う言葉を整理しておきます。1つは SMART です。Specific（明確）・Measurable（測定可能）・Achievable（達成可能）・Relevant（関連性）・Time-bound（期限）の頭文字で、1つの目標を「誰にでも分かり、客観的に測れ、期限が明確」な言葉にするための型です（出典：SmartHR「OKRとは」）。OKR とは競合しません。OKR の Objective や Key Results を書くときに、SMART をチェックリストとして借りると、言葉が締まります。ただし、1つの目標を SMART で磨き込む各論は目標設定の基本が正本なので、本講座では「言葉づかいに借りる」ところまでにします。

もう1つが KGI（Key Goal Indicator＝重要目標達成指標）です。これは事業や組織の「最終的なゴールそのものの数字」を示す指標で、たとえば「年間売上1,000万円」のようなものです。KPI が最終ゴールまでの過程（中間）を測るのに対し、KGI はゴールの達成度を測ります（出典：freee「KPIとは」）。三者の関係は階層で捉えると分かりやすいです。一番上に最終ゴールの KGI があり、それを達成するための中間指標として KPI があり、KPI ツリーのように論理的にブレイクダウンされていきます（出典：freee「KPIとは」）。チームの OKR を作るときは、その Objective が会社の最終ゴール（KGI）のどこにつながるかを一言で確認しておく——接続を意識するだけで十分です。最終ゴールを数字に落とす作り方そのものはKGIの基本へ送ります。

人事評価との連動という、MBOとの決定的な違い

OKR と混同されやすい言葉に、MBO（Management by Objectives＝目標管理制度）があります。MBO は通常1年ごとに目標を設定し、その達成率を給与・賞与など報酬の決定に直結させる仕組みです（出典：freee「OKRとは」）。ここが OKR との決定的な違いです。OKR は、達成率を人事評価や報酬に直接反映させません（出典：freee「OKRとは」／SmartHR「OKRとは」）。理由はシンプルで、達成度を評価・査定に直結させると、メンバーは評価を下げないように「確実に達成できる無難で低い目標」を立てるようになり、挑戦という OKR 本来の目的が失われてしまうからです（出典：SmartHR「OKRとは」）。また、MBO は個人目標を非公開で管理することが多いのに対し、OKR は組織全体に公開して足並みをそろえます（出典：JMAM「OKR」）。この「評価と切り離す」「公開する」という2点は、次章以降の運用にも効いてくる前提です。

この章の確認（演習）

自チームで使っている、あるいは使えそうな指標の候補を、いくつか書き出してください。それを「OKR に載せる（今期、挑戦して伸ばしたいもの）」と「KPI として監視し続ける（常に見張りたいもの）」の2つに仕分けます。仕分けたら、OKR 側に積みすぎていないか（ダッシュボードのコピーになっていないか）を確認し、その OKR が会社の最終ゴール（KGI）のどこにつながるかを一言で書き添えてみましょう。

チームのOKRを作る——ObjectiveとKey Resultsの書き方

作る順序は「上位の方針 → Objective → Key Results」

OKR は、いきなり自分のチーム単独で考え始めるのではなく、上位の方針から降ろしてくると軸がぶれません。Google のガイドも、目標設定では「組織の OKR の設定から着手し、上位の優先順位に沿って整える」とし、トップダウンとボトムアップ双方の提案を組み合わせると効果が高いとしています（出典：Google re:Work「OKRを設定する」）。OKR は会社→部署→チーム→個人へと連動して細分化していく仕組みです（出典：freee「OKRとは」）。

実際の手順は次の通りです。まず、会社や部の方針から、自チームが今期いちばん貢献できる点を1つ選びます。次に、その貢献を「目指す状態」として Objective を1文で書きます。続いて、その状態に近づけたと言える Key Results を2〜3つ挙げ、各々が「達成したと言える数字になっているか」を点検します。最後に、メンバーと共有し、各自の日々の動きがこの OKR とどうつながるかを確認します。問い合わせ対応チームなら、「会社として顧客満足を高める」という上位方針から、「すぐ解決したと感じる窓口になる」という自チームの Objective を選び取る、という降ろし方になります。

Objectiveは1つに絞り、到達点・状態の言葉で書く

Objective を書くときのコツは、到達点や状態を示す言葉にすることです。Google のガイドは、「採用を続ける」「市場での地位を維持する」のような“さらなる高みを求めない表現”は避け、「山を登る」「Y という機能を実装する」のように到達点・状態を示す、具体的・客観的・明確な言葉を使うよう勧めています。観察した人が、達成できたかどうかを判断できることが必要だとも述べています（出典：Google re:Work「OKRを設定する」）。

そして Objective は1つに絞ります。複数立てると、チームの焦点がぼやけ、「結局どれが今期いちばん大事なのか」が分からなくなるからです。問い合わせ対応チームの例なら、Objective は（例）「ユーザーが“すぐ解決した”と感じる窓口になる」の1文。「対応も速くしつつコストも下げてマニュアルも整える」と欲張らず、今期の主役を1つに決める——これが第一の点検ポイントです。

Key Resultsは2〜3つ、「達成したと言える証拠」で書く

Key Results は、Objective の達成を測る指標です。ここで効くのが、第1章でも触れた「行動ではなく行動の成果を書く」という原則です。Google のガイドは、成果指標は計測可能で、実現すれば目標達成に直結すると分かるものにし、「完遂の証拠（入手可能・信頼でき・容易に見つかる）」を含めるべきだとしています（出典：Google re:Work「OKRを設定する」）。つまり「マニュアルを整備する」という作業ではなく、「（例）自己解決率がどう変わったか」という結果で書く、ということです。

問い合わせ対応チームなら、Objective「すぐ解決したと感じる窓口になる」に対し、Key Results を（例）「一次回答までの時間」「自己解決率」「問い合わせ後の満足度」のように2〜3つ置きます（具体的な目標値は説明のための例です）。書いたら、各 Key Result について「期末にこれを見て、達成したか・しなかったかを判定できるか」を自問します。判定できないなら、それはまだ作業の言葉か、あいまいな表現が残っているサインです。つまずきやすいのは、Key Results が多すぎて追えなくなることと、達成基準があいまいで期末に判定できないこと。少数に絞り、判定できる形にするのが、作成の肝です。Objective や Key Results の一文を、達成基準が明確な目標として磨き込むコツは目標設定の基本で深掘りできます。

この章の確認（演習）

自チームの四半期 OKR を「Objective 1つ＋Key Results 2〜3つ」で、1セット書き出してください。Objective は到達点・状態の言葉で1文、Key Results はそれぞれ「行動の成果（結果）」で。書けたら、各 Key Result について「期末にこの指標を見て、達成したかどうかを自分で判定できるか」を一つずつチェックします。判定できないものは、結果の言葉に書き直してみましょう。

OKRを回す——進捗確認と期末の採点・次サイクルへの引き継ぎ

OKRは「立てて終わり」ではなく「立てる→確認→採点→引き継ぎ」まで回す

ここまでで OKR は作れました。しかし、作って机にしまえば「立てっぱなし」に逆戻りです。OKR が機能するのは、立てた後に回すからです。回し方は4ステップ。立てる→期中に確認する→期末に採点する→次サイクルへ引き継ぐ、です。問い合わせ対応チームでいえば、四半期の頭に OKR を立て、期中は進捗を見て、期末に各 Key Result を採点し、その学びを次の四半期 OKR に活かす——この1周を回し切って初めて、目標が「立てる道具」から「回す型」に変わります。

期中は短い定例で進捗を見て、期末に達成度を採点する

まず期中の確認です。Google のガイドは、最終的な評価の前段階として「四半期の中頃に、すべてのレベルの OKR を検証し、現在地を把握する」ことを勧めています（出典：Google re:Work「OKRを設定する」）。実務では、週1回または隔週で「チェックイン」と呼ばれる短時間の進捗確認を行うやり方が一般的です。チェックインでは、うまくいっていない原因を言い訳するのではなく、現段階の進捗・課題・達成に向けた具体的なアクションを整理します（出典：JMAM「OKR」）。問い合わせ対応チームなら、隔週で「自己解決率は今どこか」「満足度はどう動いたか」を短く確認し、ずれていれば早めに手を打ちます。

次に期末の採点です。Google では通常、各 Key Result を0.0〜1.0で採点し、その概算平均で Objective を評価します（1.0＝完全達成）。0か1で採点する指標もあれば、より細かく採点する指標もあります（たとえば「6機能のうち3機能リリース」なら0.5）（出典：Google re:Work「OKRを設定する」）。ここで大事なのが、満点を狙わないことです。Google のガイドは「OKR の最適な達成率はおおよそ60〜70%。すべての OKR の平均点が0.6〜0.7に収まるのが理想」だとしています（出典：Google re:Work「OKRを設定する」）。常に1.0なら目標が低すぎ、低すぎれば届いていない、という診断のシグナルとして使うわけです。なお、これは Google が示す目安で、採点方法は組織によって変わります。本講座では採点の細かな各論には踏み込まず、「0〜1で採点し、満点ではなく7割前後を狙う」という考え方だけ押さえます。

この「あえて高い目標を置き、7割で成功とみなす」という発想は、ストレッチゴール（ムーンショット）と呼ばれます。Google のガイドは、「70%達成できれば成功と言えるような OKR を設定する」「目標を高く設定すると、達成できなかった場合でも格段の進歩を遂げられることが少なくない」としています（出典：Google re:Work「OKRを設定する」）。満点を取りにいくのではなく、届くか届かないかの高さに置いて、前進を引き出すのが OKR の狙いです。

採点を人事評価に直結させない／学びを次サイクルへ引き継ぐ

採点を運用するうえで、絶対に外せない注意点があります。採点結果を、そのまま人事評価・査定に直結させないことです。Google のガイドは「OKR は実績を評価するためのツールではない」と明言しています（出典：Google re:Work「OKRを設定する」）。理由は第2章でも触れた通りで、達成度が昇給・昇格に直結すると思わせると、メンバーは達成しやすい無難な目標を立てるようになり、挑戦という本来の目的が失われるからです。評価するなら、達成度の数字そのものではなく「目標達成のための行動や思考プロセス」を見ます（出典：SmartHR「OKRとは」）。問い合わせ対応チームの採点も、「自己解決率が0.7だったから査定を下げる」ではなく、「なぜそこで止まったのか、次に何を変えるか」を語る材料として使います。

最後が、次サイクルへの引き継ぎです。期末の最終レビューでは、達成率が高すぎ／低すぎなかったか、目標が適切だったかを分析します。評価が低かった場合も、失敗ではなく「次の OKR を改善するためのデータ」として捉えます（出典：Google re:Work「OKRを設定する」）。そして、達成・未達の理由を言語化し、同じ目標を続けるのか、新しい目標に変えるのかを決めて、次の四半期 OKR に反映します。この「確認→採点→次へ」を、OKR だけでなく仕事全体で回し続ける土台がPDCAの基本です。OKR の四半期サイクルは、その PDCA を目標運用に当てはめた一つの形だと捉えると、つながりが見えてきます。

この章の確認（演習）

第3章で作った自チームの OKR に、「期中の確認タイミング」と「期末の採点方法」を1つずつ決めて書き加えてください。確認タイミングは、たとえば「隔週のチェックインで各 Key Result の進捗を見る」のように具体的に。採点方法は、たとえば「各 Key Result を0〜1で採点し、満点ではなく0.7前後を成功とみなす」のように。書けたら、その採点を「人事評価に直結させない」前提で、何を次サイクルに引き継ぐかを一言メモしておきましょう。