Rettyの開発組織をぶっ壊して、LeSSを導入した話をPO視点で書きました
この記事はProduct Manager Advent Calendar 2019の17日目です。初参加のRettyPM野口です。
10月よりRettyのプロダクト部門担当役員を拝命し、同時にプロダクト開発で本格的に導入された大規模スクラム(LeSS)のプロダクトオーナー(PO)をやっております。
LeSSを導入してくれたスクラムコーチでエンジニアのマネージャー常松のRetty Advent Calendar 2019 からボールを渡されまして、別Advent Calendarではありますが、POの視点から今回のLeSS導入について書いていきます。
Retty開発体制の課題をどう解決していけば良いか、もっとユーザーさんに食のHappyを届けるためにはどうすれば良いか、考えに考え抜いた結果、LeSSの導入に至りました。
LeSSの導入が効果的な開発組織は少ないはずなので、全ての開発チームに役立つ話ではないかもしれません。ただ、1プロダクトを10名以上の開発メンバーで担当している会社さんであれば、何かしらのヒントになると思うので、是非ご一読ください。
なぜLeSSを導入したか
Rettyは良くも悪くも企画に責任を持つマネージャーによるチーム統制、リーダーシップがはっきりした組織でした。開発チームはWeb、アプリ、検索、お店さん向け開発、運用系、グローバルなどに分かれ、KPIツリーを踏まえたミッションKPIに関する開発を行っております。各チームにプロダクトマネージャー(Rettyではプロダクトマネージャーを厳密に定めていないので、実体は担当プロダクトのロードマップを決め、ピープルマネジメントの権限があるマネージャー)、プランナー、デザイナー、エンジニアがアサインされている形でした。
そのため、継続して以下のような問題を抱えていました。
・全体では予約数がKGIだが、各チーム同士のKPIの連動性がなく、特にWeb、アプリ、検索、ネット予約のような関連性の高いチーム・機能同士で、施策やUIの乖離、ノウハウ共有の乏しさが起こっていた
・各チーム四半期毎にガチガチに目標と開発スケジュールを決めており、四半期内での優先順位変更に柔軟に対応できない
・優先度がエンジニア人員計画にダイレクト反映されていた故に、失礼な表現で使いたくないが、チーム間で人の取り合いが起こっていた
・嫌な表現だが、チーム間での工数融通が「貸し借り」のようになっていた
・これも使いたくない表現だが、やりたいことの実現のためには、チーム同士の握り、根回しが必要になっていた
・そのため、プロダクトマネージャー(PdM)の動きを誰もできておらず、プロジェクトマネージャー(PjM)ロール人材ばかりだった
書いてみて、改めてゾッとしますね。
Rettyは「食を通じて世界中の人々をHappyに。」というビジョンを掲げた会社です。ただビジョンやKGIはあったものの、チーム同士の戦術の摺合せができていたかでいうと、全くできていませんでした。四半期に一回の摺合せの機会はあったものの、あとは良くも悪くも工数の使い方がチームに委ねられていました。
これは例えば「アプリは投稿、WebはSEOを各々改善してね！連動する必要ないから！」というKPIシンプルグロースフェイズや、やりたいことに対してエンジニアの数が十二分に足りている場合には有効です。
ただRettyでは開発工数が限られています。他のチームで急を要する開発があっても、チームを跨ぐとすぐに助けることができない。1プロダクトなので、Webが自由にUI作ってしまうと、アプリと乖離すると体験が統一されない。あるチームが余った工数で自分の担当範囲の機能をリリースしたが、サービス全体を考えるともっとやった方が良いことがたくさんあるのではないか。ちぐはぐな動きが目立ちました。
おまけに、転職してきたばかりのエンジニアからは「RettyはPdMはいなくて、PjMばかり。スケジュール管理と調整に終始して、ユーザーストーリーやサービスの未来を思考できていない」という耳が痛い一言。しかしそう言われても仕方ない状況でした。
今考えてもなぜそうなったという感じですが、課題だらけの開発体制でした。
導入前のインプット
実際の進め方は常松の記事を見ていただければと思います。導入に際して、LeSSのPOをやることになった野口がどのように考えていたか書いていきます。
当時上記のような課題と他社の事例から、全チームの施策を一まとめのバックログにした方が優先度が判断しやすいのでは？とぼんやり思っていました。
ただ知識不足故、LeSSの存在を知らず、
悶々としていたところpmjp Slack オフ会なる勉強会でLeSSの事例に遭遇。
野口「めちゃ良いじゃないですかーこれだー！😆」
となっていたらVPoEの一言
VPoE 小迫「もう導入予定で検討中だよ🚀」
野口「なんだってーー😂😂😂」
僕が知らないだけで、すでにVPoEの小迫と常松で導入に向けて進めてくれていたとのこと。肩透かしでしたね。
すぐ本を読んでインプットしました。
プロダクト全体思考をベースに
その後他の体制変更もあり、野口も加わり、LeSS導入後の未来を検討。
私はLeSSになった時PdM、デザイナーチームをどう分けていくか考えました。
この時大事にしたこととして、LeSSで大事にされているプロダクト全体思考があります。
プロダクト全体思考
顧客は、プロダクトの一部分だけを買うということはなく、プロダクト全体を購入します。
(中略)
・単一チームのアウトプットへの部分最適と、プロダクト全体への全体最適、どちらを取るか選択を迫られた時は、常にプロダクト全体を選択すべきである
多くの大規模なプロダクト開発グループでは、（自分たち個々の部品、タスク、専門領域ではなく、）プロダクト全体へ全員が焦点を当てるように仕向けることが、スクラムをスケーリングするに当たって最も難しい課題の一つになります。
常に、プロダクト全体に意識を向けましょう。常に、断片的な部品や仕掛かり中の部品に価値はないことを全員に意識させましょう。
https://less.works/jp/less/principles/whole-product-focus.html
断片的な部品や仕掛かり中の部品に価値はない。Rettyの個別機能、デバイスではなく、Retty全体としてユーザーさんにどう価値を届けるか。これが重要なのだと痛感しました。
これまでは自分の担当領域に集中するが余り、その領域ではベストでも全体を見れば部分最適に過ぎない施策が少なくありませんでした。
エンジニアのコンポーネントチームの欠点と同様、従来のPdM・デザイナーの動きとして、自分のWebやアプリという領域に縛られた思考をしてしまいがちな傾向にありました。
各チームの連動性の無さを問題と捉え、一貫した体験設計を行うことを念頭に置きました。予約に関わるチームというと、Webチーム、アプリチーム、検索チームなどありましたが、これらを一つのチームとして合体することにしました。以下は特徴的なチーム移行部分のイメージです。
さすがにPdM、プランナー、デザイナーで15名程いるので、全員を一つということは難しかったので、予約以外では、集客（SEO、アライアンス集客など）、投稿に加えて、従来通りの運用（CS、オペレーション）、FRM開発（お店会員さん向け開発）、グローバルは別チームとしました。バックログはまだ統合のための移行中ではありますが、基本1つ。各プロダクトマネージャーの意見をベースに、私がLeSSのプロダクトオーナーとしてバックログにある全ての施策の優先度判断を行う体制にしました。
このチーム分けはかなり迷ったのが正直なところです。Rettyと同様に、Webとアプリのようなクロスデバイス対応しているあるいは、toB・toC両軸持つのWeb企業に複数ヒアリングや勉強会で意見交換させてもらい、最適解を探りました。
外部の方からは今回の体制変更に関する反対意見ももらいました。「Webとアプリで分けないと領域が広すぎる」、「Web・アプリ個別にKPIを追った方が改善スピードが速い」など。
社内からの反発に近い質問意見もありました。「一つのバックログで優先度判断なんかできないのではないか」、「アプリのクオリティーを誰が考えるのか」、「プロダクトのどこを改善しているのかわからなくなりそう」など。導入を担当した常松・小迫や私で、時間をかけてしっかり議論・回答。メンバーの不安を適宜解消していきました。
ただ、やはりユーザーさんを食でHappyにしたいという想いは皆同じ。そのために一貫した体験設計をすべきで、プロダクト全体思考に組織が生まれ変わることが最優先と考え、決断しました。
テーマは「全体最適！ONE TEAM！」
プロダクト部門のテーマとしては全体最適！ONE TEAMを掲げました。そうです、完全にラグビー・ワールドカップの日本代表から来ています（いや〜痺れました〜〜〜）。
ラグビー日本代表も高い目標に向けて、大きな壁、厳しい練習に耐え、一致団結してハードワークしていました。我々もユーザーさんのHappyのために一丸になろうという想いでこのテーマを掲げました。
野口の全体に向けたこうしたテーマ発表はあまりウケていなかったので、響いたのかわかりませんが、新体制が進むにつれ、開発組織は徐々にまとまりを見せてきました。
・体験設計はWeb・アプリ両面で考える
・プランナー・デザイナー全員で朝会をやる
・スクラムイベントには開発組織全員で参加し、出荷される製品をチェックする
・全体の優先度を踏まえて、バックログを並び替える
優先度判断で喧々諤々とした議論が展開されることもありますが、LeSSの基本＋一貫した体験設計のために当たり前のことを地道にこなすことで、プロダクト全体思考を体現できるようになってきました。これに関しては実際にチームを担当したマネージャーやメンバーの努力が本当に大きいと思います。
導入で成果もあったが、まだまだ課題点は山積み
まだ成果は少しずつで、劇的な変化はこれからですが、導入して良かったなというのはこんな感じです。
・PdM(プランナー)が体験や施策を考えることに集中できるようになった
・なぜこのユーザーストーリーをリリースするかが(せざるを得ないので)明確になった
・不要な進行管理業務がなくなった→イテレーションに入ってからはエンジニアで自走して問題解決
・Webとアプリの垣根がなくなった
・(デザイナーメンバーの声)サービス全体の体験を考えながらデザインできるようになった
・改めてライトユーザー・ヘビーユーザー両面の視点で、一気通貫した体験の設計ができた
・KGI、KPIツリー、やることの整理が進み、明確になった
一旦は狙い通り一定の成果は出ていそうな感覚はあります。
（まだ部分的に別バックログな箇所もあるが）バックログが一つになり、チームで開発リリースを決めるのではなく、プロダクト組織全体で優先順位を決めるので、自由度が下がるのではという声が、プロダクトマネージャーから元々上がっていました。確かに全体インパクト観点で判断されることが多いため、優先順位が後ろになるプロジェクトもありますが、その優先順位をどう上げていけば良いか、ユーザーストーリーのWhyを研ぎ澄ませるのがプロダクトマネージャーの腕の見せ所のはず。その意味であるべき姿なのではないかと思います。
これからの課題点としてはやはりプロダクトマネージャー不足。中期的なプロダクトの方針を決めることができる人材は多くはいませんし、そもそもプロダクトマネージャーの能力要件定義がないのが現状です。個々人がキャッチアップを進めると共に、ワーキンググループを作って、プロダクトマネージャーの必要能力の定義を進めていきます。
またかつてのようにエンジニアとプロダクトマネージャー・デザイナーが同じチームではないので、ちらほら距離が遠くなったという声も聞かれます。スクラムイベントでの密な連携や今後はプロダクト方針を考えるワーキンググループを適宜行うなど工夫していきたいものの、ここは注意したいですね。
LeSSを入れたRettyの開発組織のこれから
冒頭で、「今考えてもなぜそうなったという感じですが、課題だらけの開発体制でした」と書きましたが、今振り返るとプロダクト全体思考が欠けていたというのに尽きますね。今回たまたま体験ベースでPdM組織を分割しましたが、これも手段に過ぎないかなと。Rettyというプロダクトとしてどう価値提供すべきかを忘れず、組織を最適な形態にしていくべき。その点、LeSSのフレームワークが今の組織フェイズにピッタリなやり方でした。
LeSSのおかげで、エンジニアの自由度と生産性が上がったことに加え、プロダクトマネージャーがあるべきプロダクトマネージャー業に集中できるようになってきました。
ただスムーズに開発が進むことではなく、一つのプロダクトとしてユーザーさんにどれだけ価値提供できるかが本当に重要なこと。
来年はよりワクワクする機能のリリースを増やしていけるようONE TEAMで頑張っていければと思います。
今回の記事は以上です。
Product Manager Advent Calendar 2019 も Retty Advent Calendar 2019もまだまだ続きますので、以降をお楽しみに。
頂いたサポートを記事を書くためのインプットに活用します