LeSSでのOKR運用を見直してみた話
こんにちは。SmartHR プロダクトマネージャーの齋藤( @yyysai )です。
この記事は 「SmartHRのプロダクトマネージャー全員でブログ書く2024」 への参加記事です。
25人が持ち回りで毎週記事を投稿します。ぜひご覧ください。
今回は 「7チームで作っていた大きなプロダクトを分割再編しました」の組織再編を受け、LeSS(大規模スクラム)でのOKRの立て方・運用の仕方を大きく見直してみた話をしようと思います。
うまく機能していなかった、ユニットOKR
組織再編をする前、SmartHR基本機能のLeSSはこのような体制で動いていました。
この体制では、LeSSという同じ屋根の下で「フロントシステム(現・労務サービス)」「従業員DB(現・労務データ管理)」という2つの概念上のユニットに分かれ、それぞれのユニットでOKRを立てて運用していました。
ただ、そうした体制下でのOKR策定・運用には以下のような課題がありました🤔
普段の会議体は、LeSSの7チーム合同での大きな単位で開催されることが多く、各チームのユニットへの帰属意識・解像度が低い状態だった
ユニットの定例会議にはPM / PMMが主に参加しており、OKRもそのメンバー主導で立てられていたので、PMとPdE(プロダクトエンジニア)でユニットOKRに対するコミット意識にズレがあった
各チームで分断されたKRを追うような目標設定になっており、ユニットとして互いに協力して目標達成に取り組むケースも少なかった
曖昧な境界線で囲まれたユニットのすべての活動を網羅的に目標に取り込もうとしてしまい、Objectiveや各KRの抽象度が高くなってしまっていた
実際にやってみたこと
組織再編と合わせて、1チームのPMと兼務でLeSSのPOも担うことになることが決まっていたこともあり、自分が昨期末頃から今期のOKR策定をリードすることになりました。
OKR策定を進める中で今回試してみようと思ったのが、
上記の各課題に対し、ユニットとして
各チームが同じ方向を協力して向けるようにする
PMとPdE間でOKRに対するコミット意識を揃える
OKRに対する認識のズレが起きないよう目標を具体的にする
というアラインメントを図ってみることでした💪
組織とOKRの構造をまとめると、この形です。
実際に試してみたことの詳細は以下でまとめています。
各チームが同じ方向を協力して向けるようにする
これまでのOKRでは、「いつまでにリリースできるか」というリリース(アウトプット)までが目標に置かれていました。
そのため、ロードマップで設定されている開発テーマ・アウトカムが達成できたかどうかまでを追えていないのが実情でした。
かつ、KRがfeatureごと(= チームごと)の目標になっていたことから、他チームが今何をやっているのかに目を向ける頻度も少ない状態でした。
そこで、今回のOKRでは「アウトカムの達成」を主眼に置いた目標を立て、アウトプット(feature開発)の目標が記載される比率を下げています🙆🏻♂️
あくまでアウトプット(リリース)するfeatureは仮説であり、その先のアウトカム達成こそが大事であると考えているためです。
また、KRをチーム単位の目標にせず、各チームが協力して成し遂げる前提の構成へと変えてみました。
PMとPdE間でOKRに対するコミット意識を揃える
これまではユニット定例にてOKRを立てており、必須参加者はPM/PMMだったため、OKRの策定プロセスにPdEがあまり介在できておらず、どうしてもPMとPdEとでOKRへのコミット意識に差がある状態でした。
そこで、Objectiveのうち1つをユニットとしての生産性向上に置きたいという意向だけを各チームのPdEリーダーに伝え、その後のObjective1つの策定を最初からお任せしました。
PdEリーダーのユニットOKRに対する解像度上げと、そこから各チームPdEへのOKRの浸透・行動の促しも期待しての試みです👀
また、それとは別で、今回から3つあるObjectiveのそれぞれにユニット内から有志でPM1名 + PdE1名のオーナーを立て、Objective達成に向けた旗振りを行ってもらうようにしています。
OKRに対する認識のズレが起きないよう目標を具体的にする
例えば、「◯◯に関するボトルネックを解消する」という目標だと、目標が達成できたかどうかが分からない、どこまでやればユニットとしてストレッチな目標達成をしたと言えるかが曖昧、という課題がありました💭
また、半期でユニットとして行っていく活動を網羅的にOKRに入れようとしていたため、各KRのアクションを束ねるObjectiveが抽象度の高い文言となっていたことも課題だったのではと考えています。
そのため、今回のOKRでは、価値のデリバリー観点で例えば「商談でご提案ができる状態(= 受注に繋がるかの検証ができている状態)」「ユーザーの◯◯の課題が解決されていることが検証できている状態」といったようにアクションの完了状態の定義をさらに明確にしています。
現在、そして今後
上記の試みをしながら今期のOKRを運用してみて、すでに良かった点・改善点が見えてきています。
そもそも今回立てたOKRが本来のOKRの理想状態とは異なる部分があるということも認識しているので、改善を繰り返して理想状態に近づけていければと思っています。
良かった点😋
ユニットの半期Kick OffでOKRとロードマップの説明をしたところ、事後アンケートで「やっていきの気持ちになった」という良いフィードバックが多く見られた
オーナーを筆頭にObjectiveごとの分科会が生まれ、チーム間で知見を共有しながらObjective達成に向けた動きが生まれている
ユニット定例で、Objectiveを達成するために他チームに対してサポートできることはあるか?という質問やアドバイスが出てくるようになった
ユニットの半期Kickoffの事後アンケート回答(一部抜粋):
伸びしろ😭
まだOKRの振り返りができているわけではないので個人的な意見になりますが、さらに伸びしろがあると感じているポイントの一例です。
Objectiveごとにオーナーを立てているため、Objective間の進め方のすり合わせに時間がかかる
feature単位のリリース時期の目標値はOKRから手放したので、リリース時期についてのストレッチ感は各チームに託されており、オーナーからするとコントローラビリティが低い
リリースまで数ヶ月間のfeatureがあると、そのアウトカム計測はどうしても次の半期に持ち越しになってしまい、OKRのサイクルと噛み合わないケースがある
最後に
3ヶ月しか運用していないので新しいOKR運用方法の検証は今後もまだ続きますが、引き続き各チームがユニットへの帰属意識と「やっていき」の気持ちを持てるようなOKRを立てられるよう、運用をブラッシュアップしていきます。
また、このようにLeSSの単位で複数チームを束ねるOKRを策定して動かしていくという経験をできる機会は、なかなか無いなと感じています。
私たちはプロダクトマネージャーを募集しています!
SmartHRでは引き続きPMの採用に注力しています🙏
PM職に関する情報をまとめた記事がありますので、ぜひご一読ください。
カジュアル面談のリンクなどもこちらに掲載しております。
この記事が気に入ったらサポートをしてみませんか?