最短距離で価値検証するために、開発生産性に向き合おうとしている話

季節の変わり目、みなさん体調いかがでしょうか？

SmartHRで人事評価の開発をしているプロダクトエンジニアのnomusonです。今回は、開発生産性に関する指標を使って、最短距離で価値検証するために取り組もうとしていることを紹介します。

開発生産性って聞くとウッとなる

「開発生産性」という言葉を聞くと、ウッとなったり、身構えたりすることはないでしょうか？私自身もそう思ったことがあります。開発生産性にネガティブな印象を受けるときは、数字が一人歩きしてしまわないか、開発の現場に対して監視や抑圧をされてしまうのではないか、といった不安を感じると、私は思います。

一方で、開発生産性を現場のものとして扱えば、数値で現状を把握して、改善した結果を数値で実感して、より伸びしろをみつけていけるのではないでしょうか。

開発生産性の指標

開発生産性の指標として『LeanとDevOpsの科学』で広まったソフトウェアデリバリーのパフォーマンスの重要指標「Four Keys」があります。著者の1人Gene Kimさんの『The DevOps 逆転だ！』は、私の好きなビジネス小説のひとつです。

DevOps Research and Assessment(DORA)チームの調査から、以下のFour Keysが高い開発組織はハイパフォーマンスであることが判りました。

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

詳細は2019年のDORAレポート記事を参照してください。また、2022年のDORAレポートでは、Four Keysに加えて、運用パフォーマンスの重要指標として「信頼性」が追加されました。

わたしたちはこうやろうと思っている

今期、最短距離で価値検証をするために、機能のデリバリーをより早くしたいという目標があります。そのために、Four Keysの「変更のリードタイム」が短い状態になっていたいです。

直近の機能開発でFindy Team+を使ってデータを収集していたので、その結果から「変更のリードタイム」を短くする上で重点的に追っていく指標を探して、目標値を考えてみました。

ある機能の開発期間のFindy Team+ サイクルタイム平均値。コミットからオープンまでの平均時間が6.3時間であった。 — ある機能の開発期間のFindy Team+ サイクルタイム平均値

この画面の「コミットからオープンまでの平均時間」は、Pull Requestの最初のコミットからPull Requestがオープンになるまでの時間を指しています。つまり、実装時間と言えます。そこで「コミットからオープンまでの平均時間」を6h以内と、およそ1日以内に実装が終わるようにプロセス改善をしていくことを目標に定めました。

そして、「コミットからオープンまでの平均時間」を6h以内になっているときの、チームの状態の仮説を立ててみました。

1日以内に実装が完了できる粒度に、プロダクトバックログアイテムやタスクが詳細化できている
Pull Requestのサイズが適度に小さくなるよう、プロダクトバックログアイテムやタスクを分割できている
結果として、毎スプリント動く機能ができて、スプリントレビューでデモができる

プロセス改善をくり返して、実装時間が短くなっていくか確認していきたいと考えています。

数値を目標に据えるリスクと狙い

数値を目標に据えると、グッドハートの法則に陥るリスクがあります。グッドハートの法則とは「測定が目標になると、それは適切な測定ではなくなる」という法則です。数値目標を満たすためのハックはできるかもしれませんが、理想の状態を設定することで、理想とのギャップが明らかになり改善点を見出しやすくなります。ただ数値を満たすのでなく、プロダクトの目標、チームの目標を達成することを念頭におきながら、ふりかえりで数値を見て、伸びしろを見出していきます。

Four Keysだけじゃない開発生産性

『LeanとDevOpsの科学』の著者の1人Nicole Forsgrenさんらが提唱した開発生産性フレームワークSPACEというものがあります。SPACEは、「重要な1つの指標」で生産性のすべてを捉えようとする過ちに対して、複数の観点、指標でバランスをとって生産性を捉えることを提唱しています。

おっと、私たちがやろうとしていることは1つの指標だけ追おうとしているので、このままではチームの生産性を見誤りそうです。

SPACEは5つの観点の頭文字を取ったものです。5つの観点は次になります。

Satisfaction and well being - 開発者の仕事、チーム、ツール、文化への満足度、健康で幸せであるか
Performance - システムやプロセスの結果、品質や顧客満足度などの成果
Activity - 作業を行う過程で完了した行動やアウトプットの数
Communication and Collaboration - 人々とチームがどのようにコミュニケーションをとって一緒に作業をするか、ドキュメントの検索性や質など
Efficiency and flow - 最小限の中断や遅延で仕事を完了させたり進捗を遂げたりする能力

記事執筆時点では、チームでどの観点を活用するかまだ決まっていません。SPACEをチームに紹介したところ、どの観点も興味深いというコメントがあり思案しています。SPACEでは、3つの観点を選んで計測することが推奨されています。

SPACEについて調べていく中で、前期のチーム活動の中ですでに計測しているものがあることがわかりました。具体的には、デプロイフローの運用改善、バグの流出数と重大度の計測、新機能の利用状況の分析、といった計測や取り組みを行っていました。今回定めた実装時間の目標はActivityに該当するので、チームの理想状態を考えて、他の観点の指標も選んでふりかえりに活かしたいと思います。