PR数から「SPACEフレームワーク」へ、技術組織の成長と共に進化した開発生産性の計測手法

【9-E-8】 定量評価疲弊しませんか? ～Well-beingと生産性指標を組み合わせたエンジニアリングメトリクスプログラムについて～

　技術組織のパフォーマンスを定量的に計測するにはさまざまな手法がある。どの手法でどのように評価するか、開発する内容や組織の成長段階よって異なってくる。ITエンジニア／デザイナーの副業・転職サービス「Offers」を開発・提供する株式会社overflowでも、組織の成長に合わせて定量評価の指標を進化させてきた。CTOである大谷旅人氏は「定量的な評価は組織を疲労させる」と、これまでの取り組みを紹介し、現在使用しているSPACEフレームワークについて解説してくれた。開発組織のパフォーマンス指標に興味がある人、組織をどのように評価すればいいのか検討している人のヒントになるだろう。

組織の成長段階に応じて変化した評価指標

　冒頭で大谷氏は「この6年の『Offers』開発組織の運営の中で起きたことをベースに、定量評価は組織を疲弊させるという話をします」とテーマを説明してセッションを開始した。

　ここでいう定量評価とは、『LeanとDevOpsの科学』という書籍に出てくるような技術組織の開発生産性を表す定量的な指標のことだ。代表的な指標として、Source lines of code（SLOC）やPR作成数・マージ数・d/d/d（deploys/a day/a developer）などがあるという。

　overflowでは、こういった指標を取り入れた結果、あらためて開発組織の健全性やチームの状態を把握するとは何なのかを考えることになった。

　では、実際にどのような評価指標を取り入れていったのだろうか。これには、次のように4つの段階があったという。

人数規模と指標の推移

　最初の指標は、プルリクエスト（PR）のマージ数である。メンバーも5名程度と少なく、モニタリングに時間をかけられなかったため、この指標を採用した。具体的には、PRのマージ数を機能リリース数と仮定して、1カ月単位で振り返りを実施していた。

　「この指標は、測定が簡単で運用も楽でした。しかし、やはり1PRが1機能リリースとは限らないため、ブランチやPRの運用次第になってしまい数字が不安定になってしまいました。また、メンバー増減の効果を見づらいという側面もありました。PRの増加が、メンバーが増えたおかげかパフォーマンスが増加したおかげか区別できないからです」

　2番目に導入した指標がd/d/dである。これは、1日当たりのデプロイ回数を開発者数で割った数で、チームが拡大しても安定して機能提供できているか把握できる。

　どちらかというと推移を見る指標で、たとえば数値が下降傾向にあるのであれば1開発者あたりの生産性が上がってない、維持してるのであれば安定・停滞している、上昇傾向であればチームが順調に拡大してる、といった具合になるという。

　この指標は、メンバーの増減も考慮されており計測も比較的容易になっている。一方で、ボトルネックになっている要因が見えにくく、別の指標から要因を探る必要があった。

　「私たちの組織も、d/d/dを導入した時期は人員増加していたタイミングで、d/d/d/も上昇傾向で良い感じだと思っていました。しかし、ある時期から数字が大きく変動しなくなり、状態を把握する指標としては使えなくなりました」

　そこで2年ほど前からFour Keysという指標を導入した。これは、GoogleでDevOpsに関する研究開発を行っているDevOps Research and Assessment（DORA）チームがソフトウェア開発とチームパフォーマンスについて確立した指標で、デプロイ頻度・変更のリードタイム・変更障害率・サービス復元時間という4つの指標を用いる。この4つの指標が優秀なチームほど、ハイパフォーマンスでビジネス的にも競争優性が高い組織であるという分析結果に基づいて統計的な面から確立した組織評価を行う指標になっている。

　「この指標は、設計・実装・テスト・デリバリー・保守運用というフルサイクルフローを総合的に測るにはいい指標だと思います。あとエンジアニングプロセスの改善結果が数字に現れやすいのもいい面だなと思います。測定が比較的大変ですが正直あまり悪い印象はありませんでした」

　実際この指標を導入したことで各種プロセスの改善が進んだという。改善活動が結果の数値に結びつくためだ。また、Four Keysの内容が普遍的なものだと判断して、会社のnoteにも公開して広報的にも役立てている。

　こうしてチームのパフォーマンスが測定できるようになったので、これに加えて機能やプロダクトにフォーカスすることにしたという。そのために、SLO（Service Level Objectives：サービスレベル目標）とSLI（Service level Indicators：サービスレベル指標）を定義して、重要機能が継続的に改善・実行できているか観測している。

　Four KeysとSLO/SLIを同時に観測することで、チームとプロダクトの両面で持続可能な改善が行われてるか計測可能になったと大月氏は説明した。従来、属人的に行ってきたパフォーマンス劣化の対応にチームで対応できるようになったのだ。