「OKRがよく分からない」人に向けたOKR設定の注意点
Mirai Translate Tech Blog の記事は、エンジニアリング組織における OKR 設定の誤解を解消し、目的と手段の区別や野心的目標の重要性を解説する実践的なガイドである。
キーポイント
O と KR の本質的違いと勘違いの回避
O（Objective）は定性的な「目指す姿」であり、KR（Key Results）はそれを測る定量的指標であるべきだが、多くの組織で手段が目的化したり、タスクが成果として混同されたりしている。
コミット型と野心的 OKR の明確な区別
必ず達成すべき「コミットする OKR」と、挑戦的な「野心的 OKR」は性質が異なるため、両者を混同せず使い分けることが組織の健全な成長に不可欠である。
エンジニアリング指標を OKR に適用する際の注意点
デプロイ数やリードタイムなどの生産性指標は手段になりがちであり、それらがもたらす最終的なビジネス価値（O）と結びつけて設定する必要がある。
上位組織の OKR 未定時の対処法
上位組織の目標が決まっていない場合でも、自チームが貢献すべき領域を仮説として設定し、ツリー構造を意識しつつも柔軟に調整するアプローチが推奨される。
野心的OKRとコミット目標の区別
野心的OKR（ムーンショット）は達成率60-70%を期待する挑戦的目標であり、100%達成時は目標が低すぎるとみなされる。これに対しコミット目標は100%達成が前提であるため、両者の混同による目標設定の誤りを防ぐ必要がある。
OKRの柔軟な構造とボトムアップの活用
OKRは組織のツリー構造に縛られず、上位目標を全て取り込む必要はない。ボトムアップでメンバーがやりたい目標を設定し、他部署との連携で全社目標達成を目指すことでモチベーション向上が図れる。
優先順位付けと定期的な見直しの重要性
リソース集中のため目標数は3-5個程度に絞り、複数設定時は事前に優先順位を明確にする必要がある。また、状況変化に応じて四半期内で定期的に進捗を確認し、柔軟に見直すプロセスが不可欠である。
影響分析・編集コメントを表示
影響分析
この記事は、AI/テック業界で急速に導入が進む OKR の運用において、多くの組織が陥りがちな「数値目標の安易な設定」や「タスクと成果の混同」という実務上の課題を鋭く指摘しています。特にエンジニアリングチーム向けに、生産性指標をどう扱うかという具体的な事例を示しているため、現場のマネージャーやリーダーにとって即座に適用可能な改善指針となります。
編集コメント
AI/テック業界特有の技術トレンドではありませんが、組織の生産性を最大化するための普遍的なフレームワーク運用における「落とし穴」を指摘しており、現場リーダーにとって非常に価値のある実践知です。
プラットフォーム開発部 EM の chika です。
今回は技術ブログとしてはあまり需要がなさそうな OKR に関する話題です。
弊社では組織目標を OKR で設定するようにしています。
目標設定はいつも難しいなと思いますが、ここ最近、OKR に対する理解が不足していることがその一因になっているのではないかと考えるようになりました。
EM という立場でありながら言いにくいのですが、自分の OKR に対する理解は表面的であり、教科書的な設定の仕方は知っていても実際の設定やその後の運用面について実践での理解が浅い状態だったので、もう少しちゃんと OKR のことを学ぼうと決意しました。
以降は、押さえておきたい基本的なことと合わせて、ここ最近で理解したこと、「もっと早く知りたかった」と感じたことなどをまとめてみました。
なお、それでも勘違いは多分にあると思いますので、明らかな間違いなどあれば暖かいツッコミをいただけると幸いです。
OKR の基本知識 OKR って何のためのもの？
O と KR の意味 O：Objectives（目標、目的）
KR：Key Results（主要な結果、成果指標）
OKR 設定・運用時の注意点 O と KR でやってしまいがちな勘違い 手段（KR）を目的（O）化してしまう
「コミットする OKR」と「野心的 OKR」をごっちゃにしない
「OKR はツリー構造」に囚われない
こんなときどうすれば良い？定量的な KR を立てるのが難しいのだけどどうすれば？
上位組織の OKR が決まっていないのだけど？
デプロイ数・リードタイムなどのエンジニアチームの生産性指標を目標にして良い？
チーム OKR と個人 OKR は直結するべき？
今更必要もないかもしれませんが、一応基礎的なことも書いておきます。
OKR は、簡単には達成できないような難易度の高い目標を掲げて進捗状況を確認できるようにするためのものです。
OKR は、できるとわかっている以上のことを成し遂げる後押しをするために設計されている。"ムーンショット"を目指せば、たとえ月までたどりつけなくても、きっと壮大な眺めを楽しめる
（『OKR（オーケーアール）シリコンバレー式で大胆な目標を達成する方法』より）
OKR の目的は従業員の評価をすることでも、タスクを社内で共有することでもありません。
高いけど手が届きそうな目標を目指すことで従業員のモチベーションを高め、想定よりも大きな成果を上げるためのものです。
O：Objectives（目標、目的）
目指す状態を表す定性的な方針を示したものです。
定性的な方針というと Mission・Vision に似ていますが、Mission・Vision が年単位で実現したり、ずっと変わらない方針を表すのに対して、OKR は四半期程度で実現できるものを設定するため、O はより短期の方針を示します。
「70% 達成できれば成功、100% 達成は難しい」といわれますが、レベル感を補足すると、設定した期間にやり遂げるのが難しいが、それでいて不可能ではない現実的な目標を立てます。
また、O は「わくわくできるようなもの」とも言われます。
達成が難しい目標に対して、「あとひと押し」できるかどうかは、メンバーがわくわくして目標達成のために頑張れるかどうかにかかっている、ということでしょう。
KR：Key Results（主要な結果、成果指標）
目標（O）を達成するために必要な、具体的で測定可能な成果の指標です。通常、各 O に対して 3～5 つの KR を設定し、それぞれの進捗を数値や達成度合いで追跡します。
また、「ストレッチ目標を立てよう」ということをよく言いますが、設定する KR は「10 分の 5 の自信度」を設定するとよいと言われています。
つまり、確実に達成できるわけでも「まず無理」と思ってしまうものでもなく、あらゆる手を尽くせば五分五分で達成できそうと思えるものにしようということです。
OKR は全社目標からチーム・個人目標までを連動させることができるフレームワークです。
チームの OKR を設定する際は、一般的には上位組織（例えば部署）の OKR の達成指標としてブレイクダウンされた、自チームの業務領域に該当する KR を自チームの O として読み替えて*1設定します。
この、「上位組織の KR≒自チームのO」のようなブレイクダウンするようなアプローチが、OKR がツリー構造といわれる所以です。
O と KR でやってしまいがちな勘違い
手段（KR）を目的（O）化してしまう
「目標は客観的に達成が判断可能になっているべき」ということが頭に入っている人が多いのか、O に「MAU を○○にする」「生産性を○%向上する」などのような定量的な表現で設定してしまったことはないでしょうか。
O は「『こうありたい」という姿を表す定性的な方針」と最初に書きましたが、それに対し、このような定量的な表現で設定された目標は、何らか到達したい状態になるための「手段」であるはずで、どちらかといえば KR に設定されるべきものです。
O：ビジネス用途で日本一使われる AI 翻訳になる KR：（そのために）MAU を○○する
O：毎月リリースがあるプロダクトにする KR：（そのために）開発の生産性を○%向上する
何のために MAU や生産性を上げるのか？上げることでどんな状態になることを目指しているのか？それがないのだとしたら、手段が目的化してしまっているということになります。
また、KR に「○○を設計する」「○○を開発する」「○○のドキュメントを作成する」などと言った表現を見かけることもよくあります。これらが目標達成のために必要なことであることはわかりますが、これは行動（アクションプラン）であって、成果ではありません。行動は成果を得るためにとりますが、成果を得るための唯一の行動ではありません。言ってみればただのタスクです。タスクはその時々でいくらでも変わります。
プロジェクトに従事している場合などは、究極的にはプロジェクト完了までは成果にはならないので KR を立てるのが難しいかもしれませんが、その時は完了までのマイルストーンを成果に見立てて KR に設定するのが現実的かと思います。
「コミットする OKR」と「野心的 OKR」をごっちゃにしない
OKR の基本を知ると、OKR とはとにかくストレッチ目標を立てるもの、と思い込んでしまいますが、実は OKR には「コミットする OKR」と「野心的 OKR」の 2 種類があり、両者を区別することが重要です。
「コミットする OKR」は組織として必ず達成すると決めて計画するもので、期待される達成率は 100%
必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等)は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:
{"translation": "翻訳全文"}
「野心的 OKR」とは、自分たちが実現したい世界を描くもので、どうすればそこに到達できるのか、達成にどれだけのリソースが必要なのかまるで分からない、というレベルのもので、期待される達成率は 60-70% です。
（参考：『Measure What Matters』より）
野心的 OKR は、「月に届くほどの高い目標」という意味で「ムーンショット」とも呼ばれます。それに対し、コミットする目標は、挑戦的だが達成可能性の高い目標ということで「ルーフショット」（屋根に届くほどの目標）と呼ばれます。
コミットする目標が 100% 達成を期待されるのに対して、野心的 OKR は難しい挑戦であるゆえに、期待される達成率は 60-70% であり、逆に達成率が 100% の場合、目標が低すぎる可能性があるとみなされます。
（これ、言うのは簡単ですが設定時のさじ加減が非常に難しい。。）
この両者を認識して区別できていないと、設定した目標は全部達成しないといけないものと思い込み、未達を恐れて達成可能な手堅い目標ばかり設定してしまったり、本当は「コミットする OKR」である目標に対して 70% 程度の達成にとどまってしまってもそれで良しとしてしまい、実際は何の成果も得られていないということになりかねません。
「OKR はツリー構造」に囚われない
OKR が一般的にツリー構造であると認識されるあまり、それが先入観となってしまい、
「チーム目標には部署目標を全部含めないといけない」
「部署目標にない目標は立てちゃダメ」
と思ってしまいがちですが、これは誤りです。
上位の組織の OKR は全て取り込む必要はありません。
OKR はトップダウンとボトムアップ双方の提案が組み合わさることで高い効果が期待できます。トップダウンで”やらされる”目標ばかりにするのではなく、ボトムアップでチームが”これはぜひやりたい”と考える目標をチームの OKR に設定する方が、メンバーの目標達成に対するモチベーションが上がりますよね。
また、実際の現場業務は組織のツリー構造どおりに綺麗に分割されているわけでもないので、部署目標だけを見てチーム目標を立てるのが実情に合わないこともよくあります。その場合は、隣の部署や、自部署の上位の部門の KR（Key Results：主要成果指標）をもとにしてチーム OKR を設定することも可能です。
要は他のチームと協力して部署や全社の OKR が達成できれば良いということです。
この「ツリー構造じゃなくて良い」というのは以下の記事を読んで「それでいいんだ」と気付かされました。
一つ注意するなら、ボトムアップで目標設定した場合でも、上位の組織（直属でなくても）のどれかには関係しているかと思いますので、それが所属している組織にどんな価値をもたらす目標なのか、上位組織の目標に追加できるかどうかを検討・相談しましょう。
Google re:Work によると、Google で目標設定する際は、3〜5 個の目標（O：Objectives：目的）を立て、それぞれの目標について成果指標（KR：Key Results：主要成果指標）を 3 個ほど設定するということです。
rework.withgoogle.com
リソースの分散を防ぎ集中するという意味では O を 1 つにするのが理想ですが、ただでさえ同時並行でやるべきことが多い現代のビジネス環境では 1 つに絞れないというチームの方が多いと思いますので、チーム目標が 3〜5 個というのは的を射た数だと思います。
個人的には、四半期で 5 個も目標があるのは正直多いと感じるので、3 つくらいまでにするのが良いと思います。
KR（Key Results：主要成果指標）についても、1 つの O（Objective：目的）について 3〜5 個程度と言われています。
場合によっては O の達成を計測・判断するために 5 個を超える成果指標が必要ということもあり得ると思いますが、指標を計測する負荷も増えてしまいます。あまりに必要な成果指標が多い場合は O 自体を見直した方が良いかもしれません。
経験的には、ボトムアップで達成したい・改善したいことを KR として集めて OKR（Objectives and Key Results：目標と主要成果指標）を設定するアプローチをとると KR が多くなってしまいがちです。多種多様な業務を抱える組織ではどうしてもそのような形になることもあり否定はできませんが、チームレベルの目標で KR が多くなる場合は、中身を見るとただのタスクリストになっている、ということもよくあるので注意が必要と感じています。
高い目標を達成するためにはリソースの集中が必要です。そもそも「野心的な OKR」を達成するにはリソースを集中させても達成できるかどうか、という難易度なのです。この状態で複数設定した OKR を全て達成しようとすると、どれも満足に達成できない可能性が高くなります。
これを避けるためには、複数の OKR、およびその他目標に含まれていない通常業務も含めて、優先順位の設定が大事です。
期中には「思っていたよりも難易度が高くてちょっと達成が厳しい」といった状況にしばしば直面するので、その際に「次にどの KR の達成を優先するか」や、「どの O の達成を諦めるのか」をスムーズに判断するために、事前に OKR の優先順位を可能な限り明確にしておくのが良いです。
OKR は設定するだけでは意味がありません。四半期でも状況はどんどん変わっていくため、定期的に目標と進捗を共有し、状況変化により目標と実態のズレが生じてきたら見直さなければなりません。
スクラムでスプリントごとに区切ってレビューとふりかえりを行い、次のスプリントゴールやプロダクトゴールを見直すのと同じですね。
OKR は目の前の業務に集中するとどうしても忘れがちになるので、スクラムイベントと同じように目標についても意図的にふりかえりの場・タイミングを設けておかないと、気がついたら期末最終月を迎えていたということになります。
とはいえ、目標の運用自体に時間をかけすぎてしまうと「OKR 疲れ」してしまう原因となってしまうので、いかに手間をかけずに進捗状況の確認と目標の見直しができるかが鍵です。
今期、プラットフォーム開発部ではチームの進捗報告の場として週 1 回開催している会議で、OKR の達成度や進捗状況を報告するようにしました。そのほか、個人目標の状況確認と合わせて 1on1 で確認するなどしています。
OKR について調べていた際、こちらの動画を見つけて視聴したのですが、「こういうときどうすれば良いの？」というよくある疑問に答えてくれる素晴らしい内容でした。
その中で特に参考になった内容を、自分の理解も交えていくつか共有します。
www.youtube.com
定量的な KR を立てるのが難しいのだけどどうすれば？
エンジニアチームの場合、売り上げや契約数など事業目標に直接紐づく数字を目標にすることが難しく、定量的な KR（Key Results：主要成果指標）を立てるのが難しい場合があります。その場合にどうやって客観的に判断可能な KR を立てれば良いでしょうか？
結論として、機能実装の完了やリリース完了などを目標にすること自体は仕方ない側面があるので、それ自体を否定はできません。
ただし、期末までに完了するのでは達成が簡単になってしまうこともあります。そこで「SMART」の T：Time-bound（時間制約がある）の要素として期限を設けることで、適切な難易度設定ができ、目標が引き締まります。
とはいえ、関係者の多いプロジェクトの完了に対して期限を設けてしまうと、自分たちの手の及ばないところで遅延が発生してしまい目標達成できないという事態がよく起こります。安易にオンスケ（納期遵守）をコミットしたり、早期完了にチャレンジする設定をするのは禁物です。
上位組織の OKR が決まっていないのだけど？
組織目標を決めるタイミングで上位の組織の目標がまだ決まっていない、組織目標はまだ固まっていないけどチーム目標を先行して検討しないと、というケースもよくあります。この状態で OKR を設定するのは可能でしょうか？
もちろん、上位組織の OKR が決まっている状態で検討するのが理想ですが、実際はトップ OKR に対して下位の組織はツリー上に綺麗に分割されるわけでないですし、横の関連部署の目標と関わることも多いので、上位が決まっていなくても、縦横を見て検討すれば自ずとトップ OKR とは合うものができるはずです。
あとで上位組織の OKR が決まったら、整合性を合わせれば良いのです。
デプロイ数・リードタイムなどのエンジニアチームの生産性指標を目標にして良い？
エンジニアチームではなかなかビジネスに直結する目標が立てられないこともよくあります。一方で、生産性の向上として定量的な指標を目標に設定しようとするケースもよくあります。生産性指標を OKR に設定するのは良いのでしょうか？
プロダクト進化の過程から見ると仮説検証のサイクルに直結するという意味ではデプロイ数・リードタイムなどの指標をモニタリングすることは重要です。
ただ、目標にしてしまうとそれに執着してビルドトラップ（アウトプットに偏重し、リリース自体をゴールと捉えてしまう状態）に陥る恐れがあります。
www.oreilly.com
モニタリングすべきヘルスチェック指標としては設定するのは良いことですが、OKR に設定することとは切り離して考えた方がよく、その指標の先にどんな価値があるのかを考える必要があります。
チーム OKR と個人 OKR は直結するべき？
OKR は組織目標から個人目標までをツリーで表現することも多いですが、個人目標は人事評価に直結することが多く、達成が困難な目標を立てにくいと感じる方も多いと思います。
OKR の最小単位はチームでしょうか、それとも個人までブレイクダウンするのが良いのでしょうか。
結論から言えば、OKR の最小単位はチームが良いということです。
OKR と人事評価は非依存にして、OKR はそのまま人事評価に用いるべきではない（少なくとも、OKR の達成度をそのまま人事評価にしない）という見解を示されていました。
理由は誰もが感じているように、自分の評価・給与に直結すると思うと、ストレッチ目標（挑戦的な目標）にすることがなくなってしまうからです。こうなると、最終的に割を食うのは事業を成長させたい会社側です。
良い OKR を設定するには、評価に紐づかない、制約のない状態で検討する必要があります。
個人の評価に当たってはチーム OKR の結果そのものではなく、定性的に「目標にどう貢献したか」を評価するなど、視点を変える必要があります。
今回は OKR の意味、設定の仕方の基本や、実際に運用する際にあるあるな疑問について取り上げてまとめました。
基礎的な部分と合わせて書かせていただいたので、これから学ぼうとする誰か他の方の役にでも立てば幸いです。
なお今回調べたことで自分が目標設定にどれだけ活かせたかというと、なかなかその通りにはいかないなぁという難しさを感じつつも、モヤモヤしていたところの理解が進むなど、部分的には改善できたかなと思います。
みらい翻訳では、私たちと一緒に翻訳プロダクトの開発を進めていただけるエンジニアを募集しています！ ご興味のある方は、ぜひ下記リンクよりご応募・お問い合わせをお待ちしております。
miraitranslate.com
Google re:Work - ガイド：OKR を設定する
Measure What Matters: 伝説のベンチャー投資家が Google に教えた成功手法 OKR
OKR（オーケーアール）シリコンバレー式で大胆な目標を達成する方法
OKR をエンジニア組織で導入する方法とは？元 Google の及川氏が徹底解説 - YouTube
第 1 章 OKR を知る ～組織の目標に貢献できる実感が、個人のやる気を向上させる | gihyo.jp
OKR とは？目標への推進力を高める、話題の目標管理手法 - SmartHR Mag.
なぜ KPI よりも OKR と言われるのか？OKR の勘所 #マネジメント - Qiita
成功する目標設定 5 つのポイント「SMART の法則」とは？【フレームワーク解説／意味・具体的な使い方／ゴール設定】 | GLOBIS 学び放題×知見録
*1:ここで読み替えと言っているのは、そのまま持ってくるということではなく、自チームに相応しい目標として定性的な表現で定義し直すという意味です
原文を表示
プラットフォーム開発部EMのchikaです。
今回は技術ブログとしてはあまり需要がなさそうなOKRに関する話題です。
弊社では組織目標をOKRで設定するようにしています。
目標設定はいつも難しいなと思いますが、ここ最近、OKRに対する理解が不足していることがその一因になっているのではないかと考えるようになりました。
EMという立場でありながら言いにくいのですが、自分のOKRに対する理解は表面的であり、教科書的な設定の仕方は知っていても実際の設定やその後の運用面について実践での理解が浅い状態だったので、もう少しちゃんとOKRのことを学ぼうと決意しました。
以降は、押さえておきたい基本的なことと合わせて、ここ最近で理解したこと、「もっと早く知りたかった」と感じたことなどをまとめてみました。
なお、それでも勘違いは多分にあると思いますので、明らかな間違いなどあれば暖かいツッコミをいただけると幸いです。
OKRの基本知識 OKRって何のためのもの？
OとKRの意味 O：Objectives（目標、目的）
KR：Key Results（主要な結果、成果指標）
OKR設定・運用時の注意点 OとKRでやってしまいがちな勘違い 手段（KR）を目的（O）化してしまう
「コミットするOKR」と「野心的OKR」をごっちゃにしない
「OKRはツリー構造」に囚われない
こんなときどうすれば良い？ 定量的なKRを立てるのが難しいのだけどどうすれば？
上位組織のOKRが決まっていないのだけど？
デプロイ数・リードタイムなどのエンジニアチームの生産性指標を目標にして良い？
チームOKRと個人OKRは直結するべき？
今更必要もないかもしれませんが、一応基礎的なことも書いておきます。
OKRは、簡単には達成できないような難易度の高い目標を掲げて進捗状況を確認できるようにするためのものです。
OKRは、できるとわかっている以上のことを成し遂げる後押しをするために設計されている。“ムーンショット”を目指せば、たとえ月までたどりつけなくても、きっと壮大な眺めを楽しめる
（『OKR（オーケーアール）シリコンバレー式で大胆な目標を達成する方法』より）
OKRの目的は従業員の評価をすることでも、タスクを社内で共有することでもありません。
高いけど手が届きそうな目標を目指すことで従業員のモチベーションを高め、想定よりも大きな成果を上げるためのものです。
O：Objectives（目標、目的）
目指す状態を表す定性的な方針を示したものです。
定性的な方針というとMission・Visionに似ていますが、Mission・Visionが年単位で実現したり、ずっと変わらない方針を表すのに対して、OKRは四半期程度で実現できるものを設定するため、Oはより短期の方針を示します。
「70%達成できれば成功、100%達成は難しい」といわれますが、レベル感を補足すると、設定した期間にやり遂げるのが難しいが、それでいて不可能ではない現実的な目標を立てます。
また、Oは「わくわくできるようなもの」とも言われます。
達成が難しい目標に対して、「あとひと押し」できるかどうかは、メンバーがわくわくして目標達成のために頑張れるかどうかにかかっている、ということでしょう。
KR：Key Results（主要な結果、成果指標）
目標（O）を達成するために必要な、具体的で測定可能な成果の指標です。通常、各Oに対して3～5つのKRを設定し、それぞれの進捗を数値や達成度合いで追跡します。
また、「ストレッチ目標を立てよう」ということをよく言いますが、設定するKRは「10分の5の自信度」を設定するとよいと言われています。
つまり、確実に達成できるわけでも「まず無理」と思ってしまうものでもなく、あらゆる手を尽くせば五分五分で達成できそうと思えるものにしようということです。
OKRは全社目標からチーム・個人目標までを連動させることができるフレームワークです。
チームのOKRを設定する際は、一般的には上位組織（例えば部署）のOKRの達成指標としてブレイクダウンされた、自チームの業務領域に該当するKRを自チームのOとして読み替えて*1設定します。
この、「上位組織のKR≒自チームのO」のようなブレイクダウンするようなアプローチが、OKRがツリー構造といわれる所以です。
OとKRでやってしまいがちな勘違い
手段（KR）を目的（O）化してしまう
「目標は客観的に達成が判断可能になっているべき」ということが頭に入っている人が多いのか、Oに「MAUを○○にする」「生産性を○%向上する」などのような定量的な表現で設定してしまったことはないでしょうか。
Oは「『こうありたい」という姿を表す定性的な方針」と最初に書きましたが、それに対し、このような定量的な表現で設定された目標は、何らか到達したい状態になるための「手段」であるはずで、どちらかといえばKRに設定されるべきものです。
O：ビジネス用途で日本一使われるAI翻訳になる KR：（そのために）MAUを○○する
O：毎月リリースがあるプロダクトにする KR：（そのために）開発の生産性を○%向上する
何のためにMAUや生産性を上げるのか？上げることでどんな状態になることを目指しているのか？それがないのだとしたら、手段が目的化してしまっているということになります。
また、KRに「○○を設計する」「○○を開発する」「○○のドキュメントを作成する」などと言った表現を見かけることもよくあります。これらが目標達成のために必要なことであることはわかりますが、これは行動（アクションプラン）であって、成果ではありません。行動は成果を得るためにとりますが、成果を得るための唯一の行動ではありません。言ってみればただのタスクです。タスクはその時々でいくらでも変わります。
プロジェクトに従事している場合などは、究極的にはプロジェクト完了までは成果にはならないのでKRを立てるのが難しいかもしれませんが、その時は完了までのマイルストーンを成果に見立ててKRに設定するのが現実的かと思います。
「コミットするOKR」と「野心的OKR」をごっちゃにしない
OKRの基本を知ると、OKRとはとにかくストレッチ目標を立てるもの、と思い込んでしまいますが、実はOKRには「コミットするOKR」と「野心的OKR」の2種類があり、両者を区別することが重要です。
「コミットするOKR」は組織として必ず達成すると決めて計画するもので、期待される達成率は100%
「野心的OKR」とは自分たちが実現したい世界を描くもので、どうすればそこに到達できるのか、達成にどれだけのリソースが必要なのかまるで分からない、というレベルのもので、期待される達成率は60-70%
（参考：『Measure What Matters』 より）
野心的OKRは、「月に届くほどの高い目標」という意味で「ムーンショット」とも呼ばれます。それに対し、コミットする目標は、挑戦的だが達成可能性の高い目標ということで「ルーフショット」（屋根に届くほどの目標）と呼ばれます。
コミットする目標が100%達成を期待されるのに対して、野心的OKRは難しい挑戦であるゆえに、期待される達成率は60-70%であり、逆に達成率が100%の場合、目標が低すぎる可能性があるとみなされます。
（これ、言うのは簡単ですが設定時のさじ加減が非常に難しい。。）
この両者を認識して区別できていないと、設定した目標は全部達成しないといけないものと思い込み、未達を恐れて達成可能な手堅い目標ばかり設定してしまったり、本当は「コミットするOKR」である目標に対して70%程度の達成にとどまってしまってもそれで良しとしてしまい、実際は何の成果も得られていないということになりかねません。
「OKRはツリー構造」に囚われない
OKRが一般的にツリー構造であると認識されるあまり、それが先入観となってしまい、
「チーム目標には部署目標を全部含めないといけない」
「部署目標にない目標は立てちゃダメ」
と思ってしまいがちですが、これは誤りです。
上位の組織のOKRは全て取り込む必要はありません。
OKR はトップダウンとボトムアップ双方の提案が組み合わさることで高い効果が期待できます。トップダウンで ”やらされる” 目標ばかりにするのではなく、ボトムアップでチームが ”これはぜひやりたい” と考える目標をチームのOKRに設定する方が、メンバーの目標達成に対するモチベーションが上がりますよね。
また、実際の現場業務は組織のツリー構造どおりに綺麗に分割されているわけでもないので、部署目標だけを見てチーム目標を立てるのが実情に合わないこともよくあります。その場合は、隣の部署や、自部署の上位の部門のKRをもとにしてチームOKRを設定することも可能です。
要は他のチームと協力して部署や全社のOKRが達成できれば良いということです。
この「ツリー構造じゃなくて良い」というのは以下の記事を読んで「それでいいんだ」と気付かされました。
一つ注意するなら、ボトムアップで目標設定した場合でも、上位の組織（直属でなくても）のどれかには関係しているかと思いますので、それが所属している組織にどんな価値をもたらす目標なのか、上位組織の目標に追加できるかどうかを検討・相談しましょう。
Google re:Work によると、Googleで目標設定する際は、3〜5個の目標（O）を立て、それぞれの目標について成果指標（KR）を3個ほど設定するということです。
rework.withgoogle.com
リソースの分散を防ぎ集中するという意味ではOを1つにするのが理想ですが、ただでさえ同時並行でやるべきことが多い現代のビジネス環境では1つに絞れないというチームの方が多いと思いますので、チーム目標が3〜5個というのは的を射た数だと思います。
個人的には、四半期で5個も目標があるのは正直多いと感じるので、3つくらいまでにするのが良いと思います。
KRについても、1つのOについて3〜5個程度と言われています。
場合によってはOの達成を計測・判断するために5個を超える成果指標が必要ということもあり得ると思いますが、指標を計測する負荷も増えてしまいます。あまりに必要な成果指標が多い場合はO自体を見直した方が良いかもしれません。
経験的には、ボトムアップで達成したい・改善したいことをKRとして集めてOKRを設定するアプローチをとるとKRが多くなってしまいがちです。多種多様な業務を抱える組織ではどうしてもそのような形になることもあり否定はできませんが、チームレベルの目標でKRが多くなる場合は、中身を見るとただのタスクリストになっている、ということもよくあるので注意が必要と感じています。
高い目標を達成するためにはリソースの集中が必要です。そもそも「野心的なOKR」を達成するにはリソースを集中させても達成できるかどうか、という難易度なのです。この状態で複数設定したOKRを全て達成しようとすると、どれも満足に達成できない可能性が高くなります。
これを避けるためには、複数のOKR、およびその他目標に含まれていない通常業務も含めて、優先順位の設定が大事です。
期中には「思っていたよりも難易度が高くてちょっと達成が厳しい」といった状況にしばしば直面するので、その際に「次にどのKRの達成を優先するか」や、「どのOの達成を諦めるのか」をスムーズに判断するために、事前にOKRの優先順位を可能な限り明確にしておくのが良いです。
OKRは設定するだけでは意味がありません。四半期でも状況はどんどん変わっていくため、定期的に目標と進捗を共有し、状況変化により目標と実態のズレが生じてきたら見直さなければなりません。
スクラムでスプリントごとに区切ってレビューとふりかえりを行い、次のスプリントゴールやプロダクトゴールを見直すのと同じですね。
OKRは目の前の業務に集中するとどうしても忘れがちになるので、スクラムイベントと同じように目標についても意図的にふりかえりの場・タイミングを設けておかないと、気がついたら期末最終月を迎えていたということになります。
とはいえ、目標の運用自体に時間をかけすぎてしまうと「OKR疲れ」してしまう原因となってしまうので、いかに手間をかけずに進捗状況の確認と目標の見直しができるかが鍵です。
今期、プラットフォーム開発部ではチームの進捗報告の場として週1回開催している会議で、OKRの達成度や進捗状況を報告するようにしました。そのほか、個人目標の状況確認と合わせて1on1で確認するなどしています。
OKRについて調べていた際、こちらの動画を見つけて視聴したのですが、「こういうときどうすれば良いの？」というよくある疑問に答えてくれる素晴らしい内容でした。
その中で特に参考になった内容を、自分の理解も交えていくつか共有します。
www.youtube.com
定量的なKRを立てるのが難しいのだけどどうすれば？
エンジニアチームだと売り上げや契約数など、事業目標に直接紐づいた数字を目標にするのが難しいため、定量的なKRを立てるのが難しい場合があります。その場合にどうやって客観的に判断可能なKRを立てれば良いでしょうか？
結論として、機能実装の完了やリリース完了などを目標にすること自体は仕方ない側面があるので、それ自体を否定はできません。
ただし、期末までに完了するのでは達成が簡単になってしまうこともあります。そこで「SMART」のT：Time-bound（時間制約がある）の要素として期限を設けることで、適切な難易度設定ができ、目標が引き締まります。
とはいえ、関係者の多いプロジェクトの完了に対して期限を設けてしまうと、自分たちの手の及ばないところで遅延が発生してしまい目標達成できないという事態がよく起こります。安易にオンスケをコミットしたり、早期完了にチャレンジする設定をするのは禁物です。
上位組織のOKRが決まっていないのだけど？
組織目標を決めるタイミングで上位の組織の目標がまだ決まっていない、組織目標はまだ固まっていないけどチーム目標を先行して検討しないと、というケースもよくあります。この状態でOKRを設定するのは可能でしょうか？
もちろん、上位組織のOKRが決まっている状態で検討するのが理想ですが、実際はトップOKRに対して下位の組織はツリー上に綺麗に分割されるわけでないですし、横の関連部署の目標と関わることも多いので、上位が決まっていなくても、縦横を見て検討すれば自ずとトップOKRとは合うものができるはずです。
あとで上位組織のOKRが決まったら、整合性を合わせれば良いのです。
デプロイ数・リードタイムなどのエンジニアチームの生産性指標を目標にして良い？
エンジニアチームではなかなかビジネスに直結する目標が立てられないこともよくあります。一方で、生産性の向上として定量的な指標を目標に設定しようとするケースもよくあります。生産性指標をOKRに設定するのは良いのでしょうか？
プロダクト進化の過程から見ると仮説検証のサイクルに直結するという意味ではデプロイ数・リードタイムなどの指標をモニタリングすることは重要です。
ただ、目標にしてしまうとそれに執着してビルドトラップ（アウトプットに偏重し、リリース自体をゴールと捉えてしまう状態）に陥る恐れがあります。
www.oreilly.com
モニタリングすべきヘルスチェック指標としては設定するのは良いことですが、OKRに設定することとは切り離して考えた方がよく、その指標の先にどんな価値があるのかを考える必要があります。
チームOKRと個人OKRは直結するべき？
OKRは組織目標から個人目標までをツリーで表現することも多いですが、個人目標は人事評価に直結することが多く、達成が困難な目標を立てにくいと感じる方も多いと思います。
OKRの最小単位はチームでしょうか、それとも個人までブレイクダウンするのが良いのでしょうか。
結論から言えば、OKRの最小単位はチームが良いということです。
OKRと人事評価は非依存にして、OKRはそのまま人事評価に用いるべきではない（少なくとも、OKRの達成度をそのまま人事評価にしない）という見解を示されていました。
理由は誰もが感じているように、自分の評価・給与に直結すると思うと、ストレッチ目標にすることがなくなってしまうからです。こうなると、最終的に割を食うのは事業を成長させたい会社側です。
良いOKRを設定するには、評価に紐づかない、制約のない状態で検討する必要があります。
個人の評価に当たってはチームOKRの結果そのものではなく、定性的に「目標にどう貢献したか」を評価するなど、視点を変える必要があります。
今回はOKRの意味、設定の仕方の基本や、実際に運用する際にあるあるな疑問について取り上げてまとめました。
基礎的な部分と合わせて書かせていただいたので、これから学ぼうとする誰か他の方の役にでも立てば幸いです。
なお今回調べたことで自分が目標設定にどれだけ活かせたかというと、なかなかその通りにはいかないなぁという難しさを感じつつも、モヤモヤしていたところの理解が進むなど、部分的には改善できたかなと思います。
みらい翻訳では、私たちと一緒に翻訳プロダクトの開発を進めていただけるエンジニアを募集しています！ ご興味のある方は、ぜひ下記リンクよりご応募・お問い合わせをお待ちしております。
miraitranslate.com
Google re:Work - ガイド: OKRを設定する
Measure What Matters: 伝説のベンチャー投資家がGoogleに教えた成功手法OKR
OKR（オーケーアール）シリコンバレー式で大胆な目標を達成する方法
OKRをエンジニア組織で導入する方法とは？元Googleの及川氏が徹底解説 - YouTube
第1章 OKRを知る ～組織の目標に貢献できる実感が、個人のやる気を向上させる | gihyo.jp
OKRとは？目標への推進力を高める、話題の目標管理手法 - SmartHR Mag.
なぜKPIよりもOKRと言われるのか？OKRの勘所 #マネジメント - Qiita
成功する目標設定５つのポイント「SMARTの法則」とは？【フレームワーク解説／意味・具体的な使い方／ゴール設定】 | GLOBIS学び放題×知見録
*1:ここで読み替えと言っているのは、そのまま持ってくるということではなく、自チームに相応しい目標として定性的な表現で定義し直すという意味です
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み