OKRとエンジニアリングの微妙な関係

導入

近年、目標管理において、OKR（Objectives and Key Results）を導入することは珍しくなくなっています。しかし、エンジニアリングマネージャの立場から見ると、OKRがエンジニアリングと微妙に合わないと感じることがあります。本記事では、OKRとエンジニアリングの微妙な関係について考察し、現時点での僕の考えをまとめたいと思います。

OKRとは何か？

OKR（Objectives and Key Results）は、組織や個人の目標を明確にし、その達成度を測るためのフレームワークです。目標（Objective）と主要成果指標（Key Results）を設定し、定期的に評価することで、目標達成に向けた取り組みを可視化し、効率的に進むことができます。達成自信度が50%程度の、普通にやってたら無理だけど頑張ったらギリいけそう、みたいな水準の目標設定を実現することが期待されます。高い目標を設定するため、人事評価とは切り離して運用することが推奨されています。（達成できなかったからといって評価を下げるなどはしない。）

本稿におけるエンジニアリングとは？

エンジニアリングとは、技術的な問題を解決するためのプロセスや手法のことを指します。コンピュータシステムやソフトウェアの開発、運用、改善に関する様々な技術や手法を用いて、効果的かつ効率的に問題解決を行います。特に本稿ではソフトウェアエンジニアリングについて言及しています。

OKRとエンジニアリングの相性の悪さの理由

僕がOKRとエンジニアリングの相性が微妙だと感じる理由は、主に以下の2つの要因によります。

1.成果の質の違い

OKRの成果評価は、主に数値目標に基づいて行われます。しかし、エンジニアリングの成果は、コードの質や開発プロセスの改善など、数値化しにくい要素が多く含まれるため、評価が難しいことがあります。（エンジニアはどちらかといえば企画そのものをどう実現するかのプロセスに責任を持っています。システムは安全か、リリースは迅速か、とかそういうのです。）この点についてはGoogleが組織した研究チームが長期間取り組んでいるようなテーマですから、多くの企業、組織にとって非常に難解な問題と言えます。

2.タイムラインの違い

OKRでは、通常、四半期ごとの短期目標に焦点を当てますが、エンジニアリングプロジェクトでは、中長期的な視点が必要な場合が多いです。3ヶ月で達成可能な事をリストし、その優先順位をチーム全員で民主的に決めれば、チームの熟練度にもよりますが基本的に中長期の関心ごとに責任を負うようなロールが割を食う形で計画がアウトプットされます。端的に言えば、「短期で売り上げを改善しようとするもの」は優先されやすく、「中長期的には重要だがすぐに売り上げを改善しないもの」は優先されにくくなります。

こうした方針がフィットするフェーズの製品やチームは存在しますが、それが全てではありません。
問題はこうした方針を組織全体へ一様に適用しようとする時に起きます。
全ての製品やチームがOKRのようなシステムを必要としている訳ではないのです。

具体的な問題点

1.ウィークリーOKRという名の「週単位の朝令暮改」

週単位で進捗に応じた軌道修正が期待されるウィークリーOKRは運用によっては非常に開発チームに負担のかかるやり方です。営業資料のテンプレートや記事コンテンツなどを修正するようなテンションで気軽にシステムを変更し続ければ、システムの持続的な変更容易性は簡単に破壊されます。よく訓練されたスクラムチームでさえ、システムを変更可能に維持して持続的に進むことは難しいのですから、そうでないチームや人にその主導権を持たせることが将来的に問題を生むのは簡単に想像できます。

2.投資方針との矛盾を生む「ムーンショットしなきゃ！バイアス」

OKRは、大胆な目標を達成するためのフレームワークです。そのため、達成困難な難しい目標をクリアするために必要な、人の思考を飛躍させ、人のモチベーションを向上する仕組み、手法がセットでインストールされます。（ウィークリーOKRやWinSession、OKR起案の際に推奨される各種ワークなどがそれです。）
そのため、現実的なリソース制約に捉われないようチームの思考を誘導し、大胆な発想を引き出すことでムーンショット達成を目指します。

十分な予算を確保した製品とその担当チームに関して選択的にOKRを導入する場合は問題ないのですが、一様にOKRでプレイしていると低予算の製品とその担当チームでは困った事になります。
労力を割いて生み出した渾身のOKRに対して、予算が無いためできない、と言われるチームの感情を想像しましょう。（一応答えを書いておくと、「だったらなんでOKRなんかやらせるんだ？」です。）

経営の投資方針に基づく事業戦略によってある程度どの製品に力を注ぐか決定しているのなら予算をつけなかった戦場においてOKRを実行することは止めましょう。混乱を生むだけです。

