プラットフォーム開発部EMのchikaです。
今回は技術ブログとしてはあまり需要がなさそうなOKRに関する話題です。
弊社では組織目標をOKRで設定するようにしています。
目標設定はいつも難しいなと思いますが、ここ最近、OKRに対する理解が不足していることがその一因になっているのではないかと考えるようになりました。
EMという立場でありながら言いにくいのですが、自分のOKRに対する理解は表面的であり、教科書的な設定の仕方は知っていても実際の設定やその後の運用面について実践での理解が浅い状態だったので、もう少しちゃんとOKRのことを学ぼうと決意しました。
以降は、押さえておきたい基本的なことと合わせて、ここ最近で理解したこと、「もっと早く知りたかった」と感じたことなどをまとめてみました。
なお、それでも勘違いは多分にあると思いますので、明らかな間違いなどあれば暖かいツッコミをいただけると幸いです。
OKRの基本知識
今更必要もないかもしれませんが、一応基礎的なことも書いておきます。
OKRって何のためのもの？
OKRは、簡単には達成できないような難易度の高い目標を掲げて進捗状況を確認できるようにするためのものです。
OKRは、できるとわかっている以上のことを成し遂げる後押しをするために設計されている。“ムーンショット”を目指せば、たとえ月までたどりつけなくても、きっと壮大な眺めを楽しめる
（『OKR（オーケーアール）シリコンバレー式で大胆な目標を達成する方法』より）
OKRの目的は従業員の評価をすることでも、タスクを社内で共有することでもありません。
高いけど手が届きそうな目標を目指すことで従業員のモチベーションを高め、想定よりも大きな成果を上げるためのものです。
OとKRの意味
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を設定する際は、一般的には上位組織（例えば部署）のOKRの達成指標としてブレイクダウンされた、自チームの業務領域に該当するKRを自チームのOとして読み替えて*1設定します。
この、「上位組織のKR≒自チームのO」のようなブレイクダウンするようなアプローチが、OKRがツリー構造といわれる所以です。
OKR設定・運用時の注意点
OとKRでやってしまいがちな勘違い
手段（KR）を目的（O）化してしまう
「目標は客観的に達成が判断可能になっているべき」ということが頭に入っている人が多いのか、Oに「MAUを○○にする」「生産性を○%向上する」などのような定量的な表現で設定してしまったことはないでしょうか。
Oは「『こうありたい」という姿を表す定性的な方針」と最初に書きましたが、それに対し、このような定量的な表現で設定された目標は、何らか到達したい状態になるための「手段」であるはずで、どちらかといえばKRに設定されるべきものです。
例えばこんなイメージです。
- O：ビジネス用途で日本一使われるAI翻訳になる
- KR：（そのために）MAUを○○する
- O：毎月リリースがあるプロダクトにする
- KR：（そのために）開発の生産性を○%向上する
何のためにMAUや生産性を上げるのか？上げることでどんな状態になることを目指しているのか？それがないのだとしたら、手段が目的化してしまっているということになります。
KRをタスクにしてしまう
また、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が達成できれば良いということです。
この「ツリー構造じゃなくて良い」というのは以下の記事を読んで「それでいいんだ」と気付かされました。
一つ注意するなら、ボトムアップで目標設定した場合でも、上位の組織（直属でなくても）のどれかには関係しているかと思いますので、それが所属している組織にどんな価値をもたらす目標なのか、上位組織の目標に追加できるかどうかを検討・相談しましょう。
OもKRも3〜5個程度まで
Google re:Work によると、Googleで目標設定する際は、3〜5個の目標（O）を立て、それぞれの目標について成果指標（KR）を3個ほど設定するということです。
リソースの分散を防ぎ集中するという意味では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について調べていた際、こちらの動画を見つけて視聴したのですが、「こういうときどうすれば良いの？」というよくある疑問に答えてくれる素晴らしい内容でした。
その中で特に参考になった内容を、自分の理解も交えていくつか共有します。
定量的なKRを立てるのが難しいのだけどどうすれば？
エンジニアチームだと売り上げや契約数など、事業目標に直接紐づいた数字を目標にするのが難しいため、定量的なKRを立てるのが難しい場合があります。その場合にどうやって客観的に判断可能なKRを立てれば良いでしょうか？
結論として、機能実装の完了やリリース完了などを目標にすること自体は仕方ない側面があるので、それ自体を否定はできません。
ただし、期末までに完了するのでは達成が簡単になってしまうこともあります。そこで「SMART」のT：Time-bound（時間制約がある）の要素として期限を設けることで、適切な難易度設定ができ、目標が引き締まります。
とはいえ、関係者の多いプロジェクトの完了に対して期限を設けてしまうと、自分たちの手の及ばないところで遅延が発生してしまい目標達成できないという事態がよく起こります。安易にオンスケをコミットしたり、早期完了にチャレンジする設定をするのは禁物です。
上位組織のOKRが決まっていないのだけど？
組織目標を決めるタイミングで上位の組織の目標がまだ決まっていない、組織目標はまだ固まっていないけどチーム目標を先行して検討しないと、というケースもよくあります。この状態でOKRを設定するのは可能でしょうか？
もちろん、上位組織のOKRが決まっている状態で検討するのが理想ですが、実際はトップOKRに対して下位の組織はツリー上に綺麗に分割されるわけでないですし、横の関連部署の目標と関わることも多いので、上位が決まっていなくても、縦横を見て検討すれば自ずとトップOKRとは合うものができるはずです。
あとで上位組織のOKRが決まったら、整合性を合わせれば良いのです。
デプロイ数・リードタイムなどのエンジニアチームの生産性指標を目標にして良い？
エンジニアチームではなかなかビジネスに直結する目標が立てられないこともよくあります。一方で、生産性の向上として定量的な指標を目標に設定しようとするケースもよくあります。生産性指標をOKRに設定するのは良いのでしょうか？
プロダクト進化の過程から見ると仮説検証のサイクルに直結するという意味ではデプロイ数・リードタイムなどの指標をモニタリングすることは重要です。
ただ、目標にしてしまうとそれに執着してビルドトラップ（アウトプットに偏重し、リリース自体をゴールと捉えてしまう状態）に陥る恐れがあります。
モニタリングすべきヘルスチェック指標としては設定するのは良いことですが、OKRに設定することとは切り離して考えた方がよく、その指標の先にどんな価値があるのかを考える必要があります。
チームOKRと個人OKRは直結するべき？
OKRは組織目標から個人目標までをツリーで表現することも多いですが、個人目標は人事評価に直結することが多く、達成が困難な目標を立てにくいと感じる方も多いと思います。
OKRの最小単位はチームでしょうか、それとも個人までブレイクダウンするのが良いのでしょうか。
結論から言えば、OKRの最小単位はチームが良いということです。
OKRと人事評価は非依存にして、OKRはそのまま人事評価に用いるべきではない（少なくとも、OKRの達成度をそのまま人事評価にしない）という見解を示されていました。
理由は誰もが感じているように、自分の評価・給与に直結すると思うと、ストレッチ目標にすることがなくなってしまうからです。こうなると、最終的に割を食うのは事業を成長させたい会社側です。
良いOKRを設定するには、評価に紐づかない、制約のない状態で検討する必要があります。
個人の評価に当たってはチームOKRの結果そのものではなく、定性的に「目標にどう貢献したか」を評価するなど、視点を変える必要があります。
まとめ
今回はOKRの意味、設定の仕方の基本や、実際に運用する際にあるあるな疑問について取り上げてまとめました。
基礎的な部分と合わせて書かせていただいたので、これから学ぼうとする誰か他の方の役にでも立てば幸いです。
なお今回調べたことで自分が目標設定にどれだけ活かせたかというと、なかなかその通りにはいかないなぁという難しさを感じつつも、モヤモヤしていたところの理解が進むなど、部分的には改善できたかなと思います。
We are hiring!
みらい翻訳では、私たちと一緒に翻訳プロダクトの開発を進めていただけるエンジニアを募集しています！ ご興味のある方は、ぜひ下記リンクよりご応募・お問い合わせをお待ちしております。
参考資料
- 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:ここで読み替えと言っているのは、そのまま持ってくるということではなく、自チームに相応しい目標として定性的な表現で定義し直すという意味です
