技術部門にOKRを導入したら3ヶ月で部の雰囲気がめちゃくちゃ良くなった話

こんにちは、食べログシステム本部本部長代理の京和と言います。今年の7月から食べログにジョインし、10月に技術部という部署を新設しました。技術部はSREチーム、QAチーム、マイクロサービスチーム、DX(Developer Experience)チームの4チームで構成されています。

本エントリでは技術部におけるOKRの導入事例について紹介します。

目的と背景

一定規模以上のサービスではよくあることですが、食べログの技術部門ではプロダクトや組織の成長に伴い日々の運用業務の負荷が高くなった結果、既存システムの抜本的な改善のための時間を取ることができず、システムのレガシー化や技術的負債が徐々に蓄積していく課題がありました。
少し抽象化すると、組織の構造的な課題によって技術負債が生まれており、技術負債を解消していくためには、まず組織課題を解消することが必要でした。これらの課題に対して、横串でシステムを見ることのできる技術部の新設と、OKRの導入によって打破しようと試みたものです。

OKRの導入

幾つかOKRの書籍を読んだ中で、まずは一番シンプルで運用についても具体的に書かれている下記の本をベースにOKRに取り組んでいくことにしました（以下OKR本と呼びます）。前半は小説形式でOKRを紹介する構成なので、早い人であれば1時間程度で読めると思います。

まず最初にメンバー全員にこの本を読んでもらい、各チームでOKRを考え、1週間毎に皆で集まってOKRの報告会（ウィンセッション）を開催するという流れで進めました。
運用自体は下記のように非常にシンプルな形で始めています。

• 月曜日に各チームでチェックインMTGを実施し、週次のOKR Issueに記載
• 金曜日に部全体でウィンセッションを実施し、各チームで成果を発表し、お互いを褒め合う・称え合う

導入初期からいきなりうまくいったわけではありませんが、そこから様々な改善を行うことで、結果的にはタイトルのようにこれまでの部の雰囲気とはガラッと変わり、とても良い雰囲気に変わりました。
OKR導入の中でやってよかったと思うことを幾つか紹介していきたいと思います。

やってよかったこと

最初はOKR本のやり方を忠実に守る

日本には「守破離」と言う言葉が昔からあります。これは技術の習得プロセスを3段階に分けたもので、最初の段階では書かれている事を忠実に「守」り、そこから基本を身に着けた後、徐々に基本を「破」り、「離」れていくと言う考え方です。
OKR本ではOとKRの他に「今週の優先事項（P1/P2）」「OKR自信度状況」「健康・健全性指標」「今後の4週間」などがOKRを上手に運用するためのプロセスが詳しく紹介されています。最初はこれらはすべて取り入れ、出来得る限りアレンジすることなくそのまま運用することを心がけました。
それによって、OKRのプロセスを考えたり議論するフェーズをスキップし、OKRの中身を考える事やOKRの運用のブラッシュアップに集中することができました。

最初はチームのOKRに絞る

最初は何事もシンプルに始めることが重要です。「会社 - 部署 - チーム - 個人 」と言った階層構造でOKRを設計する事例もありますが、そうするとステークホルダーが増え、OKRを運用する難易度や複雑度は一気に跳ね上がります。
そこで、技術部ではまずはチームのOKRに絞り、小さく始めることにしました（OKR本でも階層OKRについてはあまり触れられていません）。
一方で、そもそも技術部全体として目指すべきゴールがないと、各チームのOKRの方向性がバラバラになってしまう懸念がありました。そこで、技術部では、
「食べログのシステムやサービス開発プロセスを改善することで、より速く、より安定的にユーザーに価値を届けられるようにする」
と言う長期目標を掲げているため、各チームのObjectiveは必ずこの長期目標の実現に繋がるものにするルールとしました。技術部門であっても自分達の存在意義を「ユーザーに価値を届けること」とし、ユーザー第一で考えることは非常に重要なことだと考えています。

最初のOKRは納得行くまで徹底的に考える

OKR本ではOKRの決定プロセスも細かく紹介されています。忠実に守ると言いつつここは華麗にスルーして、最初は十分に時間を取って各チームでOKRを考え、私自身もそのレビューに多くの時間を費やしました。10回近くレビューしたチームもあったと思います。
高い理想を掲げ、それに向かって挑戦するというOKRの考え方は、バグや障害を起こすことなくシステムを運用する事を指向するエンジニアの考え方からすると馴染みが薄いこと、また、メンバーレベルでチームが目指すべき方向性を自分で考える機会がこれまで少なかったこともあり、納得行くまで対話をする時間そのものに価値があると考えました。

後に行ったOKRの振り返りでは、

・これまではやることが決まっていたレールに乗っていたが、「なぜやるのか」「何をやるのか」をいざ自分たちで考えると想像以上に時間を要した。
・目標を自分たちで考えたことが根底にあるのかもしれないが、うまく行かなかった問題・課題に対しても自分ごととして考えられているように見える。だから改善案も自発的に出てくる。

と言ったコメントがあり、最初にしっかり時間を取ってよかったと思っています。
OKRは運用が始まってからも悩み苦しむことになるため、OKRの決定に一人一人が納得感を持つ事が非常に重要だと思います。

ウィンセッションを毎週改善する

OKR本ではウィンセッションを行う目的や期待する効果については書かれていますが、ウィンセッションの具体的なやり方はあまり詳しく書かれていません。とりあえずエイヤで始めてみたものの、なかなかうまく行かなかったので、ウィンセッション後に毎回KPTを行い、会そのものを継続的に改善する取り組みを始めました。

初期のつらみを感じるPたち

KPTでは毎週10〜15のTryが出て、その中で毎回約半分くらいを実際に実行していきました。これまで大小含めて40〜50個近い改善を行っています。

良かった改善は幾つもありますが、特に効果が大きかった発表フォーマットの変更について紹介します。

Before

# 活動サマリ
task|result|description|
--|--|--|
タスク1|できた|ほげほげ
タスク2|できなかった|ふがふが

# その他

After

## Objective / Key Results

## できたこと・できたもの

## チームの課題・それに対する対策

## 今週の学び

フォーマットのポイントとしては、大きく下記の二点です。

• 従来の報告のやり方にどうしても引きずられてしまい、成果ではなく進捗の話になってしまっていたので、「できなかったこと」の反省や振り返りやチーム内で行い、ウィンセッションでは成果（できたこと・できたもの）にフォーカスする
• できなかったことは「課題に対する対策」や「学び」として、他チームでも活かせる形で展開する

この変更によって、ウィンセッションの趣旨である「成果を発表する」事にぐっとフォーカスできるようになりました。他にも、発表の密度を上げるための工夫や、質問や褒めが積極的に行われるような改善に加え、チームも徐々にOKRに慣れていくことで、改善の兆しが見え始めました。

変化の兆しを感じるKが出始める

更に改善を続けた結果、12月にはウィンセッションの雰囲気もぐっと良くなり、この雰囲気を他部署にも伝えたいとゲストを呼んでみると、ゲストから非常にエモいKがもらえるようにまでなりました。

いい感じに仕上がってきて明るいKが目立つように

MTGそのもののKPTを行い、MTG自体を継続的に改善していくと言う取り組みは良いプラクティスだと思っていて、ウィンセッション以外でもいろいろな所で効果が出ているので、個人的にはとてもおすすめです。

ウィンセッションではできるだけデモ形式で発表する

前項の改善の一環でもありますが、デモ形式による発表を強く推奨するようにしました。エンジニアとして動いているものを見るのは単純に楽しいですし、盛り上がりますね。また、発表する側としても、デモをする以上は一定以上のクオリティが要求されるため、成果に対する緊張感が生まれます。
仕事の内容によってはデモは難しいんじゃないか、と思われるかもしれませんが、私はほぼすべての仕事でデモが可能だと思います。

例えばある週のウィンセッションでは、

## マイクロサービス
* バッチシステムのK8s化
* Argo CDによるデプロイとバッチの実行〜ログの確認までをデモ

## SRE
* GrafanaとPrometheusを本番のアクセスログを使って計測や監視やってみるデモ
* PromQLを書いてメトリクスを追加するデモ

## QA
* 他チームへ障害分析のヒアリングするためのQAチームのピッチ資料をデモ

## DX
* Microsoft Teamsの新しい運用ガイドラインの草案と改善後のTeamsのチーム構成案をデモ

このような感じですべてデモ形式で成果発表がありました。
デモによって他チームの取り組みをより深く理解することで、成果を称えやすくなり、その結果チームを超えて部全体の一体感が高まり、自然とチーム間での協力が生まれるという、とても良いサイクルが生まれるようになりました。

OKRを振り返って

OKRは運用がすべて

様々な場所で言及されていますが、OKRは『導入した企業の大半が最初は失敗し、OKRが定着せずになくなってしまう企業も多い』と言われています。
技術部も今でこそ部の雰囲気は大きく変わりましたが、導入当初はそれほどうまく行っておらず、懐疑的な人も多かったように思います。定常業務の負荷が非常に高く、OKRに取り組む精神的な余裕を持つことが難しいチームもありました。
そういった状況の中で、熱意を持って各チームと粘り強く対話し、OKRで実現したいことを繰り返し説明しながら、毎週運用をブラッシュアップしていくことで、徐々にOKRの考え方が浸透し、成果も出始めることで部の雰囲気が変わっていきました。
OKRはOとKRをただ設定するだけではほぼ100%失敗します。OKRはあくまでもツールであり、OKRの導入をきっかけとして、組織やチームの目指すべき姿について深い議論を行い、これまでの考え方や思い込みを変え、新しい習慣を身につける事が本質的な価値だと思います。

OKRで「働き方の型」ができた

技術部門の仕事は締切が曖昧な領域も多く、日々の運用業務に追われスケジュールがつい後ろ倒しになってしまったりと、易きに流れてしまいがちです（私はこれを人の問題ではなく構造の問題だと考えています）。
こうした問題も、OKRを導入することによって、良い意味で緊張感を持って仕事を進めることができるようになりました。

「金曜日は毎週のリズムの一部になった。毎週月曜日に、全員でその週の計画を練り、互いに対してコミットする。若い会社に必要な、厳しい話し合いだ。そして毎週金曜日に、お祝いをする。OKRの達成は無理ではないか、と思ってしまうような厳しい週でも、金曜日のウィンセッションがチャレンジを続ける希望になる。士気を上げる効果は絶大だった。誰もが金曜日に発表できる成果を求め、1週間頑張って働く。まるで、会社全体が魔法に包まれたかのようだった。」

上記はOKR本の引用になりますが、これまでとの一番の大きな違いは「週の始めにゴールを決め、そのゴールに向かって仕事をする」という逆算思考で仕事を進める点です。これまでは、毎日の積み重ねで後から振り返って「今週はこれができた」と言う積み上げ思考でしたが、逆算思考で仕事をすることによって、自分達で締切を作り、良い意味で追い込む事ができるようになったと言えます。
また、毎週の成果を他チームにも見えるように作ることで、アウトプットの形をこれまでより明確に考えるようになったことも大きいでしょう。
OKRを通じてこのような「働き方の型」が出来たことで、日々の業務に時間を追われながらも、それぞれのチームがやるべき抜本的な改善から目を逸らすことなくフォーカスし続けることができるようになったと思います。

今後について

OKRを導入して3ヶ月と言う短期間でここまで大きく良い方向に変わるというのは私自身も予想しておらず、とても嬉しい結果になりました。技術部の忘年会でも、皆口々に「OKRで本当に組織が変わった」「OKR本の表紙のとおりだった」と言っていたことが印象的でした。
OKRを通じてチームが本来果たすべきアイデンティティにしっかりと向き合い、それに向かって成果志向で自律的に動けるチーム作りができてきていると感じています。

私は自分の役割は、日々の仕事はチームを信頼し任せながら、チームが本質的に果たすべき役割にフォーカス出来ているかを、OKRなどの仕組みを通じて支援することだと考えています。
まだOKRの運用も始めたばかりで課題も山積みですが、食べログをより多くのユーザーや飲食店から愛されるサービスにするため、技術部全体で「食べログのシステムやサービス開発プロセスを改善することで、より速く、より安定的にユーザーに価値を届けられるようにする」と言う長期目標の実現に向かっていけるように、今後も頑張っていきます。

もし食べログに興味がある開発者の方がいれば Twitter や Facebook などで気軽にお声がけください。
俺たちの戦いはこれからだ！