LeSS導入からじき2年
 Rettyが経験した改善と悩みについて
 常松祐一
 2021/4/16


自己紹介
 ● 常松祐一 (つねまつ ゆういち) 
 ● SNSアカウント
 ○ tunepolo : 
 ○ tune : 
 
 ● Retty マネージャー 
 ● アジャイルの取り組みは5年目、LeSS導入の取り 組みは4年目
 ● LeSS導入は2社目
 ● Certified LeSS Practitioner(多分失効) 


3 自分にとってBESTなお店が見つかる 
 日本最大級の"実名型"グルメサービス
 レビューよりもレコメンド。 
 Rettyは他人におすすめしたい 
 美味しいお店を投稿するサービス！ 
 食の好みは人それぞれ。 
 自分と嗜好が合う人をフォローして、 
 BESTなお店を見つけられるSNS型！ 
 実名制の口コミだからこそ 
 「信頼できる」「ポジティブ」な 
 情報が集まっています！ 
 批評ではなくオススメの口コミ 
 自分と好みが近い人から探せる 
 顔が見えて信頼できる実名制 


飲食店のオーダー業務をゼロに Rettyが運営する 店内モバイルオーダー Retty オーダー 03-6852-8007 受付時間：平日 11:00-18:30 
 Retty関連サービスのお知らせ お問い合わせ https://lp.self-order.retty.me/

ネット予約 投稿 集客 CS/データ整備 toB開発 運用・バグ 取り組むこと 代表者 代表者 🎍たけのこ 開発チーム2 🐡あんこう 開発チーム3 🍄きのこ 開発チーム1 🥩はらみ 開発チーム4 🍑ももてん 開発チーム5 意思決定者 大規模スクラム? LeSS?


ユーザー価値 決定者 大規模スクラム? LeSS?
 取り組むこと 開発チーム ● 全員で1つのスクラムを回す意識を持つ。
 ● 人数が多く分割・集約が必要なところだけ工夫する。


Rettyの開発プロセスにおける私の立ち位置
 PO BackLog PdM Team PdM Planner Designer PdM Planner Designer Feature Team x 5 ユーザース トーリー 追加 ユーザース トーリー 追加 ユーザース トーリー 並び替え 開発着手 Engineer Team リファインメント SM Engineer SM Engineer Manager &プロセス全体の 問題解決 Engineer SM toC toC toC toB App

この後の流れ
 ● LeSS導入開始から現在までの流れ
 ○ LeSS導入期 2019/6〜2020/3
 ○ Go To EatをLeSSで乗り切る 2020/4〜2020/10
 ○ LeSSをやめプロジェクトを編成 2020/11〜2021/4
 ● 「何を作るか」をどうしたら洗練させられるか


LeSS導入期
 2019/6〜2020/3


RettyのLeSS導入経緯 (1)
 「1プロダクトをみんなで作る！」 Rettyでの大規模スクラム(LeSS)導入記 Rettyの開発組織をぶっ壊して、 LeSSを導入した話をPO視点で書きました

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

まとめると
 ● チーム間の調整が増え、開発が全体の優先順位ではなく、調 整に左右される課題が出た。そこでバックログを一つにまとめ るべきと考え、LeSSを知って導入した。
 ● 「開発スピードが目に見えて落ちている」ことが大きな経営課 題だったので、導入はすんなり進んだ。
 ● とはいえ完璧なLeSSではなく、試行錯誤しながら適用範囲を 広げている。


部門長 BackLog PdM Team Analyst Team PdM Planner Designer PdM Planner Designer SM Engineer Engineer Feature Team SM Engineer Engineer Feature Team SM Engineer Engineer Feature Team user story add user story add user story sort analysis support analysis support user story get Engineer Team Feature Team Engineer Engineer SM refinement refinement 【部門長・PO】 何を(何から)作る かに最終責任を 持つ 【開発チーム】 どう作るかに責任 を持つ 【SM】 開発プロセスの遵 守に責任を持つ 【PdM・Planner・Designer】 どんなユーザ価値を提供するの か考え抜く

開発サイクル
 月 火 水 木 金 午前 お昼休み 午後 スプリントレ ビュー チーム 振り返り スプリント プランニング リファインメント 優先順位のす り合わせ 振り返り 共有会 チーム朝会 チーム朝会 チーム朝会 チーム朝会 リファインメント リファインメント リファインメント

導入期で大変だったこと


Go To EatをLeSSで乗り切る
 2020/4〜2020/10


