プロダクトが成長すれば、当然その開発チームも拡大していく。それに伴い、多くの企業ではサービス軸や目的軸などでチームを細かく分けることで、意思決定スピードや機動力を担保していくことになる。

しかし、特に「ひとつのプロダクト」を開発する組織の場合、分権をすることが必ずしも最善とは言えないケースもあるだろう。

日本最大級の実名型グルメサービスRettyを展開するRetty株式会社。同社は2019年の時点では「検索」「SEO」「ネット予約」といった目的別のチームに大きく権限を委譲することで、成果を最大化することを目指していた。

しかし、各チーム内での「部分最適」が進むことで、ユーザー体験にズレが発生したり、プロダクト全体としての優先順位付けができなかったりと、多くの課題も抱えていたという。

そこで同社では、より良い開発プロセスづくりを目指し、大規模スクラム（LeSS：Large-Scale Scrum）を導入。「組織全体でひとつのスクラムを回し、みんなで力を合わせてひとつのプロダクトを作る」ことで、ユーザーにより速く価値を届けられるようになり、またメンバーのマインドにも大きな変化が起こっていったという。

ただ、その道のりは決して簡単なものではなく、議論を繰り返しながら、少しずつLeSSの開発体制を構築していったそうだ。

今回は、同社でWeb開発領域のシニアマネージャーを務める常松 祐一さんと、エンジニアの池田 直弥さんに、2019年〜現在までのRetty開発組織の変化についてお伺いした。

「みんなで力を合わせてひとつのプロダクトを作る」組織へと変化

常松　私は2019年6月にRettyに参画し、現在はエンジニアリング部門のシニアマネージャーを務めています。領域としては、ユーザーさんが外食のお店探しに使うtoC向けのWebメディアと、飲食店向けの管理画面や集客支援といったtoB向けのWebシステム、両方を見ています。

池田　私は2019年8月にRettyに入社し、エンジニアリング部門でエンジニアをしています。入社当時はtoC向けの開発をしていましたが、途中でチームを移動して、今はtoB向けの管理画面や、Retty社内の営業が使うツールの開発業務などをしています。

個人的に得意としているのはサーバーサイドですが、業務上はフロントもやりますし、インフラもやるという感じです。

▼【左】常松さん【右】池田さん

常松　エンジニアリング部門には、今、社員としてエンジニア40名弱が在籍しています。その対等な立ち位置にプロダクト部門があり、プロダクトマネージャーや企画職、デザイナーが所属しています。

このように組織としては二つに分かれていますが、実際の開発では組織の壁はなく、一緒に大規模スクラム（以下、LeSS）を回す形で開発をしています。

LeSSは、「組織全体でひとつのスクラムを回すことを考える。その上で、人数が多くスケールが必要なところを工夫する」という考え方です。

▼LeSSの全体像（※出典：https://less.works/less/homepage）

常松　Rettyは2019年からLeSSの導入に取り組み、開発組織の形を変化させてきました。以前は「ネット予約」「検索」といった目的別のチームを組んでいましたが、現在では「みんなで力を合わせて、Rettyというプロダクトにとって重要なことから協力して取り組んでいこう」という組織に変わったんですね。

結果的に、その方がユーザーに早く価値を届けることができますし、お互いに領域をオーバーラップして協力し合うことで、より良い打ち手が見つけ出せるようになりました。

もともとRettyは、「User Happy」にとても向き合っている組織ですが、LeSSを導入したことで、より一層「ユーザーに価値を届けること」に集中できるようになったと思います。

目的別のチームで部分最適が進む中、「LeSS」という選択肢が登場

常松　私が入社した当時のRettyでは、まだエンジニアの大半が企画やプロダクトの部門に所属していて、デザイナー等と一緒に目的別のチームを組んでいました。

例えばネット予約を頑張るチームだったり、SEOを頑張るチームだったり、検索を頑張るチームだったり。やることを絞った上で、そこに各自のリソースを最大限に使って全力投球すれば、結果として成果が最大化されるだろう、という考え方だったと思います。

領域ごとに強く権限移譲をしていたので、裁量はとても高かったのですが、あくまでも自分たちのリソースの中でしかやりくりができない状態で。全社として何を優先すべきかという視点ではなく、自分たちの守備範囲の中で動く、部分最適のような開発になってしまっていました。

結果として、サービス全体としてユーザー体験がちぐはぐだったり、思っていた通りに成長しなかったり、といった課題も挙がっていました。エンジニアとしても、「いまひとつ開発しづらいな」という感覚があったと思います。

一般的に、ある程度関わる人数が多くなれば、サービス単位で組織を分けることは多いですよね。ですが、社外から見れば、どれも同じRettyであることは変わりないはずで。であれば、それぞれが部分最適をしていくことはあまり良くないのではないか、もっと違うアプローチがあるのでは、と感じていました。

