OKR例文つき作り方ガイド｜職種別の良い例・悪い例で即実践

▼ この記事の内容

OKR例は、Objectiveに実現したい状態、Key Resultに測定できる成果指標を分けて書くと運用しやすくなります。例文を写すだけでなく、タスク化、評価直結、抽象化を防ぐ確認まで行うことが重要です。

AtlassianのOKRガイドでは、Objectiveを1〜3個に絞り、各Objectiveに3〜5個のKey Resultを置く進め方が紹介されています。OKR例を作るときも、目標文と成果指標を分けることが出発点になります。

現場では、売上数値、実施施策、評価項目が同じ目標文に混ざりがちです。部署へ展開すると、メンバーは何を目指し、何を1on1で確認すればよいのか判断しにくくなります。

この記事では、OKR例をObjectiveとKey Resultに分け、良い例と悪い例、職種別の作り方、評価制度と混同しない運用まで整理します。例文を写すだけでなく、自社の目標設定へ直す観点が分かります。

読み終えるころには、OKRを作成して終わらせず、進捗確認と支援の対話へつなげる準備ができるはずです。

OKRを設定して終わらせず、1on1で進捗確認までつなげたい方は、以下の資料で質問とアジェンダの型を確認できます。

OKRとは？ObjectiveとKey Resultの違い

OKRは、Objectiveで目指す状態を示し、Key Resultで達成度を測る成果指標を置く目標管理の型です。例文を作る前に両者を分けると、スローガンやタスク一覧に寄りすぎない目標文を作りやすくなります。

参考：What is an OKR?｜What Matters

初めてOKRを作る場合は、まず何を実現したいかと何が変われば達成と言えるかを別々に書き出します。この分離ができると、営業、人事、開発など職種が変わっても例文を調整しやすくなります。

参考：Set goals with OKRs｜Google re:Work

OKRは目標と成果指標を分ける

OKRは、Objectiveで目指す状態を示し、Key Resultで達成度を測る成果指標を置く目標管理の型です。両者を分けると、例文を写すだけの運用を避けられます。

Objectiveは方向をそろえる役割を持ち、Key Resultは進捗を確認する役割を持ちます。両方を1文に詰め込むと、何を目指すのか、何で判断するのかが曖昧になります。

たとえば営業部門で売上を増やすという目標だけを置くと、重点顧客の開拓なのか、既存顧客の継続率改善なのかが分かりません。Objectiveに状態を書き、Key Resultに商談化率や継続率などの測定軸を置くと、進捗対話に使える形になります。

Objectiveは到達したい状態を書く

Objectiveは、チームや個人が一定期間で実現したい状態を言語化する部分です。売上額や件数そのものではなく、顧客、組織、プロダクトにどんな変化を起こしたいかを書きます。

良いObjectiveは、読んだ人が行動の方向をそろえられる文になります。営業なら重点顧客から選ばれる提案体験をつくる、人事なら評価への納得感を高める運用を定着させるのように、変化後の状態を示します。

反対に受注率30%を達成するだけを書くと、ObjectiveではなくKey Resultに近づきます。数字を置くこと自体は悪くありませんが、Objectiveが数字だけになると、なぜその数字を追うのかを説明しにくくなります。

Key Resultは測定できる成果を書く

Key Resultは、Objectiveに近づいているかを確認するための測定可能な成果です。数値化できる場合は数値で書き、数値化しにくい場合も成果物や状態変化で確認できる形にします。

AtlassianのOKRガイドでは、Objectiveを1〜3個に絞り、各Objectiveに3〜5個のKey Resultを置く進め方が紹介されています。Key Resultは施策そのものではなく、施策の結果として変わる指標にするのが要点です。

たとえば週1回の商談レビューを実施するは行動なので、Key Resultとしては弱くなります。仮に重点顧客の次回商談化率を25%から35%に上げると置くと、行動後に変わる成果を判断しやすくなります。

参考：OKR Guide & Template｜Atlassian

関連する設計を整理する際は、1on1ミーティングの基本も確認すると、本記事の論点を実務に落とし込みやすくなります。

OKRの良い例と悪い例

