Retty Tech Blog

実名口コミグルメサービスRettyのエンジニアによるTech Blogです。プロダクト開発にまつわるナレッジをアウトプットして、世の中がHappyになっていくようなコンテンツを発信します。

「全社で大規模スクラム(LeSS)移行して1年間」 #RSGT2021 での質問に、Retty執行役員が全て答えました

Rettyのプロダクト部門担当執行役員の野口です。 Regional Scrum Gathering℠ Tokyo 2021にて、書籍「大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法」の翻訳者の水野さんをモデレーターに迎え、Retty VPoEを務めるエンジニアリング部門担当執行役員の小迫とパネルディスカッションをさせてもらいました。 テーマは大規模スクラム Large-Scale Scrum(LeSS) のRetty導入事例の紹介です。

2021.scrumgatheringtokyo.org

confengine.com

いくつかレポートを書いていただきました。ありがとうございます!

qiita.com

qiita.com

45分間のセッションでしたが、Discordにて40問近くの質問を頂き、いくつかは時間内に回答いたしました。しかし残念ながらお答えできなかったもの多数。回答できなかったもの含め、改めて本テックブログにて回答していきます。

LeSS導入の概観については、LeSSの導入をリードし、また今回プロポーザルを出すことを提案してくれたエンジニア部門マネージャーの常松の記事をご覧ください。 engineer.retty.me

野口がLeSSのPO観点で書いた記事も貼っておきます。 note.com

導入のきっかけ・動機

[質問]LeSSを導入したモチベーションってなんですか?

50人規模の開発でチーム間の調整が増え、開発が全体の優先順位ではなく、調整の上手さに左右される課題が出ました。そこでバックログを一つにまとめるべきではないかと考えていた際、偶然LeSSの事例を見てピンときたため、導入することになりました。

[質問]大規模スクラムを意識し始めたのはどんなタイミングでしょうか?

19年10月からLeSSを導入していましたが、19年4月〜6月に小迫が課題を整理→常松前職事例を聞いて導入を決定。野口も同時期にRepro社の導入事例を聞いて、ピンと来たのがたまたまLeSSでした。

[質問]もともとスクラムはやっていたんですか?どういう開発プロセスでしたか

何度かチーム単位でスクラムに取り組んだりしていましたが、あまりうまく定着していませんでした。そのためむしろスクラムに対する拒否反応もありましたが、LeSSに移行する事前準備として1チームからスクラムをきちんと導入し直しています。「期限を区切ってうまく行かなかったらもとに戻します」という宣言つきだったので、試しに受け入れやすかったと思います。

導入の検討段階

[質問]数あるスケーリングフレームワークからなぜLeSSなのでしょう?

Rettyという1プロダクトを開発しているため、「1つのバックログでプロダクト全体思考」という志向性との相性が良かったことがポイントです。また、大規模スクラム本が翻訳されて勉強しやすかったのもポジティブでした。

[質問]導入の際、SAFeとLeSSの比較とかされました? LeSSを選択された決め手はなんですか?(水野さんの顔を見てて、なんとなく聞いてみた次第)

軽いチェックはしましたがそれほど比較はしていません。LeSSにすることが明確なゴールで開始しているわけではなく、その時の状況によって判断・改善を進めた結果LeSSを選びました。詳細な理由は前述の通りです。

[質問]LeSS導入に対する費用対効果を経営に理解してもらうために、どのようなステップで説明をしていきましたか?

このままの体制ではサービスの成長を支えることができなくなること、それが何故か?を整理してまとめました。次に社内の複数人と壁打ちを行い方向性が合っていそうなことを確かめた上で、こうしていくとなんの課題が解決し、どんな効果が想定できるかをまとめて説明を行いました。

[質問] 優先順位が機能しないやカニばるという問題の解決に対してLeSSの導入というソリューションはとても大きすぎる活動のような感覚を持ちました。経営陣に対してもし他のアウトカムを提示していればぜひ知りたいです!

  • 開発スピードが目に見えて落ちていたので、大きく改善されるイメージを示した
  • エンジニアをエンジニアがマネジメントする体制(PM組織と切り離す)ことによるエンジニアのモチベーション・定着率アップ