Go To EatをLeSSで乗り切る
 Go To Eatキャンペーンでの神対応はどのようにして生まれた か？ Rettyのプロダクト開発と組織改革の裏側 Go To Eatキャンペーンを支えたプロジェクトマネジメント

※農水省キャンペーンページより転載 https://gotoeat.maff.go.jp/ Go To Eatキャンペーンの概要


プロジェクト規模
 ● 携わったエンジニア数 : 26名
 ● 開発期間 : 3〜4ヶ月
 ● 開発項目
 ○ [toC]キャンペーンページの用意
 ○ [toC]キャンペーンの仕組みに合わせたネット予約の改修
 ○ [toB]ポイントの管理・発行・消化
 ○ [toB]お店からのキャンペーン申し込み画面
 ○ [toB]お店側がみる管理画面の修正。来店確認・支払管理など
 ・・・とにかく”たくさん”


Go To EatをLeSSで乗り切る
 ● バックログを全てGo To Eatキャンペーン関連のものに差し替え
 ● 全体設計・仕様整理を行った後、各チームが優先順位にしたがって粛々と 実装を進めた。
 ● toBの開発項目が多かったが、toCチームに管理画面の構築など難易度の 低いものをとってもらい負荷を調整
 ● フィーチャーフラグで表示を塞ぎ、スプリントごとのリリースを続けた。全部 揃ったところで検証し、2020/10/1に時限式でフラグが外れるようにした。


リリース後に起きたこと
 ● ユーザー問い合わせ数の急激な増加
 ● システム負荷の急激な増加
 ● キャンペーン予算消化のため11月上旬にクーポン付与が終了
 → 全社で優先順位を共有し、順次対処


まとめると
 ● 「LeSS導入を進めていなければGo To Eatキャンペーン開発 は乗り越えられなかっただろう」という社内評価
 ● toCとtoBのWeb開発で交流が進んだ
 ● リリース後に問い合わせが増えたり、負荷が高まったり、キャ ンペーンが想定より早く終了することがあったが、バックログ の優先順位を見直すだけで対応できた。


LeSSをやめプロジェクトを編成
 2020/11〜2021/3


LeSSをやめプロジェクトを編成
 ● コロナ禍で開発を延期していたビジネス要件からくる締め切りありきの大物 が2つあり、素性が大きく異なるためプロジェクト別にチームを組む体制に 一旦戻した。
 ○ プロジェクト1 : 旧来システムの拡張、PHPモノリス + 外部サービス連 携
 ○ プロジェクト2 : 新システム基盤への置き換え、Nuxt.js + GraphQL + Go/Kotlin Microservice + gRPC


LeSSをやめてどうだった?
 ● Pros
 ○ 多少の遅延はあったが、両プロジェクト無事に完遂できた。 
 ○ メンバーを固定したことで習熟が早く進み、スピードを出すという主目的は達成できた。 
 ○ 企画・デザイン・開発のプロジェクト内に閉じた連携がスムーズにできた。 
 ● Cons
 ○ プロジェクトを超えた連携に課題 
 ○ リリース前に連携箇所の見落としが起きるなど、コミュニケーションの問題が発生した。 


いったんまとめ
 LeSS導入状況と効果


LeSS導入状況
 ● 5チームで3つのプロダクトバックログを持っている。
 ○ toC Web x 3、App、toB Web
 ● Rettyのメイン開発はLeSSだが、それ以外も残っている。
 ○ 広告関連、新規事業(Retty Order)、データ基盤、データ分析、インフラ
 ● チームで取り組み、振り返りを行って改善していこうという文化はほぼ全 チームに定着した。


LeSS導入による効果
 ● 開発に関する恒常的な悩みが減った。0になったわけではない が、急ぎ対処しないとまずいものが無くなった。
 ● チーム開発の意識が浸透し、属人化が解消に進む。
 ● 複数チームに跨がる技術課題に取り組みやすくなった。
 ● 開発プロセスが全体で揃い、優先順位の上げ下げのみで全 社の方向性を揃えやすくなった。
 ● 人員が増えても開発が回るイメージが持てている。


「何を作るか」をどうしたら洗練させられるか


リファインメントがうまくできない問題


PM内で工数見積もりしてもらうことが目的化し、開発物が洗練されていない中で見積もりを依頼される エンジニアとPMが険悪なムードに。 工数見積もりを行わないと開発ラインに載せるこ とができないため、開発物を洗練することよりも工 数を見積もることが目的化。 PMの状況 ① 必要性 解決するべき問題なのか わからない ② 妥当性 最適な解決策なのか わからない ③ 実現性 　最適な詳細要件なのか わからない PMは急いで見積もりを要求するが、実際は上記い ずれかのパターンで認識が揃わず、見積もりの段 階にまでに到達できない。 認識が合わない3つのパターン 絶対見積もりして もらうぞ!! リファインメントがうまくできない問題