良いOKR例は、Objectiveに目指す状態を書き、Key Resultに測定できる成果を置きます。悪い例は、数値、施策、評価項目が混ざり、進捗確認で何を見るべきかが曖昧になります。

例文をそのまま写すより、何が良くて何が悪いのかを分けて見る必要があります。営業、人事、開発など職種が変わっても、この見方を使うと目標文を直しやすくなります。

良いOKR例は状態と成果指標が分かれている

良いOKR例は、Objectiveで変えたい状態を示し、Key Resultで達成度を測ります。状態と成果指標が分かれると、進捗会議や1on1で確認する論点が明確になります。

営業部門なら、Objectiveは重点顧客に選ばれる提案体験をつくるのように書きます。Key Resultには重点顧客の商談化率、提案後の次回接続率、失注理由の記録率などを置きます。

この分け方をすると、売上を上げるという大きな言葉だけで終わりません。何を変えたいのかと、どの数字で近づいたと判断するのかを別々に説明できます。良い例を確認するときは、以下の3点で見ると判断しやすくなります。ObjectiveとKey Resultの役割を分けるほど、例文は運用に使いやすくなります。

悪いOKR例は数値・施策・評価が混ざる

悪いOKR例は、売上数値、実施施策、評価項目を同じ文に混ぜてしまう目標です。何を目指し、何で測り、何を実行するのかが分かれないため、運用時に迷いが出ます。よくある悪い例は、仮にObjectiveに売上120%達成とだけ書く形です。これは方向性ではなく成果指標に近いため、Key Resultとの役割が重なります。

別の悪い例は、仮に週1回の商談レビューを実施するとKey Resultに置く形です。レビューは行動なので、成果指標にするなら商談レビュー後の次回接続率や失注理由の記録率へ直します。

評価項目を混ぜる失敗も起きやすいです。OKRに人事評価の点数や等級要件を直接入れると、挑戦目標ではなく査定用の安全な目標に寄ります。悪い例を直す第一歩は、文の中に目的、成果、施策、評価が混在していないかを分解することです。混ざったまま部署別に展開すると、職種ごとの例文もすべて曖昧になります。

悪い例は添削して運用文に直す

悪いOKR例は、削除するのではなく、Objective、Key Result、施策に分けて添削します。分解してから書き直すと、例文が目標設定会議と1on1の両方で使えます。

添削では、まずObjectiveから数値やタスクを外します。次にKey Resultへ測定できる成果を移し、施策は行動計画や週次の確認項目として別管理にします。

たとえば営業の悪い例が新規商談を増やすために毎週50件架電するなら、Objectiveは重点顧客との初回接点を増やすに直します。Key Resultは有効商談数や次回接続率で確認します。

部署別・職種別のOKR例

部署別・職種別のOKR例は、同じObjectiveとKey Resultの型を使いながら、追う成果の粒度を変えて作ります。営業は商談の質、人事は組織運用、開発とCSは成果物と顧客状態を分けて考えます。

職種が変わっても、Objectiveに状態を書き、Key Resultに測定できる成果を置く原則は同じです。例文を転記する前に、部署ごとの責任範囲と進捗確認の場面をそろえる必要があります。

営業部門は商談の質と重点顧客で考える

営業部門のOKR例は、売上額だけでなく、重点顧客との商談の質で設計します。Objectiveに提案体験の変化を書き、Key Resultに次回接続率や重点顧客の商談化率を置きます。

悪い例は、Objectiveに売上目標だけを書き、Key Resultに架電件数や訪問件数を並べる形です。行動量は管理しやすい一方で、顧客が前に進んだかを判断しにくくなります。

良い例では、Objectiveを重点顧客から相談される営業組織になると置きます。Key Resultは重点顧客の初回商談化率、提案後の次回接続率、失注理由の記録率などに分けます。

人事部門は採用・育成・評価の接続で考える

人事部門のOKR例は、採用人数や研修実施数だけでなく、入社後の定着、育成、評価運用までつなげて設計します。Objectiveは、組織がどの状態になれば前進と言えるかで書きます。

悪い例は、Objectiveに採用人数を増やすとだけ書く形です。人数はKey Resultに置けますが、それだけでは採用後に活躍できる状態まで説明できません。