これは私だけではなく、私の上司であるVPoEの小迫や、プロダクト部門でVPoPを務める野口なども含めて会話をしていて。その中で出てきたのが、LeSSという選択肢だったんです。

ただ、いきなり全社として体制を移行したわけではなく、まずはそれぞれができる範囲で組織を変えていきました。例えば私は、自分が関与していたWeb開発の1チームがスクラムで四苦八苦していたので、最初はその立て直しから行いました。

そして、徐々に一緒にスクラムを回すチームを2チーム、3チームと拡大していき、最終的には2019年の秋から、全社的にLeSS大規模スクラムの体制へと移行しました。

※LeSSの導入プロセスに関しては、常松さんが書かれたこちらの記事もぜひご覧ください。

プロダクトの整合性が高まり、「Why」と向き合える組織へ変貌

常松　LeSS導入後の最も大きな変化は、「本当にこれがユーザーのニーズにあっているのか、受け入れてもらえるのか」という議論が飛躍的に増えたことです。

それまでは、そもそも企画メンバーの業務の中で、プロジェクトマネジメントの割合がものすごく多かったんです。仕様を決めたり、誰が何を実装するか、進捗はどうなっているか…といったことですね。

ですので、あまり本質的な顧客の課題や体験を考える時間も、余力もなかった。それらが今の体制では開発チームが全部巻き取るようになったので、企画メンバーも「なぜそれをするのか？」というWhyの部分を考える時間をきちんと取れるようになりました。

「とりあえずデザイン変えたいです」「とりあえずバナーを貼りましょう」といったWhyの部分がない話には、早い段階でツッコミが入るようになりましたね。

また、以前のRettyは、作られた時期によって、Webとアプリで仕様やユーザー体験がズレていることがありました。実際にLeSSを始めてから、毎週、全員が集まって1週間の成果物をデモで見るスプリントレビューを行っているのですが、最初の頃は仕様が揃っていなくてちょっと空気が悪かったです（笑）。

池田　そうでしたね（笑）。特にユーザー体験を考えてくださっているデザイナーさんからは「ここが揃っていないのはおかしい」という形で、バチバチ指摘が入っていました。

常松　それまでは、そのズレに気が付かないままサービスを世に出してしまっていたんです。それが今では、みんな横の意識を持って揃えていますし、「ズレていたら直していかないといけないよね」ということが当たり前になりました。

また、LeSSに移行したことが特に力を発揮したのが、コロナ禍で実施されたGo To Eatキャンペーンへの対応でした。

LeSS移行の翌年にキャンペーンが実施されたのですが、その対応を全社の最優先事項にしようということで、開発の優先順位を全部ごそっと入れ替えることができたんです。全員でひとつのスクラムを回しているので、何が最優先なのかが誰にでもわかりやすく、結果として無事にリリースをすることができました。

ただ、実はその後、2020年11月にいったんLeSSをやめてプロジェクト編成型に戻しているんです。その背景としては、Go To Eatキャンペーンが無事にリリースされ、次に何に注力するかという話になった時に、コロナ禍で延期せざるを得なかった開発事項が二つ挙がったのですが、どちらも、Rettyの将来のためにはどうしても時期をずらせなかったんです。

どう進めるかを社内で話し合う中で、LeSSにこだわってるわけではないし、ある程度は属人化させたほうがスピードが出るのは事実なので、いったんLeSSをやめようとなり、開発体制を二つに分けました。

結果的に狙い通りにスピードが出て、共にほぼ期日通りにリリースすることができました。

池田　ただ、当時はみんな担当プロジェクトのスピードを出すことに集中していたので、二つのチームでお互いが何をやっているかはあまり共有されなかったですね。リリースの直前になってくると、お互いに相反する内容もあり、調整にちょっとバタバタしていました。

常松　ある程度、予想はしていたのですが、やはりそうなったなと。そこで、LeSSに体制を戻して、そこからは大きな問題なく開発ができています。

時間をかけて組織が変化。チーム内・チーム同士のコラボも増加

常松　2019年からこれまでを振り返ると、LeSSを導入したことで突然問題が解決したわけではなく、時間をかけて良くなってきたと思います。やはり、最初に馴染むまでには時間もかかりましたし、議論もたくさんありました。

例えば立場の違うメンバーそれぞれが「今は自分たちが最優先だ」と言っている状況で、納得がいくまで議論をすることってなかなか難しいじゃないですか。その点は時間をかけて、話し方や伝え方、議論の仕方を学んできたと思います。うまく回るようになるまでに、1年〜1年半くらいはかかりましたね。

実際、最初に全社員が集まる場所で武田から「開発体制にLeSSというものを導入します」と話をしたのですが、LeSSという言葉だけが独り歩きしてしまって。「私たち、どう変わるんだろう？」とみんなをドキドキさせてしまったこともありました。

