集合知プラットフォーム事業部・開発部の榎本です。
前回の記事はフロントエンドエンジニアの小林さんによる『小さくはじめる Vue の Composable』でした。
今回は小さくはじめるシリーズ第二弾ということで、今期開発部でOKRを導入してみて、それがいい感じにワークしたので紹介したいと思います。
OKR導入前の課題
私たちの開発部を含む組織図は下図のようになっていました。
flowchart TD
事業部 --> 開発部
事業部 --> A部
事業部 --> B部
事業部 --> ...
１つの大きな事業部があり、その事業部を構成するユニットの１つとして開発部がある形です。
事業部単位および部署単位でそれぞれ目標を設定しています。しかし、１つ大きな問題がありました。
それは、事業部目標と開発部目標が関連していないことです。つまり、事業部は事業部として達成したい目標がある一方、開発部は開発部として「（事業部とは関係のない）開発部がやりたいこと」をベースに立てた目標が掲げられていました。
その結果、以下の問題が生じていました。
- 事業部目標と開発部目標がリンクしていない
- 開発部目標が単なる開発チームのToDoになっている（ToBeではない）
このような状況だったため、私自身も日々の業務をしながら「同じ事業部なんだけど、他の部署とはどことなく違う方向を向いて仕事をしているな〜」という違和感が付いて回っていました。
OKRを導入
上記の課題を解決するために、開発部でOKRを導入しました。OKRを導入すれば、「事業部目標と開発部目標が関連しない」問題を解決できると考えたからです。
本来、OKRは組織全体で導入するべきものです。しかし組織全体としては現状運用しているMBOの目標設定があり、その制度はすぐには変えることができなそうだったので、開発部のみで試験的にOKRを導入・運用してみることにしました。
OKRをどう決めるか？
チームのOKRは、そのチームの上位チームのOKRから決めるべきとされています。『Google re:Work - ガイド: OKRを設定する』 には下記のように書かれています。
最初に組織の目標を表明しておくと、チームや個人がそれを考慮して自分たちの目標を設定できます。この方法なら、組織全体の OKR に整合性をもたせることができます。
（中略）
ただしチームの OKR は、組織の OKR の少なくとも 1 つには関係している必要があります。
この「組織の目標」を「事業部の目標」、「組織のOKR」を「事業部のミッション」に置き換えて開発部のOKRを考えてみることにしました。
OKR研修を実施
OKRを決める前に、まずはOKRという目標設定のフレームワークの理解を深める必要があります。
Google re:Work のOKRガイドや、社内のOKR経験者へのヒアリング、OKRに関する書籍を参考に資料にまとめ、マネージャー陣に共有しました。
この時使った資料は、公開用に内容をアップデートして、speakerdeckで公開していますので、よろしければご活用ください。
OKR基本のキ / OKR Basics - Speaker Deck
OKRの決め方
マネージャー陣でディスカッション
OKRの基礎知識をインストールできたら、いざOKRについてのディスカッションです。
開発部のマネージャー陣を招集し、下記の順番でOKRのディスカッションを進めました。
- Objective決め
- 事業部目標をベースにブレスト
- Objectiveの決定（3つ）
- Key Results（以下「KR」と表記します）決め
- 1で決めたObjectiveを順番にKRをブレスト
- KRの決定（１つの Objective 毎に約3つずつ）
- OKR運用方法決め
- チームとしてどのようにOKRを運用していくかを決定
時間はめっちゃかかる
サラッと書きましたが、このディスカッションはとても時間を要しました。参加メンバー全員初めてのOKR、ということもあってか約4時間のミーティングを三回、計12時間以上ディスカッションしました。
大変骨が折れる作業ではありましたが、以下の理由から時間をかけただけの価値は十分にあったと考えています。
- 事業部目標とリンクする目標設定ができた
- 「今期、何にフォーカスすべきか？」のコンセンサスが得られた
- 腹落ちするObjective・ワクワクするObjectiveを設定できた
- ディスカッションを通してマネージャー同士の相互理解が進み、目線を合わせることができた
工夫した点
KRオーナーを決める
良いOKRを決めたとしても、それを推進する旗振り役がいなければ、なかなか前には進みません。
私たちはそれぞれのKR毎にオーナーを決め、担当者にオーナーシップをもって達成率の向上にコミットしてもらいました。オーナーは個人の場合もありますし、複数名の場合もありますし、チーム名の場合もあります。
オーナーは具体的には下記のことをやってもらいました。
- KR達成のために、関係者を巻き込み、まとめ上げる
- KRの達成率の管理
- 四半期毎の振り返りの実施
また、オーナーにとって下記のような良い副作用もありました。
- 旗振り役になってもらった人の中には、チームをリードした経験が少ないエンジニアもいたが、OKRのリード経験を通して成長に繋がった
- KRの達成のためにチームを跨いだ活動も増え、チームを超えた交流の機会になった
週定例で進捗を追う
言うまでもなく、OKRは立てて終わりではなく、達成に向けて動き続けなければなりません。
私たちの現在のObjectiveは何で、Key Results の最新の進捗状況をどれくらいなのかを週次の開発部の定例で確認するようにしました。これによって、メンバー各人がOKRに自覚的になり、達成に向けた動きを加速させることが出来たと感じています。
OKRの振り返り
OKRを半年間やってみて、振り返りを実施しました。その結果を一部抜粋して共有します。
よかったこと
多くの開発部メンバーから「やってよかった」「来期もOKRを続けたい」という声を得ることが出来ました。
他にも以下のポジティブな感想を得ることが出来ました。
- 運用改善KRを推進したチームが運用チームにアンケートを取ったところ、「運用改善の効果を感じられたか？」「来期もこの取り組みを続けていきたい思うか？」という質問に対して、運用チームほぼ全員からポジティブな結果を得られた
- ストレッチ目標を設定することで、自分のキャパシティを超えた活動まで可能になった
- オーナーの中には、楽しそうにオーナーを勤めてくれる人もいて頼もしかった
- 今までよりも費用対効果の高いタスクに優先的に取り組むことができた
- 同じ事業部の別の部署にもOKR研修を実施し「OKRとは何ぞや」について理解してもらえた
- 同じKRを追っているメンバーでモブプログラミング・モブレビューを実施し、知見を共有できた
課題に感じたこと
一方で振り返って課題に感じたことも出てきました。
- 推進力がオーナーの力に依存してしまう
- 数値に目が行きすぎて、目的を見失うケースが一部あった
- もっと適切なKR成果指標があるのに、最初に定めたKRで硬直化してしまっていた
- 「OKRツリー」という言葉があるが、必ずしも全てがツリー状には紐づかない
今後改善したいこと
上課題も踏まえて、次回OKRをもっと上手に回すために、下記の点に気を付けたいと思っています。
- 上手な進め方をしているKRオーナーをモデルケースとして、ノウハウを横展開する
- オブザーバーとしてマネージャー陣もOKRのミーティングに参加し、きちんと目的を失わないようにガイドする
- 「Objective達成のためのKey Result」という意識を持つことが大事
- KRの成果指標・数値は（適切な理由があれば）変更可能なことをオーナーに伝える
- 「OKRをツリー状にすること」に拘らないようにする
OKRを成功させるためのポイント
実際にOKRを半年間運用していみて感じる、OKRを成功させるためのポイントは下記だと考えます。
- 前提として上位組織（今回でいうと事業部）のObjectiveを明確にする
- 皆が率先して「やりたい！」と思えるようなチャレンジングでワクワクするObjectiveを設定する
- OKRを全体公開し、定期的に進捗をチェックし、必要であれば見直し・振り返りを行う
- マネージャー・リーダーがOKRを理解し、達成に向けてコミットする
- OKRをそのまま従業員評価ツールに使わない
- 評価を上げるためのいわゆる「数値ハック」を防止
- ムーンショットを目指すというOKRの考え方を理解し、ストレッチした目標をきちんと設定すること
- MBOに慣れてしまった脳だと、達成可能な範囲内の数値目標を置いてしまいがち
さいごに
今回は開発部で小さく始めたOKRの例を紹介させていただきました。
OKRは基本的に全社レベルで導入する目標設定フレームワークですが、部単位でOKRを設定しても十分にワークする手応えを得られました。
皆様の目標設定の一助になれば幸いです。
是非読者になってください！
メドピアでは一緒に働く仲間を募集しています。
ご応募をお待ちしております！
■募集ポジションはこちら medpeer.co.jp
■エンジニア紹介ページはこちら engineer.medpeer.co.jp
■メドピア公式YouTube www.youtube.com
■メドピア公式note
style.medpeer.co.jp
