OKRを導入するぞ！
スタートアップでエンジニアリングマネージャをやっています、おーのAです。2023年1月頃から組織の目標設定についてもやもやもやもやもやもや考えていました。今回はチーム内に閉じた話ではありますが、OKRを導入することにしました。これについて、忘れないように経緯をまとめます。
OKR気になる
OKRとの出会い
もちろん以前からOKRは知っていましたが、本格的に意識し始めたのはRSGT2023の小田中さんの発表です。
うんうん。会社のために、評価のために目標立てるんじゃなくて、モチベートされてワクワクするような目標を立てたいですよね！
そんな感じでOKRの魅力に惹かれていきました。
そうは言っても会社の目標管理を作るのムリゲー
はい。とはいえ、私は経営陣ではないので、目標管理について「OKR導入しましょう！」なんて言ったところで、「そうですね、目標管理考えていきたいですよね。」としか返ってこないわけです。そう、会社全体に導入しようなんて考えていたのですが、これは叶わぬ願いでした。
OKRの発表に触れることで沸き立つ思い
そんな感じでモヤモヤしながら2023年5月になりました。スクラムフェス新潟に向かった私はまたも小田中さんのOKRの発表に触発されるわけです。
うんうん。不確実性に打ち勝ちたいよね！この時の話、研究開発っぽい要素のある話で、私がメインでマネージャーをやっているチームの感じに似ててすごく刺さりました。
ますますOKRに対する熱量が上がっていったのを覚えています。
OKR導入を検討し始める
私とPOと開発メンバーの思いのミスマッチへの課題感
私がマネージャをやっているチームは研究開発を担当しています。
2023年4月、5月から開発チームメンバーが少し変わり、チームが新体制という感じでスタートしていました。そんな中で、開発の方向性について、何度か話す機会がありました。
開発者：「予測精度を上げないとプロダクトにならない」
PO：「予測精度が悪いとお客さんも見向きをしてくれないんじゃないか」
私：「開発はお客さんにフィードバックをもらうためにたとえ精度が悪くても出していきたい。そもそもシステムとして構築できるか検証もできてないし、精度向上ばっかりやっても仕方がない。スタートアップなんだからどんどんチャレンジしていきましょう」
こんな会話です。しかし、この時以外でも「予測精度」に関する議論は何度かされました。あるときは開発者から「うちの会社は精度向上はしないんですよね」なんてことも。いや、会社の方針で精度向上しないとは言ってないんですけどね。
つまり、端的にいうと、チームの意識、向かうべき方向性が合ってなかったのです。
「お、お、お・・・OKRの出番ではないか！」
組織とメンバーの目標をアラインメントしていく必要がある。まさにOKRが活きそうな課題でした。
POと1on1で相談
少し話はそれて、POとの関係性について、背景的な話です。POは元々私が担当していたのですが、2022年9月頃からチームに入ってもらっています。元々プロダクトマネージャなどの経験があったわけではないので、未経験から入ってもらった形です。ただ、それまでも彼は実証実験などを取りまとめることをやっていたので、それなりに研究領域についての知見は溜まっていました。しかし、技術的な知見はそこまで高くなかったので、しばらく並走しながらPOの業務を委譲していきました。2023年5月頃にデリゲーションポーカーをやって、お互いの干渉具合を確認していたところでもあります。あ、ちなみにPOといってもプロダクトに載せるAPIまで作るチームなので、プロダクトをオウンしているわけではありません。
彼との1on1でも上述の課題について話題が上がりました。また、今の作業としてはプロダクトとして出すことを優先したとしても、将来に渡って精度向上をしないわけではないので、今後、その瞬間、何にフォーカスしなければいけないのか、というところをチームとして決めた方がよさそう。という話をしていました。
私：「OKRというのがあって、導入してみたいです。本来は会社全体でやるものらしいけど、多分チームだけでもチャレンジできそうだと思ってます。（そしてゆくゆくは会社全体に・・・）」
そしてPOの彼も「ぜひやっていきましょう」と言ってくれて、二人で進めることになりました。
まずはMeasure What Mattersを一緒に読もう！
私はOKR、OKR言っている割に大して勉強していませんでした。小田中さんがOKRのバイブルと呼ぶ「Measure What Matters」を二人で読むことを提案しました。
そして、POと週次で少しずつ読み進める読書会を始めました。そして、2023年8月。ようやくこの読書会が終わりを迎えました。（途中次回の読書会の約束忘れてて1ヶ月以上かかかった。。。）
ちなみに読書会は、読んできて、議論をする形式で始めました。チームの状況に照らし合わせながら、お互いの考えを議論しながら合わせこむことができたので非常に良い体験でした。
よっしゃOKR始めるぞ！←イマココ
さぁ、そして、動き出しました。動き出しただけなので、この節で終わりになります。
結局、POの彼と相談して、開発チームメンバーには同じ本を読んでもらうことにしました。（我々がまとめて説明するよりも彼らに読んでもらう方が理解が早そう。そして素人の我々の説明は多分良くない）
という状況で、POと私はOKRの検討に向けて、チーム全体の目標を考えたり、ツールを整備するところをスタートしています。
まとめ！
まとめのところに書くものおかしいですが、この体験で得られた学びは「手法にこだわる」のではなく、「課題にこだわる」ことです。OKRという魅力的な手法であったとしても、今組織が必要としていることでなければ、あまり効果が得られなくなってしまうはずです。
私の体験の中では、明らかにチーム中にその必要性が発生したということがあります。その課題意識を強く持っていると、手法に価値が生まれて行き、手法に向かうモメンタム（この言葉使いたかった）になります。
今後もこの話題については継続的に書いていきたいと思っています。次回を乞うご期待下さい。
ちなみに、今回の記事は新しいチャレンジで、自分の仕事を進める上での考えてたことをまとめてみました。ちゃんと仮説と検証を繰り返して、仕事の能力を高めいくためにも、今後は自分の思考を整理するためにこんな内容を書いていきたいと思ってます。
この記事が気に入ったらサポートをしてみませんか？