なぜ Four Keys を改善するのか？/productivity-con-link-and-motivation

© Link and Motivation
Group
なぜ Four Keys を改善するのか？
Developer Productivity ユニット / SRE グループ
川津雄介
〜How ではなく Why を重視したメトリクス改善活動〜

View Slide

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

View Slide

3
Group
リンクアンドモチベーションについて
327億円（2022年12月時点）
（2022年12月時点）
11社

View Slide

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

View Slide

モチベーションクラウド
診断
変革
※ 2022年度実績
10,060 社
312 万人

View Slide

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

View Slide

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

View Slide

8
Group
弊社開発組織の歴史
2016
2018
2019 2022
2023
モチベーションクラウド
のリリース
開発組織内製化のスタート
(Four Keys = Low レベル)
コミュニケーションクラウド
のリリース
ストレッチクラウド
のリリース
Four Keys メトリクス
High〜Elite レベルに到達
2020
SRE チームの誕生
弊社の開発組織は誕生して５年目です！
デプロイ頻度: 120 回/月
リードタイム: 1日
※モチベーションクラウド 5月実績

View Slide

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

View Slide

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

View Slide

11
Group
３つのプロダクトから成る、複数のチーム
社員約80名＋パートナーさん

View Slide

Group 12
本日お話したいこと

View Slide

13
Group
弊社では SRE が生産性改善を推進してきました
デプロイの自動化コンテナ化 IaC (Terraform)
Four Keys : Low 〜 Medium 時代

View Slide

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

View Slide

15
Group
…
開発者全員で
改善活動をしたい！

View Slide

16
Group
チームを横断した中央集権的な改善
改善活動の推進者
(SRE 等)
チーム B
チーム A
チーム C
課題の
調査・ヒアリング
サービス
X
サービス
Y

View Slide

17
Group
チーム B
チーム A
チーム C
対策立案
サービス
X
サービス
Y
(SRE 等)

View Slide

18
Group
チーム B
チーム A
チーム C
サービス
X
サービス
Y
具体的な
アクションの指示
(SRE 等)

View Slide

19
Group
どうやって全員で活動できるか？
一緒にメトリクス改善
をしようよ！
自分の仕事で忙しい
開発者
今のままで困ってない
(SRE 等)

View Slide

20
Group
チーム B
チーム A
チーム C
サービス
X
サービス
Y
【課題】お互いの主体性の偏り
生産性改善は自身の「ミッション」
しかし、サービス (コード)
へのオーナーシップは持っていない
(SRE 等)

View Slide

21
Group
(SRE 等)
チーム B
チーム A
チーム C
サービス
X
サービス
Y
生産性改善は彼らの
「ミッション」ではない
サービス (コード) のオーナーシップ
を持っており改善活動しやすい

View Slide

22
Group
SRE
チーム B
チーム A
チーム C
サービス
X
サービス
Y
具体的な
どうすれば全員が主体性を持って
改善活動に取り組めるか？

View Slide

23
Group
本日話したいこと

View Slide

24
Group
開発者全員で主体性を持って改善活動するには？
1
2
3
改善の「Why (目的)」を言語化する
チームの壁を超えて一丸となって改善する
改善のオーナーシップをチームに！

View Slide

Group 25
① 改善の「Why (目的)」を言語化する

View Slide

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

View Slide

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

View Slide

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

View Slide

29
Group
Why / How / What
リードタイム < ３日
How
(どうやって？)
What
(何を？)
リードタイム
３日以内を目指そう！
(SRE 等)
アプリ開発者
３日か〜。
どうやってやろうかな

View Slide

30
Group
How
What
(何を？)
アプリ開発者
３日か〜。
どうやってやろうかな
Why / How / What
リードタイム
３日以内を目指そう！
(SRE 等)
何で３日をめざすの？
(何に困ってるの？)

View Slide

31
Group
Why / How / What
How
What
(何を？)
Why
(なぜ？)
推進者 (リーダー)
がメンバーを効果的に動かすには
「Why」が肝心！

View Slide

32
Group
みんなが能動的に活動できる！
人は「何を」ではなく
「なぜ」に動かされるのです
What
How
ゴールデンサークル理論
Why
Why から始めよ
目的を見失わない為に
効果の無い How に
傾倒することが無い様に

View Slide

33
Group
実際にあった例

View Slide

34
Group
８名体制の新規プロジェクト
社員: ４名
パートナー: ４名

View Slide

35
Group
このチームの目標に「デプロイ頻度 = High」が入る
デプロイ頻度の「High」
を目指すぞ〜！！

View Slide

36
Group
当時「デプロイ頻度」を改善しようとしていた
０〜１回 / 週
５回 / 週
０〜１回 / 週５回 / 週
(当時)

View Slide

37
Group
改善の甲斐あって？目標値に近づいてきたが...
３〜４回 / 週

View Slide

38
Group
数値上は達成しつつあるが...
最近、生産性 (デプロイ頻度)
あがってきたよね！
いや、実は...
開発者
(SRE 等)

View Slide

39
Group
辛みが増している...！
一度のリリース作業に
３時間も拘束されて辛い！
リリースする人が偏ってて
なんか毎日リリース作業
してる！

View Slide

40
Group
あれ？俺たち「何で」こんな辛い思いして
「週５回」もリリースしなきゃいけないんだっけ？

View Slide

41
Group
あれ？俺たち「何で」こんな辛い思いして
「５回」もリリースしなきゃいけないんだっけ？
むしろ、生産性下がってない？
後日、２回/週がベスト
という結論に...

View Slide

42
Group
数値を「上げる」事が目的になってしまった...
デプロイ頻度
「High」達成！
How
What
(何を？)
Why
(なぜ？)
なぜ、デプロイ頻度を
上げないといけないのか？
(どんな良いことがあるか）
❌
⭕
どうやって
デプロイ頻度を上げよう？

View Slide

43
Group
２つの Why - 課題と目指す姿
デプロイ頻度
「High」達成！
How
なぜ？
低いのか？
なぜ？
低いとダメか？
原因
本当の課題と
目指す姿

View Slide

44
Group
How
なぜ？
低いのか？
原因
２つの Why - 課題と目指す姿
デプロイ頻度
「High」達成！
なぜ？
低いとダメか？
本当の課題と
目指す姿
これはみんな
するけど...
こっちが無いと間違った
ゴールの HOW になる

View Slide

45
Group
低いメトリクス値が示す意味は？
低いメトリクス
潜在した
課題
潜在した
課題
潜在した
課題
その時点の最大の
ボトルネック課題
あるべき理想
課題が解決した先の
理想の開発環境像をイメージ
できているか？
様々な要因が複合して
このメトリクスである
(要考：数値の意味)

View Slide

46
Group
何をあるべき姿として
目指していたのか？

View Slide

47
Group
そもそも...
デプロイ頻度リードタイム
…って、改善すると何が嬉しいの？？？

View Slide

48
Group
デプロイ頻度...？
デプロイ頻度
デプロイ回数が多い
生産量が多い？

View Slide

49
Group
デプロイ頻度...？
デプロイ頻度
生産量が多い？
小さいリリースの回数が多いだけかも...

View Slide

50
Group
デプロイ頻度が少ないと
１度のデプロイに
複数の Feature が混在している

View Slide

51
Group
もしこれがバグってたら...

View Slide

52
Group
全部まとめて切り戻し

View Slide

53
Group
マイグレ等が混ざってると
切り戻しに時間が掛かる
MTTR
コミュニケーション
コミュニケーション
単純に切り戻して
いいんだっけ？
マイグレあるから
待って！

View Slide

54
Group
デプロイ頻度が高い！

View Slide

55
Group
バグる

View Slide

56
Group
切り戻して、終わり

View Slide

57
Group
つまりデプロイ頻度とは...？
デプロイ頻度
？？？
※ 弊社の開発組織のケースでの一例です。
全ての開発組織で一概にそうとは限りません。

View Slide

58
Group
つまりデプロイ頻度とは...？
デプロイ頻度
安全な切り戻し
切り戻しや再リリースに掛かる工数減
MTTR の向上

View Slide

59
Group
リードタイム
リードタイム...?
マージまでの時間が短い
機能がリリースされるまでが速い？

View Slide

60
Group
リードタイム
リードタイム...?
機能がリリースされるまでが速い？
単に分割してマージしただけかも...

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

67
Group
リードタイム
つまりリードタイムとは...?
？？？

View Slide

68
Group
リードタイム短縮の目的
障害を減らしたい
リリースの複雑性
を減らしたい
スモールリリース・Feature toggle をする
リードタイム ≦ ３日
目的
手段
目標
① ②

View Slide

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

View Slide

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

View Slide

71
Group
各メトリクスは繋がっている...
デプロイ頻度リードタイム
変更障害率
MTTR

View Slide

72
Group
メトリクス値から、生産性課題 → あるべき理想の姿を見つける
潜在した
課題
潜在した
課題
潜在した
課題
あるべき理想

View Slide

Group 74
② チームの壁を超えて一丸となって改善する

View Slide

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

View Slide

76
Group
チーム B
チーム A
チーム C
サービス
X
サービス
Y
生産性改善は自身の「ミッション」
しかし、サービス (コード)
へのオーナーシップは持っていない
(SRE 等)

View Slide

77
Group
(SRE 等)
チーム B
チーム A
チーム C
サービス
X
サービス
Y

View Slide

78
Group
(SRE 等)
チーム B
チーム A
チーム C
サービス
X
サービス
Y
改善の為の明確な
チーム・役割・責務を決めるべき

View Slide

79
Group
新しいチームを結成する

View Slide

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

View Slide

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

View Slide

82
Group
チーム B
開発者のミッション・目標と結節
チーム A チーム C
各所属チームへの結節点となる
各所属チームへの結節点となる

View Slide

83
Group
逆に、チームに埋め込む

View Slide

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

View Slide

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

View Slide

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

View Slide

87
Group
改善チームを結成する
一定期間だけ
チームを異動します！
改善の推進者をストリームアラインドチームの
一員として「埋め込み」中から直接改善をする！
生産性改善チーム

View Slide

88
Group
改善チームを結成する
一定期間だけ
チームを異動します！
改善の推進者をストリームアラインドチームの
一員として「埋め込み」中から直接改善をする！
① 課題・原因の特定がしやすい
② 改善活動をチームと直接できる

View Slide

Group 89
③ 改善のオーナーシップをチームに！

View Slide

90
Group
改善推進者が主体の指示型
チーム B
チーム A
チーム C
サービス
X
サービス
Y
具体的な
(SRE 等)

View Slide

91
Group
組織の規模が拡大すると現実的ではなくなる
チーム B
チーム A
チーム C
サ
|
ビ
ス
X
Y
チーム B
チーム A
チーム C
サ
|
ビ
ス
Z
…
中央集権的にやる限界
(SRE 等)

View Slide

92
Group
組織の規模が拡大すると現実的ではなくなる
SRE
チーム B
チーム A
チーム C
サ
|
ビ
ス
X
Y
チーム B
チーム A
チーム C
サ
|
ビ
ス
Z
…
SRE も一緒にスケール
するのは微妙
どうすべき？

View Slide

93
Group
(SRE 等)
改善のオーナーシップを「チーム」に
チーム B
チーム A
チーム C
サービス
X
サービス
Y
チーム内に
「改善係」を置く？
チーム内に
チーム内に

View Slide

94
Group
※ Team Topologies より抜粋

View Slide

95
Group
チームに計測＆改善のプロセスをインストールする
チーム B
チーム A
(SRE 等)

View Slide

96
Group
チームに計測＆改善のプロセスをインストールする
チーム B
チーム A
(SRE 等)
+
+
イネーブリング
改善活動はみんなの責務
あくまで
一時的にJOIN

View Slide

97
Group
何をチームにインストールするのか？
メトリクス計測
の自動化
改善運用 /
プロセス What
How
Why
Why から
始める思想

View Slide

98
Group
の自動化
改善運用 /
プロセス What
How
Why
Why から
始める思想
Github 等から計測
ダッシュボード化

View Slide

99
Group
の自動化
改善運用 /
プロセス What
How
Why
Why から
始める思想
まずはチームの
会議体から
必要に応じて、チーム
の目標に組み込む

View Slide

100
Group
の自動化
改善運用 /
プロセス What
How
Why
Why から
始める思想
推進者が並走して
指導する必要がある

View Slide

Group 101
さいごに

View Slide

102
Group
開発生産性の活動に銀の弾丸はない

View Slide

103
Group
開発生産性の活動に銀の弾丸はない
HOW の話だから

View Slide

104
Group
組織の規模・形態が違う
チーム A チーム A
チーム B
チーム C
チーム
横断して
A
事業部
チーム内の
B
事業部
C
事業部
横断して組織・全社で

View Slide

105
Group
プロダクトの開発特性が違う
例えば、master 一本ではなく
特注リリースがあるとか
B to B / B to C とかで
メトリクスの意味も異なる

View Slide

106
Group
メトリクスが低い原因は一つではない
例えばデプロイ頻度が低い原因も、それぞれの現場で様々ある...
リリースする物はあ
るが CI・CD、自動
化が出来ていないと
か...
そもそも、一日あた
りにマージされる
Feature が少ないと
か...
インシデントが多発し
ており、その対応やリ
リース時のテスト工数
とか...

View Slide

107
Group
メトリクス値から、生産性課題 → あるべき理想の姿を見つける
潜在した
課題
潜在した
課題
潜在した
課題
あるべき理想

View Slide

108
Group
メトリクス値が示す真の意味を考えたい
潜在した
課題
潜在した
課題
潜在した
課題
あるべき理想
「Why」を考えよう！

View Slide

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

View Slide

なぜ Four Keys を改善するのか？/productivity-con-link-and-motivation

なぜ Four Keys を改善するのか？/productivity-con-link-and-motivation

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

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

Other Decks in Technology

Featured

Transcript