良い例では、Objectiveを新入社員が早期に役割を理解し、現場で成果を出し始める状態をつくると置きます。Key Resultは入社後面談の実施率、育成計画の作成率、評価面談での納得度確認などに分けます。

開発・CSは成果物と顧客状態を分ける

開発とCSのOKR例は、作ったものと顧客が得た状態を分けて書きます。開発は成果物の価値、CSは顧客の利用状態をKey Resultに置くと、タスク一覧から離れやすくなります。

開発部門で悪い例になりやすいのは、機能をリリースするとだけ書く形です。リリースは重要な行動ですが、利用率や問い合わせ削減などの変化がなければ、成果として判断しにくくなります。

CS部門では、顧客満足度を上げるだけでは抽象的です。オンボーディング完了率、主要機能の利用率、更新前のリスク顧客数など、顧客状態の変化を測れる指標にします。

個人OKRは評価目標と分けて書く

個人OKRは、評価目標そのものではなく、本人が挑戦する方向と成果の確認軸を分けて書きます。評価に直結させる場合は、OKRよりMBO寄りの運用になる点を説明する必要があります。

個人OKRで起きやすい失敗は、評価されやすい安全な目標だけを書くことです。挑戦目標として使うなら、本人の成長テーマとチーム目標の接点をObjectiveに入れます。

営業担当者なら、Objectiveを重点顧客の課題を深く理解し、提案の質を高めると置けます。Key Resultは課題仮説の記録率、次回接続率、提案後の振り返り実施率などに分けます。

OKR例を作るチェックリスト

OKR例を作るときは、Objective、Key Result、施策、振り返り欄を分けて確認します。例文を整える前にこの順番で見ると、数値だけの目標やタスク一覧への偏りを防げます。

チェックリストは、完成した文章を採点する道具ではなく、運用で使える形に直すための確認軸です。ここでは、目的・測定・対話を分けて確認する「コチーム式OKR接続3点チェック」として、設定後の1on1や進捗会議で使える形に直します。

Objectiveは変えたい状態で書く

Objectiveは、一定期間で変えたい顧客、組織、チームの状態を書きます。数値そのものではなく、達成後に何が前より良くなるかを言語化します。最初に確認するのは、Objectiveが行動や数値だけになっていないかです。売上120%達成や週次レビュー実施だけでは、目指す状態よりも結果や施策に寄りすぎます。

営業部門なら、重点顧客から相談される提案体験をつくるのように書くと、行動の方向がそろいます。人事部門なら、評価面談で納得感を持てる運用を定着させるのように、社員の状態変化まで含めます。

Objectiveを確認するときは、次の3点を見ると判断しやすくなります。どれかが欠ける場合は、例文を短くするより先に、目的語を具体化します。Objectiveが状態として読めると、次に置くKey Resultの役割も明確になります。状態を決めた後は、測定する成果指標を多すぎない数に絞ります。

KRは成果指標を3から5個に絞る

KRは、Objectiveに近づいているかを確認する成果指標です。AtlassianのOKRガイドでは、各Objectiveに3から5個のKey Resultを置く進め方が示されています。

KRが多すぎると、目標管理ではなく管理項目の一覧になります。反対に1個だけにすると、売上や件数など単一の結果に引っ張られ、途中の変化を見落としやすくなります。

KRを選ぶときは、最終結果、途中指標、品質指標を混ぜて見ます。営業なら受注額だけでなく、重点顧客の商談化率、提案後の次回接続率、失注理由の記録率を並べると判断しやすくなります。

参考：OKR Guide & Template｜Atlassian

KRをタスクにしない添削ルール

KRは、やることではなく、やった結果として変わる成果を書きます。会議実施、資料作成、架電件数だけを置くと、行動量は見えても前進したかを判断しにくくなります。タスク化を防ぐには、文末を実施するで終えないことが有効です。実施後に何が増えるのか、何が減るのか、どの状態へ近づくのかを成果の言葉に直します。

よくあるケースとして、毎週商談レビューを実施するというKRがあります。この文は施策なので、重点顧客の次回接続率を高める、失注理由の記録率を上げるのように、結果側へ置き換えます。

添削するときは、以下の表でタスクと成果を分けます。行動を消すのではなく、OKR本文から外して実行計画へ移すと、管理しやすくなります。表のように直すと、タスクは行動計画に残し、KRは成果確認に使えます。添削後は、テンプレートへ転記するときに振り返り欄まで用意します。

テンプレートには振り返り欄まで入れる

OKRテンプレートには、ObjectiveとKRだけでなく、進捗、障害、次回行動の振り返り欄を入れます。記入欄があると、設定後の対話で確認する内容が残ります。テンプレートが目標文だけで終わると、OKRは作成時点の資料になりやすくなります。週次や隔週の確認欄を入れると、未達の理由や上司の支援内容を記録できます。

小規模なチームでは、複雑なシートを作る必要はありません。Objective、KR、現在値、障害、次回行動、支援者の6項目だけでも、進捗対話に使う最低限の情報はそろいます。

目標管理で使う記入欄の作り方を詳しく確認したい場合は、目標管理テンプレートの設計方法も参考になります。OKRの例文を転記する前に、振り返りで使う欄を先に決めると運用が安定します。

MBO・KPI・評価と混同しない

OKRは評価制度そのものではなく、目標と成果指標を使って進捗対話を進める型です。MBO、KPI、人事評価とは、目的、頻度、使い方を分けて説明する必要があります。

MBOは評価接続、OKRは進捗対話に向く

MBOは、個人や部門の目標を評価や達成管理に接続しやすい考え方です。OKRは、挑戦的な目標と成果指標を置き、期中の進捗対話に使いやすい型です。

制度名は企業によって異なるため、MBOなら評価、OKRなら非評価と機械的に分ける必要はありません。大切なのは、社員に何を約束し、何を評価材料にするかを明示することです。

より詳しい違いを整理したい場合は、MBOとOKRの使い分けを確認できます。この記事では、例文を作る前提として境界だけを押さえます。

KPIは測定指標、OKRは目標と指標の組み合わせ

KPIは、業務や成果の状態を測る指標です。OKRは、Objectiveという目標文と、Key Resultという成果指標を組み合わせて使います。

KPIだけで十分な場面もあります。既存業務の安定運用や品質管理では、KPIを継続監視し、改善テーマがあるときにOKRへ切り出すほうが自然です。

OKRにKPIを入れる場合は、すべてのKPIを並べないことが重要です。Objectiveに対して今期の改善対象となる指標だけをKRに置くと、目標と日常指標の混同を防げます。

評価へ直結させる前に運用目的を分ける

OKRを評価へ直結させる前に、運用目的を分ける必要があります。挑戦学習のためのOKRなのか、評価材料として参照する目標なのかを曖昧にすると、現場の本音が出にくくなります。

評価面談でOKRを参照する場合は、達成率だけでなく、難易度、支援状況、期中の変更理由も合わせて見ます。本人に説明する材料を残すには、日常の対話記録が欠かせません。

評価コメントへ目標進捗を使う場合は、人事評価コメントの書き方も確認できます。OKRは評価の代替ではなく、評価材料を整理する補助として扱います。

OKRを1on1で運用する質問例

OKRは、設定後に1on1で進捗、障害、支援を問い直して初めて日常運用に乗ります。達成率だけを確認する場にせず、次の行動と上司側の支援を分けて記録します。

進捗確認は達成率だけで終えない

OKRの1on1では、達成率だけでなく、進捗の質を確認します。数字が進んでいても、重要顧客や本来のObjectiveから外れていれば軌道修正が必要です。

質問例は「今の進捗はObjectiveのどの状態変化につながっていますか」です。続けて「進んでいるKRと止まっているKRの違いは何ですか」と聞くと、原因を分けやすくなります。

短期目標では数値確認も必要ですが、数値報告だけで終えると支援につながりません。最後に「次回までに何を変えるか」を確認し、行動と支援の話へ進めます。

障害を聞く質問で支援を決める

障害を聞く質問は、本人の責任追及ではなく、支援内容を決めるために使います。OKRが停滞したときほど、上司は原因を人ではなく条件で整理します。

質問例は「進捗を止めている要因は、本人の行動、関係者の合意、情報不足のどれに近いですか」です。この聞き方なら、支援すべき相手や会議体を具体化できます。

マネージャーは、本人の発言だけでなく、決めた支援を記録します。コチームのように1on1、目標、評価をつなぐ運用では、支援の履歴が次回面談の起点になります。

