Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

ユニコーン企業の働き方を目指して - Rettyでの2年間の取り組みをギュッと紹介 / Tow...

ユニコーン企業の働き方を目指して - Rettyでの2年間の取り組みをギュッと紹介 / Toward a Unicorn Company Way of Working

【オンライン】JBUG広島#8 広島でWorldのおかわりじゃ! の登壇資料です
https://jbug.connpass.com/event/215111/

Yuichi Tsunematsu

June 13, 2021
Tweet

More Decks by Yuichi Tsunematsu

Other Decks in Business

Transcript

  1. 自己紹介
 • 常松祐一 (つねまつ ゆういち) 
 • SNSアカウント
 ◦ tunepolo

    : 
 ◦ tune : 
 
 • Retty マネージャー 
 • アジャイルの取り組みは5年目、LeSS導入の取り 組みは4年目
 • LeSS導入は2社目
 • Certified LeSS Practitioner(多分失効) 

  2. 5 自分にとってBESTなお店が見つかる 
 日本最大級の"実名型"グルメサービス
 レビューよりもレコメンド。 
 Rettyは他人におすすめしたい 
 美味しいお店を投稿するサービス! 


    食の好みは人それぞれ。 
 自分と嗜好が合う人をフォローして、 
 BESTなお店を見つけられるSNS型! 
 実名制の口コミだからこそ 
 「信頼できる」「ポジティブ」な 
 情報が集まっています! 
 批評ではなくオススメの口コミ 
 自分と好みが近い人から探せる 
 顔が見えて信頼できる実名制 

  3. プロジェクトの成長が全体の成長に結びつかない
 【理想】 • プロジェクトに権限と自由を与え、個別 に目標を追求する 【現実】 • 仕様のずれ、タスクのお見合い • 調整が増加、意思決定の遅れ

    • サービス全体に望ましい意思決定がで きない • 結果としてかえって自由度が低い Web App 投稿 CS データ 整備 集客 toB 開発 ネット予 約
  4. ユーザー価値 決定者 目指した働き方 - 大規模スクラム(LeSS: Large Scale Scrum)
 取り組むこと 開発チーム

    • 全員で1つのスクラムを回す意識を持つ。
 • 人数が多く分割・集約が必要なところだけ工夫する。

  5. ネット予約 投稿 集客 CS/データ整備 toB開発 運用・バグ 取り組むこと 代表者 代表者 🎍たけのこ

    開発チーム2 🐡あんこう 開発チーム3 🍄きのこ 開発チーム1 🥩はらみ 開発チーム4 🍑ももてん 開発チーム5 意思決定者 目指した働き方 - 大規模スクラム(LeSS: Large Scale Scrum)

  6. 部門長 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】 どんなユーザ価値を提供するの か考え抜く
  7. プロジェクト規模
 • 携わったエンジニア数 : 26名
 • 開発期間 : 3〜4ヶ月
 •

    開発項目
 ◦ [toC]キャンペーンページの用意
 ◦ [toC]キャンペーンの仕組みに合わせたネット予約の改修
 ◦ [toB]ポイントの管理・発行・消化
 ◦ [toB]お店からのキャンペーン申し込み画面
 ◦ [toB]お店側がみる管理画面の修正。来店確認・支払管理など
 ・・・とにかく”たくさん”

  8. Go To EatをLeSSで乗り切る
 • バックログを全てGo To Eatキャンペーン関連のものに差し替え
 • 全体設計・仕様整理を行った後、各チームが優先順位にしたがって粛々と 実装を進めた。


    • toBの開発項目が多かったが、toCチームに管理画面の構築など難易度の 低いものをとってもらい負荷を調整
 • フィーチャーフラグで表示を塞ぎ、スプリントごとのリリースを続けた。全部 揃ったところで検証し、2020/10/1に時限式でフラグが外れるようにした。

  9. PM内で工数見積もりしてもらうことが目的化し、開発物が洗練されていない中で見積もりを依頼される エンジニアとPMが険悪なムードに。 工数見積もりを行わないと開発ラインに載せるこ とができないため、開発物を洗練することよりも工 数を見積もることが目的化。 PMの状況 ① 必要性 解決するべき問題なのか わからない

    ② 妥当性 最適な解決策なのか わからない ③ 実現性  最適な詳細要件なのか わからない PMは急いで見積もりを要求するが、実際は上記い ずれかのパターンで認識が揃わず、見積もりの段 階にまでに到達できない。 認識が合わない3つのパターン 絶対見積もりして もらうぞ!! 見積もり(リファインメント)がうまくできない問題