開発生産性のリードタイム1.5倍・デプロイ頻度2倍!実践した開発生産性改善施策の振り返り

開発生産性

昔あこがれていたギターを買ったり、ギター熱が更に熱くなっている村田です。
株式会社レコチョクでエンジニアリングマネージャーをしています。
今回は実際に行った開発生産性向上の取り組みについて、その結果をご紹介します。

はじめに

この記事は、ネイティブアプリ開発チームの開発生産性の指標を定義してみたの続きとなります。
前回の記事では、開発生産性の定義と、その評価指標についてご紹介しました。
今回は実際に行った取り組みについて振り返り、開発生産性向上の具体的な成果をご紹介します。

目次

取り組み概要

今回の取り組みは、まさに「開発生産性の向上」というシンプルな目的からスタートしました。

開発生産性の向上と言っても、定量的に測れなければ向上したかどうかを判断できません。そこで、まずは指標を定義して、判断ができる状態まで持っていくことが必要と考えました。

そのため、まずは「開発生産性って何?」という定義から始め、定量的に評価できる指標を可視化出来るようFindy Team+というツールを導入し、
開発チーム内で振り返りの場を作り振り返ることで、先行指標の向上・結果指標の向上を目指して進めてきました。

先行指標と結果指標は次の考え方で利用しています。

  • 先行指標:目標を達成するための施策や活動の実施状況を測定する
  • 結果指標:目標への到達度合いを測定する

※施策選定の背景や詳細な理由については、前回の記事で詳しく解説しています。本記事では、実際に行った施策の内容と、その具体的な成果・現場の変化にフォーカスします。

指標を定義してから目標値を決めて、それに向かい改善をするというよりも、
定義してみた開発生産性の結果指標が定量・定性的にも開発生産性の概念とズレていないか?を確かめることも含めて、
FY24の目標は「結果指標向上の取り組み1件以上」として取り組みました。

評価指標

結果指標としてDevOpsのFour Keysを利用しました。
ただ、通常のFour Keysでは本番環境への反映までを含めた指標ですが、ネイティブアプリの指標としては検証環境への反映までを含めた指標としています。
これは開発チームがコントロールしやすい範囲での改善を重視するためです。

  • デプロイの頻度
    • 組織による正常な検証環境へのリリースの頻度
  • 変更のリードタイム
    • commitから検証環境稼働までの所要時間
  • 変更障害率
    • デプロイが原因で検証環境で障害が発生する割合(%)
  • 平均修復時間
    • 組織が検証環境での障害から回復するのにかかる時間

image-20250528020730845.png

先行指標としてコミットからマージされるまでにかかる時間や、PRの変更差分などを見れるチームサマリやサイクルタイム、レビュー分析を活用しました。
振り返りの際は主にここの数値を見ることで、開発チーム内の具体的な課題や改善結果を図るようにしていました。

image-20250528020751883.png

目標振り返り

「結果指標向上の取り組み1件以上」の振り返りです。

結果指標的には2つの指標が向上しました🎉

  • デプロイ頻度
    • 約2倍向上🎉(約1.5件/週→約3.0件/週)
  • 変更のリードタイム
    • 約1.5倍短縮🎉(105.4h→64.4h)

image-20250528020831606.png

途中で指標を変更したため完全に計測出来ているわけではありませんが、変更障害率も低下傾向で、QAテスト後の不具合発生数も大幅に減りました。

image-20250528020850343.png

リリース前のQAテストで検知した不具合発生数

  • vX.2.00:38件
  • vX.3.00:10件
  • vX.4.00:2件

数字で見ると、地道な改善がしっかり成果につながっているのが分かります。

得られた効果

目標を達成することで、開発チームやエンジニア個人の目線でどういった効果があったかも紹介します。

定量面

コミットからマージまでの時間が短縮(105.4h→64.4h)

image-20250528020923779.png

PRの変更差分も大幅減少(920.8行→205.9行)

image-20250528020955209.png

改善前はPRの粒度も大きく、マージまでにかかる時間も長くなっていました。
振り返りを通して、小さな変更で開発を進める様にすることでマージまでの時間も短縮しています。
その結果、問題点の早期発見・修正も可能になり、以下のようなメリットもメンバー視点で体感出来ているようでした。

  • コードレビューの効率化
    • レビューに対する抵抗感が減り、レビュー開始が早くなった
    • 確認すべき項目も減り、レビュー時間が短縮、レビュー見落としも減少
  • 機能単位の開発速度向上
    • フロー効率的に実装が進められ、機能開発のリードタイムも短縮
  • コンフリクト発生・解消のコスト・リスク軽減

定性面

今回の取組開始時、評価指標と設定していた値について、完全に納得まで出来ていない開発メンバーもいたため、定性面で答えてもらえるようなアンケートも実施しました。

そのアンケート結果でも、「やってよかった!」という声が多かったです。
上記のようなわかりやすい効果を実感出来たことも影響しているのか、納得感の高い結果も出ました。

image-20250528021049590.png

以下が開発メンバーが記入してくれた内容のサマリーです。

  • Four Keysを用いた他社比較による競争意識と改善文化の醸成
  • チーム内で改善できた内容
    • PR通知の仕組み導入
    • PR Descriptionの詳細化
    • タスク粒度の細分化
    • 時間可視化による意識的なPRレビュー
    • 放置PRの削減
  • 開発効率への意識向上
    • 見やすいPR・リードタイム削減の意識
    • 課題・問題の可視化と対策の共通認識

「開発生産性を可視化することで、どこを改善すればいいかが明確になった」「チーム全体で課題を共有できるようになった」など、現場の実感としても大きな変化がありました。

最後に

今までの取り組みは試験的にネイティブアプリの開発チームに閉じて行ってきていました。
今後はアプリだけでなく、サーバーサイドにも範囲を広げていきたいと考えています。

また、今回の改善はあくまで開発チームの「実装工程の効率化」にまだとどまっています。
継続的な改善文化を根付かせたうえで、プロダクトとしての「アウトプットの最大化」、「アウトカムの最大化」まで目線を向けて活動を続けて行きたいと考えています!

開発生産性