プロダクトチームのOKR設計で苦戦した話

2022年6月3日 14:51

株式会社Another works CTOの塩原(@ソル)です。
株式会社Another worksでは、「複業クラウド」という複業マッチングプラットフォームを運営している会社です。

今日は実際にCTOとして所属しているプロダクトチームにおいてOKRの設計で色々試行錯誤しながら、ある程度今のOKRにたどり着いたのでその変遷をお話しできればと思います。

OKRとは？

OKRに関してここで詳細に語ることはしないですが、
一般的に言われているのは、四半期や半期で事業部などの単位で設計する目標のようなものになります。
Oが目的で、KRがそれを達成するための指標となっています。

プロダクト開発に携わっている方であれば理解できると思うのですが実際にこのOKRを立てるのはかなり難しいと感じています。

というのも、例えば営業であれば受注という絶対的な最上位指標が存在するためObjectはそれになりかつ数値としても非常に明確で達成・未達もわかりやすく設計することができます。

一方でプロダクトに関しては新しい機能を作ることだけが正義というわけではなく、バグ修正だったり技術的な負債の解消、既存機能の改修・改善だったりも同様に重要であるため最上位指標というものは存在しません。

また数値での計測というのも難しく、例えばリリース数などを置いたとしても工数のかからない機能開発に着手すれば増えるし、反対に工数のかかるものに取り掛かると減るという不安定な指標となります。

これらの考察をしながら過去設計した二つの失敗例とそれを踏まえて現在設計しているOKRについて紹介をしていきます。

プロダクトの成功を測る上で日頃計測しているKPIをOKRに使うのはどうかという考えのもと上記のOKRを設定しました。

「複業クラウド」は企業とタレント(複業したい個人の方)をマッチングするサービスであるため、マッチング数がプロダクトのNSMになります。

エントリーはタレントから求人に対するアクションであるため、
そこからマッチングに繋がる割合が多く、その数値をQで伸ばすというOKRを設計しました。

数字的には非常にウォッチしやすく、チームとしてもそれを達成するためにあらゆる施策を行い数値を伸ばそうと開発を進めていきました。

しかし、結論このOKRは失敗でした。
失敗の理由の一つはエントリー数を上昇させるための施策を打ったとしてもそのQ内ですぐに効果が現れることはなく、OKRの達成に近づくことはできませんでした。

またエントリー数という目標にしたことでユーザー課題に対する課題や要望課題といったところがおざなりになり、結果的にプロダクトとして定性的によくなったとは言えないQとなりました。

その当時はより少なかったですが、現状も1チームしかない状態で事業部OKR = チームのOKRとなるため偏ったOKRは危険であることがわかりました。

上記の失敗例を踏まえて改めて考え直したのが、
課題の大枠の優先度を決めて、Qごとにテーマを立てて開発を行うというOKRを立てるようにしました。

たとえばエントリーするにあたって求人の情報が不足しているという課題がユーザー課題として大きい場合、その課題をテーマとして解決するための開発をQで行うというような目標を立てます。

課題のテーマは定量・定性的な課題から問題を抽出し、課題を設定しているので、よりコアなプロダクト課題に向き合うことができました。

ですが、このOKRの問題点として、小さいUX改善(ボタンが押しづらいなど)のようなものがあまり進みづらくなるという問題が発生しました。

またテーマを絞り切ることで、チームの中で個人の関わる度合いが変わってきました。

弊社では、企業のWeb画面のフロント・タレントのWeb画面のフロント・タレントアプリのWeb画面のフロント・サーバーサイドとそれぞれ分業でやっているため、課題のテーマによってOKRの関与度合いが変わってくるという問題が残り、別の手段を考えることとなりました。

これらの過去を踏まえOKRで重視すべき点をある程度明確にすることができました。

1. メンバー全員がそのOKRに貢献したと感じれるようなものであること
2. 人数が少ないワンチームであるため、OKRの対象が狭すぎてはいけない
3. Q内で達成したと認識できるOKRであること
4. OKR以外も意識すべき

これらの問題点を踏まえて、新しく設計したOKRは以下のようなルールを設定した上で設計しました

1. 課題からQで取り組むべきテーマを定めた上で、PBLを作成。PBLを100%達成するというOKRを設計
2. ただし、UX課題やバグ対応、パフォーマンス・技術課題などにも取り組むべきという発想からSprint(一週間)を60%PBLに、40%をその他の開発に充てるというルールを追加

このことによってメンバーや他部署にとってもわかりやすくかつ、付随する課題点をクリアしたOKRを作ることができました。

OKRはかなり試行錯誤しながらいろんなパターンを試しました。
そもそもOKRを導入していないとか、もっと会社規模が大きくなれば失敗例1や2みたいなOKRも個別チームOKRとしては成り立ちそうだなと会社のフェーズによって変わってくるなとは思っています。

なのでこれが正解だとは思わず、改善を続けていきたいと思います。

この記事が気に入ったらサポートをしてみませんか？