OKRは難しい
OKRを運用して3年目になりました
早いもので、自分が所属する組織でOKRの運用を始めてから3年目になる。
試行錯誤しながら駆け抜けた1年目は、終わってみるとそれまでよりも多くの成果が出た、という意味で対外的にその効果と意義を示せたし、実践した自分たちとしてもそれまで以上に目標を自分ごととして捉えられた。そういう意味で、1年目は概ねうまく行った。
なお、一年目の総括についてはハッカーライフラボで話した内容がYoutubeにアップされている。
そして2年目。1年目がうまくいったからこそ、2年目がある。その2年目は新しくジョインしたチームへのOKR伝達がうまくいかず、しばらく機能不全を起こすという苦い経験もした。やはり「なぜそれをやるのか」ということを伝え、またそれを納得感をもって受け入れてもらう「対話」なしにはうまくいかない、ということを痛感させられた。その話は、4/27にDevLOVEで話す予定だ。
だが、その2年目の取り組みの中で「OKR-based Scrum Team」という考え方を生み出すことができた。組織と個人をつなぎプロダクトと市場をつなぐあり方として、現時点で私がベストだと考えている方法だ。これはAgile Tech Expoで話したものがYoutubeに上がっている。
というわけで、成功と挫折を経験し、自分流といえるような考え方にたどり着き、OKRについてはそれなりにわかってきたつもりだ。
それでも、3年目になっても、思うのだ。OKRは、難しい。
定性的な指標と定量的な指標の対話
OKRのもつ大きな特徴のひとつが、「Objectiveは定性的、KRは定量的」というものだ。そして、個人的にはこれこそがOKRの独自性を際立たせている特徴だと考えている。
「○○をn件リリースする」「XXを完成させる」といった、計測可能で、一見悪くなさそうな目標があったとする。OKRという仕組みではこれらはKRに相当し、「n件リリースすると、何が達成されるのか、何がうれしいのか」ということがObjectiveという形で問いかけられる。
そう、設定したKRが達成できたらゴール、みんなハッピー、というわけではないのだ。KRの達成は一つの仮説が検証されるタイミングになった、ということを示しているに過ぎない。KRは目標に到達したけれども、それではObjectiveを達成したとは言えない・・・ということは十分起こりうる。
難しい。
そして、この難しさこそがOKRのキモなのだ。
とりあえず数値を達成したからOK、ではなく、Objectiveが達成したかを問いかける必要がある。そしてこのObjectiveは定性的なものだ。なので、KRが目標値に達していればObjectiveが達成していることを示せている、とは単純にいえないのだ。定量から定性への変換が必要になる。
そう、対話が必要となるのだ。
難しいのは、いいこと。
今年度は、OKRを導入したいという相談をたくさんいただいている。
そして皆、Objectiveというものの手強さに気づき始めている。
我々は定量的なものを是としてきた。見える化し、数値化し、主体によって評価がぶれないよう極力定量化するよう心がけてきた。
だから、定性的に考えるObjectiveというものが、どこかとらえどころがないものにも思えてしまうのだ。
しかし、もともと手元にあった数値が、そもそも何を目指すものだったのか、何の達成を示すものなのかを考える機会になっているともいえる。定性的でとらえどころがないからこそ考える。考えた先に、「あれ、これまでおっていた数値は、もしかして的はずれだったんじゃないだろうか」なんて気づいたりもするのだ。
たとえば「新しい機能をn件」というような目標。計測しやすいし、新しいものを作る、ということは基本的にポジティブなことだ。なのでこういった目標を立てるケースは少なくないだろう。
しかし、である。こういった目標設定は、機能に対する「本当にそれは必要か?」という問いかけを頭の片隅に追いやってしまう。そうして作ることが目的化した「ビルドトラップ」が発生していく。
「新しい機能をn件」が悪い、というわけではない。プロダクトのフェーズだったり、チームのミッションによってはもちろん有効だ。しかし、あらゆる状況で有効な指標ではない。
このときにObjectiveが雄弁に語りだすのだ。KRはあくまで指標であり、Objectiveを満たしうるものか?と常に問いかけられることになる。
ことによっては、KRを見直そう、となるだろう。
そう、だから難しい。一生懸命考えた指標を、自ら棄却する場面が出てくるのだ。
そして、だからこそOKRは有効なのだ。常に「それは必要か」を問いかける仕組みが備わっている。
というわけで、今年もうんうんとうなりながら、定性と定量の間で思う存分悩んでいきたいと思う。