OKRについてまとめる

それなりのキャリアの中で何回かOKRをやってみて、OKRの難しさであるとか、チームとしてつまずいたなあと思うようなポイントが複数あったので、少しまとめておこうと思います。
メモを列挙している形に近いのでだいぶ長いですが、参考になれば幸いです。
（OKRとはなんぞや？という話は書いていません。OKRそのものについて知りたい方は、末尾にあげる参考書籍や他のサイトをご覧いただくのが良いと思います）
いずれも、私が職務遂行の中でOKRを実践した経験によるもので、科学的な根拠やOKRの正式なトレーニングを受けたことによるモノではありません。

OとKRの決め方

OとKRの決め方は毎回悩むところです。
なにしろ、書籍(1.)によると「重要で、具体的で、行動を促し、（理想を言えば）人々を鼓舞するようなものだ」なんて言われていて体力を使う会議になりがちですし、別の書籍(1.)では「OKRを２週間以内に設定できなければ、優先事項を見直す必要がある。会社が結束するためのゴールを設定する以上に重要な仕事などない。」なんて書かれているので、事業にコミットしようという気持ちが強ければ強いほど、言葉尻に熱意を注ぐような、重箱の隅をつつく議論になりがちだからです。

OKRを決めるときに必ず守りたいのは、「Oから決める」という事です。
KRから決めると、大抵の場合ムーンショットにならなかったり、お飾りのOになってしまうからです。

Oを決めるためのプラクティス

まずは、私が何度かOKRをやってきた中で良いと思ったOを決めるためのプラクティスを紹介します。
ただ、これもやってみた感触として良かったなと思える方法なだけで、正解ではないと思いますし、こうして立てたOも期の最後に振り返ると全く達成できていないケースもありましたので、参考程度に見ていただくのが良いと思います。

考えたOは、ミッションやバリューの方向を向いているか

目の前の仕事に目がいくと、ミッションやバリューの方向を向いていないOを定めがちです。

OKRのOはムーンショットと呼ばれる達成困難に思える高い目標を掲げるわけですが、これは高い目標を達成するために集中する事で、通常とは異なるイノベーティブな発想ややり方を生み出すためでもあります。
そのためには、Oが自分たちのチームやプロダクトが出すべきミッションやバリューに向かっている必要があります。
Oの決定で行き詰まってしまった時は、一度ミッションやバリューがなんだったかを思い返すと良いです。

例えばECサイトを構築しているとして、顧客から伝票出力についてのクレームが入っているタイミングでOKRを決めようとすると、このクレームに目をつぶって議論することが難しくなります。
それでも、自分たちのミッションやバリューに立ち返って、そこから演繹的に議論する事で、Oを議論するタイミングに入ってきているノイズから自分たちの価値観を守ることができると思います。

アウトカムで考える

「定量的なOではなく、定性的なOにするべき」というのは多くのOKR関連書籍で言われている事ですが、本家OKR宣伝書とも言える書籍(1.)を参照すると、決してその限りではない事がわかります。
そこで、Oについては、アウトプットではなくアウトカムを狙うというのもひとつの方法だと思います。
すなわち、OKRの実施期間である3ヶ月が経過したときに、周りからどのように見られていたいか？この3ヵ月、ミッションやバリューに向かって活動した結果、何を得ていたいのかをOとして掲げる方法です。
これは、アウトプットを重視したO（XXの達成を目指す系のO）に比べると感情に訴えかけるものになりやすく、やる気を出すOを掲げるコツでもあるかなと思いました。

期間を強く意識する

