ウィルゲートでの開発生産性向上における取り組み

アドベントカレンダー2023

この記事は「ウィルゲート Advent Calendar 2023」の 24 日目の記事です。

adventar.org

こんにちは、ウィルゲート開発室の池添（@for__3）です。

近年、開発生産性という言葉が広く耳にされるようになりました。特に、findyさん主催の開発生産性カンファレンスが印象的でしたね。

ウィルゲートでもより開発の力によって事業を加速させていくための改善の指標としてちょうど去年の12月頃から各種指標を収集し分析してきました。 この記事では、ウィルゲートにおける開発生産性計測の仕組みづくりから、分析改善を通して実施してきたことについて紹介します。

開発生産性とは

開発生産性は、GoogleのDevOps Research and Assessment（以下DORA）チーム*1が調査した効率的な開発チームの特徴を示す指標で、以下の要因が効果的な開発チームの特徴として挙げられています。

  • デプロイの頻度 - 組織が正常な本番環境へのリリースを行う頻度
  • 変更のリードタイム - コミットから本番環境への稼働までの所要時間
  • 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
  • サービス復元時間 - 組織が本番環境での障害から回復するまでの時間

また『エンジニアリング組織論への招待』の著者でもある広木大地さんの 開発生産性について議論する前に知っておきたいこと #開発生産性 - Qiita の記事は開発生産性についてとても良くまとまっており、特に「開発生産性の3階層」ごとの生産性については実際に現場と経営レベルで開発生産性を改善する際の指針になります。

「開発生産性の3階層」 （開発生産性について議論する前に知っておきたいこと）
「開発生産性の3階層」 （開発生産性について議論する前に知っておきたいこと）

どのように開発生産性を計測し始めたか

開発生産性の仕組みを構築するにあたって色々検討したのですが、最初から大きな仕組みを導入してもうまく計測できないとか計測してみた結果あまり関連のない指標だった、ということになるともったいないという結論になりました。これは何事も小さく始めて試すというリーンな考え方にも通ずることですね。

そこで、初期段階では最小限のリソースで開発生産性を計測するため、スプレッドシートとGoogle Apps Script（GAS）を活用し、GitHubからPRのデータを取得したり、JIRAから障害チケットのデータを取得したりする仕組みを整えました。 ミニマムで始めたこともあり、実装するリソースも多くはなかったので、GASでGitHubからAPIを使ってシートにデータを取ってくる部分を作る人、GASでJIRAの障害チケットからAPIを使ってシートにデータを取ってくる部分を作る人、取ってきたデータをスプレッドシートの関数で集計する仕組みを作る人、という具合に分担して１人日くらいでサクッと構築しました。

実際に作成したものは下記のようなものです。

ウィルゲートの開発生産性指標スプレッドシート
ウィルゲートの開発生産性指標スプレッドシート

※データが空欄になっているところはデータが取れていなかったり、ちょうど全プロダクトのBitBucketからGitHubへの移行をしていたのですがその以降前後で取れていないものや、新しいチームの組成などによるものです。

ウィルゲートの開発生産性指標 - デプロイ頻度（d/d/d）のチーム毎の推移グラフ
ウィルゲートの開発生産性指標 - デプロイ頻度（d/d/d）のチーム毎の推移グラフ

収集している指標は、一旦取得しやすかった「デプロイ頻度（d/d/d*2）」、「変更失敗率」、「MTTR（Mean Time To Repair）」を各チーム毎に収集してます。また、デプロイ頻度に関しては特に数値の細かい動きもあったのでグラフで可視化して追っています。

開発生産性を追い始めてどう変わったか

開発生産性指標をスプレッドシートで誰でもいつでも見れる状態になったことで、マネージャーやリーダーだけが気にして見るだけではなく、メンバーも積極的に今の各チームの指標を確認し改善のために行動してくれるようになりました。 おかげで、それぞれのチームで下記のような行動がボトムアップで起き、さらにはそれらの活動がチームを超えてナレッジとして共有されるようになりました。

  • CI/CDの整備
  • PRをデプロイできる最小の単位で小さく分けて出す
  • リファクタリングデーを実施し機能開発とリファクタの分離
  • 不要コードの断捨離
  • 作業時間を確保し易いようなミーティング時間の調整（まばらにある会議をまとめる等）
  • 定期的なライブラリアップデートの実施
  • MTTR改善のための障害分類と対策
  • デプロイフローの改善
  • 変更失敗に気づきやすくするためのE2Eテストの導入
  • GitHub Copilotの導入
  • 定常保守の依頼からチケット化の自動化

結果的にまだ多少の波や程度の差はありますが、どのチームもデプロイ頻度や、変更失敗率の指標が改善されて行っています。

今後の展望

数値が改善されているのはとても喜ばしいことですが、この指標はまだ改善の第一歩であり、広木さんのQiitaの記事でいうレベル１の仕事量の生産性の指標が改善されつつあるということに過ぎません。 ここからさらに、レベル２の付加価値生産性やレベル３の実現付加価値の生産性まで紐づけて改善していける組織にするために、組織一丸となってより本質的な改善をしてプロダクトの価値を高めていけるよう頑張っていきます。 そのためにもまずは、今回MVPとして作ったスプレッドシートとGASでスケールがそろそろ辛くなってきたこの仕組みをリプレイスするところからやっていきたいと思います。

そして「ウィルゲート Advent Calendar 2023」、明日はいよいよ最終日、開発室執行役員の向平さんによる「自律する組織の実現に向けた挑戦」です。 お楽しみに！

*1:https://dora.dev/

*2:deploys / a day / a developer の略https://twitter.com/hiroki_daichi/status/1100381137929625600