双方、開発だけでなく、経営課題として大きなものだったので、LeSS導入すべきだという意思決定にすんなりなったのだと思います。

LeSS導入段階

[質問]よく単体のスクラムチームで回ってない状態からいきなりスケールは無理、みたいなこと言われますが、実態としてはどうでしたか?

仰る通り、まずは1チームでスクラムのプロセスを確立させました。そこから2チーム目→3チーム目と広げていきました。

[質問]LeSSを導入するのはアジリティの向上が目的の1つにあるかと思います。またアジリティを上げるために複数チームPBR(プロダクトバックログリファインメント )などを通して学習すると思います。アジリティをあげるためにそれなりに学習コストがかかるかとおもいますが、アジリティと学習コストのバランスはどのように考えていますか?

導入した最初の四半期はある程度スピードが上がらないのは仕方ないと考えていました。LeSSのチームを四半期に1チームずつ増やすことで、会社全体としてのスピードを落とさない工夫をしたくらいですね。

[質問]LeSS導入以前は分業のようなスタイルだったとのことですが、バックログをひとつにしたところで、その後のタスク分解時にはまた各役割ごとのチームにタスク配分されるイメージですか?それとも、LeSSに合わせて横断的な開発チームを編成しなおしましたか?

LeSSに合わせて横断的な開発チームを編成しなおしましたが道半ばとも言えます。toC向けWebはチームの役割がほぼなくなりましたがtoB向けWebやtoC向けアプリはまだチームの役割が残った状態です。とはいえ役割をなくすことがゴールではなく、Rettyにとって・働くメンバーにとって良いやり方を模索していきます。

[質問]評価の方法はどのように変化しましたか?

以前はリリースの期限や件数に依存しており、「リリースn件、n日までにリリース」のような目標でした。 現在はPM側はリリース物による数値や体験変化の効果、エンジニアは開発着手からリリースまでの期間や、四半期単位での大きな障害数など定量的で技術観点を含む目標を設定しています。

[質問]PBを一つにするところから全社にLeSS導入するまでにどれくらいの期間を要しましたか?また、それは当初予定いた期間で移行できましたか?

ほぼ一年です。想定した期間もほぼ一年でしたので大きなズレはありませんでした。

[質問] キャリアの話がここでも出ましたが、どのようなキャリア計画だったのでしょうか?

  • スクラムマスターを希望者中心にアサインした。
  • 将来的には分析アナリストやエンジニアからPMへの異動も増やしていく などを考えています

[質問] 元々のチームによって、持っている技術スキルが異なるという状況なのかと思いますが、優先順に案件対応するためには、今まで使っていなかった技術が必要になってくると思います。

フィーチャーチームを構成し、開発チームに少しずつ触ってもらう領域を広げてもらいました。当然最初はパフォーマンスが落ちることが起きましたがそれを許容し、学習する時間をきちんと与えました。

そういった技術をお互いに学んだりするためにしたことはありますか?

全社員が集まる会議でもなぜ、LeSSを導入するか、どんなビジネスインパクトがあるかを話し合いました。その他、関係のある部署毎に都度説話し合う場を持つようにしました。

[質問] 組織変革を起こそうと思うと一人ひとりの当事者意識が必要だと思いました。LeSSに至るビジネスの課題感は開発者から見た視座では課題を認識できてなかったのではないかと思いました。経営者から開発者まで課題を共有するような活動はありましたか?

全社員が集まる会議でもなぜ、LeSSを導入するか、どんなビジネスインパクトがあるかを話し合いました。その他、関係のある部署毎に都度説話し合う場を持つようにしました。

[質問]LeSSの導入を初めて軌道に乗ったなと感じるまでどのぐらいの期間かかりましたか?その間の一時的なパフォーマンスの落ち込みはどう扱いましたか?

3ヶ月くらいで、スクラムイベントも含めて軌道に乗りました。一時的に落ち込むのはしょうがないので、落ち込むことを盛り込んで計画を立てていました。

執行役員の方がアジャイルマインドをお持ちであるからこそトップダウンで組織的な動きが起こしやすかったのだろうか

