LeSSにチームがJOINして1年半たったので振 り返ってみた
 
 
 櫻井　洋一郎
 2021/10/02 @ スクラムフェス三河 


自己紹介
 ● 櫻井　洋一郎
 ● Engineering Manager 兼 日本酒担当 
 ● 趣味：漫画・アニメ鑑賞、サックス練習 
 ○ 最近ようやく攻殻機動隊見ました 
 ■ タチコマかわいい
 ● 経歴：2013年 Retty入社 
 ○ 初期はiOSエンジニア 
 ○ バックエンド開発や時にはインフラ周りまで 技術的なことを幅広くやる人 


このセッションで伝えたいこと
 ● 対象者
 ○ LeSSに興味がある人 または LeSSに取り組もうとしている人 
 ○ 特に会社がLeSSを始めていて、今からLeSSに参加しようとしているチームの人 
 ● どんなことが聞ける？ 
 ○ チームにどんな変化が起きたか 
 ○ 大事にしたほうがよさそうなこと 
 ○ 早めにやると効果的だったかもしれないこと 
 ○ 時間をかけないといけなかったこと 


目次
 1. RettyにおけるLeSSの取り組み 
 2. LeSSにJOINした私達のチーム 
 3. JOIN前のチームにおける課題 
 4. JOINして1年半のチームの軌跡 
 5. まとめ


RettyにおけるLeSSの取り組み
 ● LeSSに取り組みはじめた背景 
 ○ 会社全体の優先順位と各開発チーム内の優先順位に差がある状態 
 ○ 全社で最優先の課題解決に他チームの開発を待つというようなことが起きる状態 
 ● LeSS導入の時間軸
 ○ 2019年4月：Web開発に携わる1つのチームでまずは始める 
 ○ 2019年7月：Web開発に携わるメンバーが増え、2つのチームに編成する 
 ○ 2019年10月：アプリ開発チームが合流し、3つのチームとなる 
 ○ 2020年3月：私達のチームが合流 
 参考
 「1プロダクトをみんなで作る！」Rettyでの大規模スクラム(LeSS)導入記 
 「全社で大規模スクラム(LeSS)移行して1年間」 #RSGT2021 での質問に、Retty執行役員が全て答えました 


LeSSにJOINした私達のチーム
 ● チームの特徴
 ○ toC向けの開発ではなく、toB向けの開発を行うチーム 
 ■ ビジネス的に期日間をもった要求がくることが多い 
 ■ 突発的に発生する問い合わせによって優先度が変わったりする 
 ○ スクラムといってもなんちゃってスクラム状態だった 
 ■ 朝会はやるけど、振り返りは... 
 ■ カンバンの週次のタスクをやりきることに注力していた 
 ■ 運用・バグ対応のタスクもするけれどタスクの見える化が弱い 


JOIN前のチームにおける課題
 ● フロー効率よりリソース効率 
 ○ とにかくたくさんのことを同時に進めたい 
 ■ アウトカムよりアウトプット 
 ○ ビジネス的に期日感をもって進めたい -> 属人化してスピードアップ 
 ■ 属人化することでバス係数が下がる（○○についてはXXさんしかわからない） 
 ● toBのタスクが自チームのバックログに閉じがち 
 ○ toC / toBで別れていたので、チーム間でタスクの融通があまりできなかった 


JOINして1年半のチームの軌跡


LeSSにJOINして 0 日後 (2020年3月頃)
 
 
 ● まずは見よう見まねでスクラムを始めた 
 ○ すでに3チームがLeSSで動いていて、それらのイベントも 
 横目で見ていたのでだいたいの雰囲気は知っていた 
 ● 事前にスクラムイベントの説明はざっとうけていた 
 ○ スプリントプランニング、レトロスペクティブ、朝会、スプリントレビュー、etc 
 ● でもチームにちゃんとしたスクラム開発経験をもっている人がいない 
 ○ スクラムガイドとかSCRUM BOOT CAMPとかも読んだことない 


LeSSにJOINして 48日後


LeSSにJOINして 48日後
 ● スクラムに慣れるのに精一杯でそんなにすぐに変化はおきない 


LeSSにJOINして3ヶ月後 (〜2020年6月頃)
 ● 走りながらチームにおけるスクラム開発の型がで き始めてくる
 ○ 振り返りをKPTから変更 
 ○ 振り返り手法が変わりたくさんの意見が出る ようになってきた
 ● チームに新しいメンバーがJOIN 
 ○ toC 向けの開発経験のみだったため 
 toBのドメイン知識の共有からスタート 
 参考
 コミュニケーションの方向に着目したふりかえりの方法
 https://ihcomega.hatenadiary.com/entry/2020/04/28/055258 


LeSSにJOINして6ヶ月後 (〜2020年9月頃)
 
 
 ● Go to Eatの参画に向けて全社が集中して開発をした時期 
 ○ バックログ管理の変化 
 ■ 全社のバックログと合わせて開発を行うようになっていた 
 ■ toB向けの改修項目も多かったがタスク分割を工夫し、LeSSの別 チームで進めてもらえるよう取り組み 
 ■ 自チームしかできないタスクを減らし、全社で優先したい価値をより 柔軟に届けられるようになっていった 


