© Link and Motivation Group Four Keysが改善しても 生産性が上がらない不都合な真実 〜指標を変えて挑んだ改善の道のり〜 株式会社リンクアンドモチベーション Developer Productivityユニット SREイネーブリンググループ 伊藤 遼 

2 © Link and Motivation Group 自己紹介 伊藤 遼（@haruka_odenkun） 株式会社リンクアンドモチベーション Developer Productivityユニット SREイネーブリンググループ 開発者体験や開発生産性の向上をミッションに プラットフォームエンジニアリングに従事 

3 © Link and Motivation Group 会社紹介 創業年月日｜2000年4月7日 上場市場 ｜東京証券取引所 プライム市場 従業員数 ｜約1,500名 (グループ全体) 売上 ｜374億 (グループ全体) ※2024年12月期 事業内容 ｜組織改善クラウドの開発・提供 株式会社リンクアンドモチベーション 

4 © Link and Motivation Group 会社紹介 経営と現場をつなぐ オールインワンのサービス 国内最大級の12,870社、532万人（※）のデータ ベースをもとに組織状態を可視化・分析可能。 エンゲージメントサーベイだけではなく 個人開発 （360度診断）機能やWeb社内報（社内ポータル） 機能もご利用可能 （※）2025年3月末時点 

5 © Link and Motivation Group 今日お伝えしたいメッセージ 顧客価値に近い指標をゴールに置いて改善しよう！ 

6 © Link and Motivation Group 今日お話しすること ● 話すこと ○ 弊社における生産性向上の取り組みの歴史 ○ その過程でぶつかった壁や打ち手、学び ● 話さないこと ○ 生産性の定義 既に各所で議論済みで、目的・範囲によって変わるため ○ 一部施策の詳細 ぜひブース等で意見交換させてください！ 

7 © Link and Motivation Group そもそも... AI曰く、Platform Engineeringとは 「開発者体験と生産性の向上を通じて 顧客価値の創出を加速させる」こと 

8 © Link and Motivation Group そもそも... AI曰く、Platform Engineeringとは 「開発者体験と生産性の向上を通じて 顧客価値の創出を加速させる」こと なるほど わからん 

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

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

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

12 © Link and Motivation Group 私たちの改善の歩み 外部指標を取り入れて アプリチームとともに改善しよう！ ???? ???? ❶ 土台づくり期 （Four Keys） ❷ 試行錯誤期 （ボトムアップ） ❸ 指標確立期 （機能リリース数） 

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

14 © Link and Motivation Group 2020年某日… うちって開発生産性高いの？ どうだろ.... 基準もないし何もわからん.... 多くの企業が導入しており、生産性への相関もあることから 「DORAのFour Keys」を測ってみることに！ CTO わたし ①土台づくり期 ② ③ 

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

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

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

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

19 © Link and Motivation Group アプリチームへの働きかけ リリース分割しよう！ 自分の仕事で忙しいです… PRは溜めないようにしよう！ 今のままで困ってないんですよね… わたし 開発者 早速アプリチームに働きかけてみたが 作業を依頼しても改善はまったく進まなかった ①土台づくり期 ② ③ 

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

21 © Link and Motivation Group 変化の兆し PE 開発者 Feature Flag QAプロセスの見直し インシデントコマンダー Autifyを使った自動テスト インシデントレベル ・・・ これにより、アプリ〜インフラまで幅広い技術課題を解決できた ①土台づくり期 ② ③ 

22 © Link and Motivation Group 改善を積み重ねた結果… リリースが楽になった！ PRが小さくなってレビューが楽！ 障害対応を交代で回せるようになった！ リードタイム デプロイ頻度 変更障害率 MTTR 1日未満 5回以上 / 日 5%未満 4時間未満 開発者 ①土台づくり期 ② ③ 2023年には「High」の基準を達成することができた 

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

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

25 © Link and Motivation Group 私たちの改善の歩み 外部指標を取り入れて アプリチームとともに改善しよう！ 開発者のペインを解消しよう！ ???? ❶ 土台づくり期 （Four Keys） ❷ 試行錯誤期 （ボトムアップ） ❸ 指標確立期 （機能リリース数） 