3.OKR設定そのものにリソースを食われ必要なことを実行できない

大胆な目標達成が期待されているのですから、当然チームは既存のやり方を否定し、何か全く新しい画期的な方法を生み出そうと努力します。やっと何かを捻り出した後、気づけば次のOKRを考える時期が近づいています。
このことは単純に、チームを強く憂鬱にさせます。
それが新しい市場で、新しいチームなら探索の余地はあります。機能する期待値は高くはないでしょうが一定は有りそうです。
一方でそうでは無い状況ならどうでしょう。レガシーで安定した環境についてです。数回試す価値はあると思います。安定してしまったものを破壊することで得られるイノベーションのチャンスはあります。でも4回試して何も起きなければ、ひとまずそこに必要なものはOKRでは無いことがハッキリしていると言っていいでしょう。

OKRとエンジニアリングの相性を改善する方法

1.適切な戦場と戦況とチームで使う

先述したように、OKRはすべての状況やチームに適しているわけではありません。エンジニアリングチームがOKRを導入する場合は、チームの特性やプロジェクトの状況に応じて柔軟に適用することが重要です。

2.本当にそれが必要な時に使う

選択と集中こそが肝要です。これはOKRのコンセプトの１つでもあります。
恒常的に、全ての製品においてOKRでプレイする事はOKRのコンセプトと矛盾し、資源の無駄使いに終わります。（皮肉なことにOKRを使うチームのほとんどが選択と集中を実行できていないケースが多いように感じます。）
本当にグロースさせたい製品とそれを扱う精鋭チームが特定のフェーズにおいて、彼らがそれを必要だと思う時に初めて、必要になるようなものです。

3.やるなら柔軟な期間設定で

施策の肝心な時（2ヶ月目後半）にマネージャから次のOKR設定を求められることが、最もチームをクソイラつかせる残念な現象です。チーム、メンバーの声を積極的に聞き、取り入れ、彼らが最も力を発揮できるやり方を選択しましょう。

まとめ

書いてみるとエンジニアリングとの相性の問題というより考えなしに全ての戦場にOKRを展開して形骸化したそれが惰性で継続されるような時に謎の問題に悩まされる、というモヤモヤが自分の中にあったんだな、ということが整理できて良かったです。
OKRは素晴らしいフレームワークですが、用法容量を守って計画的なご利用を検討ください。

それから最後に、本稿は記事のコンセプトを与えたChatGPTによりその大部分を生成させたものに対して僕が手を加えたものであることを記しておきます。

よくある質問 (FAQ)

Q1: OKRとエンジニアリングは全く相性が良くないのでしょうか？

A: 先述した課題をクリアして限定的に展開する限りにおいては良いツールであると思います。

Q2: OKRの代わりにエンジニアリングチームに適した目標設定方法はありますか？

A: 書いてて思ったのですが、OKRそのものより扱う側の問題の方が大きいなと思いました。とはいえ大胆な目標に誘導しようとするものではあるので、そういうのを求めてない時には定性と定量の目標を両方用意して立体的に目標を表現するOKRのフォーマットのみ活用する形にすればMBOなどより効率的な目標管理が実現できると思います。

Q3: エンジニアリングチームでOKRを導入する際の注意点は何ですか？

A: スキルや知識、コンピテンシーの改善に関する観点を忘れないことです。エンジニアは専門職ですから、総合職より学ぶ必要のある項目が多く、問題の多くは知識不足、経験不足がガバナンスの不足と合わさった所から発生します。この場合、事業成果を直接追わせることが必ずしも成果に繋がりません。一方で彼らが正しい知識と高いスキルを身につければ、それは長期的に事業へ利益を生むでしょう。
（そう考えると総合職の、例えば営業部門などのパフォーマンス上のボトルネックになるのがメンタルやモチベーションなのかもしれません。そういうシーンにおいてはOKRは非常に良く機能するような気がします。エンジニア部門であまりマッチしないと感じるのは専門職ロールでパフォーマンス上のボトルネックになるのはモチベーションなどより知識やスキルの方に比重があるから、という事も大きく影響している気がしてきました。）

Q4: OKRが適用されている組織でエンジニアリングチームの成果を評価する方法は？

A: 定量評価が難しくても改善したいことがあるなら定量的に表現できねばなりません。（進捗が追えないので。）
そのような定量化の難しい項目に関しては、チームに定期的なアンケートを実施するのは１つの良い方法です。問題が改善したと感じる人が多いなら改善傾向と判断できるし、そうでないなら方針変更を検討できます。