それはあると思います。経営層やステークホルダーアジャイルマインドで洗脳していくのは大事そうです。

[質問]Rettyさんではどのようなチーム割にしたんですか?エリアの例を知りたいです。(例えば検索機能などの機能単位なのか、画面などのUIでエリア切っているのか)

エンジニア側

Web、アプリ、管理画面がそれぞれ得意なチームとして分けています。 ただそれぞれのチーム名に引きずられた開発のアサイン・それに伴う属人化を防ぐため、たけのこ、きのこ、あんこう、はらみ、ももてんという名前をつけています

PM・デザイナー側

体験ベースの投稿、ネット予約、検索に加えて、プロモーションやSEOを担当する集客などで分けています。

f:id:rettydev:20210110221407p:plain

[質問] 執行役員の方はアジャイルマインドをとてもお持ちである印象です。組織変革を行う中でマインドの違いによる難しさに直面しましたか?例えば、プロダクト価値の最大化ではなく言われたものを早く作るマインドでいる開発者などです。

開発メンバーは比較的アジャイルの志向性がフィットするメンバーが多く、大きな課題はありませんでした。

一方でこれまでのビジネス関連開発では、営業要望をベースに開発物を決めていた傾向がありました。期日とアウトプットが優先されがちでした。ここは最初は大きく変えず移行し、徐々にスプリントでの達成したいゴールを明確にしながら摺合せていくような形をとっていきました。今後は中期的に実現したい価値やストーリーを言語化して、プロダクトロードマップに落としていく運用を考えています。

[質問]スクラムチームを増やしていくペース(期間と数の推移)はどれくらいでしたか?

四半期に1チームのペースです。

LeSS運用・開発していく上での注意点

[質問]2つのアプリを1つのスクラムで扱うことの課題と対策について伺いたいです。優先付けや整理の判断の難しさを感じています。

2つのプロダクトを1つのバックログで扱うと優先順位が明確になることはメリットです。しかし、一方のプロダクトのみバックログで優先されがちになる恐れがあります。Rettyでの対策としては、四半期や半年で達成したいゴールイメージを明確にし、それに沿ったバックログの作り込みを行うことを進めています。 Rettyではこれからですが、中期的なロードマップの作り込みも有効かと思います。

[質問]元々複数いたPOはLeSS導入後にどうなりましたか?LeSSのPOにならなかった人たちから反発はありませんでしたか?

PMとして、ネット予約、投稿など体験ベースで区切られた範囲のユーザーストーリー作成・優先順位検討・ロードマップ作りを担当しています。PO一人では全ての施策を見切れないため領域を絞って委任しています。

うまくいくのか?各チームの意見が吸い上げられないのでは?という懐疑的な声はもちろんありましたが、現状の課題点を説明し、こうありたいという話をきちんとした結果、疑問は当然残ったものの大きな反発はありませんでした。

[質問] LeSSは単一のプロダクトやサービスを大規模に開発するのに向く気がしていて、Rettyさんはそういうビジネスな気がしてるのですが、そういうマッチはあるでしょうか? もし、まったく従来サービスと独立した新しいサービスを作るとしたら、現行のLeSSの体制の中に組み込めそうでしょうか?

向き不向きでいくと向いていたのが選択した理由です。新しいサービスを作る際にLeSSに組むこむことはできるとは思うますが、おそらく別チームに切り出します。実際に新規事業として取り組んでいるRetty OrderはLeSSのサイクルから切り離して開発を進めました。 理由としてはいくつかありますが優先順位が比較しにくいこと、開発のサイクルが合わない可能性が高いこと、最初のうちは属人化はむしろある程度許容すべきだと思っているからです。

[質問]LeSSを導入すると組織規模が大きくなるので、1チームのScrumに比べて開発プロセスのチューニング(プラクティス導入など)の意思決定の難易度が上がりそうな気がしているのですが、そのあたり改善サイクルにおける課題はありましたか?(小さく実験するのが大切だと思いますがとはいえ影響範囲が大きいと思うので・・・)