ミッションやバリューの方向を向くと、どうしても高い目標を掲げがちになってしまいます。
しかし、OKRは3ヶ月とか半年のサイクルで回っていくものなので、この部分を考えてみると、OKRを実践した期間で、今の時点よりもミッションやバリューが目指しているものに近づいていけば良いということに気付きます。
そこで、例えば3ヶ月でやるなら3ヶ月という期間を強く意識して、その中でのムーンショット的なOを考えるのが良いと思っています。
不思議なもので、期間を強く意識するとより現実味のあるOが議論の俎上に上る率が高かったように思います。
保守的になりすぎて、ルーフショット（屋根の上）程度の目標になってしまう事も度々見られましたが、そこはチームの目標であればチームによる議論で、個人の目標であれば上長との議論で誤りを訂正していけるはずです。
期間を強く意識してOをブレイクダウンさせなければいけない目安としては、これまでやってきたOKRで、毎回Oが同じ事を指していて変わらないとすれば、それはもっと小さなOを複数達成すると到達できるOなのかもしれないと思います。

そのOは地に足がついているか？

OKRについては、常々「ムーンショットな目標を立てる」と言われているため、圧倒的に高い目標を立ててしまいがちです。
これを「マーズショット」と表現するケースがありますが、月に行く目標を立てないといけないのに、月を飛び越して火星に行く目標を立ててしまうケースが起こりえます。
火星に行く目標は大抵の場合とても抽象的で、カッコいい言い回しで表現できるので魅力的なOに映ってしまいがちです。また、言葉の力強さに押し切られてチームの目指すものがこの手のOに決まってしまうこともあります。

けれども、真に価値のある、有効なOを打ち立てるためには、一旦立ち止まって「その前に月に行けていないよね？」というような視点の議論が必要です。
まずは肉眼で大きく見えている目標から順に切り崩していくのが良いと思います。
（空を見上げてみればわかるように、月は火星よりもずっと大きく、はっきり見えているはずです）

さあ、今Oを出そう！をやめる

「OKRを決める会議をします」と言って人を集めて、その場でOKRを出させるやり方はあまり良いやり方ではありませんでした。
事業規模が小さく、全員が「今何をしなければ自分たちの明日が無いか」を常に意識している状態であればこのやり方でも良いと思いますが、その段階を超えている事業であれば、事前に個々人にOKRを考えさせてくるのが良いと思います。

ただ、このとき大切なのは心理的安全性です。どんなOKRを立てて発表したとしても、会議の場で辱められたり惨めな気持ちになったりしない人たちの集まりでなければ、考えてきたOを出し合って決めるのは難しい仕事になると思います。

もし心理的安全性が醸成されていないチームでOKRを取り入れようと思うのであれば、まずはバカな事を言っても辱められたり惨めな気持ちになったりしないチームビルディングを優先させるべきだと思います。

「GitHubのIssueやPullRequestに上げて、各人で読んでコメントしよう」は避けるべき

管理する側にとっては、皆がOKRに対して何かやってくれていることが見えますし、各人の掲げたOやKRを読んでくれていること、そしてそこでコメントによる議論が行われることで活発に動いているように見えるので、とても良い方法であるように錯覚してしまいます。

けれども、私の経験的からすると、これはよくない議論の進め方です。

なぜなら単に議論が長引いたり重箱の隅をつついたりするような、内容の薄いものに力をかけてしまいがちで、「OKRを決める」という作業に無駄に時間を持っていかれた結果、本来やらなければならい価値を創造する仕事をするための時間が削がれていくからです。
最悪なものを挙げると、ちょっとした誤字を指摘するコメントがついてしまったり、語尾の言い回しを指摘するような議論に発展してしまったり、ファイル名に日本語を使っているのがよく無いなどという全く実りのないコメントが飛び交ってしまってチームが疲弊するケースがあります。
（いずれも私が実際に経験したものです）
本来の価値を出すための目標を決めるのに、価値を出せない時間が増えていくのは本末転倒だと言えます。

議論するのであれば、各人で持ち寄って、ある場を設けて一気に議論するべきで、腰を据えて誰かの考えたOKRを批評するような時間を設けるべきではありません。

細部にこだわらない

（これは「OKRの白い本」による罪だと思いますが）Oにはムーンショットや具体的である事などの諸条件に加えて「わくわくして、ベッドから飛び起きたくなるようなもの」を設定するように言われています。

