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

エンジニア文化祭 2023
登壇資料（2023/03/03）
『数字を上げることが 目的になっていませんか？
Four Keysによる開発生産性向上で陥った3つの失敗』
https://scout.forkwell.com/event/engineer-festival-2023/
#Forkwell文化祭_A #リンクアンドモチベーション #リンモチ
=============================================
【株式会社リンクアンドモチベーション】
■お問い合わせ
　engineer_pr@lmi.ne.jp
■Entrancebook
　https://note.com/lmi/n/n179505e048f4
■テックブログ
　https://link-and-motivation.hatenablog.com/
■登壇者 川津インタビュー
　https://www.wantedly.com/companies/lmi/post_articles/431391
=============================================

Transcript

1. © Link and Motivation Group 数字を上げることが 目的になっていませんか？ プロダクトデザイン室 SREユニット 川津雄介 Four Keysによる開発生産性向上で陥った3つの失敗
2. 2 © Link and Motivation 自己紹介 川津 雄介 株式会社リンクアンドモチベーション SRE • 前職は某複写機メーカーでエンジニアしてた • OSレイヤーからWeb/モバイルまで何でもやる • 中途の採用活動もします • リンクアンドモチベーションではSREとして開発 室全体の生産性向上に注力！ https://github.com/megmogmog1965 https://qiita.com/megmogmog1965
3. 3 © Link and Motivation リンクアンドモチベーションについて
4. 4 © Link and Motivation プロダクト紹介 働きがい あふれる社会へ
5. 5 © Link and Motivation モチベーションクラウド 診断 変革 ※ 2021年度 実績 8,740 社 237 万 人
6. 6 © Link and Motivation 導入企業様 ※2023年1月時点実績（https://www.motivation-cloud.com/）
7. © Link and Motivation Group 7 リンクアンドモチベーションの SRE と開発組織
8. 8 © Link and Motivation 弊社開発組織の歴史 2016 2018 2019 2022 2022 末 モチベーションクラウド のリリース 開発組織内製化のスタート (Four Keys = Low レベル) コミュニケーションクラウド のリリース ストレッチクラウド のリリース Four Keys メトリクス High レベルに到達 2020 SRE チームの誕生 弊社の開発組織は誕生して５年目です！
9. 9 © Link and Motivation SRE チームの遷移 (Team Topologies 風に言うと...) 4つのチームタイプ ※ 出典：「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」より
10. 10 © Link and Motivation SRE チームの遷移 (Team Topologies 風に言うと...) インタラクションモード (チーム間の関わり方を示す) ※ 出典：「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」より
11. 11 © Link and Motivation １年前 → Medium レベル インフラや CI/CD (仕組み) を一方的に提供していた。
12. 12 © Link and Motivation 現在 → High レベル 開発者と協働し、課題解決に取り組む。
13. © Link and Motivation Group 13 開発生産性を示す Four Keys メトリクス
14. 14 © Link and Motivation Four Keys メトリクス 出典: 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 つの指標です。
15. 15 © Link and Motivation Four Keys メトリクス 出典: https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now- out?hl=en 「速度」と「安定性」の指標。お互いが密接な関係にありバランスが重要です。 デプロイ頻度 リードタイム MTTR 変更障害率 デプロイが原因で本番環境で障害が発生す る割合（%） 組織が本番環境での障害から回復するのに かかる平均時間 First commit から本番環境稼働までの所 要時間 本番環境へのリリースの頻度 速度 安定性
16. © Link and Motivation Group 16 本日お話したいこと 〜 SRE と開発者が「協働」する為に 〜
17. 17 © Link and Motivation SRE で課題解決し一方的に押し付けてきた デプロイの自動化 コンテナ化 IaC (Terraform) Four Keys : Low 〜 Medium 時代
18. 18 © Link and Motivation 遠い (苦手) 近い (得意) インフラの仕組みだけで解決できる限界 SRE アプリ開発者 インフラ CI / CD メトリクス SRE (インフラエンジニア発) は、どうしてもインフラ側から改善しがち。 ブランチング モデル テストコード E2E テスト アプリコード
19. 19 © Link and Motivation … 開発者間の「協働」
20. 20 © Link and Motivation どうやって「協働」できるか？ 一緒にメトリクス改善 をしようよ！ 自分の仕事で忙しい SRE 開発者 今のままで困ってない
21. 21 © Link and Motivation 本日話したいこと
22. 22 © Link and Motivation SRE と開発者が協働して進めるには？ 1 2 3 開発生産性・メトリクスの基準を統一する 改善活動をみんなの目標にする 数値を上げる意味・目的を共有する
23. © Link and Motivation Group 23 ① 開発生産性・メトリクスの基準を統一する
24. 24 © Link and Motivation 生産性の議論を始める為に SRE 開発者 共通の指標 コミュニケーション 議論をする為の共通のネタ「指標」が必要。
25. 25 © Link and Motivation SRE が手動でメトリクス集計をしてました 長らく、SRE が手動でメトリクス集計&可視化をしていました。 SRE 週に１度だけ 更新する！ あ、先週更新するの 忘れてた...
26. 26 © Link and Motivation SRE が手動でメトリクス集計をしてました 長らく、SRE が手動でメトリクス集計&可視化をしていました。 SRE 週に１度だけ 更新する！ あ、先週更新するの 忘れてた... 改善に繋がらない！
27. 27 © Link and Motivation 生産性課題を特定する為に必要な情報 量・頻度・正確さ の掛け算。 量 頻度 正確さ 課題の分析をする為に、様々な面 の情報が取得できている事 最新の情報が毎日更新・記録で きている事 情報が正確で信頼できる事
28. 28 © Link and Motivation ① 情報の量 今月の PR は 100 件でした 25 th% は「0〜3日」 XXX さんの PR は７日超えが多い 今月のリードタイムは「７日」 もっと細かく・視点を変えて見ると...
29. 29 © Link and Motivation ② 情報の更新頻度 振り返りの期間は多種多様。 (相対・絶対 / 日・週・月) 11月 第2週 12月 第3週 第4週 今日 過去２週間 (相対) １週目 ２週目 月で振り返りたい
30. 30 © Link and Motivation ② 情報の更新頻度 振り返りの期間は多種多様。 (相対・絶対 / 日・週・月) 11月 第2週 12月 第3週 第4週 今日 過去２週間 (相対) １週目 ２週目 月で振り返りたい 毎日メトリクス集計できているとベスト
31. 31 © Link and Motivation ③ 情報の正確さ 情報 (ミス 0%) 機械 人間 情報 (ミス 5%) 開発者 (頻度低くても) ミスの可能性があると見る 気を無くす 自動 手作業 ❌
32. 32 © Link and Motivation 自動化が必要
33. 33 © Link and Motivation メトリクス・ダッシュボード自動化に求められる要件 全自動 リアルタイム性 変更容易性 ダッシュボード要件 見たい時に見たい情報が得られな いと、開発者は見る気を無くす メトリクスを計測する事自体が SRE の負担 (トイル) になっては ならない メトリクスの具体的な計測方法は、 利用しているツールだけでなく、開 発組織の状況によって常に変わる
34. 34 © Link and Motivation 変更に強いメトリクス集計 ツールだけでなく、開発組織や事業のフェーズによって、集計方法は都度変わる。 ブランチングモデル が変わったり... インシデント対応 プロセスが変わる等
35. 35 © Link and Motivation 最近はメトリクス集計をしてくれる良い外部サービスもある SRE 始めたての若い組織は、実績が足りないので 外部サービス (※お金掛かる) をうまく活用できるか、判断がつかない。 初めはタダで出来る範囲で 経験値を積んでからかなぁ...
36. 36 © Link and Motivation Dashboard アーキテクチャ 収集 データ加工 → 可視化 GitHub スプシ Google Sheets Google Looker Studio
37. 37 © Link and Motivation Dashboard アーキテクチャ 収集 データ加工 → 可視化 GitHub スプシ Google Sheets Google Looker Studio リードタイム デプロイ頻度 MTTR 変更障害率 毎日同期 (SQL みたいに) 1行 = 1レコード
38. 38 © Link and Motivation Dashboard アーキテクチャ 収集 データ加工 → 可視化 GitHub スプシ Google Sheets Google Looker Studio データの加工 (Excel芸) は不要 毎日同期
39. 39 © Link and Motivation Dashboard アーキテクチャ 収集 データ加工 → 可視化 GitHub スプシ Google Sheets Google Looker Studio ノーコードで ダッシュボード化 毎日同期
40. 40 © Link and Motivation データの収集について 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日
41. 41 © Link and Motivation データの閲覧について 「X軸=日 / Y軸=リードタイム」 のグラフ
42. 42 © Link and Motivation 実際に作成したダッシュボード
43. 43 © Link and Motivation 参考リンク 宜しければこちらもご覧下さい。 • https://speakerdeck.com/lmi/sre-lounge-2023?slide=35 • https://link-and-motivation.hatenablog.com/entry/four-keys-metrics- dashboard
44. © Link and Motivation Group 44 ② 改善活動をみんなの目標にする
45. 45 © Link and Motivation アプリ開発者の仕事 SRE 開発者 当然ですが、アプリ開発者は毎日すごく忙しい。 リファクタリング 顧客要求の機能開発 日々の顧客対応 インシデント対応 生産性の改善活動
46. 46 © Link and Motivation 遠い (苦手) 近い (得意) アプリケーション領域の改善 SRE アプリ開発者 インフラ CI / CD ブランチング モデル テストコード E2E テスト アプリコード メトリクス アプリケーション領域の改善には、開発者の協力が必須！
47. 47 © Link and Motivation チーム間の断絶 開発チーム ⇔ SRE チーム 間の断絶！ コミュニケーションパス が希薄 チームそれぞれの 仕事・目標の達成 が最優先 SRE だけでは 生産性向上できない
48. 48 © Link and Motivation チーム間の断絶 開発チーム ⇔ SRE チーム 間の断絶！ コミュニケーションパス が希薄 チームそれぞれの 仕事・目標の達成 が最優先 SRE だけでは 生産性向上できない 改善の為の明確な チーム・役割・責務を決める
49. 49 © Link and Motivation 新しいチームを結成する
50. 50 © Link and Motivation 各チームから協力者を選出 横断チームを結成する！ 開発チーム A 開発チーム B 開発チーム C 各ストリームアラインドチーム から活動に興味高そうな人を選出 各ストリームアラインドチーム から活動に興味高そうな人を選出 各ストリームアラインドチーム から活動に興味高そうな人を選出
51. 51 © Link and Motivation 開発者のミッション・目標と結節 開発チーム A 開発チーム B 開発チーム C 事業部目標 個人目標 弊社の 2022/4Q の 事業部全体の目標に 生産性向上が入っていた ボランティアではなく 正式に個人の仕事にする
52. 52 © Link and Motivation 改善チームを結成する 改善プロジェクトに即した、実際の活動体 (チーム・会議体) を設計する。 SRE と 開発者の 混合チーム 新しい横断チーム 会議体 共通の目標
53. 53 © Link and Motivation Embedded SRE として チームに埋め込む
54. 54 © Link and Motivation 障害が多発！ 当時、プロダクトの障害が多発しており「変更障害率」が非常に高い状態にあった... デプロイ頻度 リードタイム MTTR 変更障害率
55. 55 © Link and Motivation 障害が多発！ 頑張ってヒアリングをするも、外からでは分からない事は多い！ それぞれのチームで 何が原因で障害が増えて いるんだろう？ ヒアリングしてみたけど、い まいちはっきりしないぞ
56. 56 © Link and Motivation 障害が多発！ 頑張ってヒアリングをするも、外からでは分からない事は多い！ それぞれのチームで 何が原因で障害が増えて いるんだろう？ ヒアリングしてみたけど、い まいちはっきりしないぞ チームの一員になって 活動すると分かりそう！
57. 57 © Link and Motivation 改善チームを結成する SRE 個人を、ストリームアラインドチームの一員として「埋め込み」中から直接改善をする！ コミュニケーションパス が希薄
58. 58 © Link and Motivation 改善チームを結成する SRE 個人を、ストリームアラインドチームの一員として「埋め込み」中から直接改善をする！ コミュニケーションパス が希薄 ① 課題・原因の特定がしやすい ② 改善活動をチームと直接できる
59. © Link and Motivation Group 59 ③ 数値を上げる意味・目的を共有する
60. 60 © Link and Motivation 実際にあった怖い話 (リードタイム) とある PR を１ヶ月放置していた。 実装開始 １ヶ月前 １週前 放置期間 (※別件で忙しかった) 実装再開 (１ヶ月経って) やっと再開できるぞ！
61. 61 © Link and Motivation 実際にあった怖い話 (リードタイム) 再開する際に気を効かせてくれて、PR (ブランチ) を作りなおす！ 実装開始 １ヶ月前 PR を 作り直す １週前 リリース 放置期間 (※別件で忙しかった) 実装再開 ３日前 当日 リードタイム = ３日 ！？ (リードタイムの為に) PR を作りなおそう！
62. 62 © Link and Motivation 実際にあった怖い話 (リードタイム) 再開する際に気を効かせてくれて、PR (ブランチ) を作りなおす！ 実装開始 １ヶ月前 PR を 作り直す １週前 リリース 放置期間 (※別件で忙しかった) 実装再開 ３日前 当日 リードタイム = ３日 ！？ (リードタイムの為に) PR を作りなおそう！ 「リードタイムを３日にする」 が目的になっている
63. 63 © Link and Motivation 目標と目的 リードタイムを小さくする事の目的って何だ？ 目標 リードタイム ≦ ３日 目的 ？？？
64. 64 © Link and Motivation リードタイム (値) が表す意味 リードタイムの定義は「First Commit → リリース」までの日数。 First Commit ５日前 １日前 リリース 一つの PR・Feature を リリースするのに掛かった日数 master マージ 当日 機能？ プロジェクト？
65. 65 © Link and Motivation リードタイム (値) が表す意味 実装 機能 A 実装 リリース リリース 実装 リリース 実装 リリース 最近は、スモールリリース・Feature toggle という手があるよね。 リードタイム → 大 機能 B リードタイム → 小 リードタイム → 小 リードタイム → 小
66. 66 © Link and Motivation リードタイム (値) が表す意味 実装 機能 A 実装 リリース リリース 実装 リリース 実装 リリース 最近は、スモールリリース・Feature toggle という手があるよね。 リードタイム → 大 機能 B リードタイム → 小 リードタイム → 小 リードタイム → 小 リードタイムの単位は 「機能」ではなく「PR」である！
67. 67 © Link and Motivation 1 PR PR 大 vs 小 PR を小さくすると、レビュー＆テスト品質が上がる。 1 PR 1 PR 1 PR 実装とその影響範囲を見きれず 設計観点のチェックになる コードの１行までレビューできる 変更影響の特定が難しく、 全件リグレッションテストが多発 変更に対し最小のテストを実施 ✅ ✅ ❌ ❌
68. 68 © Link and Motivation PR 大 vs 小 巨大な PR あるある コードがコンフリクトして大変 A がマージされないと B がテスト開始できない リリース日程調整でコミュニケーションコスト高
69. 69 © Link and Motivation PR 大 vs 小 PR が十分に小さいと... コンフリクトしない / しても簡単に直すだけ 自分の Feature のテストだけしたらいい リリース日程調整は不要
70. 70 © Link and Motivation リードタイム短縮の目的
71. 71 © Link and Motivation リードタイム短縮の目的 障害を減らしたい リリースの複雑性 を減らしたい スモールリリース・Feature toggle をする リードタイム ≦ ３日 目的 手段 目標 ※ 弊社の開発組織のケースでの一例です。 全ての開発組織で一概にそうとは限りません。 ① ②
72. 72 © Link and Motivation リードタイム短縮の目的 障害を減らしたい リリースの複雑性 を減らしたい スモールリリース・Feature toggle をする リードタイム ≦ ３日 目的 手段 目標 目的に立ち戻る為に 繰り返し伝える！
73. 73 © Link and Motivation e.g. Rails アップデート ビッグバンリリース ※ リリースめちゃ怖〜 スモールリリース PR 数 変更ファイル / PR 1〜2 PR(s) 100 files PR 数 変更ファイル / PR 80 PR(s) 1〜2 files 弊社 Rails アップデートの今と昔。
74. 74 © Link and Motivation e.g. Rails アップデート 小さな互換性のあるリリースを繰り返す。 互換 リリース 1回目 80回目 最終 リリース 新・旧 どちらの Rails Version でも動く 互換コードを先行リリースする 互換 リリース 最後の１回 最後にやっと Rails の Version を上げる + 一部の非互換コード ・・・ (スモールリリース) ・・・ x8 0 ・・・
75. © Link and Motivation Group 75 #devキャリ2022 まとめ
76. 76 © Link and Motivation … 開発者間の「協働」
77. 77 © Link and Motivation 開発者みんなで「協働」して改善を進める為に 1 2 3 メトリクス集計は自動化＆ダッシュボード化しよう！ 改善活動の横断チームを作り、ちゃんと仕事化 (目標) する！ 数値を追うのではなく、目的・目指す姿を明確にしよう！
78. 78 © Link and Motivation 開発者体験 = 幸せ が高い組織 「理想の姿」を証明する為の「数値」であれ スピード・気軽さ リリースのシンプルさ 品質の高さ • リリース調整「〜はいつ出 す？」は大変 • 一つ遅れると、全部再調 整！ • 小さな改善をすぐにリリース できる • リリース承認等のプロセスで 時間が掛かる • 障害が発生すれば、対応に コストを払う • 気軽なリリースができなくなる
79. 79 © Link and Motivation 開発者体験 = 幸せ が高い組織 「理想の姿」を証明する為の「数値」であれ スピード・気軽さ リリースのシンプルさ 品質の高さ • リリース調整「〜はいつ出 す？」は大変 • 一つ遅れると、全部再調 整！ • 小さな改善をすぐにリリース できる • リリース承認等のプロセスで 時間が掛かる • 障害が発生すれば、対応に コストを払う • 気軽なリリースができなくなる 速度 安定性 表裏一体 開発メトリクス
80. 80 © Link and Motivation 開発者体験 = 幸せ が高い組織 「理想の姿」を証明する為の「数値」であれ スピード・気軽さ リリースの複雑さ 品質の高さ • リリース調整「〜はいつ出 す？」は大変 • 一つ遅れると、全部再調 整！ • 小さな改善をすぐにリリース できる • リリース承認等のプロセスで 時間が掛かる • 障害が発生すれば、対応に コストを払う • 気軽なリリースができなくなる 速度 安定性 表裏一体 開発メトリクス 理想の姿へどの位到達したか メトリクス = 達成指標
81. © Link and Motivation Group 81 #devキャリ2022 さいごに
82. 82 © Link and Motivation お知らせ • エンジニアリングマネージャー • プロダクトマネージャー • テックリード • サーバーサイドエンジニア • フロントエンドエンジニア • SRE • QAエンジニア • データエンジニア • CRM • UXデザイナー 週１でテックブログを更新中！ まずはカジュアルにお話しましょう！ 積極採用中です！