Tweet
Tweet

Slide 1

Slide 1 text

©Social Databank, Inc. 2025/02/14 ソーシャルデータバンク株式会社　島田 鉄平 新卒1年目が0から始めたDevOps ～プルリクマージ数を8倍にした開発プロセス改善～

Slide 2

Slide 2 text

2 ©Social Databank, Inc. 兼務i ● 新機能を3本開発 ● テックブログ立ち上げ ● DevOpsの推進 自己紹介 島田 鉄平 / Teppei Shimada 新卒3年目 運用保守チーム 新卒入社 メインのプロダクトチームにジョイン 2022年 4月 2022年 9月 メインi ● 運用保守（本番監視 ・障害対応 etc…）

Slide 3

Slide 3 text

©Social Databank, Inc. 謝ることがあります

Slide 4

Slide 4 text

©Social Databank, Inc. https://event.shoeisha.jp/devsumi/20250213/session/5559 プルリクマージ数を 8倍にした と書きましたが

Slide 5

Slide 5 text

©Social Databank, Inc. PRマージ数の変化（1人あたり） 始める前 2年後の同時期 4.3件 40.9件 約 10 倍 プルリクマージ数

Slide 6

Slide 6 text

©Social Databank, Inc. 2025/02/14 ソーシャルデータバンク株式会社　島田 鉄平 新卒1年目が0から始めたDevOps ～プルリクマージ数を8倍にした開発プロセス改善～ 約 10倍

Slide 7

Slide 7 text

©Social Databank, Inc. みなさんに質問です

Slide 8

Slide 8 text

©Social Databank, Inc. DevOps で 一番大事なこと って何だと思いますか？

Slide 9

Slide 9 text

©Social Databank, Inc. DevOps で 一番大事なこと って何だと思いますか？

Slide 10

Slide 10 text

©Social Databank, Inc. 正解がある問いではありませんが…、 DevOpsはまず 人、 次に プロセス、 そしてその次にようやく ツール について考えるのです。 （システム運用アンチパターンより）

Slide 11

Slide 11 text

©Social Databank, Inc. 正解がある問いではありませんが…、 DevOpsはまず 人、 次に プロセス、 そしてその次にようやく ツール について考えるのです。 （システム運用アンチパターンより） 今日は、私が DevOpsの考え方やプラクティスを どうやって組織に根付かせたか についてお話します ※ツールの話はしません

Slide 12

Slide 12 text

©Social Databank, Inc. 目次 理想と現在地を知る 会社概要・プロダクト概要 方針転換と問題解決 どう変わったか DevOpsを始めたきっかけ

Slide 13

Slide 13 text

©Social Databank, Inc. 01 会社概要とプロダクト規模

Slide 14

Slide 14 text

©Social Databank, Inc.

Slide 15

Slide 15 text

©Social Databank, Inc.

Slide 16

Slide 16 text

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含む）

Slide 17

Slide 17 text

17 ©Social Databank, Inc. 組織内のエンジニアの割合 運用保守 機能開発 15%（10人） （2チーム） 25%（15人） （2チーム） 40%（25人） 人 バックオフィス CS系 Biz系 エンジニア

Slide 18

Slide 18 text

©Social Databank, Inc. 02 DevOpsを始めたきっかけ

Slide 19

Slide 19 text

©Social Databank, Inc. 入社から半年経ったある日、

Slide 20

Slide 20 text

©Social Databank, Inc. 部長 島田くんDevOpsやってみない？ 島田

Slide 21

Slide 21 text

©Social Databank, Inc. 部長 島田くんDevOpsやってみない？ え、はい…！

Slide 22

Slide 22 text

©Social Databank, Inc. 部長 島田くんDevOpsやってみない？ え、はい…！ DevOpsを任された

Slide 23

Slide 23 text

23 ©Social Databank, Inc. 当時の島田くん 『LeanとDevOpsの科学』 は 読んだことある 新卒１年目 プロダクトチームに 入って１ヶ月 そんな新人がなぜDevOpsを？？

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

©Social Databank, Inc. 部長 なんでDevOpsやりたいんでしたっけ？ 島田

Slide 26

Slide 26 text

©Social Databank, Inc. 部長 なんでDevOpsやりたいんでしたっけ？ 面白そうだからかな 島田

Slide 27

Slide 27 text

27 ©Social Databank, Inc. 面白そうだから ● 『LeanとDevOpsの科学』の出版 ● texta.fm で twadaさん が紹介 なぜDevOpsを始めた？ https://findy-code.io/engineer-lab/t-wada

Slide 28

Slide 28 text

©Social Databank, Inc. 03 理想と現状を知る

Slide 29

Slide 29 text

29 ©Social Databank, Inc. どこから始めるか 課題 理想 と 現状 のギャップ 「理想と現状のギャップ」を 明らかにして課題を発掘する まずは 理想を明確に 現状 理想 課題

Slide 30

Slide 30 text

30 ©Social Databank, Inc. DORA - DevOps Research and Assessment ● 開発組織の「能力とパフォーマンスの関係」を 明らかにすることを目的とした研究プログラム 理想を明確にする https://cloud.google.com/devops/state-of-devops

Slide 31

Slide 31 text

31 ©Social Databank, Inc. FourKeys - DORAが提唱する、ソフトウェア組織の 　　　　　　　 パフォーマンスを示す4つの指標 理想を明確にする デプロイ頻度 リードタイム 平均修復時間 変更失敗率 （※現在は信頼性を示す指標も追加されているが、今回は割愛）

Slide 32

Slide 32 text

©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

Slide 33

Slide 33 text

©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

Slide 34

Slide 34 text

34 ©Social Databank, Inc. 理想はDORAが出している 理想を明確にする 現状 理想 課題 FourKeysを計測して現状を知ろう！ https://dora.dev/research/2022/dora-report/2022-dora-accelerate-state-of-devops-report-ja.pdf

Slide 35

Slide 35 text

35 ©Social Databank, Inc. 現状を知る 全て計測するのは大変なので… リードタイムだけ を計測してみる

Slide 36

Slide 36 text

36 ©Social Databank, Inc. チームごとにPRのリードタイムを集計 リードタイム → 1週間〜1ヶ月 現状を知る

Slide 37

Slide 37 text

©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

Slide 38

Slide 38 text

©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

Slide 39

Slide 39 text

©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週間 を目指してみる

Slide 40

Slide 40 text

©Social Databank, Inc. ギャップがあるのは わかった

Slide 41

Slide 41 text

©Social Databank, Inc. ギャップがあるのは わかった チームごとに集計する ダッシュボードも 作った

Slide 42

Slide 42 text

©Social Databank, Inc. ギャップがあるのは わかった チームごとに集計する ダッシュボードも 作った あとは全体展開して チームごとに改善 してもらおう

Slide 43

Slide 43 text

©Social Databank, Inc. 我々のパフォーマンスは 真ん中くらいです リードタイム1週間を 目指しましょう！ PRを小さくするなどで 改善お願いします！

Slide 44

Slide 44 text

©Social Databank, Inc. 我々のパフォーマンスは 真ん中くらいです リードタイム1週間を 目指しましょう！ PRを小さくするなどで 改善お願いします！ これは失敗でした

Slide 45

Slide 45 text

45 ©Social Databank, Inc. 失敗した チームから厳しい反応が返ってきました ● 強い組織に強いエンジニアが居ただけでしょ ● 今のプロセス変える必要ある？ ● PRを小さくすればリードタイムが改善するのは当たり前 ● それってただ数字をハックしてるだけで意味なくない？ 正直心が折れかけました

Slide 46

Slide 46 text

©Social Databank, Inc. DevOpsはまず 人、 次に プロセス、 そしてその次にようやく ツール について考えるのです。 （システム運用アンチパターンより）

Slide 47

Slide 47 text

©Social Databank, Inc. DevOpsはまず 人、 次に プロセス、 そしてその次にようやく ツール について考えるのです。 （システム運用アンチパターンより） リードタイムを短縮する文化のない チーム（人） リードタイムを集計する ダッシュボード（ツール）

Slide 48

Slide 48 text

