【デブサミ2025登壇資料】新卒1年目が0から始めたDevOps～プルリクマージ数を8倍にした開発プロセス改善～

Transcript

1. ©Social Databank, Inc. 2025/02/14 ソーシャルデータバンク株式会社　島田 鉄平 新卒1年目が0から始めたDevOps ～プルリクマージ数を8倍にした開発プロセス改善～
2. 2 ©Social Databank, Inc. 兼務i • 新機能を3本開発 • テックブログ立ち上げ • DevOpsの推進 自己紹介 島田 鉄平 / Teppei Shimada 新卒3年目 運用保守チーム 新卒入社 メインのプロダクトチームにジョイン 2022年 4月 2022年 9月 メインi • 運用保守（本番監視 ・障害対応 etc…）
3. ©Social Databank, Inc. 謝ることがあります
4. ©Social Databank, Inc. https://event.shoeisha.jp/devsumi/20250213/session/5559 プルリクマージ数を 8倍にした と書きましたが
5. ©Social Databank, Inc. PRマージ数の変化（1人あたり） 始める前 2年後の同時期 4.3件 40.9件 約 10 倍 プルリクマージ数
6. ©Social Databank, Inc. 2025/02/14 ソーシャルデータバンク株式会社　島田 鉄平 新卒1年目が0から始めたDevOps ～プルリクマージ数を8倍にした開発プロセス改善～ 約 10倍
7. ©Social Databank, Inc. みなさんに質問です
8. ©Social Databank, Inc. DevOps で 一番大事なこと って何だと思いますか？
9. ©Social Databank, Inc. DevOps で 一番大事なこと って何だと思いますか？
10. ©Social Databank, Inc. 正解がある問いではありませんが…、 DevOpsはまず 人、 次に プロセス、 そしてその次にようやく ツール について考えるのです。 （システム運用アンチパターンより）
11. ©Social Databank, Inc. 正解がある問いではありませんが…、 DevOpsはまず 人、 次に プロセス、 そしてその次にようやく ツール について考えるのです。 （システム運用アンチパターンより） 今日は、私が DevOpsの考え方やプラクティスを どうやって組織に根付かせたか についてお話します ※ツールの話はしません
12. ©Social Databank, Inc. 目次 理想と現在地を知る 会社概要・プロダクト概要 方針転換と問題解決 どう変わったか DevOpsを始めたきっかけ
13. ©Social Databank, Inc. 01 会社概要とプロダクト規模
14. ©Social Databank, Inc.
15. ©Social Databank, Inc.
16. 16 ©Social Databank, Inc. 数字で見る 8740 万人 総友だち数 21428 件 契約アカウント数 2億 6395万通 月間送信メッセージ数 ※2024年9月時点 0.61 2.10 4.62 10.10 17.21 18.99 19.73 1期 2期 3期 4期 5期 6期 7期 売上推移（億円） （OEM含む）
17. 17 ©Social Databank, Inc. 組織内のエンジニアの割合 運用保守 機能開発 15%（10人） （2チーム） 25%（15人） （2チーム） 40%（25人） 人 バックオフィス CS系 Biz系 エンジニア
18. ©Social Databank, Inc. 02 DevOpsを始めたきっかけ
19. ©Social Databank, Inc. 入社から半年経ったある日、
20. ©Social Databank, Inc. 部長 島田くんDevOpsやってみない？ 島田
21. ©Social Databank, Inc. 部長 島田くんDevOpsやってみない？ え、はい…！
22. ©Social Databank, Inc. 部長 島田くんDevOpsやってみない？ え、はい…！ DevOpsを任された
23. 23 ©Social Databank, Inc. 当時の島田くん 『LeanとDevOpsの科学』 は 読んだことある 新卒１年目 プロダクトチームに 入って１ヶ月 そんな新人がなぜDevOpsを？？
24. 24 ©Social Databank, Inc. なぜ1年目がDevOpsを？ 0.61 2.10 4.62 10.10 17.21 18.99 19.73 1期 2期 3期 4期 5期 6期 7期 売上推移（億円） 島田がジョインした時期 サービス規模が拡大 ◎リードエンジニアが忙しい ◎信頼性の改善を優先 　 インフラ基盤の改善 　 コード品質の改善 　 ライブラリの大型アプデ 　 　…etc
25. ©Social Databank, Inc. 部長 なんでDevOpsやりたいんでしたっけ？ 島田
26. ©Social Databank, Inc. 部長 なんでDevOpsやりたいんでしたっけ？ 面白そうだからかな 島田
27. 27 ©Social Databank, Inc. 面白そうだから • 『LeanとDevOpsの科学』の出版 • texta.fm で twadaさん が紹介 なぜDevOpsを始めた？ https://findy-code.io/engineer-lab/t-wada
28. ©Social Databank, Inc. 03 理想と現状を知る
29. 29 ©Social Databank, Inc. どこから始めるか 課題 理想 と 現状 のギャップ 「理想と現状のギャップ」を 明らかにして課題を発掘する まずは 理想を明確に 現状 理想 課題
30. 30 ©Social Databank, Inc. DORA - DevOps Research and Assessment • 開発組織の「能力とパフォーマンスの関係」を 明らかにすることを目的とした研究プログラム 理想を明確にする https://cloud.google.com/devops/state-of-devops
31. 31 ©Social Databank, Inc. FourKeys - DORAが提唱する、ソフトウェア組織の 　　　　　　　 パフォーマンスを示す4つの指標 理想を明確にする デプロイ頻度 リードタイム 平均修復時間 変更失敗率 （※現在は信頼性を示す指標も追加されているが、今回は割愛）
32. ©Social Databank, Inc. パフォーマンス指標 低 中 高 デプロイ頻度 月1回〜 6ヶ月に1回 週1回〜月1回 必要に応じて （1日に複数回のデプロイ） リードタイム 1ヶ月〜6ヶ月 1週間〜1ヶ月 1日〜1週間 平均修復時間 1週間〜1ヶ月 1日〜1週間 〜1日 変更失敗率 46%〜60% 16%〜30% 0%〜15% これがそのFourKeys https://dora.dev/research/2022/dora-report/2022-dora-accelerate-state-of-devops-report-ja.pdf
33. ©Social Databank, Inc. パフォーマンス指標 低 中 高 デプロイ頻度 月1回〜 6ヶ月に1回 週1回〜月1回 必要に応じて （1日に複数回のデプロイ） リードタイム 1ヶ月〜6ヶ月 1週間〜1ヶ月 1日〜1週間 平均修復時間 1週間〜1ヶ月 1日〜1週間 〜1日 変更失敗率 46%〜60% 16%〜30% 0%〜15% https://dora.dev/research/2022/dora-report/2022-dora-accelerate-state-of-devops-report-ja.pdf
34. 34 ©Social Databank, Inc. 理想はDORAが出している 理想を明確にする 現状 理想 課題 FourKeysを計測して現状を知ろう！ https://dora.dev/research/2022/dora-report/2022-dora-accelerate-state-of-devops-report-ja.pdf
35. 35 ©Social Databank, Inc. 現状を知る 全て計測するのは大変なので… リードタイムだけ を計測してみる
36. 36 ©Social Databank, Inc. チームごとにPRのリードタイムを集計 リードタイム → 1週間〜1ヶ月 現状を知る
37. ©Social Databank, Inc. パフォーマンス指標 低 中 高 デプロイ頻度 月1回〜 6ヶ月に1回 週1回〜月1回 必要に応じて （1日に複数回のデプロイ） リードタイム 1ヶ月〜6ヶ月 1週間〜1ヶ月 1日〜1週間 平均修復時間 1週間〜1ヶ月 1日〜1週間 〜1日 変更失敗率 46%〜60% 16%〜30% 0%〜15% 当時のDORAレポート https://dora.dev/research/2022/dora-report/2022-dora-accelerate-state-of-devops-report-ja.pdf
38. ©Social Databank, Inc. パフォーマンス指標 低 中 高 デプロイ頻度 月1回〜 6ヶ月に1回 週1回〜月1回 必要に応じて （1日に複数回のデプロイ） リードタイム 1ヶ月〜6ヶ月 1週間〜1ヶ月 1日〜1週間 平均修復時間 1週間〜1ヶ月 1日〜1週間 〜1日 変更失敗率 46%〜60% 16%〜30% 0%〜15% 低 パフォーマンス 高 現状 現状 https://dora.dev/research/2022/dora-report/2022-dora-accelerate-state-of-devops-report-ja.pdf
39. ©Social Databank, Inc. パフォーマンス指標 低 中 高 デプロイ頻度 月1回〜 6ヶ月に1回 週1回〜月1回 必要に応じて （1日に複数回のデプロイ） リードタイム 1ヶ月〜6ヶ月 1週間〜1ヶ月 1日〜1週間 平均修復時間 1週間〜1ヶ月 1日〜1週間 〜1日 変更失敗率 46%〜60% 16%〜30% 0%〜15% 低 パフォーマンス 高 現状 理想 まずは リードタイム 1週間 を目指してみる
40. ©Social Databank, Inc. ギャップがあるのは わかった
41. ©Social Databank, Inc. ギャップがあるのは わかった チームごとに集計する ダッシュボードも 作った
42. ©Social Databank, Inc. ギャップがあるのは わかった チームごとに集計する ダッシュボードも 作った あとは全体展開して チームごとに改善 してもらおう
43. ©Social Databank, Inc. 我々のパフォーマンスは 真ん中くらいです リードタイム1週間を 目指しましょう！ PRを小さくするなどで 改善お願いします！
44. ©Social Databank, Inc. 我々のパフォーマンスは 真ん中くらいです リードタイム1週間を 目指しましょう！ PRを小さくするなどで 改善お願いします！ これは失敗でした
45. 45 ©Social Databank, Inc. 失敗した チームから厳しい反応が返ってきました • 強い組織に強いエンジニアが居ただけでしょ • 今のプロセス変える必要ある？ • PRを小さくすればリードタイムが改善するのは当たり前 • それってただ数字をハックしてるだけで意味なくない？ 正直心が折れかけました
46. ©Social Databank, Inc. DevOpsはまず 人、 次に プロセス、 そしてその次にようやく ツール について考えるのです。 （システム運用アンチパターンより）
47. ©Social Databank, Inc. DevOpsはまず 人、 次に プロセス、 そしてその次にようやく ツール について考えるのです。 （システム運用アンチパターンより） リードタイムを短縮する文化のない チーム（人） リードタイムを集計する ダッシュボード（ツール）
48. ©Social Databank, Inc. DevOpsはまず 人、 次に プロセス、 そしてその次にようやく ツール について考えるのです。 （システム運用アンチパターンより） リードタイムを短縮する文化のない チーム（人） リードタイムを集計する ダッシュボード（ツール） 人（チームの文化）ではなく ツール（ダッシュボード） から始めてしまった
49. ©Social Databank, Inc. 04 方針転換と問題解決
50. 50 ©Social Databank, Inc. 方針転換 組織文化を どう変えていくか （LeanとDevOpsの科学 第3章より） チームの思考法ではなく チームの言動を変える
51. 51 ©Social Databank, Inc. 方針転換 組織文化を どう変えていくか （LeanとDevOpsの科学 第3章より） チームの思考法ではなく チームの言動を変える DevOpsの プラクティスの実践
52. 52 ©Social Databank, Inc. 方針転換 最初から組織全体の協力を得るのは難しい ツールや指標を持ち出して、「こうしろ！」 チームがDevOpsのプラクティスを実践する 　　の役割は「実践する キッカケ作り」 島田
53. 53 ©Social Databank, Inc. 方針転換 最初から組織全体の協力を得るのは難しい ツールや指標を持ち出して、「こうしろ！」 チームがDevOpsのプラクティスを実践する 　　の役割は「実践する キッカケ作り」 島田 これを念頭に 実践可能なDevOpsの プラクティスを探す
54. 54 ©Social Databank, Inc. リードエンジニアが頑張って整備してきた • CI / CD • 自動テスト • …etc 実践可能なプラクティスを探す 主要なプラクティスは整備済み
55. 55 ©Social Databank, Inc. WIP制限とは… • 仕掛かり中の作業（=Work In Process）を減らす ことで生産性を高めるプラクティス • 元々はトヨタ生産方式のプラクティス 実践可能なプラクティスを探す WIP制限に目をつけた
56. 56 ©Social Databank, Inc. • 100件以上のPR（10件/人） • WIP制限では1人あたり1〜2個であるべき 実践可能なプラクティスを探す WIP制限の障壁=PRの多さ 明らかに過剰
57. 57 ©Social Databank, Inc. • 調整ごとが増える（コンフリクト の頻発） • 作業を切り替える度に 思い出す時間 が必要 実践可能なプラクティスを探す PRが多いことって問題なの？ 1つ1つにかかる時間は5〜10分程度かもしれない 少しの積み重ねが全体の生産性を下げている
58. 58 ©Social Databank, Inc. • 調整ごとが増える（コンフリクト の頻発） • 作業を切り替える度に 思い出す時間 が必要 実践可能なプラクティスを探す PRが多いことって問題なの？ 1つ1つにかかる時間は5〜10分程度かもしれない 少しの積み重ねが全体の生産性を下げている そもそも… なぜそんなに沢山PRがあるの？
59. 59 ©Social Databank, Inc. PRがたくさんある原因 ボトムアップな組織文化 ❌ トップダウンで、計画通りに作る ⭕ ボトムアップで、「あったらいいな」を作る
60. 60 ©Social Databank, Inc. PRがたくさんある原因 ボトムアップな組織文化 良い意味で、自由・自主性がある 悪い意味で、着地できずそのまま放置 WIP 増 並行作業 認知負荷 増 増
61. 61 ©Social Databank, Inc. 100件以上あるPRの内訳 • 開発自体は進んでいるが、何ヶ月も開発中のPR • 放置されてコンフリクトまみれになったPR PRがたくさんある原因 WIP制限導入の下地を整える
62. ©Social Databank, Inc.
63. ©Social Databank, Inc. 放置されて コンフリクト まみれになった PR 何ヶ月も 開発中のPR
64. ©Social Databank, Inc. 放置されて コンフリクト まみれになった PR 何ヶ月も 開発中のPR これを解消していく
65. ©Social Databank, Inc. 放置されて コンフリクト まみれになった PR 何ヶ月も 開発中のPR
66. 66 ©Social Databank, Inc. 1. 開発用のFeatureBranchを切る 2. FeatureBranch上で機能を完成させる 3. 完成したらMainBranchにマージしてリリース PRの生存期間を短くする 当時の機能開発 よくあるFeatureBranch運用
67. 67 ©Social Databank, Inc. • 生存期間：3ヶ月〜6ヶ月 • この間MainBranchに追従し続ける必要がある PRの生存期間を短くする FeatureBranch運用の問題点 解決するために リリーストグル を導入 FeatureBranchの生存期間が長い
68. 68 ©Social Databank, Inc. • コードのデプロイと機能のリリースを分離 • 開発中のコードもMainBranchにマージできる PRの生存期間を短くする リリーストグル（フィーチャーフラグ） 新プロジェクトにおける導入を提案
69. 69 ©Social Databank, Inc. • PRの生存期間が短くなった ◦ コンフリクト発生数の減少 • 副次的な効果 ◦ 本番環境で動かせるので環境起因のバグに気付ける ◦ 関係者にβ版開放してFBをもらえるように PRの生存期間を短くする リリーストグルを導入した結果 エンジニアからもPMからも良好な反応
70. ©Social Databank, Inc. 放置されて コンフリクト まみれになった PR 何ヶ月も 開発中のPR 解決
71. 71 ©Social Databank, Inc. どうやって解消するか 1. PRを作った人と一緒に作業する時間を設定 2. PRを古い順に並べてその場で閉じる ◦ 入れられるものは Merge する ◦ 練り直すものは Close してタスクに戻す これを10回ほど繰り返しました 放置されたPRを閉じる
72. 72 ©Social Databank, Inc. 3ヶ月かけて40件まで減らした 放置されたPRを閉じる プルリク数の変化 105 40
73. 73 ©Social Databank, Inc. • リードエンジニアが全てのPRに目を通せるように • 技術的に考慮が必要な箇所を早い段階で指摘 放置されたPRを閉じる 放置されたPRを閉じたことによる効果 大きな手戻りが減った
74. 74 ©Social Databank, Inc. • ドメイン知識がないため、話がわからない 放置されたPRを閉じる 大変だったこと 話がわかる人を連れてくる • 減っても増える めげずに頑張る
75. ©Social Databank, Inc. 放置されて コンフリクト まみれになった PR 何ヶ月も 開発中のPR 解決 解決
76. ©Social Databank, Inc. 放置されて コンフリクト まみれになった PR 何ヶ月も 開発中のPR 解決 解決 今ある問題は解決できたので 再発防止策を講じる
77. 77 ©Social Databank, Inc. 並行作業数も減り、下地が整った 当初予定していた WIP制限 の導入を検討 過剰な並行作業への対策 しかしWIP制限の定着は 難しかった WIP制限の導入検討
78. 78 ©Social Databank, Inc. • PM不在のチームはコントロールする人がいない • 自動化が困難 ◦ PRが5件以上になったら自動Close？ ◦ 障害対応中に自動Closeされたら…？ 過剰な並行作業への対策 WIP制限が定着しなかった理由
79. 79 ©Social Databank, Inc. 「制限するのではなく、サポートする」 1. しばらく進んでないPRを見つける 2. 発生している問題を聞く 3. 解消の手を打つ 過剰な並行作業への対策 人間BOT これを BOTのように 週1で繰り返す
80. 80 ©Social Databank, Inc. 具体的な問題と解消手段、難しいことはしてません • テキストコミュニケーションだと難しいもの • コメントに気づいてなかった • レビュアーが他業務で忙しい 過剰な並行作業への対策 ペアプロ・ペアレビューを設定する 後追いで連絡する 他のレビュアーにアサインし直す
81. 81 ©Social Databank, Inc. 過剰な並行作業への対策 人間BOTのポイント 🐺 人間が関わることで オオカミ少年化を防止
82. 82 ©Social Databank, Inc. 過剰な並行作業への対策 人間BOTの成果 ① • PR数が 30〜50件 で安定（2件/人）
83. 83 ©Social Databank, Inc. 過剰な並行作業への対策 人間BOTの成果 ② • モブプロ・モブレビューが 自然発生 • チームの 朝会でも実施 されるように • 5分で1PRマージ できることも DevOpsのプラクティスの浸透を実感
84. ©Social Databank, Inc. 05 どう変わった
85. 85 ©Social Databank, Inc. どう変わったか 1. 組織文化の変化 2. 定量指標の変化 3. 顧客や社内からの反応の変化 DevOps実践前後の変化をみる
86. 86 ©Social Databank, Inc. どう変わったか 1. 組織文化の変化 2. 定量指標の変化 3. 顧客や社内からの反応の変化 DevOps実践前後の変化をみる
87. 87 ©Social Databank, Inc. 組織文化の変化 　まずFeatureBranchを切る 昔 新機能の開発時… 　まずリリーストグルを作る 今
88. 88 ©Social Databank, Inc. 組織文化の変化 　　大きいPRがあるのは仕方ない 昔 PRのサイズは… 　　小さくするのが当たり前 今
89. 89 ©Social Databank, Inc. 組織文化の変化 　気にしない 昔 放置されたPRは… 　チームで毎日確認 今
90. 90 ©Social Databank, Inc. どう変わったか 1. 組織文化の変化 2. 定量指標の変化 3. 顧客や社内からの反応の変化 DevOps実践前後の変化をみる
91. 91 ©Social Databank, Inc. 定量指標の変化 PRマージ数の変化（全体） 始めたのがこのあたり 今このあたり
92. 92 ©Social Databank, Inc. 定量指標の変化 PRマージ数の変化（1人あたり） 始める前 2年後の同時期 4.3件 40.9件 約10倍 マージ済み PR数
93. 93 ©Social Databank, Inc. 定量指標の変化 リードタイムの変化 始める前 2年後の同時期 7週間 (622.6h) 3週間 (375.9h) 半分以下 リードタイム
94. 94 ©Social Databank, Inc. どう変わったか 1. 組織文化の変化 2. 定量指標の変化 3. 顧客や社内からの反応の変化 DevOps実践前後の変化をみる
95. 95 ©Social Databank, Inc. 即対応に感謝、感激！ 顧客や社内からの反応の変化 対応スピード改善によって 顧客や社内からも嬉しい声が 通達から3日くらい？で反映してくれた 予約の表示時間が正しく表示されない とのお客様からのお問い合わせに 1時間以内に不具合修正してくださった！
96. 96 ©Social Databank, Inc. 顧客や社内からの反応の変化 対応スピード改善によって 顧客や社内からも嬉しい声が
97. 97 ©Social Databank, Inc. 個人的な学び 技術的な解決法だけでなく泥臭い解決法もある 組織にDevOpsを定着させるには、 • 考え方ではなく言動から変える • プラクティスを実践するキッカケを作る
98. 98 ©Social Databank, Inc. 伝えたいこと DevOpsの考え方を定着させるのはめっちゃ大変 でもその価値はある
99. ©Social Databank, Inc.