開発チームのOKRが表示速度になるまでのプロセスとその後

こんにちは。マイベストでサーバーサイドエンジニアをしている渡邊です。

現在、開発チームはOKRとして表示速度の改善を持っています。今回は、そのOKRが、どのようなプロセスで決まったのか？と、それが実際にどのように運用されているのかをご紹介できればと思います。

きっかけはチームメンバーの増加とOKRの抜本的な見直し

弊社では、昨年末から会社・チーム・個人の目標管理としてOKRを導入しています。

ただ、開発チームに限って言えば、人数が揃ったのは今年度になってからで（それまではフルタイムエンジニアは1人..）、それまでOKRはチーム目標ではなく個人目標に近いものでした。

当時のOKRから一部抜粋。Objective-KeyResultの形にはしているものの、人数（１人）に対して目標が多く、重要事項にフォーカスしきれていない..

また、以前のOKRは、それぞれのタスクの進捗を管理するものとしては機能してたものの、OBJECTIVE (目標)は決して野心的ではなく、KEY RESULTS（結果）はプロセスより結果の達成率に目がいってしまうようなものでした。

このような現状のふりかえりも踏まえて、次の3ヶ月でチームが目標とする指標は、チャレンジングかつ、達成プロセスにも目が行き届くようなものにすべく、7月に次のOKRを決める全社ブレストを行いました。

１つの試みとして、みんなでOKRを決めるようなブレストを行った時の写真。目標を自分たちで決めると自分事感がでますね。

プロダクトを横断的に担当するチームだからこそ持てる「表示速度」という指標

実際のブレストでは、現在のチームの性質上、１つの開発チームで会社全体のプロダクトを開発・保守するような動き方をしているため、特定のコンテンツに関するKPIや新機能開発のようなことに関するコミットはせずに、横断的だからこそプロダクトに価値の持たせることのできる目標になるということを意識しながらチームメンバーでアイデアをだして進めていきました。

具体的には、各自がプロダクトで解決したい課題を考え、それらをグルーピングし、現状を踏まえて優位性となるような解決課題を見つけ、それぞれの想いの方向性を揃えてまとまった案をさらに洗練させるようなステップで、OKRのOBJECTIVE (目標)の部分を決定しました。

OKRを決めるためのブレストをしている時の写真。今見ると全体的に左に寄っている。

そして、ブレストによって、ユーザーに速度を意識しないぐらい快適に使ってもらいたいという想いと、何かを選択しきてくれたユーザーに対して、余計なことで悩まずにわかりやすいUIを提供したいという想いが言語化され、「速度」という目標ができました。

このようなプロセス踏むことで、「速度」を目標とすることが、ただプロダクトを高速にするだけではなく、UI改善も含めたUXの向上に繋げていくことであるということでチームの目線が揃ったのではないかと思います。

OKR設定前後で変わった意識

実際に「表示速度」がOKRとなってから、日々の開発時の意識も大きく変わりました。

定点的な測定にはGoogle Data Studio、リリース後の測定とパフォーマンスの詳細な分析はNewRelicを用いています。

以前から、サービスのパフォーマンスは意識して取り組んでいましたが、目標設定後は、開発レビューなどでパフォーマンスに関する心遣いするようになり（かといってレビュー工数が増えたというわけではありません）、現状のUXを検討する際にも、施策の意図を汲み取りながら、必要な部分のみを取り入れたり、不要となった機能なども適宜削除していくという行動が自然と取れるようになってきました。

また、既存のコードを細かに改善したり、Ruby/Rails等のバージョンを最新に追従し続けることで、表示速度以外のパフォーマンスも向上させることができました。

サーバーの平均応答時間のケース。試行錯誤故に、途中パフォーマンスが悪くなったりもしてますが、そのあたりの学びを活かしつつ順調に下がっています！

今後は、このOKRを通してサイト内での学びを増やし、速度とUXがよりポジティブなものとなるように運用をしていこうと思っています。

ユーザー課題ファーストなチームに向けて

今回はOKRの決定とそのプロセス・運用に関して現状をご紹介させていただきました。会社としてもチームとしても立ち上がったばかりでまだまだ未成熟なところが多いですが、ユーザー課題を考え続けながら、仮説・検証・コミュニケーションを大事にしつつ、プロダクトを作っていくようなチームになっていけばいいなと思っております。