次回行動を本人と上司で分ける

次回行動は、本人がやることと上司が支援することに分けます。OKR運用では、本人の努力だけに寄せると、組織側の障害が放置されます。

本人側の行動は「重点顧客への提案仮説を更新する」のように書きます。上司側の支援は「部門長との合意を取る」「評価基準の解釈を確認する」など、本人だけでは動かせない要素にします。

OKRを設定しても、面談で何を聞くかが決まっていないと運用が止まりやすくなります。目標が放置される前に、1on1で使う問いと記録の型を整えたい方は、以下の資料を確認できます。

導入前に確認すべき質問

OKRを配る前に、評価との関係、確認頻度、記録方法、責任者を決める必要があります。例文を配るだけでは、現場がどの目的で使うのか判断できません。

評価と切り分ける説明は済んでいるか

導入前には、OKRを評価にどう使うのかを説明します。評価に直結しないならその範囲を明示し、参照するなら達成率以外の見方も伝えます。

メンバーは、評価に使われると感じると安全な目標を選びやすくなります。挑戦学習のOKRなら、未達そのものではなく、学びと支援の記録を重視すると説明します。

部門長や人事が説明できない状態で始めると、現場ごとに解釈が分かれます。最初に評価との境界をそろえ、そのうえで確認頻度を決めます。

週次か隔週で見直す場はあるか

OKRは、週次か隔週で見直す場があると運用しやすくなります。月1回だけでは、停滞に気づいたときには支援が遅れる場合があります。

人数が多い組織では、全KRを毎回見る必要はありません。進捗が止まっているKR、支援が必要なKR、変更判断が必要なKRに絞ると、面談時間を圧迫しにくくなります。

頻度は、組織規模や目標期間に合わせて調整します。重要なのは回数の多さではなく、次の行動を決める場として定着しているかです。

OKRを誰が更新し誰が支援するか

OKR導入前には、誰が更新し、誰が支援するかを決めます。本人が進捗を更新し、上司が障害と支援を記録する形にすると責任範囲が明確になります。

小規模チームでは、本人と上司が兼任に近い運用でも問題ありません。ただし、更新日、変更理由、次回行動は残しておくと、振り返りで判断しやすくなります。

責任者が曖昧なまま始めると、OKRは期初の入力物で終わります。導入前の質問を確認したうえで、FAQでは具体例やKPIとの違いを補足します。

よくある質問

OKRの具体例は何ですか？

OKRの具体例は、Objectiveに「重点顧客から相談される営業組織になる」、Key Resultに商談化率や次回接続率などを置く形です。状態と成果指標を分けると運用しやすくなります。

OKRとKPIの違いは何ですか？

KPIは業務や成果の状態を測る指標です。OKRはObjectiveという目標文と、Key Resultという成果指標を組み合わせ、今期の重点テーマを進捗対話に使う型です。

OKRは個人目標に使えますか？

OKRは個人目標にも使えます。ただし人事評価へ直結させる前提にすると安全な目標に寄りやすいため、本人の挑戦テーマと上司の支援を話す材料として扱うのが現実的です。

まとめ

OKR例を作るときは、Objectiveに変えたい状態を書き、Key Resultに測定できる成果指標を置きます。良い例は進捗対話に使える形で整理され、悪い例は数値、施策、評価項目が混ざって確認すべき論点が曖昧になります。

例文を配るだけで運用を始めると、現場ごとに解釈が分かれ、期中の1on1では達成率の報告だけが残ります。評価との関係や更新責任を決めないままでは、メンバーが安全な目標を選び、未達リスクや支援依頼を出しにくくなります。

ObjectiveとKRを分けること、例を写すだけでなく添削すること、1on1で進捗と障害を確認することが、OKRを日常運用に乗せる順番です。OKRを設定して終わらせず、1on1で進捗と支援を確認する型まで整えたい場合は、以下の資料をご確認ください。

【260スライドで1on1を完全網羅】
流れ・アジェンダ・よくある失敗まで、実践に必要な知識をすべて詰め込んだ一冊！
>>『メンバーの成長・マネジメントのプロが実践する1on1パーフェクトガイド』を無料ダウンロードする