26 © Link and Motivation Group 開発者のペインを解消 プロジェクト管理の質がバラバラ バックエンドが肥大化して変更がつらい 新たな言語の追加に毎回時間がかかる 開発者 Pjt管理のダッシュボード作ったよ！ PE モジュラーモノリスにしたよ！ 翻訳文言の管理基盤整えたよ！ ②試行錯誤期 ③ ① あがってきた開発者のペインを、一つずつ改善していった 

27 © Link and Motivation Group 開発者アンケートも実施 当時のアンケート結果 ②試行錯誤期 ③ ① SPACEを元にしたアンケートを実施し 開発者からの定性的な評価や声を収集した 

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

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

30 © Link and Motivation Group ある日… で、生産性上がったの？ リリース増えた？ CTO めっちゃ改善してきたんで 上がっているはずです！ 見てみます！ わたし ②試行錯誤期 ③ ① 

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

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

33 © Link and Motivation Group 不都合な真実 開発者のペインは解消されたが 顧客価値（機能リリース数）は増えていなかった ②試行錯誤期 ③ ① 

34 © Link and Motivation Group 私たちの改善の歩み 外部指標を取り入れて アプリチームとともに改善しよう！ 開発者のペインを解消しよう！ 顧客価値に近い指標を ゴールに置いて改善しよう！ ❶ 土台づくり期 （Four Keys） ❷ 試行錯誤期 （ボトムアップ） ❸ 指標確立期 （機能リリース数） 

35 © Link and Motivation Group 改めて、何が起こっていたのか？ 陥っていた状態 ゴール：開発者体験の向上 ② ① ③指標確立期 「開発者体験の向上」が目的となっていたため 実装工数を加味した「小粒な改善」が中心となっていた 

36 © Link and Motivation Group どうすればよかったのか？ 陥っていた状態 ゴール：開発者体験の向上 あるべき状態 ゴール：顧客価値の創出 ② ① ③指標確立期 「顧客価値創出の加速」というゴールからブレずに より本質的な改善に注力すべきだった 

37 © Link and Motivation Group Platform Engineeringとは（再掲） 開発者体験と生産性の向上を通じて 顧客価値の創出を加速させる ② ① ③指標確立期 

38 © Link and Motivation Group 新たな指標を策定 「顧客価値 = 機能リリースの総量」とし 「機能リリース数」を2倍にすることを目標に設定 ② ① ③指標確立期 【定義】 単なるデプロイ数ではなく、「顧客に提供した新たな価値の数」 【理由】 顧客価値に、よりダイレクトにつながっている指標だから 

39 © Link and Motivation Group 新たな形での改善 ※一部数字はイメージ 機能リリース数の増加を目標として、改善アクションを策定した ② ① ③指標確立期 

40 © Link and Motivation Group 指標に合わせて、課題も進化 機能リリース数を目標にすることで、これまでにない課題に挑戦 ② ① ③指標確立期 “次世代”の開発プロセス “ROI”で負債返済を推進 “PdM”領域での改善 開発者の“時間の使い方”の改善 ※一部数字はイメージ 

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は除く 

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などの要件が明確になり、チーム 内で合意されている フェーズごとの目的・完了基準を定義 フェーズごとのリードタイム目標(週)を設定 課題の不確実性と解決策の不確実性 それぞれの難易度を元に目標を設定 

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 時間/月 グループ内で 自律的に運用 フロー状態を定義し、カレンダールールに反映 カレンダー情報を元に監視・運用 

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

45 © Link and Motivation Group 機能リリース数の変化 2024年（実績） 2025年（見込み） これらの取り組みにより ひとりあたりの機能リリース数は1.5倍に増加見込み 

46 © Link and Motivation Group まとめ 顧客価値に近い指標をゴールに置いて改善しよう！ そうすることで これまでになかった新たな目標や行動 ――すなわち「越境」が生まれる 

47 © Link and Motivation Group さいごに ブースでお待ちしています！ぜひお話しましょう！ リンクアンドモチベーションでは 「Platform Engineer」「EM」の仲間を大募集中です！ モチベーション チップスを お配りしてます！ 公式 のフォローで ノベルティプレゼント！