Slide 1

Slide 1 text

ユニコーン企業の働き方を目指して - Rettyで の2年間の取り組みをギュッと紹介
 常松祐一
 2021/6/13


Slide 2

Slide 2 text

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


Slide 3

Slide 3 text

ユニコーン企業のひみつ読みましたか?
 "ユニコーン企業のひみつ"のここがオススメ!

Slide 4

Slide 4 text

今日の話の背景


Slide 5

Slide 5 text

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


Slide 6

Slide 6 text

2年前の課題感


Slide 7

Slide 7 text

プロジェクトの成長が全体の成長に結びつかない
 【理想】 ● プロジェクトに権限と自由を与え、個別 に目標を追求する 【現実】 ● 仕様のずれ、タスクのお見合い ● 調整が増加、意思決定の遅れ ● サービス全体に望ましい意思決定がで きない ● 結果としてかえって自由度が低い Web App 投稿 CS データ 整備 集客 toB 開発 ネット予 約

Slide 8

Slide 8 text

社外から見たら”Retty”と認識される1つのサービス
 https://less.works/jp/less/principles/whole-product-focus.html 


Slide 9

Slide 9 text

プロダクトとしてベストな意思決定を行う
 ● プロジェクトやデバイス、機能別での改 善ではなく、プロダクトとしてどうユー ザー価値を実現するべきかを改めて意 識する ● 取り組むことを1つにまとめ、Rettyとい うプロダクト全体としてベストな意思決 定を行なっていく Web App 投稿 CS データ 整備 集客 to B 開発 ネット予 約

Slide 10

Slide 10 text

ユーザー価値 決定者 目指した働き方 - 大規模スクラム(LeSS: Large Scale Scrum)
 取り組むこと 開発チーム ● 全員で1つのスクラムを回す意識を持つ。
 ● 人数が多く分割・集約が必要なところだけ工夫する。


Slide 11

Slide 11 text

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


Slide 12

Slide 12 text

LeSS導入期
 2019/6〜2020/3


Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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


Slide 16

Slide 16 text

部門長 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】 どんなユーザ価値を提供するの か考え抜く

Slide 17

Slide 17 text

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


Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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


Slide 20

Slide 20 text

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


Slide 21

Slide 21 text

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


Slide 22

Slide 22 text

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


Slide 23

Slide 23 text

LeSS導入による効果


Slide 24

Slide 24 text

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


Slide 25

Slide 25 text

「なぜ?」に向き合える組織へ


Slide 26

Slide 26 text

見積もり(リファインメント)がうまくできない問題


Slide 27

Slide 27 text

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


Slide 28

Slide 28 text

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


Slide 29

Slide 29 text

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


Slide 30

Slide 30 text

アウトカム主導組織への道はまだ半ば
 ● 何をやったか(アウトプット)ではなく、何を達成できたか(アウトカム) を軸に考える
 ○ 毎週の開発ゴールをアウトカムで記載
 ○ 毎週の全社会議で学んだこと・アウトカムを共有
 ○ 毎週開催する開発デモの後にディスカッション時間を設定
 ● 企画・デザイン・開発は少しずつ根付いてきたが、全社(総務・営業 含む)となると、まだまだこれから。


Slide 31

Slide 31 text

まとめ


Slide 32

Slide 32 text

まとめ
 ● LeSS導入により、開発に関する恒常的な悩みが減り、本質的 な課題に向き合う余裕ができた。
 ● アウトカムに向き合う組織づくりはまだ道半ば。