Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    237 万

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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 つの指標です。

    View Slide

  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 から本番環境稼働までの所
    要時間
    本番環境へのリリースの頻度
    速度
    安定性

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  19. 19
    © Link and Motivation

    開発者間の「協働」

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  40. 40
    © Link and Motivation
    データの収集について
    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日

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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




    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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 アップデートの今と昔。

    View Slide

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

    View Slide

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

    View Slide

  76. 76
    © Link and Motivation

    開発者間の「協働」

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide