数字を上げることが目的になっていませんか？/engineer festival 2023 Link and Motivation

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

View Slide

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

View Slide

3
リンクアンドモチベーションについて

View Slide

4
プロダクト紹介
働きがいあふれる社会へ

View Slide

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

View Slide

6
導入企業様
※2023年1月時点実績（https://www.motivation-cloud.com/）

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

19
…
開発者間の「協働」

View Slide

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

View Slide

21
本日話したいこと

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

32
自動化が必要

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

37
収集
GitHub
スプシ
Looker Studio
リードタイム
デプロイ頻度
MTTR
変更障害率
毎日同期
(SQL みたいに)
1行 = 1レコード

View Slide

38
収集
GitHub
スプシ
Looker Studio
データの加工
(Excel芸) は不要
毎日同期

View Slide

39
収集
GitHub
スプシ
Looker Studio
ノーコードで
ダッシュボード化
毎日同期

View Slide

40
データの収集について
Looker Studio は Google Sheets の１行を１レコードとして扱える。
※ 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
１行 = １レコード
複数レコードから一つの統計値を算出する
MEDIAN(4日, 2日, 1日) リードタイム = 2日

View Slide

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

View Slide

42
実際に作成したダッシュボード

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

48
チーム間の断絶
開発チーム ⇔ SRE チーム間の断絶！
が希薄
チームそれぞれの
仕事・目標の達成
が最優先
SRE だけでは
生産性向上できない
改善の為の明確な
チーム・役割・責務を決める

View Slide

49
新しいチームを結成する

View Slide

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

View Slide

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

View Slide

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

View Slide

53
Embedded SRE として
チームに埋め込む

View Slide

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

View Slide

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

View Slide

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

View Slide

57
SRE 個人を、ストリームアラインドチームの一員として「埋め込み」中から直接改善をする！
が希薄

View Slide

58
SRE 個人を、ストリームアラインドチームの一員として「埋め込み」中から直接改善をする！
が希薄
① 課題・原因の特定がしやすい
② 改善活動をチームと直接できる

View Slide

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

View Slide

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

View Slide

61
再開する際に気を効かせてくれて、PR (ブランチ) を作りなおす！
実装開始
１ヶ月前
PR を
作り直す
１週前
リリース
実装再開
３日前当日
リードタイム = ３日！？
(リードタイムの為に)
PR を作りなおそう！

View Slide

62
再開する際に気を効かせてくれて、PR (ブランチ) を作りなおす！
実装開始
１ヶ月前
PR を
作り直す
１週前
リリース
実装再開
３日前当日
リードタイム = ３日！？
(リードタイムの為に)
PR を作りなおそう！
「リードタイムを３日にする」
が目的になっている

View Slide

63
目標と目的
リードタイムを小さくする事の目的って何だ？
目標
リードタイム ≦ ３日
目的
？？？

View Slide

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

View Slide

65
実装
機能 A
実装リリース
リリース実装リリース実装リリース
最近は、スモールリリース・Feature toggle という手があるよね。
リードタイム → 大
機能 B
リードタイム → 小リードタイム → 小リードタイム → 小

View Slide

66
実装
機能 A
実装リリース
リリース実装リリース実装リリース
最近は、スモールリリース・Feature toggle という手があるよね。
リードタイム → 大
機能 B
リードタイム → 小リードタイム → 小リードタイム → 小
リードタイムの単位は
「機能」ではなく「PR」である！

View Slide

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

View Slide

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

View Slide

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

View Slide

70
リードタイム短縮の目的

View Slide

71
障害を減らしたい
リリースの複雑性
を減らしたい
スモールリリース・Feature toggle をする
目的
手段
目標
※ 弊社の開発組織のケースでの一例です。
全ての開発組織で一概にそうとは限りません。
① ②

View Slide

72
障害を減らしたい
リリースの複雑性
を減らしたい
スモールリリース・Feature toggle をする
目的
手段
目標
目的に立ち戻る為に
繰り返し伝える！

View Slide

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

View Slide

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

View Slide

76
…
開発者間の「協働」

View Slide

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

View Slide

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

View Slide

79
スピード・気軽さリリースのシンプルさ品質の高さ
す？」は大変
整！
できる
時間が掛かる
コストを払う
速度安定性
表裏一体
開発メトリクス

View Slide

80
スピード・気軽さリリースの複雑さ品質の高さ
す？」は大変
整！
できる
時間が掛かる
コストを払う
速度安定性
表裏一体
開発メトリクス
理想の姿へどの位到達したか
メトリクス = 達成指標

View Slide

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

View Slide

数字を上げることが目的になっていませんか？/engineer festival 2023 Link and Motivation

数字を上げることが目的になっていませんか？/engineer festival 2023 Link and Motivation

リンクアンドモチベーション

More Decks by リンクアンドモチベーション

Other Decks in Technology

Featured

Transcript

数字を上げることが 目的になっていませんか？/engineer festival 2023 Link and Motivation

数字を上げることが 目的になっていませんか？/engineer festival 2023 Link and Motivation

リンクアンドモチベーション

More Decks by リンクアンドモチベーション

Other Decks in Technology

Featured

Transcript

数字を上げることが目的になっていませんか？/engineer festival 2023 Link and Motivation

数字を上げることが目的になっていませんか？/engineer festival 2023 Link and Motivation