LeSSにJOINして6ヶ月後 (〜2020年9月頃)
 
 
 ● Go to Eatの参画に向けて全社が集中して開発をした時期 
 ○ 属人化リスクに向けた動きの変化 
 ■ 前Qから新メンバーも加わったため、既存の領域のドメイン知識も共 有しつつ新たな業務要件の開発を行う必要が出ていた 
 ■ 長期的な運用を考え、属人化してスピードをあげるとは別の開発方 法を選択
 ■ モブワークを徐々に始めて属人化をへらす活動が始まった 
 ● 設計のチームレビュー / ペアプロ / 運用の持ち回り化 


LeSSにJOINして9ヶ月後 (2020年12月頃)
 
 
 ● Go to Eat開発は落ち着いたため、別のプロジェクトに向けてバックログの内容は全体のものとは別に 
 ○ 必要であれば全体のものに合わせられることはわかったので柔軟に動けるようになった 
 ● オフショア開発のチームが発足し、タスクの依頼ができるようになった 
 ○ Go to Eat開発で他チームのメンバーに安心してコードを触ってもらうことの重要性に気づく 
 ■ 既存のコードにテストコードを入れてもらうタスクをたくさんお願いした 
 ○ 追加したテストコードのおかげでリリース前にクリティカルな部分に影響を与えるケースを防ぐことがで き、チームでのテストコードの大事さの認識があがり始めた 
 ○ スプリントプランニングのタスク分解時に「テストコードを追加」を入れる動きが始まる 


LeSSにJOINして1年後 (2021年3月頃)
 
 
 ● 新メンバーのJOIN
 ○ 私達のチームにもスクラム詳しい人が！ 
 ○ ある日の振り返りで「我々は改めてスクラムガイド読んでみたほうが 
 いいのでは？」となり会の設定とファシリテーションをやってくれることに 
 ○ この内容が先程の「守破離の守！」スクラムガイドをみんなで読んでみた。 
 ● タスクの見える化の再考 
 ○ 大きめのプロジェクトが始まり、初期の設計フェーズでベロシティが落ちる現象が発生した 
 ■ 原因は設計タスクがスプリントバックログに見える化されてないこと 
 ○ 調査や設計・検討についてもバックログに積んでSPをふるように変えた 


LeSSにJOINして1年半後 (2021年9月頃)
 
 
 ● さらに新メンバーがJOIN 
 ○ 会社の別のスクラムチームからの異動 
 ○ LeSS導入の初期からLeSSの中のチームとしてやってきたメンバー 
 ● 起きた変化
 ○ ペアプロ・モブプロをさらに積極的に行うようになった 
 ○ 週に一度の振り返りを待たずに改善したいことはカジュアルにDiscordで話そうよ、とみんなの意識を変 えてくれた
 ○ 他のチームで積極的に行われていた、修正に合わせてリファクタリングや周りの不要コード削除をする 文化が入った


まとめ


チームにどんな変化が起きたか
 ● 自チームしかできないタスクが減り、全社で優先したい価値をより柔軟に届けら れるようになった
 ○ バックログの運用はその時々に合わせてより良いやり方を模索 
 ○ リソース効率からフロー効率の考え方に変わってきた 
 ● モブワークにより属人化が減ってきた 
 ● テストコードの追加や不要コードの削除といった意識があがり、開発を改善しよ うという意識が強まってきた 
 ● 困ったらすぐに相談していいんだ、という心理的安全性があがってきた 


大事にしたほうがよさそうなこと
 ● 余裕 is 大事
 ○ 余裕がなくなると改善活動ができなくなるだけでなく、改善に向けた意識が切れる 
 ○ この1年半の中にもどうしても忙しさの波で余裕がなくなる場面があった 
 ○ どうしようもないときもあるけど、可能な限り余裕を作れるように意識できると良さそう 


早めにやると効果的だったかもしれないこと
 ● スクラムの基礎知識の学習 
 ○ スクラムガイドを読んでおくとか、SCRUM BOOT CAMPなどの入門書を読んでおくとか 
 ○ 親和するスピード感は高まっていたんじゃないか？と感じる 
 ● 対話の重要性と心理的安全性 
 ○ 対話できる環境（我々はDiscordを活用）があることと話しかけやすさは別 
 ○ 場を用意できても話してくれるとは限らない 
 ● メンバー編成
 ○ チームの活動がよくなったタイミングとメンバー加入のタイミングが割と一致している 
 ○ 編成によってチームカラーやポテンシャルが発揮されることもある 


時間をかけないといけなかったこと
 ● スクラムに対する理解 
 ○ いきなり理解できて、正解を選んでいけるわけじゃない 
 ● チームが学んで実感しながら変えていくことに価値がありそう 
 ○ 教科書的な知識は大事だけど、それと同じことをやればうまく回るわけでもない 
 ○ 一人が学んで出す改善案より、チームが学んで出す改善案 


ご清聴ありがとうございました