何が原因だったのか?
 ● リファインメントのメンバーが毎回変わるため、ちょうど良い塩梅の説明が 掴めない。
 ● 企画担当者の理解が足りず、「なぜやりたいのか」に答えられない。
 ● PdMから企画担当者への権限移譲が十分にされておらず、どう実現する かに相談の余地がない。
 ● 施策を多角的に(批判的に)検討する文化が無い
 ● 初期段階からエンジニアを巻き込む・相談するスキルが不足。
 ● 司会が不在、企画と開発の人数比が崩れている、ステークホルダー不在 で議論が長期化


「なぜ?」に向き合える組織へ
 ● リファインメントの仕組みを変更
 ○ 「相談のみ」が宣言できるようルール化
 ○ 司会を決める、人数上限を設ける
 ○ リファインメントの目的をこまめに周知・説明
 ● 企画部門のスキル向上
 ○ 施策の壁打ち会を定期開催
 ○ 「プロダクトマネジメント」本の読書会
 ○ スキル定義、評価制度の整備


プロダクトマネジメントをRettyの開発組織にインストールした話


中長期の計画をどう意識するか
 ● 直近ばかり意識が向き、中長期に意識が向かない。
 ○ スプリント開始に合わせて細かな施策が滑り込んでくる
 ○ 締め切りのある開発が重なってしまう。
 ユーザー ストーリー マッピング 向こう3ヶ月の予 定を共有 Spotify Rhythm (Bets) 2019/10 2020/2〜3 2020/4

プロダクトロードマップの策定
 2021年3月以降の開発優先度について議論→可視化していく。 プロダクト・事業にとってあるべき姿を描いた上で、大まかな優先度やいつ頃開発していく かを摺合せておきたい。 2イテレーション以上かかるような開発工数が大きく、複雑性が高いものの 優先度を議論していきたい。 代表者として、主にPM、EM、営業企画、事業企画で進めていく 1イテレーションの中で完結する小規模の 施策・運用・不具合対応は バックログの中で都度判断していく。

マネージャー間で認識を合わせる
 どの山に登るか、どのくらい大変なのか、
 どの登り方が良いのかを擦り合わせたい
 1日合宿を実施


まとめ


まとめ
 ● LeSS導入により、開発に関する恒常的な悩みが減り、本質的 な課題に向き合う余裕ができた。
 ● 「何を作るか」を洗練させる仕組み作りはまだ道半ば。
 ● 長期で取り組む必要がある。自分がアジャイルな考え方を知 り変わっていったのと同じだけの時間を、今学んでいる人にも 用意する必要がある。


Q&A


Q1: オーバーオールレトロのやり方
 ● 振り返り共有会 (毎週30分)
 ○ チーム代表(SM) + マネージャーが参加
 ○ チーム内で解決できない課題をエスカレーション
 ● スクラムイベントフィードバック相談会 (隔週30分)
 ○ マネージャーが参加
 ○ チームのパフォーマンスに対してFBを話す


Q2: POのふるまい (RettyのLeSS PO = VPoP, 執行役員)
 ● バックログの優先順位決定について責任を持つ
 ○ バックログにアイテムを自ら積むことはしない
 ○ プロダクトの各領域を検討するPdM/企画担当と会話し、バックログアイテムの 並び替えをする。
 ○ 勝手にバックログアイテムが並び替えられるのを叱る
 ● 最近は中期計画の立案と直近の開発との整合性担保に時間を使っている。
 ● 迷ったら最後はPOが決めるのはRettyも同様だが、「事業インパクト×リスク」の優 先度マトリクスを導入するなどして、優先度を決めるルールを組織知にする動きを 試行錯誤中


Q3: Outcomeの検証
 ● スプリントレビューで企画担当者からリリース後しばらくして発 表してもらうようにしている。
 ● 週1回の全社会議でサマリを共有するようにしている。
 ● POがアウトカムを細かく聞いて回っている


Q4: 目標管理
 ● 組織目標(部門目標)
 ○ 複数チームで共通
 ○ 3ヶ月毎に見直す、大きくは変わらない
 ● 個人目標
 ○ 全員ほぼ共通、公開する
 ○ 3ヶ月毎に見直す、あまり変わらない
 ● 個人課題
 ○ 個人ごとに固有、非公開
 ○ 業務グレードが変わらない限り変わらない