Zenn
🐈‍⬛

OKRをエンジニアリング組織に導入してみて

に公開
OKR
idea

概要

想定読者：

  • エンジニアリング組織に明確な指標を定義する際にどうするんだって悩んだことのある同士の方

想定読者ではないかもです😭：

  • 数値指標に関して、具体的な算出方法を知りたい方：本記事では記載しておらず🙏どこか別の記事で記載します🙇

結論：

経緯

  • エンジニアリング組織でマネジメントをするにあたって、実施した施策によって数値が変化することの重要性を日々感じていた。
  • 一時的なPJの中で数値目標設定を行い実施したこともあり、組織としてOKRを利用してみたので記載する

そもそも

  • OKR

OKR（Objectives and Key Results）とは、目標と主要な結果を設定し、組織や個人の目標達成を支援する目標管理フレームワークです。高い目標を掲げ、その達成度を測るための具体的な成果指標を設定することで、組織全体の目標達成を促進します。

https://www.amazon.co.jp/Measure-What-Matters（メジャー・ホワット・マターズ）-伝説のベンチャー投資家がGoogleに教えた成功手法-OKR-ebook/dp/B07JCZVFZ9/ref=sr_1_3?dib=eyJ2IjoiMSJ9.xTeu2TS3ZmQYonrbPL1Y65QbqC5XWEkLaezWkGZUMy6WzS3oc9eB067DwU9V1GJ5tgQG-JNt78yBLPxTtTzhaRMxzXEV3b_Rsx725O2IPFVQuiabvZf_d_IP05x5f7WFruBMZoqPSVOjiT4L4X2Hqp-nOqtQeDJuZ98myXZxJN9XAgSyRt3Iglx6oXK5xBF0X87b_bGRhNp9n1zbpl25T-80dSh90bLHh1PjhOUGvMbO44FcDhFuZja5r91STBTa87xaCEobOmGAgtSxhotB_-B3dRNZ0W9T4VMgC4Xl9hw.lQiflXLczRxGD95xtZXPT5Bi8sngreypsn1N3pe82PQ&dib_tag=se&keywords=okr&qid=1755182305&sr=8-3
https://dev.classmethod.jp/articles/okr-and-initiative/

意識すること

  • core→why→what→howの順で設定すること
    • 単なるノルマではなく、プロダクト軸に基づいたミッションを達成するための、メンバーが統一した認識で進むための目標を設定する必要があるため。
    • これをhowからするとひとつ一つは妥当だったとしても、全体から見ると一貫性のない目標設定になりかねないためです。

https://type.jp/et/feature/20980/

  • 数値は可能な限りノルマチックにはならないこと
    • ノルマはあくまで結果であり、仮説に基づき行動をしたら勝手に上がり、その数値の上昇に伴い目指したいノルマも達成できるという構図が望ましい(先行指標・遅行指標)
  • 数値は自動算出する機構を可能な限り検討・作成すること
    • 算出すること自体に時間をかけてたら、算出することがゴールになります
  • かといって数値が全てでもない
    • 元も子もないことを言っていますが、ミッションを達成している達成度を示す指標を設定することはもちろん原則
    • ただ、意識しすぎると「データ駆動な意思決定の誤解」に陥る
    • あくまで決定論が完璧に生まれるわけではなく、仮説検証の可視化なのである。
    • なので出せるデータをただ出して数値が良かったから次はxxに決定！とかでは仮説が伴っていない
    • 数値を元に、仮説が正しかったのか・やるべきことをやれているのか・軌道修正をする必要があるのかの改善のサイクルを回すという体制を構築するための数値的指標であります。

https://www.amazon.co.jp/エンジニアリング組織論への招待-不確実性に向き合う思考と組織のリファクタリング-広木-大地/dp/4774196053

  • Q単位で期待値も設定し、月単位で修正必要か検討する
    • これは個人の感覚かもなのですが、妥当ではない期待値及び目標値を設定し続けていても現実感がなくなってしまうので、ストレッチ目標の領域を超えてしまっていると判断した場合、思い切って修正した方が良いと考えています(簡単すぎ・難しすぎ両方)

(参考)どんな指標設定しているか

指標は、Q単位で設定して月単位で見直しているというのも、
達成したいミッションによって設定すべきkey resultsも変わると考えているから。
最新では「安定稼働性も維持しつつ、新規拡大のための開発も達成できている状態」を示すための指標設定となる。
Q単位では絶妙に顧客にリリースされてからの指標を見れない箇所もありノルマちっくな箇所も残っているのが難点で、ここいらは顧客解像度が浅いから、事業解像度も浅くなるわけで、
つまるところ顧客理解がまだまだ足りないと感じている。
かなり雑にだが以下のような内容を設定。(後で追記します🙏)

  • 全体指標
    • four keys
  • テックサポート
    • 2次受付以降の回答のリードタイム
  • エンハンス対応
    • xxxxメンバー完結のエンハンスリリース機能がxx件以上
  • バグ検知/品質保証
    • 変更障害率
    • DDP
    • 自動化ツール導入シナリオ数割合
  • 運用監視
    • 自動リトライ成功確率
    • mttr
  • 新規事業への事業拡大支援
    • 新規事業にてxxxを作成した機能数がxx件以上
    • 既存事業における新規導入の際の自動化割合がxx%以上

これから

  • エンジニアがただのノルマではない事業成功につながる指標を意識することは、プロダクト開発において大切なプロセスと感じている。

  • まっだまだ課題点の残る内容になっているのでこれからも研鑽したい

参考文献・サイト

Discussion