これによって、語尾のちょっとした言い回しや嵌め込む単語など細部にこだわった議論が展開されてしまう可能性があります。
Oの意図するところが全員に齟齬なく伝わっているのであれば、細部の言い回しや単語の置き換えにはこだわらないのが良いでしょう。

「ヨーロッパに行く」というOを掲げた結果、チームの皆がフランスやドイツやイタリア等、異なる国々を思い描いて仕事をしていたのでは、本当の目的地であるスイスにたどり着けないワケですが、「スイスに行く」といも目標を立てられたのであれば、「スイスに行ってやる！」「目指せスイス！」などといった、（Oの本質が変化しない）言い回しの違いを決めるために時間を使うべきではないです。

KRを決めるためのプラクティス

つづいてKRを決めるためのプラクティスです。
先述したとおり、Oを決めてからKRを決めるワケですが、主要な結果(KeyResult)という語感が良くないのか、KRを「達成するべき数値目標」と捉えてしまうケースが多いようです。

計測可能であることは大切な事ですが、KRは達成するべき数値目標ではなく、バロメータである事を理解する必要があります。

つまり、今Oに向かって正しく歩けているか、歩けているとしてそれはどのぐらいの速度か、といった情報を得るためのものがKRであって、達成するべき目標はあくまでOなのです。

したがって、一見するとOに対応するように見える「OOをXXの状態にする」とか「XXを4つリリースする」とか「現在と同等の水準を維持できるようにする」とか「YYの手法を共有する」などといったKRは良いKRとは言えません。

「KRは、OKRを進める中でバロメータとして機能してくれるものである」というのが、設定するうえでの大切な条件になると思います。

KRには具体性を持たせる

たとえば、「O月X日までに」といった文言を入れるなど、締め切りを定めるようなやり方は良いやり方です。
「ムーンショットだから計画は立てられない、だから日付も入れられない」という議論を展開する人が出てくるかもしれませんが、「ムーンショットを実現するために計画を立てなければいけない」というのが本質なので、日付を入れて計画をもってのぞむのが大事だと思います。
日付も入れられないほどのムーンショットであれば、それは月よりも先を目指しているか、月に行くための手立てが何も見えていない、もっと小さい目標から着手しなければならない事を示しています。

変化を追いかけることで、Oの達成度をはかることのできる指標にする

理想は週次で変化を追いかけられるものにする事です。
例えば、悪い例としてあげたXXを4つリリースするというのは数値目標でかつ行動目標になっているため、良いように思えます。
けれども、このKRは変化を追いかけることでOの達成度をはかるのが難しいです。
この手の指標を立てた場合、よく観察してみるとKRの達成を目指してしまっていて、Oの達成を脇に置いてしまっているケースがたくさんありました。

違っていると感じたら、勇気をもって見直す

一度立てた目標を変える事を嫌がる傾向がありますが、違っていると感じたら、早々に勇気をもって見直しをかけることも大事だと感じます。
せっかく立てた目標だからとか、あれだけ議論して間違っていたというのを認めたくない気持ちはわかりますが、間違ったものに向かって進んでいたら、OKRが形骸化するか、目的としていた成果が得られず、OKRの効果を実感できないか、いずれにせよ良くない結果をもたらすからです。

健康度/健全度は、ズルしてないかを見るためのもの

健康度/健全度は、書籍(1.)に出てくるフォードの例によれば、目標達成のために削ってはいけない事を削って達成していないかを見るためのものです。
「これが犠牲になっていたら、目標達成できてもかかえるリスクが大きくなりすぎる」というパラメータを2-3個設定するのが良く、健康度/健全度に設定したい内容がそれ以上の数出てくるようであれば、Oをもっと細かい領域に細分化して考えるべきケースが多いです。

これからやりたいことに対して、OKRをはじめるための土壌は整っているか？