池田　私はその時、Rettyに入社して1ヶ月ほどでしたが、LeSSは経験したことがなかったんですよね。そういう人も多かったので社内はザワザワしていましたが、「うまくいかなかったら、やめるよ」ということも併せて伝えてくれていたので、「じゃあ、やってみてダメだったら、そう言えばいいか。とりあえずやってみよう」という感じで考えてはいましたね。

常松　正確には、社内で「LeSSを導入したい」と言ったことは一度もないと思います。今はこのやり方が合っていると思いますが、合わなければ見直します、と言っていましたね。そこは、個別にもかなり話をしました。

ちなみに、最後にLeSSに合流したのが、池田がいるtoB開発のチームだったんです。このチームには当時シニアエンジニアが多く、一人ひとりが自立して動ける職人集団のような存在だったので、最後になったんですよね。

あとでこっそり聞いたのですが、彼らは「LeSSってどうなんだろう」ということで、先にやり方を変えた別のチームとコンタクトを取って、飲み会で話を聞いたらしいんです。そこで全然大丈夫だよ、という話があって、安心したと。

トップダウンで「大丈夫だよ」と言っても、伝わらないことがありますよね。でも、誰かが経験したことだったら、ちゃんとその人の言葉として届くんだなと。これは個人的に面白かったポイントです。

池田　LeSS導入から3年が経ち、現場視点で言うと、導入当初と比べてかなりチーム間のコラボレーションの意識が強くなったと思います。

そもそも入社当時のLeSS導入前は、例えば検索チームに配属されたらその中で仲良くやる、領域外のことはチームが違うからそちらにお願いしてね、という感じだったんです。

そこからLeSS導入によって、そもそもチームの組み方が「検索」などの目的別から、対外的に「同じ」責務を持つスクラムチームを複数作る、という形に変わったんですね。

▼LeSS導入によって、チーム編成が変化（※編集部にて作成したイメージ画像）

池田　最初は、まずチーム内でコラボレーションが起こるようになったんです。例えば、チームの中でバックエンドが捌ききれない時に、フロントエンドが得意な人が手伝う…といった形ですね。

私自身も、もともとフロントエンドの経験はなかったのですが、Rettyに入社してから得意な人に一緒にコードを書いてもらったり、レビューをもらったりしながら学んでいきました。各自が得意領域を持ちつつも、そこにこだわらずに開発していくようになりましたね。それがだんだん、チーム対チームにも広がっていきました。

現状の体制としてはtoCで三つ、toBで三つの六つのスクラムチームがあるのですが、本当に垣根がなくなっていて。この意識は、LeSS導入の初期と比べるととても変わったと思います。

事業として優先したいものに注力する、という意識が全員に浸透したことで、自分のチームがどうだから、というこだわりは関係ないという意識が生まれたのかなと。

結果的にこの3年間で、「この仕様は◯◯さんしか知りません」「◯◯さんしか触れません」ということもすごく減ったと思います。

私の次のチャレンジとしては、チームの垣根がなくなってきたとはいえ、今日の話も含めて、toC、toBという領域別に話をしてしまうことはあるんですよね。私がせっかくtoBもtoCも経験してるので、そこを完全に混ぜることにも挑戦したいなと思っています。

開発組織だけではなく、セールスや人事の領域にもLeSSの影響が

常松　LeSSに関しては、プロダクトが重要だと位置づけていて、それに対してみんなで力を合せてひとつずつ解決していきたい、という課題を持っている会社さんには合うのかなと思います。

導入のコツとしては、小さく始めることですね。最初から「LeSSを取り入れます、組織もそれに合わせて変えます」ではなくて、小さく成功体験を積みつつ、うまくいかないところを直しながら導入していくのが良いと思います。「いきなり全社で大規模に変えます！」という話を聞くこともありますが、すごいギャンブラーだなと（笑）。

現状のRettyでは、このLeSSの考え方が、セールスなどの開発外の組織にもだんだんと広まってきている感触があります。私としても、このやり方を使って全社を変えていきたいなという気持ちもあって。

例えば先日、新入社員向けに行ったアジャイル開発やスクラム開発の研修に、人事、採用のメンバーや、IR執行役員、CFOも参加してくれたんです。そのときはレゴ作りを通して、スクラムやアジャイルの考え方を学んだのですが、エンジニア以外にもとてもしっくり納得感のある研修になったようです。

▼実際に行った「レゴスクラム研修」の様子

※「レゴスクラム研修」については、同社のこちらのnoteもぜひご覧ください。

事業を作っていく上でも採用をする上でも、LeSSのやり方から学べること、横展開できることがあると思っていて。今後は、全社規模でLeSSの良いところを取り入れつつ、良い組織づくりを模索していければいいなと思っています。（了）