OKR はエンジニアチームと『戦略を結ぶ』ツール
OKR (Objectives and Key Results) は Google/Intel で広く実践されている目標管理フレームワークです。本記事では編集部の視点で、エンジニアチームでの運用を公開情報をもとに整理します。テックチームの作り方 もご参考に。
OKR の基本構造
(1) Objective (O)：定性的な目標。野心的に。(2) Key Result (KR)：定量的な成果指標。3〜5個。(3) 達成度：60〜70% を狙う(野心的な意味)。(4) 透明性：全員が見える。(5) 頻度：四半期が標準、年次もあり。KPI が固定指標、OKR が変化指標、と理解されることが多いです。
エンジニアチームでの O 設定
(1) ビジネス目標と連動：会社の戦略と整合。(2) 3〜5個まで：絞ることが大切。(3) 定性的かつ感情的：チームが燃える表現。(4) 四半期で達成可能な大きさ。(5) 例：『プロダクトの信頼性を業界トップに』。
KR の設計
(1) 定量化：%/件数/秒等。(2) 3〜5個。(3) KR 達成 = O 達成の構造。(4) 例：『p99レイテンシ 500ms → 200ms』『可用性 99.5% → 99.9%』。(5) 『やったこと』ではなく『結果』。KR がToDo になっていないかを毎回チェック。
四半期サイクル
(1) 四半期初：目標策定+全社レビュー。(2) 毎週/隔週：進捗チェック。(3) 四半期中：必要に応じて再調整。(4) 四半期末：振り返り+次期策定。(5) 達成 0.6〜0.7 が理想：低すぎ=野心不足、高すぎ=安全過ぎ。
個人 OKR vs チーム OKR
(1) 個人OKRはメンバーの目標。(2) チームOKRはチーム全体。(3) 会社OKR → 部 → チーム → 個人の階層連動。(4) 個人評価とは分離：野心目標と評価リンクは弊害。(5) 1on1 で個人 OKR を扱う。1on1 活用術 もご参考に。
失敗しがちなパターン
(1) KR が KPI と同じ：変化を促さない。(2) OKR と評価をリンク：保身的目標に。(3) OKR が多すぎ：絞れない。(4) 達成100%：野心不足。(5) 四半期途中で放置：見返さない。対策は、(1)変化指標、(2)分離、(3)5以下、(4)野心的、(5)定期レビュー、です。