見出し画像

どうやってOKR運用を継続的に改善するか

TAKUMA OKAMOTO

この記事は UMITRON Advent Calendar 2023 25日目の記事です。

はじめに

こんにちは。UMITRONのCo-founder / CTOの岡本(@um_takuma)です。今年も昨年に続きAdvent calendarをやることとなりました。今年、イベントや採用面接などで会う人にAdvent calendar読みましたという声をたくさん聞き、嬉しい限りです。ウミトロンのことに興味がある人に少しでも会社のことを知っていただけるようにやっていきたいです。

Advent Calendar 25日目はどうやってOKR運用を継続的に改善するかという内容をお届けします。

昨年の4月にウミトロンではOKRを全社に導入しました。昨年の取り組みをUMITRON Advent calendar 2022でどうやってOKRを導入し運用するかという記事で紹介しました。

そして、今年はそれを踏まえて今年1年間でOKRを運用する上でどのような課題が生じ、それをどう解決していったのかということについて紹介します。ぜひ昨年の記事と合わせてお読みください。
前回の続きを書くことの動機は、導入以降してしばらく経過した時点での情報について残しておこうと思ったからです。一般的に新しい取り組みなどについての記事は導入時や、その後短期間の経過についての情報はよく見かけます。しかし、その後どうなったということについて書かれてる記事はあまり見ず、情報が比較的少ないです。そのような情報は実際に運用をやっている自分などにとっては非常に有用な情報です。そこに価値があると思い書くことにしました。

昨年の時点でのOKR運用

詳しくは昨年のAdvent calendarの記事を見ていただければと思いますが、ウミトロンでは全社にOKRを導入しています。ウミトロンでの組織構造に合わせて大きく分けて3つの階層のOKRを設定しています。

  • 会社全体の1年間の目標を表す全社OKR

  • 各プロジェクト、各チームの四半期の目標を定めるプロジェクト・チームOKR

  • 全社員が各個人毎に四半期の目標を定める個人OKR

これらのOKRは以下のようなルールで運用をスタートしました。

  • 3つの階層のOKRはすべて誰でもいつでも確認できる

  • 全社OKRは1年に1回設定し四半期毎に振り返る

  • プロジェクト・チームOKRと個人OKRは四半期毎に設定し、毎月振り返る

  • 70%程度の達成度を目指すようなチャレンジングな目標を立てる

これに加えて、運用をしていく上で以下のような点を改善していきました。

  • KeyResultの達成率の計算の仕方をOKR設定時に一緒に定義しておく

  • プロジェクトやチーム単位で行われる週次ミーティングでOKRの進捗を確認する

  • プロジェクト・チームOKRでは誰がどのOKRをリードしていくか担当を決めておく

また、最初から完璧を目指さない、をメッセージとして発信して、運用を継続して改善していくことを目指しました。

1年間で生じたOKR運用の問題とその解決

昨年の運用改善後も1年を通して複数の運用上の課題が出てきました。それらを解決するために様々な改善を行いました。細かい改善を含めると多数の改善を行いましたが、特に大きなものを3つ記します。

1. NotionデータベースでOKR管理ツールを作る

昨年、OKRを会社に導入したときは、Notion上にOKR管理用のデータベースを構築して運用していました。その時は全社OKR、プロジェクト・チームOKR、個人OKRの3つのOKRを、それぞれObjectとKeyResultを別のデータベースとして合計6つのデータベースとして構築していました。これは3つのOKR間のアラインをデータベース間のリレーションで表現できるようにするためです。しかし、これはOKRの原理に厳密に従い過ぎて、逆に管理コストが上がってしまいました。そこでよりシンプルに管理できる、外部のOKR管理サービスを使って管理するように変更しました。

この運用で3四半期ほど運用していましたが、ウミトロンは全社でNotionを利用していることもあり、普段のミーティングなどでOKRを振り返るときなどに外部サービスを参照するのは手間がかかるという問題がありました。そこで、もう一度Notion上にOKR管理用のデータベースを作ることにしました。1年間のOKRの運用を経て、運用に対する知見が溜まっていたこともあり、OKR導入時よりも実際の運用に即した要件を定義することができました。変更した点を以下のような点です。

  • Notionデータベースのサブアイテム機能を使いObjectiveとKeyResultを同じデータベースでまとめてデータベース数を減らす

  • 異なる階層のOKR間のアラインを期中に振り返ることは殆どないので、リレーションははらない

  • OKRのデータベースは各プロジェクト・チーム、個人毎に生成し、それぞれの運用に合わせてプロパティなどを追加したりというカスタマイズを許容する

これらはNotionデータベースの新機能がリリースされたことにより、実装できるようになったものもあります。これらの改善によりデータベースは各プロジェクト・チームのNotionページから参照され振り返り頻度を増やすことができました。

2. OKRがうまく運用できるか計測する

各プロジェクト・チームや各個人がOKRを独立して運用している状態で、運用がうまくいっているのか、なにか課題が発生していないか、を発見するためにどうすればよいか考え取り組みました。結果として、以下のような指標を計測することにしました。

  • 3つのOKRの設定、更新期限毎の最終更新日

  • 各プロジェクト・チーム毎のObjectの平均進捗率

  • 各プロジェクト・チーム毎の、進捗率が0のまま期間が終了したKeyResultの数

