会社で導入されている『OKR』について本を読み直してみたところ、もっと良くできる気がしたのでポイントをまとめてみます。及川さんがあとがきに書かれていたように「前職で似たようなことやってたからなんとなくわかるわー」と思っていたのが間違いだった気がします。
OKRとは
すべては結果で判断する。というフレームワークです。
- Objective （明確で定性的な目標。ひとつに集中するのが望ましい。達成度合いは50％ぐらいに設定する）
- Key Result（主な結果。目標の達成度合いを判定するための定量的な指標。3つぐらい設定する。）
3ヶ月ぐらいのスパンで上記を設定し、日々進捗を追っていいきます。
結果がすべてなので、生産量（アウトプット）よりも成果（アウトカム）を意識します。そうしなければ、無駄なことをたくさんやっても成果は出ませんからね。
なかなかうまくいかない理由
「第2部 OKRのフレームワーク」に、うまくいかない理由がまとまっています。
- 優先順位がつけられていない
- ゴールを伝えきれていない
- やり遂げるためのプランがない
- 時間がない
- たくさんありすぎる
- 途中でやめてしまう
などなど。まぁ、目標設定でありがちな罠ですね。
プラス、本書の後半に書かれているのですが、ありがちなのが「目標と結果や、目的と手段がごっちゃになっているケース」かなとおもいます。たとえば、目標に「売上が前年比120％」や「お客様満足度を高める目標に対して、結果はXXXをする」とかですね。
会話のためのツール
本書では、上記のような会話のためのツールが紹介されています。ためしに、自分の置かれている環境でサンプルを書いてみました。
左側は今週（もしくは現在のスプリントとか）にやること。下側は未来にやろうと思っていること。やることはたくさんあるので、「大切なこと」だけ書くようにします。そして、未来の予定を書いておくことで、作業がはやく終わった人や、ちょっと手の空いた人が前倒してとりかかれるようにします。
右側は上がOKR。下側はOKRとは別に監視を続けたい項目を書き、色で状態をわかりやすくします。たとえば、売上を達成するためにメンバーが疲弊していたら続きませんよね。
メンバー全員が見える場所にこの表をはりつけ、左側はタイムボックスごとに更新。右下は朝礼などで更新していくといいかもしれません。
本書では、月曜日に表を更新し、当週達成に向けて走り、金曜日に達成度を祝う形になっていました。
興味深かったのが「OKRをプロダクトチームに向ける」こと。
たとえば僕のように、機能別部署（自動化＆QAグループ）を担当している場合は、そのチームの目標を考えればいいです。おもしろいことに本書でも「品質管理部長はテスト管理ツールの選定を」とありました。
でも、もしそのチームにプロダクトチーム（プロダクトに向かって働く人）がいる場合、プロダクトの責任者と話して機能別部署として貢献するOKRを立てる必要があります。
とまぁ、後半は読者の置かれている状況や立場を選びそうなのでいまいちだけど、前半から中盤はとてもわかりやすいいい本でした。自分の担当するメンバーには必読の書にしようとおもいました。
旅と子育てとアジャイルコーチのブログ「世界」 