OKR 本を読んだメモ

OKR 本を読んだ。

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法 | クリスティーナ・ウォドキー, 及川 卓也(解説), 二木 夢子 |本 | 通販 | Amazon

とくに OKR ってなんぞやというあたりにだけ絞ってメモった。

• OKR = Objective + KeyResult
  • Objective
    • 魅力的で人を鼓舞するようなものを 1 つ設定する
    • 時間的な制約をつける（1Qずつ、3か月くらいがおすすめ）
    • それぞれの Objective は独立したものにする
      • 別部署がやらなかったんでこっちも無理でした、みたいのはナシ
    • 具体的な数字が出るようなものは KR になるので設定しないほうが良い
  • KeyResult
    • 具体的な数字としての結果を 2 ～ 4 つほど設定する
    • 数字として測れるものなら何でもよい
    • Objective の状態、結果になるために、何の数字がどうなっていたらいいか
    • この数字は成功率が50%くらい、めっちゃ頑張って達成するぞ！というストレッチゴールにする必要がある
• OKR は階層的に紐づいていく
  • 会社としての OKR があって
  • その KeyResult に紐づく形で部門の OKR があって
  • その KeyResult に紐づく形でチームの OKR があって
  • その KeyResult に紐づく形で個人の OKR があって
• OKR は毎週確認する
  • 日常的な業務をあれこれやっていると絶対忘れる
  • 必ず振り返りをして、方向性を直し、 OKR というゴールを目指すようにする
  • 4つのマトリックスに分けて OKR を毎週確認するのがおすすめ
    • 今週の優先事項
      • 優先事項によって OKR が進むかを考える
    • 今後 4 週間で起こる重要なこと
      • 予定に備えられるようにする
    • OKR の自信度状況
      • 成功率がどんなもんだろうか？みたいなもの
    • 健康・健全性指標
      • 目標に向かって進むが健全なために守ることを 2 つくらいあげる
  • 金曜日に進んでいる感を味わうこと
    • 各チームの今週の見せられるものを見せる
      • こんな顧客と契約した、こんなものを作った、…etc
• 機能別かプロダクト別か
  • 組織としては機能別になっていることが多いと思うが、 OKR はプロダクト別に設定したほうが良い
  • 階層型の話と合わせると、プロダクトチームの OKR → 機能ごとの OKR → 個人 OKR という構造が良い
  • プロダクト別のチームで業務が進んでいくため
• OKR を初めてやろうとすると失敗するのがありがちなのでリスクを減らしておく
  • 1 つのチームで導入する
  • 1 つのプロジェクトで導入する

所感とか

• OKR それ自体はそんなに難しくないフレームワークっぽい。
• 機能別かプロダクト別かって話は面白くて、個人 OKR になったときはどっちも盛り込むような方向が良いように思う
  • 例えば～～～って考えてみるとこういう感じ？
    • Objective
      • XXプロジェクトにおいて最前線で戦えるようになる
    • KeyResult
      • XXプロジェクトにおいて3つ以上のリリースをする
        • プロダクトに対応したKR
      • リリースされるもののうち3つ以上のレビューを担当する
        • プロダクト・機能（エンジニア面）に対応したKR
      • 次フェーズで必要になるライブラリについて予習し、チーム全体に教えられるようにする
        • 教えられるようにする → 勉強会/ハンズオンを3回実施する みたいなほうがいいかな
        • 機能（エンジニア面）に対応したKR
• 以前、ちょっと大きめの開発でこの日に絶対リリースするぞ！ってやってたときがあって。
  • そのときは個々人で何ができるかーみたいのをなんとなく考えてやってて
  • っていうのが整理したら OKR やんって思った。
• 評価って枠組みで考えると、OKR自体はプラスの評価に使うべきだなあって気持ち
  • なんとなくやっててもKRは達成できない
  • 考えて、動いて、一定チャレンジングにやっていく
  • だから飛躍するかもしれないし、もしかしたら失敗してしまうかもしれない
  • 失敗してもサイクル回してやっていこう?

いじょ