マネージャーの調整力に左右されていた、開発の優先順位　大規模スクラム導入で目指す、組織・チームのありたい姿

Retty社・マネージャー池田直弥氏

池田直弥氏（以下、池田）：トップバッターで緊張していますが、RettyのLeSSの取り組みについてお話しします。

先ほどもご紹介いただきました、Retty株式会社のマネージャーを務めている池田と申します。2021年のちょうど今頃から2022年9月までスクラムマスターをやっていました。2022年10月から新しくマネージャーになったので、「マネージャーです」と名乗るのにまったく慣れていません（笑）。

最初に簡単にRettyのサービスを紹介させてください。「あなたにBESTなお店が見つかる」というコンセプトで、みなさんの食の好みに合ったユーザーさんの投稿から、自分好みのお店を探せるという世界観でグルメサービスを提供しています。

特にこの「イタリアン好き人気店」など、「〇〇好き人気店」は、そのジャンルが好きなユーザーさんがおすすめをしているお店で、このラベルからお店探しをすると好みのお店に出会いやすいと思います。みなさんぜひRettyを使ってお店探しをしてみてください。

プロジェクトマネージャーの調整力に開発が左右されていた

池田：それでは本題に入って、LeSSの導入の背景と全体の体制図。あとはその中の取り組みで工夫をしていることについてお話をしていきます。

まずは、LeSS導入の背景と体制図ですね。LeSSを導入する前のRettyは、アプリ、toC、toBと大きく分かれていて、その中で検索、予約などが細かくチームで分かれていました。それぞれの中でロードマップを持っていて、個別にそのロードマップを達成していく、グロースしていくという戦略を取っていました。

組織やサービスも、それで大きく成長してきたのですが、組織やサービスのフェーズが変わったことにより、個別グロースがなかなかうまくいかなくなってきていました。

その当時の課題として、Rettyというサービス全体の優先順位ではなく、各チームごとで調整をしているプロジェクトマネージャーの調整力の上手さに開発が左右されるというのがありました。

そのため、全体のKGIと各チームのKPIがぜんぜん連動できていなかったり、お店の情報やネット予約など関連性の高い機能のUIや体験が完全に乖離してしまうというのが起きてしまっていました。

一方で、「Rettyという1つのサービスが一貫した体験設計をすることでユーザーさんに価値を届ける。チームごとの担当領域でベストを出すのではなく、Retty全体でベストを目指していきたい」というのが当時のRettyのありたい姿でした。

（スライドを示して）ここにLeSSのプロダクト全体思考という考え方が書いてありますが、「顧客はプロダクトの一部分だけを買うのではなく全体を購入しますよ」という思想があります。これがちょうどRettyのありたい姿とマッチしたというのがLeSSの導入の背景です。

LeSS体制図の説明

（スライドを示して）これがLeSSに関わっているところの全体の体制図です。今はtoCとtoBにそれぞれプロダクトオーナーがいて、アプリとWebでバックログを分けているかたちでやっています。

具体的に説明します。まず、施策を考えるプランナーという職種のチームの動き方ですが、例えばtoCのプランナーのチームであれば、主にアプリとWebのバックログにアイテムを追加します。ただし、施策によってはお店の管理画面やtoB領域などに関わる場合もあるので、その場合は、toBのバックログにも（アイテムを）追加します。それぞれのバックログの優先順位は、プロダクトオーナーが最終的に決定します。

次に、エンジニアチームの動きについて。例えば、toCを担当しているエンジニアであれば、それぞれのチームで分担して、toCのWebのバックログからアイテムを取っています。その中でアイテム優先順位の調整をしたければ、プロダクトオーナーと直接話して、プロダクトオーナーがそこも最終決定します。こういったかたちで日々開発と運用をしています。

取り組みその1　「チームで幅広く対応する」

池田：では、この導入の理由にもなった、プロダクト全体思考を体現する取り組みや工夫についてお話ししていきます。大きく分けて、2つの取り組みと工夫についてお話ししていこうと思います。

1つ目は「チームで幅広く対応する」というところで、Rettyではそれぞれのチームの得意領域を尖らせすぎないチーム編成にしています。