基本的には全体で決まっているプラクティスは少なくしておき、それ以外はチームにゆだねています。各チームの代表が集まるふりかえり(KPT)の共有がありますので、良かったものはそこで共有され、他チームにも波及して全体に広まっていたということが起きています。また、うまくいっているスクラムイベントの見学なども推奨しています。

[質問] 開発やエンジニアリング以外の職種、サポート、営業、管理職などはLeSSのなかでどういう位置づけにありますか? 仕事のやり方や内容に変化はありましたか?

バックログの優先順位決めにおいて、ビジネス側の開発物については、営業企画とプランニングMTGの前に打合せるようにしています。また開発の成果物を共有するスプリントレビューには、開発メンバー全員に加えて、CSメンバーも参加します。 その他の社員には、週1の全社会議で1週間のスプリントのゴールを共有しています。

[質問]具体的なスプリントでの運用って聞けたりしますか?

f:id:tune:20210111085835j:plain

基本に忠実に1週間スプリントで回しています。

  • プランニング事前MTG:PM、エンジニアリングマネージャーでスプリントに入れるストーリーを相談しPOが決定。スプリントのゴールの設定
  • プランニングMTG:各チームにユーザーストーリーを振り分けた後、チームがタスク分解する
  • スプリントレビュー:チームごとにスプリントの成果物を全員にデモ共有→フィードバックをMeetのチャットで集める
  • 振り返り会:各チームでKPT
  • リファインメント:毎日30分固定の時間を設け、やりたい人が依頼する。チーム横断で見積もりする。

その他、デイリースクラムを別途チームごとに開催

基本的には教科書や原理原則に則り、適宜振り返りで良いものに少しずつアップデートしています。

[質問] (ふりかえってみて)導入は小さく始めるのが良い、or 全社一気に のどちらが良いと思われます?

Rettyは小さく始めたのですが、今振り返っても「一気にではないほうが良かった」と思います。 小さな成功事例を聞いて、他のチームでもじゃあやってみようかという雰囲気になっていました。

[質問]各チームの振り返り内容の共有が上手くいっているようですが、具体的にどうやっていたのでしょうか?

基本的にはKPTをベースにしています。加えて、あるチームで効果的だったトライを他のチームに展開することは比較的うまくいっていると思います。

[質問]各チームごとのPOが居ないことで、PO不在な感じの状況(意思決定が遅くなる、曖昧になる)なんてことは無いですか?

セッション内で伝わりにくかったかもしれませんが、PMデザイナー組織側は各チーム毎の意思決定者として、PM(プロダクトマネージャー)を置いています。

[質問]一度編成したチームのメンバー変更(増減含め)は結構ありましたか?(特に導入初期)チームの成熟度は、導入後どのような推移をたどりましたか?

頻繁ではありませんが、四半期毎に多少(各チーム1〜2名程度)の入れ替えはあります。LeSSでうまくいっているチームのメンバーが新しくLeSSを導入するチームに参画し、ノウハウを広げる動きをしてくれる場合もあります。

[質問] もともと優先順位が機能してなかったという問題があったと聞きました。取り組みたいビジネステーマに対して開発チームが大きすぎる小さすぎるといったリソース効率に対する課題感はありましたか?課題感があるなら人の移動はどのようにするべきと考えていますか

開発チームの大小よりも取り組むべきテーマが多数あって、それを兼務、ヘルプしながら複数チームで対応していたが故に、優先順位をつけられていなかったことが問題でした。 対策としては、「1. 優先順位をシンプルにする」「2. チームを横断する開発でも、人のアサインを変えたり一部の人間がヘルプに入るのではなく、基本的にチームとチームで協力して開発できるようにする」でしょうか。

[質問] 職種ごとのチームだと、エンジニアはトップダウン感があるように感じてしまう方もいるのでしょうか。そうならないようにされている施策や工夫があれば知りたいです

チームを分けたことによる職種毎の壁はまさに課題です。リファインメントで要件をガチガチに固める前にエンジニアとユーザーストーリーや仕様を揉んでいけるようにするなどの工夫を進めているところです。

[質問] PMと開発でチームが分かれてるとのことですが、PMと開発でストーリー優先度や具体開発内容の不一致が起こったりしないのでしょうか?また起こった場合はどう対処してるのでしょうか?

