目標設定のフレームワークとして OKR を採用することにしたので、OKR 導入のために必要な基礎的な知識をまとめる。

OKR とは

目標の設定・管理方法の１つで、Objective と KeyResults の略称

勉強のために読んだ本によると、

第一の原則は、みんなのモチベーションを高めて最高の仕事をしてもらう方法、 第二の原則は、有意義な形で進捗を測る方法と言える

OKR（オーケーアール） | クリスティーナ・ウォドキー (著)

とも書いてあり、それぞれ Objective と KeyResutls を表していると思われる

また OKR は、スタートアップのような小規模のチームから Google のような大企業まで活用することができる目標設定のフレームワークである。

OKR の決め方

会社のミッションを確認する

世界を変えたいと思って起業された会社にはミッションがあるはずだ。

ミッションを言語化するにあたり以下のようなものが使える

私たちは、[価値提案]によって、[市場]における[問題を取り除きます/生活を向上させます]

OKR（オーケーアール） | クリスティーナ・ウォドキー (著)

上記の本では会社を 5 年間支えてくれるようなミッションを設定してね、と言われてる

市場の変化や会社の方針などによって色々在るが 5 年間は頑張ろうという意味でもあるのかな。

Objective と Key Results の理解

これはとてもシンプルで前述している通り、Objective と KeyResults のみからなる。

各項目は以下のような性質を持つ

  • Objective
    • 定性的でチームのテンションが上がるような１文にまとめる
    • チームが独立して実行できるものにする
    • 達成のための期間を設定する、例えば四半期や半期などを考えられる
  • KeyResults
    • Objective で設定した感覚的なことばを定量化する
    • 達成するのが困難だが、不可能ではないものを設定する

Objective と KeyResults の設定

実はこれの決め方についてはあまり紹介されている書籍やブログなどが見当たらなかった。

一方で実際に OKR をやってみて思うのは、「実行するチームが Objective を深く理解すること」が最も重要なことだと思った。

いろいろなワークショップ手法や雑談など何でもいいが、チームが OKR をやることを心から納得していて、設定された Objective を自分にとって達成したいと思えるものに言い換えることができればあとはなんでもよい。

あとで Good/Bad などまとめるが、それよりも上記を達成することに力を注いだほうが絶対にいい結果になる。

ちなみに会社のミッションの設定から OKR の設定まで 4 時間ほどで完了できたら順調くらいの温度感。

OKR Tree

これは必要な組織のみやれば良い

まずは会社のミッションから経営層などが OKR を設定し、その KeyResults を下位組織の Objective を同等の関係性になる

イメージはこんな感じ、

  • Mission
    • 会社の Objective
    • 会社の KeyResults
      • KeyResult 1 (= 部署 1 の Objective)
        • 部署 1 の KeyResult 1
        • 部署 1 の KeyResult 2
      • KeyResult 2 (= 部署 2 の Objective)
        • 部署 2 の KeyResult 1
        • 部署 2 の KeyResult 2

OKR の Good/Bad とその例

  • Good 👍
    • Objective は若干気後れするくらい高いレベルに設定する
    • KeyResults は評価を単純にするために数値化して測定する
    • OKR を組織全体に公開する
    • 会社に来ることが楽しみになるような目標になっている
  • Bad 👎
    • 個人を評価するために使う
    • タスク管理のために利用する

OKR の運用

毎週月曜日に１週間の仕事を計画し、金曜日にその達成を祝う。というのが基本のリズム

月曜日の計画でやること

  • 今週の最優先事項の設定
  • 今後 4 週間
  • OKR の自信度状況の更新
  • 健康・健全性指標の確認

水~木曜日

ここでは計画したことを実行

金曜日に Win Session

月曜日に計画したことの達成有無を確認する

達成のためにやったメンバーの素晴らしい仕事や助けられたことなど些細なことでもお互いに褒める

あまり書籍などには書かれていないが、逆にそうではないことを指摘する場にもなるといいと思う。 （これが褒めることが目的になって馴れ合いっぽくなって改善されないこともあるので）

OKR を振り返る

OKR ははじめ失敗することが当たり前とされている

最初に設定した期間が終了した時点でその間どうだったかを振り返る

  • 設定した Objective は本当に野心的だったか
    • 難易度が低く達成できてしまった
    • 抽象的すぎて日々意識することができなかった
    • etc
  • 運用方法について
    • KeyResults が計測できる形でなく進捗を計測できなかった
    • 毎週 Objective に近づけるタスクを立てられなかった
    • etc

正直この当たりは実行した組織によっていろいろ在ると思う。

これをしっかり運用できるか、失敗を前提としてチームが振り返ることができるかが重要だと感じる。

なぜ OKR は失敗するのか

参考にした書籍には、OKR 導入の最初は失敗するものだと明言されている。

実際はわからないが、チームが合意できてなかったり、会社のミッションと関係性が作れていなかったりなどあるだろうが、いずれにしてもそれを四半期で振り返り、改善することができなかったら成功することは無いと思う

まとめ

  • まずは正式なフレームに沿って運用するべき
  • 最初は失敗するのが前提
  • 設定した期間が終了したら OKR を振り返り改善することを必ずする

あたりを守っておけばひとまず運用はスタート出来るんじゃ無いかと思った

あとは Google re:works のブログなど見ると良さそう

Support

もしこの記事が役に立ったなら、 こちらから ☕ を一杯支援いただけると喜びます