パフォーマンスモニタリングからはじめる開発生産性向上の取り組み

先日4年ぶりの現地開催となったDevelopers Summit(デブサミ)にいってきました、なかむらです。

オンラインのセミナーや勉強会ではBGM的に聞いたり倍速で視聴しがちになりますが、現地では集中してセッションを聴くことができました。腰と背中が限界になったことには衰えを感じざるを得ませんでしたが、久しぶりのデブサミは羽田空港第三ターミナル直結の新しい会場だったこともあり、新鮮でとても刺激になりました。

「開発生産性」まずはアウトプット向上を目指す

今年のデブサミも開発生産性のセッションがいくつかあったように、一昨年あたりから「開発生産性」というワードをよく耳にするようになりました。

開発組織における開発生産性は大きく3つのレベルがあり、最終的には以下の実現付加価値の生産性を上げることが、顧客やユーザーの満足度に繋がると考えられます。

1. 作業量の生産性(アウトプット) ：決まった時間でどのくらいの量の仕事を終えることができたか
2. 期待付加価値の生産性(アウトカム) ：決まった時間でどのくらいの価値が期待される仕事ができたか
3. 実現付加価値の生産性(ビジネスインパクト) ：決まった時間でどのくらいの価値を実現ができたか

3つのレベルのうちアウトカムやビジネスインパクトはシステム開発グループだけにとどまらないので、自分たちだけで改善ができる、レベル１のアウトプットの向上を目指すことにしました。レベル１の生産性が高くても、レベル２以降の生産性が高いと言えるかはわかりませんが、少なくともチームの作業効率が悪くないという評価ができれば良いなと考えています。

また、ソフトウェア開発における開発生産性は、プロジェクトをいかに効率的に進められるか、決められた時間内にどれだけ多くの価値のある機能を提供できるか、といったチームの能力を測る尺度のことで、ソフトウェア開発においてはコードの品質の高さやデリバリーの速度・安定性などが主な指標と言われています。

先述の通り、まずはアウトプット向上を目指すので「デリバリーの速度・安定性」の目標値を立てるつもりはないのですが、現状の把握はしておきたいなと思っています。

なんもわからん！という課題

自分たちのアウトプットを向上させるにはどうしたらいいんだろうかと考え始めたとき、いくつか疑問に思ったことがありました。

• 自分たちの今のアウトプットはどうなの？高いの？低いの？
• 事業で大きく２つのチームに別れているけど、チーム間に差はあるの？
• 過去のブログで「GitHub Copilotと爆速でGoogle Chrome拡張機能を作ってみた」に書いてあるとおり、AI活用の事例としてGitHub Copilot導入したけど、果たしてCopilot導入はアウトプットに効果があったの？
• 開発プロセスは適切なの？改善すべきところはある？
• そもそもチームは健全と言える状態なの？

これらを疑問に思っても、いまがどうなのかを自分たちで計測もしていなかったですし、分析できるようなデータを持っていませんでした。なにもわかってないということがわかったので、まずは現状の見える化をする必要がありました。そこでパフォーマンスモニタリングができるサービスの導入を検討することにしました。

Findy Team+でお試し中！

現状を把握するため、エンジニア組織のパフォーマンス向上を支援するSaaSの「Findy Team+」のトライアルをしています。ちなみに運営会社のFindy社はデブサミの展示スポンサーだったので、展示会場ではトライアルでお世話になっている担当の方と初めて対面でお会いすることができました。

Findy Team+はエンジニア向けツールを解析することで生産性を可視化するサービスです。アトラスはGitHubを利用しているので、GitHubのIssueやプルリクを解析していろいろな指標が表示され、確認できます。２つの画面だけ紹介します。

サイクルタイム分析 : コーディングプロセスにおけるリードタイム

「サイクルタイム分析」画面では、以下の平均時間などが確認できます。

• コミットからオープンまで
• オープンからレビューまで
• レビューからアプルーブまで
• アプルーブからマージまで

自分たちがどのレベルかがわかるベンチマークも確認できました。プランによっては見えないらしいですが、トライアル期間なら見れるそうです。参考になってありがたいですね。アウトプット向上のためにここの数値を改善することを目標としていきます。

DevOps分析 : FourKeysの数値

FourKeysとは、DORA(DevOps Research and Assessment) が提唱するデリバリーパフォーマンスを示す4つの指標(デプロイ頻度、変更のリードタイム、変更障害率、平均修復時間)のことです。
「DevOps分析」画面ではそれぞれが見やすく表示されます。

残念ながら現在のGItHub運用ルールでは変更障害率と平均修復時間が算出できていないため、運用方法を変更する予定です。

運用変更：プルリクの除外ラベル付与とブランチの使い分けルール更新

なるべく正確な数値を算出して分析できるようにするために、GitHubでの運用ルールを2点変更しました。

1. サイクル計測のための除外ラベル登録

リードタイムのサイクル分析をするためには、コーディングやレビューを実施するプルリクだけを集計の対象にする必要があります。しかし、アトラスのブランチ運用ではプロダクトを各環境に反映するための以下のようなブランチが存在しており、これらのブランチ間でのプルリクは集計の対象外にしなければ正確な数値が算出されません。

• 試験環境：develop もしくは staging ブランチ
• プレ環境：hotfix もしくは pre ブランチ
• 本番環境：masterブランチ

Findy Team+では過去1年間のデータをプルリクラベルの有無でフィルタリングして分析することができるので、運用上必要なマージ作業のためのプルリクには「Operation」 のラベルを付与し、除外して集計できるようにしました。

2. 変更障害率と復旧時間計測のための hotfix ブランチ運用

前述の通り、DevOps分析で変更障害率と復旧時間が算出されていないのでブランチ運用のルールを変更することにしました。
これまでは、プレ環境に反映するブランチに対して新機能拡張分も不具合改修分もマージしていたので、プレ環境に反映するブランチ(pre) と 不具合対応ブランチ(hotfix)を明確に分けて運用することにしました。これで変更障害率と復旧時間が計測できるはずです。

ふりかえりをしっかりやる

今後は可視化されたパフォーマンスについてチームごとにふりかえり会を実施する予定です。自分たちのパフォーマンスを落とさず維持する、または高めていくためのアクションをチームメンバーから提案してもらい、よりリードタイムを早くするにはどう取り組んでいくかを相談して、チーム全員で実践していく改善ループを作っていきたいと考えています。

と思ったそんな時に、Findy Team+にふりかえりのための機能がリリースされました！まだチームでミーティングを実施してないので機能を試せてないのですが、実際にメンバーと使ってふりかえるのが楽しみです。

ここからはじまる開発生産性向上

GitHubのIssueやプルリクから自分たちのパフォーマンスモニタリングができる状態になり、やっと開発生産性向上のスタート地点に立てました。
とはいえ、トライアルは一部のメンバーのみで実施しており、突然はじまった開発生産性向上の取り組みはシステム開発グループ全体ではまだ浸透していないので、グループ内外に布教活動をしつつ、「アウトプットあげるぞー！おー！」といった盛り上がりを見せれるように積極的に取り組んでいきたいと思います。
開発生産性向上の取り組みの続編にぜひご期待ください！