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

Four Keysが改善しても、生産性が上がらない不都合な真実 / pek2025-link-...

Four Keysが改善しても、生産性が上がらない不都合な真実 / pek2025-link-and-motivation

リンクアンドモチベーション登壇資料(2025/09/18)

Four Keysが改善しても、生産性が上がらない不都合な真実
〜指標を変えて挑んだ改善の道のり〜

#PEK2025 #リンモチ

===========================================
【イベント情報】
■イベントページ
https://www.cnia.io/pek2025/

【株式会社リンクアンドモチベーション】
■お問合せ先
 [email protected]
■テックブログ
 https://link-and-motivation.hatenablog.com/
■開発組織の公式X
 https://x.com/LinkandM_dev
=============================================

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

Transcript

  1. 2 © Link and Motivation Group 自己紹介 伊藤 遼(@haruka_odenkun) 株式会社リンクアンドモチベーション

    Developer Productivityユニット SREイネーブリンググループ 開発者体験や開発生産性の向上をミッションに プラットフォームエンジニアリングに従事
  2. 3 © Link and Motivation Group 会社紹介 創業年月日|2000年4月7日 上場市場 |東京証券取引所

    プライム市場 従業員数 |約1,500名 (グループ全体) 売上 |374億 (グループ全体) ※2024年12月期 事業内容 |組織改善クラウドの開発・提供 株式会社リンクアンドモチベーション
  3. 4 © Link and Motivation Group 会社紹介 経営と現場をつなぐ オールインワンのサービス 国内最大級の12,870社、532万人(※)のデータ

    ベースをもとに組織状態を可視化・分析可能。 エンゲージメントサーベイだけではなく 個人開発 (360度診断)機能やWeb社内報(社内ポータル) 機能もご利用可能 (※)2025年3月末時点
  4. 6 © Link and Motivation Group 今日お話しすること • 話すこと ◦

    弊社における生産性向上の取り組みの歴史 ◦ その過程でぶつかった壁や打ち手、学び • 話さないこと ◦ 生産性の定義 既に各所で議論済みで、目的・範囲によって変わるため ◦ 一部施策の詳細 ぜひブース等で意見交換させてください!
  5. 9 © Link and Motivation Group Platform Engineeringの悩み... 何から着手すべき? やるべきことが多すぎて

    何をすべきかわからない... どう関係者と協働する? 開発者が協力的ではなくて 思うように改善が進まない... どんな指標を置けばよい? 経営層に成果の説明を 求められるが難しい... こんな悩み、ありませんか?
  6. 10 © Link and Motivation Group Platform Engineeringの悩み... 何から着手すべき? やるべきことが多すぎて、

    何からすべきかわからない... どう関係者と協働する? 開発者が協力的じゃなくて 思うように改善が進まない... どんな指標を置けばよい? 経営層に成果の説明を 求められるが難しい... こんな悩み、ありませんか? 様々な悩みや壁に直面しながら、 課題を乗り越えていった過程をお話します。
  7. 11 © Link and Motivation Group 私たちの改善の歩み ???? ???? ????

    2020年から現在に至るまで、 3つのフェーズに分けて取り組みをお伝えします。 ❶ 土台づくり期 (Four Keys) ❷ 試行錯誤期 (ボトムアップ) ❸ 指標確立期 (機能リリース数)
  8. 12 © Link and Motivation Group 私たちの改善の歩み 外部指標を取り入れて アプリチームとともに改善しよう! ????

    ???? ❶ 土台づくり期 (Four Keys) ❷ 試行錯誤期 (ボトムアップ) ❸ 指標確立期 (機能リリース数)
  9. 13 © Link and Motivation Group 2020年某日… うちって開発生産性高いの? CTO わたし

    ①土台づくり期 ② ③ どうだろ.... 基準もないし何もわからん....
  10. 14 © Link and Motivation Group 2020年某日… うちって開発生産性高いの? どうだろ.... 基準もないし何もわからん....

    多くの企業が導入しており、生産性への相関もあることから 「DORAのFour Keys」を測ってみることに! CTO わたし ①土台づくり期 ② ③
  11. 15 © Link and Motivation Group 計測した結果… 2020年当時のFour Keys Metrics

    リードタイム デプロイ頻度 変更障害率 MTTR Low Low Low Low 計測したところ、結果は「Low」 開発生産性の低さを定量的に認識した ①土台づくり期 ② ③
  12. 16 © Link and Motivation Group 計測した結果… 2020年当時のFour Keys Metrics

    リードタイム デプロイ頻度 変更障害率 MTTR Low Low Low Low 計測したところ、結果は「Low」 開発生産性の低さを定量的に認識した ①土台づくり期 ② ③ まずは「High」の達成を目標に、改善活動を開始した。
  13. 17 © Link and Motivation Group PEメンバーで始動 デプロイの自動化 コンテナ化 IaC

    (Terraform) リードタイム バグの混入 E2Eテスト インフラ領域 改善完了!! アプリ領域 未着手... PEメンバー中心にインフラの仕組みを改善するも アプリ領域においては、改善が進まなかった ①土台づくり期 ② ③
  14. 18 © Link and Motivation Group PEメンバーで始動 デプロイの自動化 コンテナ化 IaC

    (Terraform) リードタイム バグの混入 E2Eテスト インフラ領域 改善完了!! アプリ領域 未着手... PEメンバー中心にインフラの仕組みを改善するも アプリ領域においては、改善が進まなかった ①土台づくり期 ② ③ インフラ領域のみを改善しても、 Highの基準には到達できなかった。
  15. 19 © Link and Motivation Group アプリチームへの働きかけ リリース分割しよう! 自分の仕事で忙しいです… PRは溜めないようにしよう!

    今のままで困ってないんですよね… わたし 開発者 早速アプリチームに働きかけてみたが 作業を依頼しても改善はまったく進まなかった ①土台づくり期 ② ③
  16. 20 © Link and Motivation Group 関わり方を変える Before After PE

    開発者 一方的に 作業を依頼 PE 開発者 横断チームで 目標・会議体 を持つ Four Keys の改善 共通の目的を設定し、同席する会議体を設けることで 一丸となって改善を進めた ①土台づくり期 ② ③
  17. 21 © Link and Motivation Group 変化の兆し PE 開発者 Feature

    Flag QAプロセスの見直し インシデントコマンダー Autifyを使った自動テスト インシデントレベル ・・・ これにより、アプリ〜インフラまで幅広い技術課題を解決できた ①土台づくり期 ② ③
  18. 22 © Link and Motivation Group 改善を積み重ねた結果… リリースが楽になった! PRが小さくなってレビューが楽! 障害対応を交代で回せるようになった!

    リードタイム デプロイ頻度 変更障害率 MTTR 1日未満 5回以上 / 日 5%未満 4時間未満 開発者 ①土台づくり期 ② ③ 2023年には「High」の基準を達成することができた
  19. 23 © Link and Motivation Group 次に生じた課題 プロジェクト管理の質がバラバラ バックエンドが肥大化して変更がつらい プロダクト増えてデザインの統一が大変

    新たな言語の追加に毎回時間がかかる 開発者 ①土台づくり期 ② ③ 「スコアが改善された割には、生産性が上がった実感が湧かない」 という声が開発者から上がり始めた
  20. 24 © Link and Motivation Group 次に生じた課題 プロジェクト管理の質がバラバラ バックエンドが肥大化して変更がつらい プロダクト増えてデザインの統一が大変

    新たな言語の追加に毎回時間がかかる 開発者 ①土台づくり期 ② ③ 「スコアが改善された割には、生産性が上がった実感が湧かない」 という声が開発者から上がり始めた より具体的な開発者のペイン解消に取り組むことに!
  21. 25 © Link and Motivation Group 私たちの改善の歩み 外部指標を取り入れて アプリチームとともに改善しよう! 開発者のペインを解消しよう!

    ???? ❶ 土台づくり期 (Four Keys) ❷ 試行錯誤期 (ボトムアップ) ❸ 指標確立期 (機能リリース数)
  22. 26 © Link and Motivation Group 開発者のペインを解消 プロジェクト管理の質がバラバラ バックエンドが肥大化して変更がつらい 新たな言語の追加に毎回時間がかかる

    開発者 Pjt管理のダッシュボード作ったよ! PE モジュラーモノリスにしたよ! 翻訳文言の管理基盤整えたよ! ②試行錯誤期 ③ ① あがってきた開発者のペインを、一つずつ改善していった
  23. 27 © Link and Motivation Group 開発者アンケートも実施 当時のアンケート結果 ②試行錯誤期 ③

    ① SPACEを元にしたアンケートを実施し 開発者からの定性的な評価や声を収集した
  24. 28 © Link and Motivation Group 活動の成果 開発者体験が めちゃくちゃ良くなりました!! モジュラーモノリス

    デザイントークン Dev Container 翻訳文言管理基盤 OpenAPI ・・・ Pjtダッシュボード GitHub Copilot ②試行錯誤期 ③ ① 結果として、大小さまざまなペインを解消! アンケート結果も改善し、開発者からは喜びの声が溢れた!
  25. 29 © Link and Motivation Group 活動の成果 開発者体験が めちゃくちゃ良くなりました!! モジュラーモノリス

    デザイントークン Dev Container 翻訳文言管理基盤 OpenAPI ・・・ Pjtダッシュボード GitHub Copilot ②試行錯誤期 ③ ① 結果として、大小さまざまなペインを解消! アンケート結果も改善し、開発者からは喜びの声が溢れた! しかし…
  26. 30 © Link and Motivation Group ある日… で、生産性上がったの? リリース増えた? CTO

    めっちゃ改善してきたんで 上がっているはずです! 見てみます! わたし ②試行錯誤期 ③ ①
  27. 31 © Link and Motivation Group 不都合な真実 ②試行錯誤期 ③ ①

    2023年 2024年 ひとりあたりの機能リリース数 (年間機能リリース数 / 開発者数)
  28. 32 © Link and Motivation Group 不都合な真実 ②試行錯誤期 ③ ①

    2023年 2024年 えっ ひとりあたりの機能リリース数 (年間機能リリース数 / 開発者数)
  29. 34 © Link and Motivation Group 私たちの改善の歩み 外部指標を取り入れて アプリチームとともに改善しよう! 開発者のペインを解消しよう!

    顧客価値に近い指標を ゴールに置いて改善しよう! ❶ 土台づくり期 (Four Keys) ❷ 試行錯誤期 (ボトムアップ) ❸ 指標確立期 (機能リリース数)
  30. 35 © Link and Motivation Group 改めて、何が起こっていたのか? 陥っていた状態 ゴール:開発者体験の向上 ②

    ① ③指標確立期 「開発者体験の向上」が目的となっていたため 実装工数を加味した「小粒な改善」が中心となっていた
  31. 36 © Link and Motivation Group どうすればよかったのか? 陥っていた状態 ゴール:開発者体験の向上 あるべき状態

    ゴール:顧客価値の創出 ② ① ③指標確立期 「顧客価値創出の加速」というゴールからブレずに より本質的な改善に注力すべきだった
  32. 38 © Link and Motivation Group 新たな指標を策定 「顧客価値 = 機能リリースの総量」とし

    「機能リリース数」を2倍にすることを目標に設定 ② ① ③指標確立期 【定義】 単なるデプロイ数ではなく、「顧客に提供した新たな価値の数」 【理由】 顧客価値に、よりダイレクトにつながっている指標だから
  33. 40 © Link and Motivation Group 指標に合わせて、課題も進化 機能リリース数を目標にすることで、これまでにない課題に挑戦 ② ①

    ③指標確立期 “次世代”の開発プロセス “ROI”で負債返済を推進 “PdM”領域での改善 開発者の“時間の使い方”の改善 ※一部数字はイメージ
  34. 41 © Link and Motivation Group 全PRにラベルの付与を強制 • ai: AIによって100%のコードを生成

    • ai-assisted: AIによって80%のコードを生成 • tried-ai - AIを試したがかなりの手作業が生じた • no-ai - AIを使用せずに開発 AIコード生成比率60%に向けた取り組み ② ① ③指標確立期 AIコーディングエージェントのナレッジの展開を促進し 実装工数を削減できないか挑戦中 進行中 活用比率を定義して可視化・目標設定 全員で取り組み、良い取り組みをシェア Aチーム PE Devin Cursor Claude Code AIエージェント Bチーム 利用 学び / 事例共有 展開 利用メトリクスを取得 .cursor/rules 共有用repo 社内イベントでの発表 Slackなどでフォロー 定期で情報取得 整形 可視化 AIコード生成比率の定義・目標: ”ai”ラベルPR数 / 全PR数 > 60% ※dependabotのような自動化されたPRは除く
  35. 42 © Link and Motivation Group 要件定義リードタイム削減に向けた取り組み ② ① ③指標確立期

    要件定義のフェーズごとの指標を設定 改善サイクルをPdMと回し要件定義のリードタイム削減に成功 完了 課題の 不確実性 解決策の 不確実性 合計 課題仮説検証 フェーズ 価値仮説検証 フェーズ 要件定義・デザイ ン作成 フェーズ 低 低 4 1 1 2 低 中 7 1 2 4 低 高 11 1 4 6 中 低 6 2 2 2 中 中 10 2 4 4 中 高 16 2 8 6 高 低 8 4 2 2 高 中 12 4 4 4 高 高 18 4 8 6 課題仮説検証フェーズ 価値仮説検証フェーズ 要件定義・デザイン作成フェーズ 目的:「誰の」「どんな課題」を解決するかを正しく理解する 完了基準:複数の課題の中から、最も大きなインパクトを与える課題が特 定されている 目的:課題をどのように解決するか、具体的な解決策を作る 完了基準:顧客の主要な課題に対し、どの機能や方法で解決するかが具体 的に言葉で表現されている 目的:製品の要件を固め、実際に使えるプロダクトとして形にする 完了基準:機能や性能(非機能)、UI/UXなどの要件が明確になり、チーム 内で合意されている フェーズごとの目的・完了基準を定義 フェーズごとのリードタイム目標(週)を設定 課題の不確実性と解決策の不確実性 それぞれの難易度を元に目標を設定
  36. 43 © Link and Motivation Group 開発集中時間に増加向けた取り組み ② ① ③指標確立期

    集中時間を確保のため、部署全体の会議ルールを設定 メトリクスとして監視し、集中時間の維持に成功した 完了 フロー状態かどうか判定式: メトリクス監視 グループ B グループ A グループ C ルール プロセス 【集計のアルゴリズム】 • Google Calendar 上の 2時間 以上 連続した空き時間を計測 • 特定の文字を含むタイトルを meeting と判断 • 9:00〜19:00 の間 (9h) で計測 ◦ 一律 12:00〜13:00 は除外 【異常の基準】 • 1ヶ月は 180 時間 ◦ 9時間 (※平均残業時間込み) x 20日 • 「45 時間/月」を下回る人を改善対象とする 𝚺 (2時間以上の空き時間) > 45 時間/月 グループ内で 自律的に運用 フロー状態を定義し、カレンダールールに反映 カレンダー情報を元に監視・運用
  37. 44 © Link and Motivation Group 障害対応に充てる工数削減向けた取り組み ② ① ③指標確立期

    過去の障害対応工数から、リターン(=改善で得られる工数)を算出 これまで着手できなかった改善もROI提示で経営に提案して推進 進行中 横断的な分析でやるべき改善とそのROIを算出 再発防止のステータス監視と実行の徹底 過去1年半の障害全ての振り返り資料を元に分析 多数の実施されていない再発防止策のアイデアを発見 @メンションで自動で生成 ・AIによるサマリー ・振り返り資料雛形 ・対応管理チケット キーワード 発生した工数 復旧対応工数: 人・時間 恒久対応工数: 人・時間 発生パターン ①システム自体の変更: 修正やアップデートで挙動が変わった ②利用パターンの変化: これまで通らなかったパスでバグに当たった ③キャパ超過: 設計容量を超える負荷がかかった ④依存の劣化: 外部コンポーネントのデグレ ⑤依存の仕様変更: 関連システムの仕様が変わった 機能名 テーブル名 モジュール 操作ミス セキュリティ 帳票 メール送信 多言語対応 マスタデータ 内部マイクロサービス Feature Flag エラーハンドリング API共通処理 テーブル設計 期日までに完了してなかったら 担当者をメンション 発生頻度と 1回あたりの工数 を算出 ・・・ イベントストーミングで 根本原因と 確からしさを確認 責務過多な 大規模テーブル リファクタリング ROIとその確からしさを元に後回し課題にも着手
  38. 47 © Link and Motivation Group さいごに ブースでお待ちしています!ぜひお話しましょう! リンクアンドモチベーションでは 「Platform

    Engineer」「EM」の仲間を大募集中です! モチベーション チップスを お配りしてます! 公式 のフォローで ノベルティプレゼント!