上からの号令でOKRをやることになったものの、OKRをはじめるための土壌がないために頓珍漢なOKRを立ててしまって、達成できずに挫折し、果てはOKRを捨ててしまったチームも見てきました。
そういう状態にならないために、OKRをはじめる土壌としてどんな環境が必要なのかを考えてみます。

組織としてのマインド

「とはいえ」等のキーワードを使って、OKRで定めた以外の事柄に目を向けさせるチームだとOKRはうまく機能しません。
例えば駆け出しのモール型ECサイトで、OKRとして購入してくれるユーザに対するものを掲げているのに、「とはいえ」というキーワードを使って出店する店舗の側を向いた機能開発をしてしまうようなマインドの組織だとOKRを適用するのは時期尚早です。

OKRはチームやプロダクトに対して本当に必要な、価値のある仕事に一極集中することで高い価値創造と一点突破する突破力を発揮できるフレームワークなので、「もったいない精神」とか「八方美人精神」が働いてしまうチームの場合、まずはそのマインドセットを改めるところから手を付ける必要があると思っています。

無意味なKRを設定しないための下準備

上からの号令でOKRを設定した場合、魅力的なOを設定できてもそれを測るためのKRの設定に苦労するケースが多くみられます。
KRは、普段から取っている統計情報をベースに定められると心強いので、普段から統計情報を取っていないチームでは、これらの情報を定期的にとるところから着手すると良いです。
例えばコードメトリクスやテストカバレッジ、顧客満足度や契約件数などの数値を定期的に取得するような組織体制を整えることが何よりも先にやることだと思います。
（付け焼刃で設定したKRでOを測定しても、正しい計測にならないことがほとんどです）

2サイクル目移行のOKRはどう進めたら良いか

OKRについて紹介している書籍の多くは、だいたいやり方を解説するだけで、継続する際のポイントについては触れられていない事が多いです。
そこで、私が経験したチームで2サイクル目以降のOKRをどう進めていたかをメモしようと思います

振り返りをする

1回目のOKRが終わったら、必ず振り返りをします。
振り返りのフレームワークは何でもいいと思いますが、続けたい事と改善したい事(問題点)、また進める上で不安に感じていた事をまとめられると良いと思います。

振り返りでは、全員でKRの目標値と達成値の差を眺めて、どの程度達成できているのか、達成できた(できなかった)要因は何かを議論して振り返ると良いです。
この振り返りではチームとして結論を出す必要はなく、多く出た意見をまとめるようにすると、次のサイクルで成果を出しやすくなると感じました。
（例えば、チームメンバー6名中4名が似たような要因を感じていたとか）
そのため、誰かの出した意見を否定する振り返りは行わないように注意します。
特に声の大きな人や議論を引っ張るタイプの人から否定的な意見が出ると、チーム全体としてどのような状態にあったのかも見えづらくなるので注意が必要です。

OKRは見直しても良いし、継続しても良い

KRにして6-7割達成できたのであれば、次はより遠い目標を立てても良いと思います。
達成率が0に近いのであれば、Oを見直すか、そもそもKRが正しくOの動きを測れるものでなかったのではないかという疑いをかけるべきです。
（というか、日々仕事をしていて、1週間の間でKRが目的とする方向に動いていないとすれば、KRの設定が間違っているか、やっている仕事が間違っているかなので早めに見直しをかけたほうが良いです）
KRの達成率が3-4割であれば、引き続き同じパラメータで継続しなおしても良いと思います。
ただ、KRはより遠くに設定するようにしないと、単にゴールが近づいてくるだけの状態になるので注意が必要です。

OKRは、正しく使えば強い武器になる

つらつらとOKRに対する経験則をならべてきましたが、OKRをあきらめてしまうチームがある一方で、少しずつでも軌道修正しながらOKRにくらいついていくチームでは、高い効果を発揮できる武器である事も実感しました。
私の経験が、今OKRに悩んでいる人の一助になれば幸いです。