例えば、会社によってはフロントエンドエンジニアのチーム、バックエンドエンジニアのチームみたいなかたちで固めるところもあると思います。ただ、それをやるとフロントエンドの開発系のタスクが高い優先順位としてたくさん上がってきた時に、フロントエンドチームが開発が多く、バックエンドチームは暇、みたいなことがどうしても起きがちかなと思っています。

それを解消するために、各領域得意な人を各チームに混ぜて、どんなアイテムが来ても万遍なく取れるチーム体制を取っています。

ですが、このやり方を取っているから「全員がフルスタックエンジニアになれ」とは言っていません。実際には、エンジニアごとに貢献できる得意領域があるので、「フロントエンド中心」とか「バックエンドでやります」というのは別に問題ないとしています。

ただ、「自分は得意じゃないからやりません」というのはNGにしています。苦手領域に対処していくのにただ開発してくれというのも難しいので、チーム内で得意な人とペアプロをしたり、チーム内でモブプロをしたり。

あとは、RettyのSlackにはチーム横断で相談できるチャンネルがあって、例えば実際に#frontend_askというチャンネルにフロントエンドに関する相談を投げると、チーム関係なく得意な人が相談に乗ってくれます。

こういったかたちで、自分の得意領域で部分最適で貢献するのではなく、プロダクト全体の最適に対して貢献できるチーム体制を取っています。

取り組みその2　「トラベラーを使って知識を広げる」

池田：LeSSの取り組みに入っている2つ目が、「トラベラーでチーム間コラボレーションをしている」です。先ほど「（アイテムを）万遍なく取る」とは言ったのですが、実際に1チームでは開発しきれない時もあります。

これは実際にRettyであった例で、「お店の予約情報を取得するAPIの刷新」というものがありました。前提条件として、お店の予約というのはけっこう複雑で、期間限定のコースがあったり、飲食店によく行かれる方はわかると思いますが、4人席と4人席を合わせて8人入れますみたいな予約など、実際に飲食店ではやられています。

システムで表現しているので、システム上の構造はけっこう複雑だったりしています。また、RettyはモノリスなPHPがメインなのですが、Go言語でマイクロサービス移行をしているというのが前提としてあり、この予約情報にはシステムパフォーマンスもけっこう必要なので、それも踏まえてGo言語で実装するという方針にしていました。

当時これをやるチームが2つあったのですが、片方はGo言語を中心とした技術系が得意だけれども、予約の業務知識が少ない。もう片方のチームは、予約の業務知識自体にはかなり詳しいけれど、特にGo言語を書いたことがないみたいな。両方のチームの強みが同時に必要なシーンがありました。

この時にどうしたかというと、LeSSのガイドに書いてあるトラベラーというのを使って、業務知識が必要な場合には予約をすごく知っている人が技術が得意なチームに一時的に混ざって一緒に開発をする。スプリント開発が終わったら元のチームに戻る、みたいなことをやりました。

「得意な人たちを集めて専用のチームで開発をしたらいいんじゃないの？」みたいな意見もあると思いますが、それはあえてしていません。専用のチームを作ったとしても、そのチームがずっと開発や運用をしていくわけじゃない。いずれフィーチャーチームの持ち物になるだろうなというのがありますし、予約というのは飲食業においてはけっこう大事で、サービスのあちこちに影響するものなので、触れるチームを少なくするとそこがすぐにボトルネックになるという懸念もありました。

なので専用チームにするのではなく、プロダクト全体の優先順位に合わせて開発していける体制を作るために、トラベラーというものを取り入れて開発をしています。

一番大事なことは「何を達成したいか」

池田：ここまでいろいろとお話をしてきたのですが、一番大事なのは「何を達成したいか」だと思っています。まず組織やチームが何を達成したいのかの価値観を一緒に話すことが大事で、プラクティスとしてそれを体現できるものを選ぶのがいいのかなと思っています。

Rettyの社内でよく話題に出るのですが、私たちはLeSSをうまくやりたいわけではなくて、プロダクト開発をうまくやりたいという前提があります。組織やチームのありたい姿の思想がLeSSというフレームワークに適しているのであれば、フレームワークにうまく乗っかることで、LeSSを継続できるしプロダクト開発もうまくできる。そういうかたちで考えています。これでRettyの事例紹介を終わります。ご清聴ありがとうございました。