©Social Databank, Inc. DevOpsはまず 人、 次に プロセス、 そしてその次にようやく ツール について考えるのです。 （システム運用アンチパターンより） リードタイムを短縮する文化のない チーム（人） リードタイムを集計する ダッシュボード（ツール） 人（チームの文化）ではなく ツール（ダッシュボード） から始めてしまった

Slide 49

Slide 49 text

©Social Databank, Inc. 04 方針転換と問題解決

Slide 50

Slide 50 text

50 ©Social Databank, Inc. 方針転換 組織文化を どう変えていくか （LeanとDevOpsの科学 第3章より） チームの思考法ではなく チームの言動を変える

Slide 51

Slide 51 text

51 ©Social Databank, Inc. 方針転換 組織文化を どう変えていくか （LeanとDevOpsの科学 第3章より） チームの思考法ではなく チームの言動を変える DevOpsの プラクティスの実践

Slide 52

Slide 52 text

52 ©Social Databank, Inc. 方針転換 最初から組織全体の協力を得るのは難しい ツールや指標を持ち出して、「こうしろ！」 チームがDevOpsのプラクティスを実践する 　　の役割は「実践する キッカケ作り」 島田

Slide 53

Slide 53 text

53 ©Social Databank, Inc. 方針転換 最初から組織全体の協力を得るのは難しい ツールや指標を持ち出して、「こうしろ！」 チームがDevOpsのプラクティスを実践する 　　の役割は「実践する キッカケ作り」 島田 これを念頭に 実践可能なDevOpsの プラクティスを探す

Slide 54

Slide 54 text

54 ©Social Databank, Inc. リードエンジニアが頑張って整備してきた ● CI / CD ● 自動テスト ● …etc 実践可能なプラクティスを探す 主要なプラクティスは整備済み

Slide 55

Slide 55 text

55 ©Social Databank, Inc. WIP制限とは… ● 仕掛かり中の作業（=Work In Process）を減らす ことで生産性を高めるプラクティス ● 元々はトヨタ生産方式のプラクティス 実践可能なプラクティスを探す WIP制限に目をつけた

Slide 56

Slide 56 text

56 ©Social Databank, Inc. ● 100件以上のPR（10件/人） ● WIP制限では1人あたり1〜2個であるべき 実践可能なプラクティスを探す WIP制限の障壁=PRの多さ 明らかに過剰

Slide 57

Slide 57 text

57 ©Social Databank, Inc. ● 調整ごとが増える（コンフリクト の頻発） ● 作業を切り替える度に 思い出す時間 が必要 実践可能なプラクティスを探す PRが多いことって問題なの？ 1つ1つにかかる時間は5〜10分程度かもしれない 少しの積み重ねが全体の生産性を下げている

Slide 58

Slide 58 text

58 ©Social Databank, Inc. ● 調整ごとが増える（コンフリクト の頻発） ● 作業を切り替える度に 思い出す時間 が必要 実践可能なプラクティスを探す PRが多いことって問題なの？ 1つ1つにかかる時間は5〜10分程度かもしれない 少しの積み重ねが全体の生産性を下げている そもそも… なぜそんなに沢山PRがあるの？

Slide 59

Slide 59 text

59 ©Social Databank, Inc. PRがたくさんある原因 ボトムアップな組織文化 ❌ トップダウンで、計画通りに作る ⭕ ボトムアップで、「あったらいいな」を作る

Slide 60

Slide 60 text

60 ©Social Databank, Inc. PRがたくさんある原因 ボトムアップな組織文化 良い意味で、自由・自主性がある 悪い意味で、着地できずそのまま放置 WIP 増 並行作業 認知負荷 増 増

Slide 61

Slide 61 text

61 ©Social Databank, Inc. 100件以上あるPRの内訳 ● 開発自体は進んでいるが、何ヶ月も開発中のPR ● 放置されてコンフリクトまみれになったPR PRがたくさんある原因 WIP制限導入の下地を整える

Slide 62

Slide 62 text

©Social Databank, Inc.

Slide 63

Slide 63 text

©Social Databank, Inc. 放置されて コンフリクト まみれになった PR 何ヶ月も 開発中のPR

Slide 64

Slide 64 text

