Slide 1

Slide 1 text

© Link and Motivation Group 数字を上げることが 目的になっていませんか? プロダクトデザイン室 SREユニット 川津雄介 Four Keysによる開発生産性向上で陥った3つの失敗

Slide 2

Slide 2 text

2 © Link and Motivation Group 自己紹介 川津 雄介 株式会社リンクアンドモチベーション SRE ● 前職は某複写機メーカーでエンジニアしてた ● OSレイヤーからWeb/モバイルまで何でもやる ● 中途の採用活動もします ● リンクアンドモチベーションではSREとして開発 室全体の生産性向上に注力! https://github.com/megmogmog1965 https://qiita.com/megmogmog1965

Slide 3

Slide 3 text

3 © Link and Motivation Group リンクアンドモチベーションについて

Slide 4

Slide 4 text

4 © Link and Motivation Group プロダクト紹介 働きがい あふれる社会へ

Slide 5

Slide 5 text

5 © Link and Motivation Group モチベーションクラウド 診断 変革 ※ 2021年度 実績 8,740 社 237 万人

Slide 6

Slide 6 text

6 © Link and Motivation Group 導入企業様 ※2023年1月時点実績(https://www.motivation-cloud.com/)

Slide 7

Slide 7 text

© Link and Motivation Group 7 リンクアンドモチベーションの SRE と開発組織

Slide 8

Slide 8 text

8 © Link and Motivation Group 弊社開発組織の歴史 2016 2018 2019 2022 2022 末 モチベーションクラウド のリリース 開発組織内製化のスタート (Four Keys = Low レベル) コミュニケーションクラウド のリリース ストレッチクラウド のリリース Four Keys メトリクス High レベルに到達 2020 SRE チームの誕生 弊社の開発組織は誕生して5年目です!

Slide 9

Slide 9 text

9 © Link and Motivation Group SRE チームの遷移 (Team Topologies 風に言うと...) 4つのチームタイプ ※ 出典:「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」より

Slide 10

Slide 10 text

10 © Link and Motivation Group SRE チームの遷移 (Team Topologies 風に言うと...) インタラクションモード (チーム間の関わり方を示す) ※ 出典:「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」より

Slide 11

Slide 11 text

11 © Link and Motivation Group 1年前 → Medium レベル インフラや CI/CD (仕組み) を一方的に提供していた。

Slide 12

Slide 12 text

12 © Link and Motivation Group 現在 → High レベル 開発者と協働し、課題解決に取り組む。

Slide 13

Slide 13 text

© Link and Motivation Group 13 開発生産性を示す Four Keys メトリクス

Slide 14

Slide 14 text

14 © Link and Motivation Group Four Keys メトリクス 出典: https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now- out?hl=en Four Key メトリクスは、DevOps Research and Assessment(DORA) チームが実施した 研究が出典のソフトウェア開発チームのパフォーマンスを示す 4 つの指標です。

Slide 15

Slide 15 text

15 © Link and Motivation Group Four Keys メトリクス 出典: https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now- out?hl=en 「速度」と「安定性」の指標。お互いが密接な関係にありバランスが重要です。 デプロイ頻度 リードタイム MTTR 変更障害率 デプロイが原因で本番環境で障害が発 生する割合(%) 組織が本番環境での障害から回復する のにかかる平均時間 First commit から本番環境稼働までの 所要時間 本番環境へのリリースの頻度 速度 安定性

Slide 16

Slide 16 text

© Link and Motivation Group 16 本日お話したいこと 〜 SRE と開発者が「協働」する為に 〜

Slide 17

Slide 17 text

17 © Link and Motivation Group SRE で課題解決し一方的に押し付けてきた デプロイの自動化 コンテナ化 IaC (Terraform) Four Keys : Low 〜 Medium 時代

Slide 18

Slide 18 text

18 © Link and Motivation Group 遠い (苦手) 近い (得意) インフラの仕組みだけで解決できる限界 SRE アプリ開発者 インフラ CI / CD メトリクス SRE (インフラエンジニア発) は、どうしてもインフラ側から改善しがち。 ブランチング モデル テストコード E2E テスト アプリコード

Slide 19

Slide 19 text

19 © Link and Motivation Group … 開発者間の「協働」

Slide 20

Slide 20 text

20 © Link and Motivation Group どうやって「協働」できるか? 一緒にメトリクス改善 をしようよ! 自分の仕事で忙しい SRE 開発者 今のままで困ってない

Slide 21

Slide 21 text

21 © Link and Motivation Group 本日話したいこと

Slide 22

Slide 22 text

22 © Link and Motivation Group SRE と開発者が協働して進めるには? 1 2 3 開発生産性・メトリクスの基準を統一する 改善活動をみんなの目標にする 数値を上げる意味・目的を共有する

Slide 23

Slide 23 text

© Link and Motivation Group 23 ① 開発生産性・メトリクスの基準を統一する

Slide 24

Slide 24 text

24 © Link and Motivation Group 生産性の議論を始める為に SRE 開発者 共通の指標 コミュニケーション 議論をする為の共通のネタ「指標」が必要。

Slide 25

Slide 25 text

25 © Link and Motivation Group SRE が手動でメトリクス集計をしてました 長らく、SRE が手動でメトリクス集計&可視化をしていました。 SRE 週に1度だけ 更新する! あ、先週更新するの 忘れてた...

Slide 26

Slide 26 text

26 © Link and Motivation Group SRE が手動でメトリクス集計をしてました 長らく、SRE が手動でメトリクス集計&可視化をしていました。 SRE 週に1度だけ 更新する! あ、先週更新するの 忘れてた... 改善に繋がらない!

Slide 27

Slide 27 text

27 © Link and Motivation Group 生産性課題を特定する為に必要な情報 量・頻度・正確さ の掛け算。 量 頻度 正確さ 課題の分析をする為に、 様々な面の情報が 取得できている事 最新の情報が毎日更新・記録 できている事 情報が正確で信頼できる事

Slide 28

Slide 28 text

28 © Link and Motivation Group ① 情報の量 今月の PR は 100 件でした 25 th% は「0〜3日」 XXX さんの PR は7日超えが多い 今月のリードタイムは「7日」 もっと細かく・視点を変えて見ると...

Slide 29

Slide 29 text

29 © Link and Motivation Group ② 情報の更新頻度 振り返りの期間は多種多様。 (相対・絶対 / 日・週・月) 11月 第2週 12月 第3週 第4週 今日 過去2週間 (相対) 1週目 2週目 月で振り返りたい

Slide 30

Slide 30 text

30 © Link and Motivation Group ② 情報の更新頻度 振り返りの期間は多種多様。 (相対・絶対 / 日・週・月) 11月 第2週 12月 第3週 第4週 今日 過去2週間 (相対) 1週目 2週目 月で振り返りたい 毎日メトリクス集計できているとベスト

Slide 31

Slide 31 text

31 © Link and Motivation Group ③ 情報の正確さ 情報 (ミス 0%) 機械 人間 情報 (ミス 5%) 開発者 (頻度低くても) ミスの可能性があると 見る気を無くす 自動 手作業 ❌

Slide 32

Slide 32 text

32 © Link and Motivation Group 自動化が必要

Slide 33

Slide 33 text

33 © Link and Motivation Group メトリクス・ダッシュボード自動化に求められる要件 全自動 リアルタイム性 変更容易性 ダッシュボード要件 見たい時に見たい情報が得ら れないと、開発者は見る気を 無くす メトリクスを計測する事自体 が SRE の負担 (トイル) にな ってはならない メトリクスの具体的な計測方 法は、利用しているツールだ けでなく、開発組織の状況に よって常に変わる

Slide 34

Slide 34 text

34 © Link and Motivation Group 変更に強いメトリクス集計 ツールだけでなく、開発組織や事業のフェーズによって、集計方法は都度変わる。 ブランチングモデル が変わったり... インシデント対応 プロセスが変わる等

Slide 35

Slide 35 text

35 © Link and Motivation Group 最近はメトリクス集計をする外部サービスもあるよね SRE 始めたての若い組織は、実績が足りないので 外部サービス (※お金掛かる) をうまく活用できるか、判断がつかない。 初めはタダで出来る範囲で 経験値を積んでからかなぁ...

Slide 36

Slide 36 text

36 © Link and Motivation Group Dashboard アーキテクチャ 収集 データ加工 → 可視化 GitHub スプシ Google Sheets Google Looker Studio

Slide 37

Slide 37 text

37 © Link and Motivation Group Dashboard アーキテクチャ 収集 データ加工 → 可視化 GitHub スプシ Google Sheets Google Looker Studio リードタイム デプロイ頻度 MTTR 変更障害率 毎日同期 (SQL みたいに) 1行 = 1レコード

Slide 38

Slide 38 text

38 © Link and Motivation Group Dashboard アーキテクチャ 収集 データ加工 → 可視化 GitHub スプシ Google Sheets Google Looker Studio データの加工 (Excel芸) は不要 毎日同期

Slide 39

Slide 39 text

39 © Link and Motivation Group Dashboard アーキテクチャ 収集 データ加工 → 可視化 GitHub スプシ Google Sheets Google Looker Studio ノーコードで ダッシュボード化 毎日同期

Slide 40

Slide 40 text

40 © Link and Motivation Group データの収集について Looker Studio は Google Sheets の1行を1レコードとして扱える。 ※ RDB の SQL みたいな感じ. タイトル 作成者 URL First commit Merged バグ修正 B さん https://… 2022-10- 23T02:00:00Z 2022-10-27T04:00:00Z リファクタ B さん https://… 2022-10- 26T04:00:00Z 2022-10-28T05:00:00Z Typo C さん https://… 2022-10- 28T05:00:00Z 2022-10-28T06:00:00Z 1行 = 1レコード 複数レコードから一つの統計値を算出する MEDIAN(4日, 2日, 1日) リードタイム = 2日

Slide 41

Slide 41 text

41 © Link and Motivation Group データの閲覧について 「X軸=日 / Y軸=リードタイム」 のグラフ

Slide 42

Slide 42 text

42 © Link and Motivation Group 実際に作成したダッシュボード

Slide 43

Slide 43 text

43 © Link and Motivation Group 参考リンク 宜しければこちらもご覧下さい。 ● https://speakerdeck.com/lmi/sre-lounge-2023?slide=35 ● https://link-and-motivation.hatenablog.com/entry/four-keys-metrics- dashboard

Slide 44

Slide 44 text

© Link and Motivation Group 44 ② 改善活動をみんなの目標にする

Slide 45

Slide 45 text

45 © Link and Motivation Group アプリ開発者の仕事 SRE 開発者 当然ですが、アプリ開発者は毎日すごく忙しい。 リファクタリング 顧客要求の機能開発 日々の顧客対応 インシデント対応 生産性の改善活動

Slide 46

Slide 46 text

46 © Link and Motivation Group 遠い (苦手) 近い (得意) アプリケーション領域の改善 SRE アプリ開発者 インフラ CI / CD ブランチング モデル テストコード E2E テスト アプリコード メトリクス アプリケーション領域の改善には、開発者の協力が必須!

Slide 47

Slide 47 text

47 © Link and Motivation Group チーム間の断絶 開発チーム ⇔ SRE チーム 間の断絶! コミュニケーションパス が希薄 チームそれぞれの 仕事・目標の達成 が最優先 SRE だけでは 生産性向上できない

Slide 48

Slide 48 text

48 © Link and Motivation Group チーム間の断絶 開発チーム ⇔ SRE チーム 間の断絶! コミュニケーションパス が希薄 チームそれぞれの 仕事・目標の達成 が最優先 SRE だけでは 生産性向上できない 改善の為の明確な チーム・役割・責務を決める

Slide 49

Slide 49 text

49 © Link and Motivation Group 新しいチームを結成する

Slide 50

Slide 50 text

50 © Link and Motivation Group 各チームから協力者を選出 横断チームを結成する! 開発チーム A 開発チーム B 開発チーム C 各ストリームアラインドチーム から活動に興味高そうな人を選出 各ストリームアラインドチーム から活動に興味高そうな人を選出 各ストリームアラインドチーム から活動に興味高そうな人を選出

Slide 51

Slide 51 text

51 © Link and Motivation Group 開発者のミッション・目標と結節 開発チーム A 開発チーム B 開発チーム C 事業部目標 個人目標 弊社の 2022/4Q の 事業部全体の目標に 生産性向上が入っていた ボランティアではなく 正式に個人の仕事にする

Slide 52

Slide 52 text

52 © Link and Motivation Group 改善チームを結成する 改善プロジェクトに即した、実際の活動体 (チーム・会議体) を設計する。 SRE と 開発者の 混合チーム 新しい横断チーム 会議体 共通の目標

Slide 53

Slide 53 text

53 © Link and Motivation Group Embedded SRE として チームに埋め込む

Slide 54

Slide 54 text

54 © Link and Motivation Group 障害が多発! 当時、プロダクトの障害が多発しており「変更障害率」が非常に高い状態にあった... デプロイ頻度 リードタイム MTTR 変更障害率

Slide 55

Slide 55 text

55 © Link and Motivation Group 障害が多発! 頑張ってヒアリングをするも、外からでは分からない事は多い! それぞれのチームで 何が原因で障害が増え ているんだろう? ヒアリングしてみたけ ど、いまいちはっきり しないぞ

Slide 56

Slide 56 text

56 © Link and Motivation Group 障害が多発! 頑張ってヒアリングをするも、外からでは分からない事は多い! それぞれのチームで 何が原因で障害が増え ているんだろう? ヒアリングしてみたけ ど、いまいちはっきり しないぞ チームの一員になって 活動すると分かりそう!

Slide 57

Slide 57 text

57 © Link and Motivation Group 改善チームを結成する SRE 個人を、ストリームアラインドチームの一員として「埋め込み」中から直接改善をする! コミュニケーションパス が希薄

Slide 58

Slide 58 text

58 © Link and Motivation Group 改善チームを結成する SRE 個人を、ストリームアラインドチームの一員として「埋め込み」中から直接改善をする! コミュニケーションパス が希薄 ① 課題・原因の特定がしやすい ② 改善活動をチームと直接できる

Slide 59

Slide 59 text

© Link and Motivation Group 59 ③ 数値を上げる意味・目的を共有する

Slide 60

Slide 60 text

60 © Link and Motivation Group 実際にあった怖い話 (リードタイム) とある PR を1ヶ月放置していた。 実装開始 1ヶ月前 1週前 放置期間 (※別件で忙しかった) 実装再開 (1ヶ月経って) やっと再開できるぞ!

Slide 61

Slide 61 text

61 © Link and Motivation Group 実際にあった怖い話 (リードタイム) 再開する際に気を効かせてくれて、PR (ブランチ) を作りなおす! 実装開始 1ヶ月前 PR を 作り直す 1週前 リリース 放置期間 (※別件で忙しかった) 実装再開 3日前 当日 リードタイム = 3日 !? (リードタイムの為に) PR を作りなおそう!

Slide 62

Slide 62 text

62 © Link and Motivation Group 実際にあった怖い話 (リードタイム) 再開する際に気を効かせてくれて、PR (ブランチ) を作りなおす! 実装開始 1ヶ月前 PR を 作り直す 1週前 リリース 放置期間 (※別件で忙しかった) 実装再開 3日前 当日 リードタイム = 3日 !? (リードタイムの為に) PR を作りなおそう! 「リードタイムを3日にする」 が目的になっている

Slide 63

Slide 63 text

63 © Link and Motivation Group 目標と目的 リードタイムを小さくする事の目的って何だ? 目標 リードタイム ≦ 3日 目的 ???

Slide 64

Slide 64 text

64 © Link and Motivation Group リードタイム (値) が表す意味 リードタイムの定義は「First Commit → リリース」までの日数。 First Commit 5日前 1日前 リリース 一つの PR・Feature を リリースするのに掛かった日数 master マージ 当日 機能? プロジェクト?

Slide 65

Slide 65 text

65 © Link and Motivation Group リードタイム (値) が表す意味 実装 機能 A 実装 リリース リリース 実装 リリース 実装 リリース 最近は、スモールリリース・Feature toggle という手があるよね。 リードタイム → 大 機能 B リードタイム → 小 リードタイム → 小 リードタイム → 小

Slide 66

Slide 66 text

66 © Link and Motivation Group リードタイム (値) が表す意味 実装 機能 A 実装 リリース リリース 実装 リリース 実装 リリース 最近は、スモールリリース・Feature toggle という手があるよね。 リードタイム → 大 機能 B リードタイム → 小 リードタイム → 小 リードタイム → 小 リードタイムの単位は 「機能」ではなく「PR」である!

Slide 67

Slide 67 text

67 © Link and Motivation Group 1 PR PR 大 vs 小 PR を小さくすると、レビュー&テスト品質が上がる。 1 PR 1 PR 1 PR 実装とその影響範囲を見きれず 設計観点のチェックになる コードの1行までレビューできる 変更影響の特定が難しく、 全件リグレッションテストが多発 変更に対し最小のテストを実施 ✅ ✅ ❌ ❌

Slide 68

Slide 68 text

68 © Link and Motivation Group PR 大 vs 小 巨大な PR あるある コードがコンフリクトして大変 A がマージされないと B がテスト開始できない リリース日程調整でコミュニケーションコスト高

Slide 69

Slide 69 text

69 © Link and Motivation Group PR 大 vs 小 PR が十分に小さいと... コンフリクトしない / しても簡単に直すだけ 自分の Feature のテストだけしたらいい リリース日程調整は不要

Slide 70

Slide 70 text

70 © Link and Motivation Group リードタイム短縮の目的

Slide 71

Slide 71 text

71 © Link and Motivation Group リードタイム短縮の目的 障害を減らしたい リリースの複雑性 を減らしたい スモールリリース・Feature toggle をする リードタイム ≦ 3日 目的 手段 目標 ※ 弊社の開発組織のケースでの一例です。 全ての開発組織で一概にそうとは限りません。 ① ②

Slide 72

Slide 72 text

72 © Link and Motivation Group リードタイム短縮の目的 障害を減らしたい リリースの複雑性 を減らしたい スモールリリース・Feature toggle をする リードタイム ≦ 3日 目的 手段 目標 目的に立ち戻る為に 繰り返し伝える!

Slide 73

Slide 73 text

73 © Link and Motivation Group e.g. Rails アップデート ビッグバンリリース ※ リリースめちゃ怖〜 スモールリリース PR 数 変更ファイル / PR 1〜2 PR(s) 100 files PR 数 変更ファイル / PR 80 PR(s) 1〜2 files 弊社 Rails アップデートの今と昔。

Slide 74

Slide 74 text

74 © Link and Motivation Group e.g. Rails アップデート 小さな互換性のあるリリースを繰り返す。 互換 リリース 1回目 80回目 最終 リリース 新・旧 どちらの Rails Version でも動く 互換コードを先行リリースする 互換 リリース 最後の1回 最後にやっと Rails の Version を上げる + 一部の非互換コード ・・・ (スモールリリース) ・・・ x8 0 ・・・

Slide 75

Slide 75 text

© Link and Motivation Group 75 #devキャリ2022 まとめ

Slide 76

Slide 76 text

76 © Link and Motivation Group … 開発者間の「協働」

Slide 77

Slide 77 text

77 © Link and Motivation Group 開発者みんなで「協働」して改善を進める為に 1 2 3 メトリクス集計は自動化&ダッシュボード化しよう! 改善活動の横断チームを作り、ちゃんと仕事化 (目標) する! 数値を追うのではなく、目的・目指す姿を明確にしよう!

Slide 78

Slide 78 text

78 © Link and Motivation Group 開発者体験 = 幸せ が高い組織 「理想の姿」を証明する為の「数値」であれ スピード・気軽さ リリースの複雑さ 品質の高さ ● リリース調整「〜はい つ出す?」は大変 ● 一つ遅れると、全部再 調整! ● 小さな改善をすぐにリ リースできる ● リリース承認等のプロ セスで時間が掛かる ● 障害が発生すれば、対 応にコストを払う ● 気軽なリリースができ なくなる

Slide 79

Slide 79 text

79 © Link and Motivation Group 開発者体験 = 幸せ が高い組織 「理想の姿」を証明する為の「数値」であれ スピード・気軽さ リリースの複雑さ 品質の高さ ● リリース調整「〜はい つ出す?」は大変 ● 一つ遅れると、全部再 調整! ● 小さな改善をすぐにリ リースできる ● リリース承認等のプロ セスで時間が掛かる ● 障害が発生すれば、対 応にコストを払う ● 気軽なリリースができ なくなる 速度 安定性 表裏一体 開発メトリクス

Slide 80

Slide 80 text

80 © Link and Motivation Group 開発者体験 = 幸せ が高い組織 「理想の姿」を証明する為の「数値」であれ スピード・気軽さ リリースの複雑さ 品質の高さ ● リリース調整「〜はい つ出す?」は大変 ● 一つ遅れると、全部再 調整! ● 小さな改善をすぐにリ リースできる ● リリース承認等のプロ セスで時間が掛かる ● 障害が発生すれば、対 応にコストを払う ● 気軽なリリースができ なくなる 速度 安定性 表裏一体 開発メトリクス 理想の姿へどの位到達したか メトリクス = 達成指標

Slide 81

Slide 81 text

© Link and Motivation Group 81 #devキャリ2022 さいごに

Slide 82

Slide 82 text

82 © Link and Motivation Group お知らせ ● エンジニアリングマネージャー ● プロダクトマネージャー ● テックリード ● サーバーサイドエンジニア ● フロントエンドエンジニア ● SRE ● QAエンジニア ● データエンジニア ● CRM ● UXデザイナー 週1でテックブログを更新中! まずはカジュアルにお話しましょう! 積極採用中です!