最近よく耳にする「マネジメント3.0」のツールの一つである「OKR」について勉強中でありつつも、自チームへどうしたらうまく導入できるか、どうしたらうまく運用できるかを模索した結果、他の人にも役に立ちそうな内容を見つけたので、共有しようかなと思います。
OKRは、一般的なチームの目標設定と目標達成までの流れを綺麗に整理する道具として大変有効なものですが、エンジニアリング現場では若干導入が難しい面があると言われています。
以下の記事から、エンジニアリング現場でもOKRの良い例をいくつかピックアップしましたので、紹介します。
あくまでも「例」なので、これらをそのまま使える現場はおそらくないですが、自チームのOKRを決めるときの参考になるかなと思います。
「Engineering OKR Examples」
「What are some examples of good OKRs for software engineers? For engineering managers? For individual contributors?」
そもそもOKRって？おさらい
OKR = Objective & Key Results の頭文字から来ている略で、結果思考のゴール設定フレームワークです。ここでいう結果は、会社やチームのコアバリューに基づくものが基本だそうです。
今までよく使われていたKPIやMBOと違って、上層部が作るものがメンバーに伝達されるのではなく、評価にも使われないことが多いようです。そのため、半期またはクオーターでの見直しや従来の進捗管理なども行わないことが多いです。OKRを使っているチームのメンバーが「自ら背伸びをした目的を追うために必要な目標を設定する」ことを可能にするフレームワークだと言われています。
OKRは基本的に全てオープンで会社がどれだけ大きくても透明性が保たれている状態で運用されているのは普通です。
Objectiveは「目的」とも言えます。理想の「O」は： 期限があり、数値化されていない、野心的な、自らの目的・存在意義を問う時の答えになる、組織内部の協力を促しその力を与える、明確な主語と目的語及び主語が目的のために通る道すべを語る ものが望ましいです。
Key Resultsは「絶対に必要な結果」として訳してもいいかなと思います。OKRの「KR」は：数字で計測可能で、変化をデータとして表現できる、複数のタスクの結果でありながらもタスクではない、目的の「O」を達成できたかどうかをどうしたらわかるのか？の答えになるように設定することがベストだそうです。
多くの場合、KRは3つまでと言われていますが、2つや4つを設定するケースもあるらしいです。
ただし、KRは「Oのためのカギとなる結果」なので、本当に必要なものだけにフォーカスして絞った方がよいとのことです。
これらは一般的な組織のビジネス側の場合はそれなりに自然に設定できそうなものです。売り上げや利益、直帰率やリピート率などの数字を多く元々扱っている職種の場合は「O」が難しくても、「KR」はそうでもない場合が多いようです。
では、エンジニアリング現場だったらどうなのかな？と調べた結果を共有します。
エンジニアチームのOKRサンプル
チームのパフォーマンスをターゲッタしたO: 効率の良いエンジニアチームを作る
KR:
- チームの成績（パフォーマンス）を今より25％向上させる
→ 計測さえできていれば、明確な数字で達成を表現可能で、さらに途中経過もデータで裏付け可能な内容。 - エンジニアチームの成績を計測できるためのメットリクスを開発・ドキュメント化する
→ 一つ目のKRを測るための指標を開発しただけでここがDoneになる。「目的を達成できたかどうかをどうしたらわかるのか？」の答えを出せるために必要不可欠な内容。 - 前期に比べて最低2つのエンジニアリングカンファレンスに参加する
製品の品質をターゲットにしたO: リリース物の本質を向上させる
KR:
- 開発途中の発見バグ数を20％削減する
- コードのユニットテストのカバレッジを50％から70％のあげる
- 各エンジニア個人が全スプリントに比べて20％多くのコードレビューをする
→ 最初から綺麗なコードを書けば手戻りが減り、品質は上がる。これに向けたタスクを洗い出すのも実践するのもエンジニアならやりがいがありそう。
製品のリリース速度をターゲットにしたO: 機能のリリースを早くする
KR:
- ユーザーテスト前の品質保証テスト期間を2週間伸ばす
- リリース予定の全週に報告されるバグを50％減らす
- 開発プロセス途中の問題を25％減らす
→ 不具合発見のタイミングをなるべく手戻りが少ない状態の時に集中させる印象を受けました。自分ならここで要件定義のレベルアップを促すKRを入れたいところです。
バックエンド向けのO: アプリケーションのパフォーマンスを向上させる
KR:
- API応答時間を4秒にする
- アプリケーションの応答時間を平均で450ミリ秒にする
- コードレビューにかかる時間を半分にする
→ この最後のKRがどうして必要なのかはちょっと疑問があるがレビュー時間を減らすにはコードを綺麗に書く・小さく書く必要がありその辺りで結局は早く動くコードを書くようになるとう意図が込められているのかな？
ちょっと大きなチームのためのO: 上質なエンジニアリングを提供する
KR:
- リードタイム（またはサイクルタイム）を現状より10％削減する
- ユニットテストのカバレッジを現状より20%増やす
- AWSの費用を25%減らす
- 半期でユーザーに報告されたクリティカルな不具合を5またはそれ以下にする
いくつかのベストプラクティス
- ORKは個人レベルではなく、必ずチームレベルで設定する。
- いくらいい例があってもそれがそのまま使えるOKRには絶対ならない。あなたの組織とそのOKRに適切なものを作る必要がある。
- エンジニアの場合、KRがよく大きめのタスクのように書かれがち。タスクらしい表現から「そのタスクが終わったらどうなるか？」を表す表現に書き換えると良いKRになる。例：「検索ワードのデータベースを早いスペックのインスタンスに移行する」→「ユーザーが使う検索機能の応答速度を25％あげる」
一旦今日はここまでにします。次の記事でまたマネジメント3.0とエンジニアリング現場について書こうと思います。