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

Slide 1

Slide 1 text

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 リンクアンドモチベーションについて 327億円（2022年12月時点）（2022年12月時点） 11社

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Slide 8

Slide 8 text

8 © Link and Motivation Group 弊社開発組織の歴史 2016 2018 2019 2022 2023 モチベーションクラウドのリリース開発組織内製化のスタート (Four Keys = Low レベル) コミュニケーションクラウドのリリースストレッチクラウドのリリース Four Keys メトリクス High〜Elite レベルに到達 2020 SRE チームの誕生弊社の開発組織は誕生して５年目です！デプロイ頻度: 120 回/月リードタイム: 1日 ※モチベーションクラウド 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 ３つのプロダクトから成る、複数のチーム社員約80名＋パートナーさん

Slide 12

Slide 12 text

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

17 © Link and Motivation Group チームを横断した中央集権的な改善チーム B チーム A チーム C 対策立案サービス X サービス Y 改善活動の推進者 (SRE 等)

Slide 18

Slide 18 text

18 © Link and Motivation Group チームを横断した中央集権的な改善チーム B チーム A チーム C サービス X サービス Y 具体的なアクションの指示改善活動の推進者 (SRE 等)

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

21 © Link and Motivation Group 改善活動の推進者 (SRE 等) 【課題】お互いの主体性の偏りチーム B チーム A チーム C サービス X サービス Y 生産性改善は彼らの「ミッション」ではないサービス (コード) のオーナーシップを持っており改善活動しやすい

Slide 22

Slide 22 text

22 © Link and Motivation Group チームを横断した中央集権的な改善 SRE チーム B チーム A チーム C サービス X サービス Y 具体的なアクションの指示どうすれば全員が主体性を持って改善活動に取り組めるか？

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

29 © Link and Motivation Group Why / How / What リードタイム < ３日 How (どうやって？) What (何を？) リードタイム３日以内を目指そう！改善活動の推進者 (SRE 等) アプリ開発者３日か〜。どうやってやろうかな

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

31 © Link and Motivation Group Why / How / What リードタイム < ３日 How (どうやって？) What (何を？) Why (なぜ？) 推進者 (リーダー) がメンバーを効果的に動かすには「Why」が肝心！

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

33 © Link and Motivation Group 実際にあった例

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

35 © Link and Motivation Group このチームの目標に「デプロイ頻度 = High」が入るデプロイ頻度の「High」を目指すぞ〜！！改善活動の推進者

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

38 © Link and Motivation Group 数値上は達成しつつあるが... 最近、生産性 (デプロイ頻度) あがってきたよね！いや、実は... 開発者改善活動の推進者 (SRE 等)

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

40 © Link and Motivation Group 辛みが増している...！あれ？俺たち「何で」こんな辛い思いして「週５回」もリリースしなきゃいけないんだっけ？

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

43 © Link and Motivation Group ２つの Why - 課題と目指す姿デプロイ頻度「High」達成！ How (どうやって？) なぜ？低いのか？なぜ？低いとダメか？原因本当の課題と目指す姿

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

51 © Link and Motivation Group デプロイ頻度が少ないともしこれがバグってたら...

Slide 52

Slide 52 text

52 © Link and Motivation Group デプロイ頻度が少ないと全部まとめて切り戻し

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

54 © Link and Motivation Group デプロイ頻度が高い！

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 つまりデプロイ頻度とは...？デプロイ頻度デプロイ回数が多い？？？ ※ 弊社の開発組織のケースでの一例です。全ての開発組織で一概にそうとは限りません。

Slide 58

Slide 58 text

58 © Link and Motivation Group つまりデプロイ頻度とは...？デプロイ頻度デプロイ回数が多い安全な切り戻し切り戻しや再リリースに掛かる工数減 ※ 弊社の開発組織のケースでの一例です。全ての開発組織で一概にそうとは限りません。 MTTR の向上

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

67 © Link and Motivation Group リードタイムつまりリードタイムとは...? マージまでの時間が短い？？？

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

69 © 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 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

72 © Link and Motivation Group メトリクス値から、生産性課題 → あるべき理想の姿を見つける低いメトリクス潜在した課題潜在した課題潜在した課題その時点の最大のボトルネック課題あるべき理想課題が解決した先の理想の開発環境像をイメージできているか？様々な要因が複合してこのメトリクスである (要考：数値の意味)

Slide 73

Slide 73 text

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

77 © Link and Motivation Group 改善活動の推進者 (SRE 等) 【課題】お互いの主体性の偏りチーム B チーム A チーム C サービス X サービス Y 生産性改善は彼らの「ミッション」ではないサービス (コード) のオーナーシップを持っており改善活動しやすい

Slide 77

Slide 77 text

78 © Link and Motivation Group 改善活動の推進者 (SRE 等) 【課題】お互いの主体性の偏りチーム B チーム A チーム C サービス X サービス Y 生産性改善は彼らの「ミッション」ではないサービス (コード) のオーナーシップを持っており改善活動しやすい改善の為の明確なチーム・役割・責務を決めるべき

Slide 78

Slide 78 text

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

Slide 84

Slide 84 text

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

Slide 89

Slide 89 text

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

93 © Link and Motivation Group 改善活動の推進者 (SRE 等) 改善のオーナーシップを「チーム」にチーム B チーム A チーム C サービス X サービス Y チーム内に「改善係」を置く？チーム内に「改善係」を置く？チーム内に「改善係」を置く？

Slide 93

Slide 93 text

Slide 94

Slide 94 text

Slide 95

Slide 95 text

Slide 96

Slide 96 text

Slide 97

Slide 97 text

Slide 98

Slide 98 text

99 © Link and Motivation Group 何をチームにインストールするのか？メトリクス計測の自動化改善運用 / プロセス What How Why Why から始める思想まずはチームの会議体から必要に応じて、チームの目標に組み込む

Slide 99

Slide 99 text

Slide 100

Slide 100 text

Slide 101

Slide 101 text

Slide 102

Slide 102 text

Slide 103

Slide 103 text

Slide 104

Slide 104 text

Slide 105

Slide 105 text

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

Slide 106

Slide 106 text

107 © Link and Motivation Group メトリクス値から、生産性課題 → あるべき理想の姿を見つける低いメトリクス潜在した課題潜在した課題潜在した課題その時点の最大のボトルネック課題あるべき理想課題が解決した先の理想の開発環境像をイメージできているか？様々な要因が複合してこのメトリクスである (要考：数値の意味)

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

Slide 109

Slide 109 text

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