©Social Databank, Inc. 放置されて コンフリクト まみれになった PR 何ヶ月も 開発中のPR これを解消していく

Slide 65

Slide 65 text

©Social Databank, Inc. 放置されて コンフリクト まみれになった PR 何ヶ月も 開発中のPR

Slide 66

Slide 66 text

66 ©Social Databank, Inc. 1. 開発用のFeatureBranchを切る 2. FeatureBranch上で機能を完成させる 3. 完成したらMainBranchにマージしてリリース PRの生存期間を短くする 当時の機能開発 よくあるFeatureBranch運用

Slide 67

Slide 67 text

67 ©Social Databank, Inc. ● 生存期間：3ヶ月〜6ヶ月 ● この間MainBranchに追従し続ける必要がある PRの生存期間を短くする FeatureBranch運用の問題点 解決するために リリーストグル を導入 FeatureBranchの生存期間が長い

Slide 68

Slide 68 text

68 ©Social Databank, Inc. ● コードのデプロイと機能のリリースを分離 ● 開発中のコードもMainBranchにマージできる PRの生存期間を短くする リリーストグル（フィーチャーフラグ） 新プロジェクトにおける導入を提案

Slide 69

Slide 69 text

69 ©Social Databank, Inc. ● PRの生存期間が短くなった ○ コンフリクト発生数の減少 ● 副次的な効果 ○ 本番環境で動かせるので環境起因のバグに気付ける ○ 関係者にβ版開放してFBをもらえるように PRの生存期間を短くする リリーストグルを導入した結果 エンジニアからもPMからも良好な反応

Slide 70

Slide 70 text

©Social Databank, Inc. 放置されて コンフリクト まみれになった PR 何ヶ月も 開発中のPR 解決

Slide 71

Slide 71 text

71 ©Social Databank, Inc. どうやって解消するか 1. PRを作った人と一緒に作業する時間を設定 2. PRを古い順に並べてその場で閉じる ○ 入れられるものは Merge する ○ 練り直すものは Close してタスクに戻す これを10回ほど繰り返しました 放置されたPRを閉じる

Slide 72

Slide 72 text

72 ©Social Databank, Inc. 3ヶ月かけて40件まで減らした 放置されたPRを閉じる プルリク数の変化 105 40

Slide 73

Slide 73 text

73 ©Social Databank, Inc. ● リードエンジニアが全てのPRに目を通せるように ● 技術的に考慮が必要な箇所を早い段階で指摘 放置されたPRを閉じる 放置されたPRを閉じたことによる効果 大きな手戻りが減った

Slide 74

Slide 74 text

74 ©Social Databank, Inc. ● ドメイン知識がないため、話がわからない 放置されたPRを閉じる 大変だったこと 話がわかる人を連れてくる ● 減っても増える めげずに頑張る

Slide 75

Slide 75 text

©Social Databank, Inc. 放置されて コンフリクト まみれになった PR 何ヶ月も 開発中のPR 解決 解決

Slide 76

Slide 76 text

©Social Databank, Inc. 放置されて コンフリクト まみれになった PR 何ヶ月も 開発中のPR 解決 解決 今ある問題は解決できたので 再発防止策を講じる

Slide 77

Slide 77 text

77 ©Social Databank, Inc. 並行作業数も減り、下地が整った 当初予定していた WIP制限 の導入を検討 過剰な並行作業への対策 しかしWIP制限の定着は 難しかった WIP制限の導入検討

Slide 78

Slide 78 text

78 ©Social Databank, Inc. ● PM不在のチームはコントロールする人がいない ● 自動化が困難 ○ PRが5件以上になったら自動Close？ ○ 障害対応中に自動Closeされたら…？ 過剰な並行作業への対策 WIP制限が定着しなかった理由

Slide 79

Slide 79 text

79 ©Social Databank, Inc. 「制限するのではなく、サポートする」 1. しばらく進んでないPRを見つける 2. 発生している問題を聞く 3. 解消の手を打つ 過剰な並行作業への対策 人間BOT これを BOTのように 週1で繰り返す

Slide 80

Slide 80 text

80 ©Social Databank, Inc. 具体的な問題と解消手段、難しいことはしてません ● テキストコミュニケーションだと難しいもの ● コメントに気づいてなかった ● レビュアーが他業務で忙しい 過剰な並行作業への対策 ペアプロ・ペアレビューを設定する 後追いで連絡する 他のレビュアーにアサインし直す

Slide 81

Slide 81 text

81 ©Social Databank, Inc. 過剰な並行作業への対策 人間BOTのポイント 🐺 人間が関わることで オオカミ少年化を防止

Slide 82

Slide 82 text

82 ©Social Databank, Inc. 過剰な並行作業への対策 人間BOTの成果 ① ● PR数が 30〜50件 で安定（2件/人）

Slide 83

Slide 83 text

83 ©Social Databank, Inc. 過剰な並行作業への対策 人間BOTの成果 ② ● モブプロ・モブレビューが 自然発生 ● チームの 朝会でも実施 されるように ● 5分で1PRマージ できることも DevOpsのプラクティスの浸透を実感

Slide 84

Slide 84 text

©Social Databank, Inc. 05 どう変わった

Slide 85

Slide 85 text

85 ©Social Databank, Inc. どう変わったか 1. 組織文化の変化 2. 定量指標の変化 3. 顧客や社内からの反応の変化 DevOps実践前後の変化をみる

Slide 86

Slide 86 text

86 ©Social Databank, Inc. どう変わったか 1. 組織文化の変化 2. 定量指標の変化 3. 顧客や社内からの反応の変化 DevOps実践前後の変化をみる

Slide 87

Slide 87 text

87 ©Social Databank, Inc. 組織文化の変化 　まずFeatureBranchを切る 昔 新機能の開発時… 　まずリリーストグルを作る 今

Slide 88

Slide 88 text

88 ©Social Databank, Inc. 組織文化の変化 　　大きいPRがあるのは仕方ない 昔 PRのサイズは… 　　小さくするのが当たり前 今

Slide 89

Slide 89 text

89 ©Social Databank, Inc. 組織文化の変化 　気にしない 昔 放置されたPRは… 　チームで毎日確認 今

Slide 90

Slide 90 text

90 ©Social Databank, Inc. どう変わったか 1. 組織文化の変化 2. 定量指標の変化 3. 顧客や社内からの反応の変化 DevOps実践前後の変化をみる

Slide 91

Slide 91 text

91 ©Social Databank, Inc. 定量指標の変化 PRマージ数の変化（全体） 始めたのがこのあたり 今このあたり

Slide 92

Slide 92 text

92 ©Social Databank, Inc. 定量指標の変化 PRマージ数の変化（1人あたり） 始める前 2年後の同時期 4.3件 40.9件 約10倍 マージ済み PR数

Slide 93

Slide 93 text

93 ©Social Databank, Inc. 定量指標の変化 リードタイムの変化 始める前 2年後の同時期 7週間 (622.6h) 3週間 (375.9h) 半分以下 リードタイム

Slide 94

Slide 94 text

94 ©Social Databank, Inc. どう変わったか 1. 組織文化の変化 2. 定量指標の変化 3. 顧客や社内からの反応の変化 DevOps実践前後の変化をみる

Slide 95

Slide 95 text

95 ©Social Databank, Inc. 即対応に感謝、感激！ 顧客や社内からの反応の変化 対応スピード改善によって 顧客や社内からも嬉しい声が 通達から3日くらい？で反映してくれた 予約の表示時間が正しく表示されない とのお客様からのお問い合わせに 1時間以内に不具合修正してくださった！

Slide 96

Slide 96 text

96 ©Social Databank, Inc. 顧客や社内からの反応の変化 対応スピード改善によって 顧客や社内からも嬉しい声が

Slide 97

Slide 97 text

97 ©Social Databank, Inc. 個人的な学び 技術的な解決法だけでなく泥臭い解決法もある 組織にDevOpsを定着させるには、 ● 考え方ではなく言動から変える ● プラクティスを実践するキッカケを作る

Slide 98

Slide 98 text

98 ©Social Databank, Inc. 伝えたいこと DevOpsの考え方を定着させるのはめっちゃ大変 でもその価値はある

Slide 99

Slide 99 text

©Social Databank, Inc.