勿論PM-開発間だけでなく、PM同士やPM-営業でも、不一致は起こります。プランニング準備MTGなど優先順位を話し合う場で都度解消するようにしています。またQ毎に各PJで実現したいゴールを作成して共有し、そこに向けて協働するよう工夫しています。

導入後の成果や課題

[質問]実際にやってみて感じた思わぬメリット、または思わぬ課題ってありましたか?

本質的な議論が各所で増えました。課題をきちんと声を出して解決することが増えた → 自己組織化が進んだイメージです。 思わぬ課題としては、現状では小さいのはありますが、大きいのは前述のような想定していた範囲です。

[質問] 新しい機能やエンハンスをリリースまでのリードタイムに変化はあったのでしょうか?

開発物によりますが、「1. PJ開始までの工数調整の時間」「2. チーム間で仕様の抜け漏れを確認・リカバリーする時間がなくなったもしくは大幅に減った分リードタイムが速くなった実感」があります。

[質問]導入にあたって、想定していた難しさ、ここは想定外だった難しさ/現在進行で直面中の課題などはどのようなのがありますか?

想定していた難しさ

かつてのエンジニアリソースを持っていたマネージャー(PO)、営業、エンジニアの反発 小さく導入したチームの成果を見せながら、徐々に話しながら解決していきました。

想定外の難しさ/現在直面している課題

  • エンジニア-PMのコミュニケーションやリファインメントの質の向上
  • よりアウトカムを上げるために、エンジニアとPMでいかにユーザーストーリーをブラッシュアップしていくか

[質問]現在、抱えている開発組織の課題(特に開発プロセス面で)はなんでしょうか?

  • エンジニアーPMのコミュニケーションやリファインメントの質の向上
  • よりアウトカムを上げるために、エンジニアとPMでいかにユーザーストーリーをブラッシュアップしていくか

[質問]LeSSチームとLeSSじゃないチームとの協働してるとおっしゃってましたが協働部分に関して課題が生まれそうなイメージです。どんな課題が生まれたか、そして解決できた課題と現在も解決に向けて取り組んでいる課題があれば教えてください。

  1. CSなどLeSS外から不具合報告をプロダクトバックログアイテムに追加しにくい LeSSのフレームワークをがちっと固めた故に、LeSS外の人がプロダクトバックログアイテムを追加しにくいという問題が出ました。以前はCSメンバーも不具合報告を気軽にバックログに追加していたのですが、LeSS導入に伴い運用フローを固めたため、スクラム外メンバーが関わりにくくなりました。 PMが間に入って、CSや営業から吸い上げ、バックログに追加するようにしていますが、さらに連携はスムーズにしていきたい点です。

  2. LeSSのPOが優先順位を決定するので、営業要望が反映されないのではないかという懸念が生まれた 各種要望を踏まえて優先順位を決定する旨を説明しました。運用としては、営業との共有MTGで、開発物を協力して決定していくようにしています。

今後に向けて

[質問]そろそろLeSSに拘らず「こういうことしたいなー」ってことありますか?

会社としての中期計画のアップデートに合わせて、プロダクトのロードマップに落としていくことを思考中です。またRettyのデータを活かした体験改善にも着手していこうと思っています。

いかがでしたでしょうか

たくさんの熱量の高い質問ありがとうございました! Rettyの開発組織はこれが完成形ではなく、これからも進化していきます。ユーザーさんにより良いプロダクトを届けられるよう改善を続けていきます。

水野さん改めて素晴らしい機会をありがとうございました! (撮影の時に限り、マスクを外しております) f:id:rettydev:20210110224209j:plain:w400

そして、今回のRSGT2021はオンラインとオフラインのハイブリッドイベントでした。感染症対策を行ってのオフラインと映像配信やDiscordで交流するオンラインを両立することは非常に難しかったと思います。しかしながら、今後のテック業界のコミュニティ活動にとっては素晴らしい先例になったのではないでしょうか。運営の皆様ありがとうございました!

最後に、Rettyでは開発メンバー始め、様々な職種で新たな仲間を募集しております!ご興味ある方はぜひ一度カジュアルにお話しましょう!

hrmos.co