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

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

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

【開発生産性Conference】
リンクアンドモチベーション登壇資料(2023/07/13)

『なぜ Four Keys を改善するのか?
〜How ではなく Why を重視したメトリクス改善活動〜』

#開発生産性con_findy #リンクアンドモチベーション #リンモチ
=============================================
【イベント情報】
■イベントページ
 https://findy.connpass.com/event/283417/

■特設サイト
 https://dev-productivity-con.findy-code.io/

【株式会社リンクアンドモチベーション】
■お問い合わせ
 [email protected]
■Entrancebook
 https://note.com/lmi/n/n179505e048f4
■テックブログ
 https://link-and-motivation.hatenablog.com/
=============================================

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

Other Decks in Technology

Transcript

  1. © Link and Motivation Group なぜ Four Keys を改善するのか? Developer

    Productivity ユニット / SRE グループ 川津雄介 〜How ではなく Why を重視したメトリクス改善活動〜
  2. 2 © Link and Motivation Group 自己紹介 川津 雄介 株式会社リンクアンドモチベーション

    SRE • 前職は某複写機メーカーでエンジニアしてた • OSレイヤーからWeb/モバイルまで何でもやる • 中途の採用活動もします • リンクアンドモチベーションではSREとして開発 室全体の生産性向上に注力! https://github.com/megmogmog1965 https://qiita.com/megmogmog1965
  3. 8 © Link and Motivation Group 弊社開発組織の歴史 2016 2018 2019

    2022 2023 モチベーションクラウド のリリース 開発組織内製化のスタート (Four Keys = Low レベル) コミュニケーションクラウド のリリース ストレッチクラウド のリリース Four Keys メトリクス High〜Elite レベルに到達 2020 SRE チームの誕生 弊社の開発組織は誕生して5年目です! デプロイ頻度: 120 回/月 リードタイム: 1日 ※モチベーションクラウド 5月実績
  4. 9 © Link and Motivation Group SRE チームの遷移 (Team Topologies

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

    風に言うと...) インタラクションモード (チーム間の関わり方を示す) ※ 出典:『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』より
  6. 14 © Link and Motivation Group 遠い (苦手) 近い (得意)

    インフラの仕組みだけで解決できる限界 SRE アプリ開発者 インフラ CI / CD メトリクス SRE (インフラエンジニア発) は、どうしてもインフラ側から改善しがち。 ブランチング モデル テストコード E2E テスト アプリコード オーナーシップ
  7. 16 © Link and Motivation Group チームを横断した中央集権的な改善 改善活動の推進者 (SRE 等)

    チーム B チーム A チーム C 課題の 調査・ヒアリング サービス X サービス Y
  8. 17 © Link and Motivation Group チームを横断した中央集権的な改善 チーム B チーム

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

    A チーム C サービス X サービス Y 具体的な アクションの指示 改善活動の推進者 (SRE 等)
  10. 20 © Link and Motivation Group チーム B チーム A

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

    チーム B チーム A チーム C サービス X サービス Y 生産性改善は彼らの 「ミッション」ではない サービス (コード) のオーナーシップ を持っており改善活動しやすい
  12. 22 © Link and Motivation Group チームを横断した中央集権的な改善 SRE チーム B

    チーム A チーム C サービス X サービス Y 具体的な アクションの指示 どうすれば全員が主体性を持って 改善活動に取り組めるか?
  13. 24 © Link and Motivation Group 開発者全員で主体性を持って改善活動するには? 1 2 3

    改善の「Why (目的)」を言語化する チームの壁を超えて一丸となって改善する 改善のオーナーシップをチームに!
  14. 26 © Link and Motivation Group 実際にあった怖い話 (リードタイム) とある PR

    を1ヶ月放置していた。 実装開始 1ヶ月前 1週前 放置期間 (※別件で忙しかった) 実装再開 (1ヶ月経って) やっと再開できるぞ!
  15. 27 © Link and Motivation Group 実際にあった怖い話 (リードタイム) 再開する際に気を効かせてくれて、PR (ブランチ)

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

    を作りなおす! 実装開始 1ヶ月前 PR を 作り直す 1週前 リリース 放置期間 (※別件で忙しかった) 実装再開 3日前 当日 リードタイム = 3日 !? (リードタイムの為に) PR を作りなおそう! 「リードタイムを3日にする」 が目的になっている
  17. 29 © Link and Motivation Group Why / How /

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

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

    What リードタイム < 3日 How (どうやって?) What (何を?) Why (なぜ?) 推進者 (リーダー) がメンバーを効果的に動かすには 「Why」が肝心!
  20. 32 © Link and Motivation Group みんなが能動的に活動できる! 人は「何を」ではなく 「なぜ」に動かされるのです What

    How ゴールデンサークル理論 Why Why から始めよ 目的を見失わない為に 効果の無い How に 傾倒することが無い様に
  21. 42 © Link and Motivation Group 数値を「上げる」事が目的になってしまった... デプロイ頻度 「High」達成! How

    (どうやって?) What (何を?) Why (なぜ?) なぜ、デプロイ頻度を 上げないといけないのか? (どんな良いことがあるか) ❌ ⭕ どうやって デプロイ頻度を上げよう?
  22. 43 © Link and Motivation Group 2つの Why - 課題と目指す姿

    デプロイ頻度 「High」達成! How (どうやって?) なぜ? 低いのか? なぜ? 低いとダメか? 原因 本当の課題と 目指す姿
  23. 44 © Link and Motivation Group How (どうやって?) なぜ? 低いのか?

    原因 2つの Why - 課題と目指す姿 デプロイ頻度 「High」達成! なぜ? 低いとダメか? 本当の課題と 目指す姿 これはみんな するけど... こっちが無いと間違った ゴールの HOW になる
  24. 45 © Link and Motivation Group 低いメトリクス値が示す意味は? 低いメトリクス 潜在した 課題

    潜在した 課題 潜在した 課題 その時点の最大の ボトルネック課題 あるべき理想 課題が解決した先の 理想の開発環境像をイメージ できているか? 様々な要因が複合して このメトリクスである (要考:数値の意味)
  25. 53 © Link and Motivation Group デプロイ頻度が少ないと マイグレ等が混ざってると 切り戻しに時間が掛かる MTTR

    コミュニケーション コミュニケーション 単純に切り戻して いいんだっけ? マイグレあるから 待って!
  26. 57 © Link and Motivation Group つまりデプロイ頻度とは...? デプロイ頻度 デプロイ回数が多い ???

    ※ 弊社の開発組織のケースでの一例です。 全ての開発組織で一概にそうとは限りません。
  27. 58 © Link and Motivation Group つまりデプロイ頻度とは...? デプロイ頻度 デプロイ回数が多い 安全な切り戻し

    切り戻しや再リリースに掛かる工数減 ※ 弊社の開発組織のケースでの一例です。 全ての開発組織で一概にそうとは限りません。 MTTR の向上
  28. 61 © Link and Motivation Group リードタイム (値) が表す意味 リードタイムの定義は「First

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

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

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

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

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

    PR が十分に小さいと... コンフリクトしない / しても簡単に直すだけ 自分の Feature のテストだけしたらいい リリース日程調整は不要
  34. 68 © Link and Motivation Group リードタイム短縮の目的 障害を減らしたい リリースの複雑性 を減らしたい

    スモールリリース・Feature toggle をする リードタイム ≦ 3日 目的 手段 目標 ※ 弊社の開発組織のケースでの一例です。 全ての開発組織で一概にそうとは限りません。 ① ②
  35. 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 アップデートの今と昔。
  36. 70 © Link and Motivation Group e.g. Rails アップデート 小さな互換性のあるリリースを繰り返す。

    互換 リリース 1回目 80回目 最終 リリース 新・旧 どちらの Rails Version でも動く 互換コードを先行リリースする 互換 リリース 最後の1回 最後にやっと Rails の Version を上げる + 一部の非互換コード ・・・ (スモールリリース) ・・・ x8 0 ・・・
  37. 72 © Link and Motivation Group メトリクス値から、生産性課題 → あるべき理想の姿を見つける 低いメトリクス

    潜在した 課題 潜在した 課題 潜在した 課題 その時点の最大の ボトルネック課題 あるべき理想 課題が解決した先の 理想の開発環境像をイメージ できているか? 様々な要因が複合して このメトリクスである (要考:数値の意味)
  38. 75 © Link and Motivation Group アプリ開発者の仕事 開発者 当然ですが、アプリ開発者は毎日すごく忙しい。 リファクタリング

    顧客要求の機能開発 日々の顧客対応 インシデント対応 生産性の改善活動 改善活動の推進者 (SRE 等)
  39. 76 © Link and Motivation Group チーム B チーム A

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

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

    チーム B チーム A チーム C サービス X サービス Y 生産性改善は彼らの 「ミッション」ではない サービス (コード) のオーナーシップ を持っており改善活動しやすい 改善の為の明確な チーム・役割・責務を決めるべき
  42. 80 © Link and Motivation Group 各チームから協力者を選出 横断チームを結成する! 開発チーム A

    開発チーム B 開発チーム C 各ストリームアラインドチーム から活動に興味高そうな人を選出 各ストリームアラインドチーム から活動に興味高そうな人を選出 各ストリームアラインドチーム から活動に興味高そうな人を選出
  43. 81 © Link and Motivation Group 開発者のミッション・目標と結節 開発チーム A 開発チーム

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

    A チーム C 各所属チームへの結節点となる 各所属チームへの結節点となる
  45. 86 © Link and Motivation Group 障害が多発! 頑張ってヒアリングをするも、外からでは分からない事は多い! チームの何が原因で障害が 増えているんだろう?

    ヒアリングしてみたけど、 いまいちはっきりしないぞ チームの一員になって 活動すると分かりそう!
  46. 88 © Link and Motivation Group 改善チームを結成する 一定期間だけ チームを異動します! 改善の推進者をストリームアラインドチームの

    一員として「埋め込み」中から直接改善をする! ① 課題・原因の特定がしやすい ② 改善活動をチームと直接できる
  47. 90 © Link and Motivation Group 改善推進者が主体の指示型 チーム B チーム

    A チーム C サービス X サービス Y 具体的な アクションの指示 改善活動の推進者 (SRE 等)
  48. 91 © Link and Motivation Group 組織の規模が拡大すると現実的ではなくなる チーム B チーム

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

    チーム A チーム C サ | ビ ス X Y チーム B チーム A チーム C サ | ビ ス Z … SRE も一緒にスケール するのは微妙 どうすべき?
  50. 93 © Link and Motivation Group 改善活動の推進者 (SRE 等) 改善のオーナーシップを「チーム」に

    チーム B チーム A チーム C サービス X サービス Y チーム内に 「改善係」を置く? チーム内に 「改善係」を置く? チーム内に 「改善係」を置く?
  51. 96 © Link and Motivation Group チームに計測&改善のプロセスをインストールする チーム B チーム

    A 改善活動の推進者 (SRE 等) + + イネーブリング 改善活動はみんなの責務 あくまで 一時的にJOIN
  52. 98 © Link and Motivation Group 何をチームにインストールするのか? メトリクス計測 の自動化 改善運用

    / プロセス What How Why Why から 始める思想 Github 等から計測 ダッシュボード化
  53. 99 © Link and Motivation Group 何をチームにインストールするのか? メトリクス計測 の自動化 改善運用

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

    / プロセス What How Why Why から 始める思想 推進者が並走して 指導する必要がある
  55. 104 © Link and Motivation Group 組織の規模・形態が違う チーム A チーム

    A チーム B チーム C チーム 横断して A 事業部 チーム内の B 事業部 C 事業部 横断して 組織・全社で
  56. 106 © Link and Motivation Group メトリクスが低い原因は一つではない 例えばデプロイ頻度が低い原因も、それぞれの現場で様々ある... リリースする物はあ るが

    CI・CD、自動 化が出来ていないと か... そもそも、一日あた りにマージされる Feature が少ないと か... インシデントが多発し ており、その対応やリ リース時のテスト工数 とか...
  57. 107 © Link and Motivation Group メトリクス値から、生産性課題 → あるべき理想の姿を見つける 低いメトリクス

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

    潜在した 課題 潜在した 課題 その時点の最大の ボトルネック課題 あるべき理想 課題が解決した先の 理想の開発環境像をイメージ できているか? 様々な要因が複合して このメトリクスである (要考:数値の意味) 「Why」を考えよう!
  59. 110 © Link and Motivation Group お知らせ • エンジニアリングマネージャー •

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