こんにちは。
株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。
ラクスでは社内独自指標での開発生産性指標の計測を行ってきましたが、今年度からFindy Team+を開発本部全体に導入しFour Keysをベースとした計測1に切り替えてきました。
今回はFindy Team+導入に関する記事を書こうと思います。
導入と経緯
課題
ラクスではもともと工数見積もりをベースにした独自の生産性指標を利用していました。
ただしこの独自指標には以下のような問題が生まれていました。
- 見積もりを過大にすることで数値をハックできる
- 見積もり精度を高める取り組みは重視されていなかった
- 個人目標に利用されていた
特に1つ目については、見積もりを過大にすることで見かけの成果物の量が多くなり、見かけ上の指標値を良くすることができました。 指標値を良くするために過大見積もりを行う、というほど悪意のある行動はなかったかと思いますが、見積もりを小さくするための取り組み――技術的負債の低減、見積もり精度を上げて作業バッファを低減する、など――に対する取り組みが、数値上の成果に繋がらないため行いにくくなってしまっていました2。
経緯
そんな中、DORAによって発表されていたState of DevOps Reportに出てくるFour Keys3が書籍『LeanとDevOpsの科学』の影響もあり注目されてきました。
Four Keysを知った当初は、ラクスのサービスがBtoBであることもあり、1日に何度も本番環境にデプロイするなどの状況がイメージできない4事もあって導入に関しては懐疑的でしたが、その後SPACEフレームワークの考え方を知ることで、「Four KeysもSPACEの（特にPerformance）を軸にした指標群の一例であり、成果物の産出量、レビュー数、割り込みの発生頻度（≒不具合発生頻度）など複数の観点で計測することが重要で、これらがそれぞれカウンター指標として機能する」という考えに至りました。
これにより、自社で計測する指標としてFour Keysをベースとしながら、自社に合わせた指標にカスタマイズして採用していくことにしました。 オリジナルのFour Keysとの大きな違いは「本番環境へのデプロイ」を軸にするのではなく「開発者からの手離れ」を軸に置き換えています。
- デプロイの頻度
- 本来は「変更を本番環境にデプロイした回数」
- ラクスでは「コードレビューを終えて、メインブランチにマージされた回数」
- 変更のリードタイム
- 本来は「最初の変更コミットから本番環境にデプロイされるまでの所要時間」
- ラクスでは「最初の変更コミットからメインブランチにマージされるまでの時間」
- 変更失敗率
- サービス復元時間
特に「デプロイの頻度」という項目ではフィーチャーフラグなどを駆使して、本番デプロイ回数の計測のままにしようかとも検討しましたが、フィーチャーフラグでオフにしているのであれば結局はユーザーへの価値提供はできていないため、ここにこだわる理由は見つけられませんでした6。
指標までは検討できたので、実際の計測基盤をどうするかという段階に話が進みます。
ファインディ社との関わり
開発生産性カンファレンス
多少時間は前後しますが、新たに開発生産性を計測していくにあたって2023年に開催されたファインディ社が主催する「開発生産性カンファレンス」に参加しました。
このカンファレンスで行われたニコール・フォースグレン博士の発表にて、当時はまだ今ほど知られていなかったSPACEフレームワークについて理解を深めることができました。今ならネットで検索したり、ChatGPTに聞けば教えてくれるはず。
指標のハックについてはひとまず考えない
また社内で導入することを考えると指標のハックについても話題に上がることを考えて、カンファレンスの懇親会でお話させていただいた各社に実際の運用を聞いて回りました（話に付き合っていただいた皆様ありがとうございます）。
各社の運用を聞いていると
- 「ある程度ハックされることは想定しているが、あまり気にしないようにしている」
- 「極端なハックは逆に仕事がしにくくなると思うのである程度で抑制されると考えている」
といった回答が多かったです。
確かにマージ件数を増やすためにプルリクエストを細分化すると言っても、1行ずつ分割してたらレビュアーに怒られると思いますし7、開発業務のオーバーヘッドは逆に増えて面倒になると思います。
Four KeysやSPACEフレームワークの考え方の則って取り組む場合には、複数の指標を用いてそれらがある程度カウンター指標となることが考えられるので、ひとまずは余計なことは考えずに導入を進めることにしました。
Findy Team+ 検討、仮決定
というわけで自社でどんな計測を行いたいのかがある程度固まってきたので、計測ツールについての検討を始めました。いくつかの開発生産性計測サービスと内製によるシンプルな計測と比較していく中でFindy Team+を提供するファインディ社にも問い合わせを行いました。
何社か話を聞いていく中で、コスト面で折り合いがつかなかったり、開発体制の厚さがラクスの基準に合わなかったりという形で残ったのが、Findy社のFindy Team+でした。
内製でやるのは結構大変そう
内製についても検討しましたが、GitHubからデータを収集し、「マージ回数」「1日あたりマージ頻度」「PRあたりの平均リード時間」を算出するくらいまでは作成したものの、社内で運用保守していくにあたって片手間でやるには大変で、専任メンバーを割り当てるのも悩ましい8ということがわかり、専任メンバーを当てるコストを考えたらクラウド型の計測サービスの利用を優先的に考えたほうが良さそうだという判断を行いました。
組織がもっと大きくなり、専任のチームを設置できるくらいの規模であればできそうですが、ラクスではまだ少し厳しそうです。
試用期間
Findy Team+の利用を仮決定したものの、実際に導入して（想定した運用の手間で）運用可能なのかという判断が必要になります。
Findy社に問い合わせて試用をお願いして、Team+を実際に触る機会をもらいました。
場合によっては内製化というパターンも完全には消えていないので、生産性計測に何が必要なのかという学習も兼ねて各機能を触っていきました。
ちょっと機能が豊富すぎて「オーバースペックかなぁ……」という感想は抱きましたが、一方で主要指標で問題の芽を見つけたときに原因分析していくことを考えるとある程度細かく数値を取れていないと難しそう（＝ある程度の機能が必要）だな、という感想も持ちました。
また、試用期間中にも新機能のリリースが頻繁に行われており、なにか機能要望があったときの反映にも期待できそうだという感想を覚えました。
2チームでスモールスタート
その後、比較的新しい2つのチームに対して、試験的にFindy Team+を導入しました。
これらのチームは開発生産性に興味を持っていたということに加えて、比較的モダンな開発プロセスを採用しており、細かな開発ルールについても柔軟に改善できる段階にありました。指標をもとに議論を始めやすいフェーズと考え、導入効果が見えやすいのではという仮説のもと選出しました。
当初の見立てではチームに計測の概念が浸透し、実際のアクションや改善につながるまでには少なくとも半年はかかるだろうと予想していました。 しかし、導入から2ヶ月目あたりで早くもいくつかの数字に変化が現れ始め、3ヶ月目には改善効果として有意な差が見られるという予想以上のスピードでチーム内の行動が改善していることが観察されました。
具体的にはプルリクエストのサイズが小さくなり、プルリクエストあたりのリードタイムが短縮。プルリクエストごとのレビュー難易度が低減されたため、偏りのあったレビュアーが分散され、レビュー待ちのボトルネックが解消される、といった傾向が見られました。
全チーム本格導入
導入済みチームで数字に変化が現れ始めたことを受けて、社内へのさらなる展開を進めるためにフローの整備を始めました。 単にツールを導入するだけではなく、「なぜこのツールを使うのか」「どんな成果が期待できるのか」を社内にしっかり伝え、各チームの導入モチベーションを高めることが重要だと考えています。
そこで、まずは導入済みチームで実際にどのような効果が出ているかを紹介する勉強会を企画しました。 この勉強会では、Findy社にも全面的にご協力いただき、開発生産性の考え方や使い始めたときのコツ、導入済みチームで出ている成果を第三者視点から紹介してもらう機会を設けることができています。
プルリクエスト作成数やプルリクエストのレビュー時間などの具体的な改善事例を共有しつつ
- 数字をもとにした改善ポイントの見つけ方
- 改善サイクルの回し方
についても紹介してもらいました。 実際に成果が出ているチームの様子や、Findy社からのリアルな説明を受けたことで、「自分たちのチームでも試してみたい」「改善に役立てられそうだ」という前向きな反応を引き出すことができました。
この取り組みをきっかけに、興味を持ってくれるチームの導入モチベーションを刺激することができたと思います。興味をもってくれているチームから順次導入することで社内文化として定着させ、スムーズに浸透させていければと考えています。
今後やっていきたいこと
現在、導入済みのチームでは指標上の数値が徐々に改善傾向を見せており、一定の成果は見え始めています。 ただし、数値が改善しているからといって必ずしも現場の体感としても「良くなった」と感じられているとは限りません。
今後はメンバーへのヒアリングを実施し、主観的な働きやすさやチームの健康状態にも目を向けていく予定です。 特にSPACEフレームワークにおける「S（Satisfaction and well-being）」の観点を意識し、数値だけでは拾いきれない現場の声を把握しながら指標と実態のズレがあれば、それを補正していきたいと考えています。
まだFindy Team+の導入が進んでいないチームに対しても、適切なタイミングでフォローを続けていく必要があります。 単なるツールの押し付けにならないよう、各チームの状況や課題感に寄り添いながら、必要性を一緒に整理していく支援を進めていきたいと思っています。
- Four Keysを元にしていますが、厳密にはFour Keysではありません。おおまかにはデプロイを基準にしている部分を、レビュー後のマージに置き換えた考え方で定義しています。当初は本来の定義を変えることに疑いがあったのですが、SPACEフレームワークの考え方に則って考えれば問題ないだろうと判断しています。↩
- 実際は各種改善は行われていましたが、用いていた生産性指標の上では成果が現れないため、評価者が個別に取り組みを評価する手間が発生していた。↩
- Four Keysはソフトウェアデリバリーのパフォーマンスを表す4つの指標ですが、2022年版以降には追加の指標として運用パフォーマンスを表す「信頼性」が提唱されています。↩
- サービス利用されている顧客の中には自社内で利用マニュアルを整備していることも多々あり、事前通知が必要だったり、頻繁な新機能リリースやデザイン変更はクレームの元になると考えています。↩
- サービス復元時間の計測はまだ本格的には行えていません。↩
- こまめにデプロイすることでデプロイを日常業務として効率化を図る、という観点は捨てがたいところもありましたが、これを実現するのは生産性計測の取り組みではなくデプロイの仕組みやデプロイフローの見直しを行うべきで、それが終わるまで開発生産性が上がらないというのも計測の意味がなくなるので現状はこのようにしています。もちろん毎日でもデプロイできる仕組みができたら計測の基準を見直すかもしれません。↩
- 私も説教すると思います。マージ件数をカウントする意味とか、プルリクエストを細分化する意味とか、レビュー効率の話とか、逆に長引くくらいに。↩
- 社内に開発生産性のプロを抱えたいというわけではないので……。↩