1つ目の指標は、全社で決めた四半期毎のOKR設定のスケジュールから遅れていたり、1ヶ月毎のOKR進捗の更新のスケジュールから遅れていたりするチームや個人を特定するためです。会社全体の傾向なのか、特定のチームや個人における課題なのかを見極められます。前者であれば全社でのOKRの運用方法自体に課題がある事がわかります。
2つ目の指標は、1つ目の指標と同様に、全社のOKRの傾向と各プロジェクト・チームの傾向を比較することで、特定のプロジェクト・チームが何か課題がないかを発見するのに効果的です。これはOKR運用上の問題だけでなく実際のビジネス状況やプロダクト開発など、他の課題の発見にも利用できます。課題を調査するためにヒアリングを実施する場合も、全社に細かく状況についてヒアリングすることは調査コストがかかりますが、特定のチームならば細かく調査することが可能です。
3つ目の指標は、運用中に後から追加した指標です。2つ目の指標を計測していると、あるチームのObjectの進捗率が全社と比較して著しく低いということがわかりました。詳しく調べていくと、そのObjectには進捗率が0のままのKeyResultが複数あり、それが主な原因ということがわかりました。これはチームのキャパシティ以上に多くのKeyResultを設定してしまっていて、チームが最も重要なことにフォーカスできてないことを意味します。進捗率が0のKeyResultが多くあるチームは重要なことにフォーカスするためにKeyResultの数を減らすようにアドバイスします。

これらの指標に加えて、全社員に対するサーベイも行い、具体的なOKR運用の課題や要望を直接社員からも募って反映したりもしました。 このように全社のOKRの運用上の課題を把握できるようにしておくことは、会社やビジネスのフェイズが変わってOKRの運用が実態に即していない状況に早く気づいて改善に取り掛かるためには重要です。

3. 個人OKRの設定を任意にする

上記の1つ目の指標を計測していると、全社OKRや各プロジェクト・チームのOKRの進捗更新に比べて、個人OKRの進捗更新が滞っている傾向があることがわかりました。また、自分が属するプロジェクト・チームOKRの一部と個人OKRが一致していて、管理コストが高くなっている、という声が社員からもありました。実際に、現在のウミトロンの組織サイズ、プロジェクト・チームサイズではプロジェクト・チームのKeyResultが各個人のOKRに一致するケースが多くありました。
そこで、OKRの進捗更新の管理コストを下げることを優先するために、個人OKRの設定を任意にしてみました。完全に廃止しなかった理由は、入社直後の人などはチームのKeyResultが各個人のOKRに一致しないケースがあったり、自分が属する各プロジェクト・チームの目標と完全には対応しない目標を個人が持てる余地を残したりするためです。
この決定をしてからまだ四半期は経過しておらず、どのような結果になるかはまだわからない部分もあります。まず、一四半期経過した時点でどのよう効果があったか計測し、今後も同様の運用にするか決定する予定です。

今後のOKR運用

プロジェクト・チーム毎のKeyResultの数の最適化

上述のOKRの運用状況を把握するための指標を設定し計測することで、プロジェクト・チームを重要なことにフォーカスさせたり、チャレンジングな目標を達成したりするために、KeyResultの数がとても重要だということがわかってきました。プロジェクト・チームのサイズ毎にどの程度のKeyResultの数が妥当なのかということがだんだんと検討がついてきたので、妥当な数を保つことに注力していきたいです。
例えば、四半期の途中で無闇にKeyResultを増やすと、プロジェクト・チームが重要なことにフォーカスすることを妨げる可能性があります。その場合は、既存のKeyResultと比較して、単純に追加していいのか、それとも、既存のKeyResultを廃止して入れ替えるべきか、を吟味します。そのような運用を全社に根付かせるような方法を検討していきたいです。

OKRを軸とした実務運用

純粋なOKRの運用ではないですが、各プロジェクト・チームはOKRを軸に実際の実務タスクを設定し、業務を行っています。そのようなときに各タスクの優先度を決定する必要がありますが、OKRを指標として各タスクの優先度を決定すると優先度の決定コストが低くなり、プロジェクト・チームにおける重要なことに関連するタスクに集中することができます。
例えば、プロダクトのユーザや社内のオペレーションチームからの要望に基づき、新しく開発するべきプロダクトの機能が出てきます。その場合、その機能がプロジェクト・チームのOKRを達成する上で重要なのか、それともプロジェクト・チームのOKRの達成よりもその機能を開発しリリースすることが重要なのか、そうでないかと言う観点で機能の開発の優先度を考えられます。OKR達成に必要ならその機能は開発するべきであり、不具合や障害といったユーザやオペレーションに影響が出ているものならOKRに関わらなくても開発するべきです。
また、四半期の頭に設定したOKRに変更が必要な状況になっていないかどうかも考える必要があります。上記の方法でタスクの優先度を決めていくと、四半期の頭に設定したOKRが、実はプロジェクト・チームの置かれている状況に即していなかったり、期中であっても変更が必要だということに気づいたりということにも繋がります。
このような実際のタスクに関わる実務運用はまだ手探りで、方法論の確立までには至っていません。実務運用は各プロジェクト・チームに委ねられていて、一部のチームで効果がありそうな方法が見えてきたに過ぎないです。今後はそのようなOKRを軸とした実務運用についての各チームのノウハウを蓄積し、全社に展開できるようにしたいです。

おわりに

1年を通して、ウミトロンの実態に合わせたときに、OKRの運用の原則の中でも必要な部分とあまり重要ではない部分がだんだんと把握できてきました。これらは会社の規模やステージによって変わっていき、それにより新しい課題が出てくると予想できます。今後も課題の発見と解決のプロセスを定期的に実行し、OKRの運用を変化させていきます。

ウミトロンでは一緒に働く仲間を募集しております。持続可能な水産養殖を地球に実装するというミッションの元で、私たちと一緒に水産養殖xテクノロジーに取り組みませんか？


この記事が気に入ったらサポートをしてみませんか？