https://confengine.com/conferences/scrum-fest-osaka-2022/proposal/16762

1. チームで避けるビッグバンリリース
それを支える仕組みやメンバーオンボーディングの紹介
June 18th, 2022
Yokoyama Tsukasa / Yanagimoto Koichi / Komori Jun
Rakuten Group, Inc.

2. 2
本日のあらすじ
レガシーなプロダクトの刷新を行った結果とても苦労した
↓
原因の1つは、ミドルウェアの更新を怠っていたため変更差分が大きくなり、
その変更に依存する変更が連鎖的に必要になり、バタフライエフェクトを引き起こしたこと
↓
「今後絶対にミドルウェアのUpdateは小さく頻繁に継続的に行おう」と心に誓った
↓
いざやってみると、純粋に作業量が増えるためチームの高負荷を招いた
↓
対応できる人を増やすために、Onboardingに力を入れ目標設定もチームで行うように変更した

3. 3
自己紹介
Sapporo
Tokyo
Komori Jun
Engineering Group
Growth engineering team leader
Engineering Group
Mr. Kaizen
https://illustrain.com/?cat=19
Yanagimoto Koichi
猫とRubyを愛してやまない
人と未来にフォーカスする
頼れるリーダー
YokoyamaTsukasa
Product Managing Group
vice manager
北海道生まれ北海道育ち
Agile Sapporoメンバー

4. 4
おすすめの楽天市場ショップ
FromYokoyama
生粋の北海道人でも知らない道産の魅力を
再発見できる！
他のECでは買いにくい商品も多数あり！
From Komori
牡蠣好きにはたまらないお店
定期的に買っています
美味しいの向こう側を体験できる
https://www.rakuten.co.jp/hokkaido-dosankoplaza/ https://www.rakuten.ne.jp/gold/gakikaki/
2022/06/13 2022/06/13

5. 5
おすすめショップ
https://www.rakuten.co.jp/teraokake/
FromYanagimoto
醤油好きにはたまらないお店
牡蠣醤油が美味しい、卵かけご飯用も美味しい。
醤油がある国に生まれて良かった！
2022/06/13

6. 6
部署紹介
Vision
Operation ZERO
https://publicdomainq.net/pleiades-seven-sisters-0048565/

7. 7
部署紹介
プロダクト・ライフサイクル上でGrowth phase 以降のプロダクトを集め
マンパワーではなく、エンジニアリングによる改善と自動化によって
少ない工数で安定稼働させること
Mission
エンジニアあたりの担当プロダクト数が社内でもダントツで多い
要件や使われ方、関係者も多種多様であり全プロダクトを完璧に把握するのが困難
歴史あるものが多くレガシーなもの少しずつモダンなものに改善している
特徴

8. 8

9. 9
イメージ図
職種
@jikun1234 / @kyanagimoto
またはお近くの楽天社員まで
https://www.irasutoya.com/2016/02/blog-post_329.html
• Software Engineer
• SRE
• Project manager
• Product manager

10. 10
きっかけとなったプロジェクト
https://codezine.jp/article/detail/12021
もし、ミドルウェアの更新がもっと早く出来ていれば…

11. 11
学んだこと
ミドルウェアのUpdateは小さく頻繁に継続的に行うべき

12. 12
Continuous update project
概要
GitHub Actions
Keep everything always up-to-date
https://kotonohaworks.com/free-icons/user/
変更検知
PR作成
影響確認
PRレ
ビュー
テスト
デプロイ
auto
auto manual
auto manual
+
Web
Server
Programming
language
Web
Framework

13. 13
Continuous update project
上手くいったこと
140倍 (YoY 14,000%)
１）ミドルウェアの更新回数が前年比で
影響確認/テスト/Rollbackが容易になり一回のUpdateあたりの作業負荷を削減できた
２）さらに、ミドルウェア更新でのトラブルが激減

14. 14
Continuous update project
改善点
1. リーダーの高負荷（タスクアサイン / コードレビュー)
2. プルリクが溜まるようになった
3. 各Updateの状況が分かりにくくなった
4. 特定のメンバーの作業負荷が高くなった

15. 15
Continuous update project – 改善点(リーダーの高負荷)
課題1. リーダーによるタスクアサインが大変
自動でランダムアサインに変更
課題2. シニアエンジニアによるコードレビューが大変
コードオーナーの制定
コードオーナーと、ランダムアサインされたメンバーのレビューに変更

16. 16
Continuous update project – 改善点(プルリク溜まる問題)
課題. 全メンバーに均等にコードレビュー待ちが発生
レビュー待ち状況を可視化しハドルで声を掛け合う
減っていくのが目に見える喜び

17. 17
Continuous update project – 改善点(各Updateの状況が分かりづらい)
課題. 開発PRJとも並行するため今誰が何をしているのか、何待ちなのか把握が難しくなった
各タスクの完了タイミングでGitHubのラベルを貼ることで、
ラベルを見ればいまどのフェーズで誰がボールを持っているかわかるようにした

18. 18
Continuous update project – チームのスケールアウト
課題. 特定のメンバーの負荷が高くなっていった（既存の開発PRJ + Continuous update）
対応できる人を増やす
1. プロダクト理解度チェックテストの作成
2. 個人目標をチームで行う

19. 19
Continuous update project – チームのスケールアウト
プロダクト理解度チェックテスト
• 仕様書との違いは、何を知るべきかという観点かつ機能単位ではなくレベル単位になっている
（登録機能だけで全パターンを学ぶのではなく、まずは単純なパターンで全機能を）
• チームとして取り組む時間の確保を行い、
問題や答えの作成はプロダクトに詳しくないメンバー同士で行うことができた
Role、レベルごとに分けて問題を作成
PdM/PjM
エンジニア
クライアントサポート
要件/仕様
実装/インフラ
運用作業
トラブル対応などでも効果あり

20. 20
Continuous update project – チームのスケールアウト
個人の目標設定をチームで
マネージャ/メンバー全員でお互いの期待値を伝えあう
マネージャからチームのOKRをシェア
自分の期待値とチームのOKRを見ながら個人目標を建てる
その目標について皆でディスカッション、目標設定後も月イチで達成状況を確認している
上手くいった点
• 人の目標を知ることで、「あの人なんであんなことやってるんだろう？」が減ってきている
• マネージャの目標も公開しているので、「なんで急にあんな事言いだしたんだろう」が減ってきてる
改善が必要な点
• 時間がかかる。どれくらい時間かけるべきか考えていきたい
• メンバーによる温度感の差

21. 21
Continuous update project – まとめ
ミドルウェアのUpdateを放置しないために、
小さく頻繁に継続的な更新が出来る仕組みづくりにチャレンジ中
- 担当者アサインを自動化した
- コードオーナー+ランダムでコードレビュアーアサインを自動化した
- コードレビュー待ちが溜まらないようにプルリク状況を可視化した
- GitHubのIssueとLabelを使って各Updateの進捗状況を可視化した
- チーム全員で取り組むために、
- プロダクト理解度テストを、プロダクトに詳しくない人で作り何を知るべきかのリストを作った
- 個人の目標設定をマネージャ含めてチーム全員で行うようにし、より効果的な目標設定と振り返りになるようにした
1回当りの変更が小さいとはいえ、仕事が増えるので工夫が必要

22. 22
イメージ図
職種
@jikun1234 / @kyanagimoto
またはお近くの楽天社員まで
https://www.irasutoya.com/2016/02/blog-post_329.html
• Software Engineer
• SRE
• Project manager
• Product manager