開発生産性指標に判断基準を作ったら、チームの自律的な改善が始まった話

こんにちは、齋藤です！

先日、Web Creators LTというイベントで「メトリクスの勘所」というタイトルで発表させていただきました。
この記事のはそのLTの内容をベースに、もっと内容を詳細に記載したものです。

開発生産性の計測で経験した課題と、そこから学んだ「測るだけではなく、判断できる基準を作ることの重要性」について書いていきたいと思います！

デプロイ頻度だけを測っていた頃の課題

実はラクーンでも3年前から開発生産性の計測自体は行っていました。
当時は独自の指標で測定しており、その中にはデプロイ頻度も含まれていました。

ダッシュボードを作成し、毎週の定例でグラフを確認する・・・よくある運用の形です。
しかし、しばらく続けているうちに、ただ見るだけ、感想を持てない、という状況に陥ってしまいました。

ある日の定例会議での実際の会話を振り返ってみます。

「最近デプロイ頻度が下がっていますね」
「今、大きめの案件に取り組んでいるので、下がるのは仕方ないですね」
「そうですね」
「...」

議論終了です！笑

今考えるとこれは仕方なかったかなぁと思います。。。
グラフを見ても「この数値は良いのか、悪いのか」という根本的な疑問に答えることができず、それはメンバーが感想を持てないのと同義でした。

こういった状況が続き、「計測することに本当に意味があるのだろうか」と自問自答する日々が続きました。

今期からの新たな取り組み

このような反省を踏まえて、ラクーンでは今期から開発生産性の計測方法を全面的に見直しました。

「測定するだけではなく、その結果から適切な判断ができるようにする！」

これが今回の取り組みにおける最も重要なテーマとなりました。

採用した2つのメトリクス

DORAメトリクス（Four Keys）

まず採用したのが、DORAメトリクスです。
GoogleのDevOps Research and Assessmentチームが提唱している、開発チームのパフォーマンスを測る4つの指標です。

開発生産性の指標としては、一番ポピュラーなものだと思います。
測るのは下記4つの指標です。

デプロイ頻度 - どれだけ頻繁にリリースしているか
変更リードタイム - コミットからデプロイまでの時間
障害回復時間 - 障害からの復旧にかかる時間
変更失敗率 - デプロイによる障害の発生率

「デプロイ頻度」の計測は以前と変わりませんが、今回は大きな違いがあります。

DORAメトリクスの優れている点は、公式に評価基準が定められていることです。
Elite、High、Medium、Lowの4段階で、明確に現在の状態を評価することができます。

例えばデプロイ頻度の場合：

Elite: 1日に複数回
High: 1日〜1週間に1回
Medium: 1週間〜1ヶ月に1回
Low: 1ヶ月〜6ヶ月に1回

この基準があることで、「現在はMediumレベルなので、次はHighレベルを目指そう」といった具体的な目標設定が可能になります。

SPACE

しかし、DORAメトリクスだけでは測定できない重要な要素もあります。
具体的には、チームの満足度やコミュニケーションの質といった定性的な側面です。
そこで採用したのがSPACEです。

SPACEは以下の5つの観点の頭文字を取ったものです：

Satisfaction and well-being（満足度）
Performance（パフォーマンス）
Activity（アクティビティ）
Communication and collaboration（コミュニケーション）
Efficiency and flow（効率性とフロー）

今回は特に「Satisfaction and well-being」と「Communication and collaboration」の計測を行うことにしました。

この2つを選んだ理由は以下になります。

Satisfaction and well-being

満足度は開発生産性の先行指標となり得るというデータがあります。
これは例えば、DORAメトリクスがとても良い状態でも、満足度が低い状態だと、近い将来開発生産性は下がっていくというものです。
満足度の指標の一つには「燃え尽き症候群」という項目があるのですが、目一杯仕事を頑張ることを長期的に続けるのはしんどいというのはイメージしやすいと思います。

DORAメトリクスはあくまで今現在の生産性というイメージなので、それが持続可能かという視点を入れるために、この指標を計測対象としました。

Communication and collaboration

コミュニケーションは、部署間で発生するリードタイムやチームの成熟度を把握するための重要な指標になると考えました。
例えば、DORAメトリクスで生産性に課題があると判断した際、その原因がチームのコミュニケーションの部分にあったとしても、
ここが可視化されていないと、この部分を課題としては設定し辛くなると思い、計測対象として判断しました。

どういうことかというと、「生産性が低い状態なのは、コミュニケーションのせいだ！」という課題設定の会議って、なんとなく暗ーい議論になりそうじゃないですか？
逆に言うと、ここを可視化できれば、何を改善すればよいかが明確になり、チーム内で前向きな議論ができるようになると考えました。

加えて、タックマンモデルで提唱されるチームビルディングの段階においても、コミュニケーションの量と質はチームのレベルを上げるための壁と定義されています。

ある程度フラットにチームの状態を認識することが、この課題に対処するために必須だと考えました。

判断基準の作り方

DORAメトリクスの実装

DORAメトリクスについては、何を測るかは公式の基準があり明確でした。
ただし、正確な計測を実現するためには様々な工夫が必要でした。

例えば、障害回復時間を正しく測定するために、障害対応時のフローを見直したり、
障害の開始時刻と終了時刻を確実に記録する仕組みを導入し、障害の定義も明確化したりしました。

こうした準備を経て、ダッシュボードには現在の状態が一目で把握できるようElite/High/Medium/Lowのバッジを表示できるようになりました。

SPACEの課題と独自の工夫

一方、SPACEの計測は、DORAメトリクスのように単純に計測の仕組みを作るだけではいきません。

SPACEの公式ドキュメントには「こういった観点で測定しましょう」という指針は示されていますが、「具体的にどう測定するか」「どの数値が良好と判断できるか」といった詳細な基準は記載されていないからです

なので、自分たちで基準を作る必要がありました。

計測方法の設計

まず、満足度とコミュニケーションという定性的な要素をどう数値化するか検討しました。
採用した手段は、よくある形ではありますが、サーベイ形式です。

サーベイの設問の回答には、リッカート尺度という心理学研究でよく使われる測定手法を使うことにしました。
これは、質問に対して「1（全く同意しない）」から「5（強く同意する）」までの5段階で回答してもらう方式です。
中間の3を「どちらでもない」とすることで、回答者が明確な意見を持たない場合の選択肢も用意しています。

設問の設計

各指標につき9問の設問を用意しました。

満足度（Satisfaction and well-being）では以下の質問を設定しています。

「現在の待遇にどの程度満足していますか？」
「技術戦略部の居心地にどの程度満足していますか？」
「スクラムチームの居心地にどの程度満足していますか？」
「上司（評価権限を持つ人）との関係にどの程度満足していますか？」
「仕事を効率的するために必要なツールやリソースの提供にどの程度満足していますか？」
「スキルアップや技術的成長の機会の提供にどの程度満足していますか？」
「技術的な意思決定を行うための権限や裁量にどの程度満足していますか？」
「最近の仕事において、精神的・身体的に疲れ果てていると感じる頻度はどの程度ですか？（5: 全くない / 4: 稀に / 3: 時々 / 2: 頻繁に / 1: 常に）」
「現在の開発業務に対して、やりがいや達成感を感じられていますか？（5: 強く感じる / 4: やや感じる / 3: どちらでもない / 2: あまり感じない / 1: 全く感じない）」

SPACEの公式資料では、「従業員満足度」「開発者効力」「燃え尽き症候群」の3分類を測定すると良いという記載があるので、それらに分類できる設問で組み立てました。

コミュニケーション（Communication and collaboration）では、より具体的な行動や状況について尋ねる以下の設問を設定しました。

「あなたのチームは、必要なドキュメントや情報が簡単に閲覧できますか？」
「あなたのチームは、他メンバーの作業の内容や進捗が公開されていますか？」
「チーム内のレビュー（企画やコードのレビュー）の質は高いと感じますか？」
「新しいメンバーが業務に慣れるまでの支援は十分だと感じますか？」
「チーム内のミーティングは意思決定や課題解決に効果的だと感じますか？」
「チームメンバー同士の助け合いは評価されると感じますか？」
「チーム内で共有された新しい情報やノウハウがどの程度実践されていますか？」
「あなたのチームでは、異なる視点や多様な経験を持つメンバーの意見が、忖度なく取り入れられていると感じますか？」
「あなたのチームでの共同作業（例：定例会議、問い合わせ対応など）は、あなたの作業への集中力に影響を与えていますか？」

これらの設問は、単に「コミュニケーションは良い感じですか？」という抽象的な質問ではなく、日々の業務で実際に経験する具体的な場面を想起させるように設計しました。

しかし、設問を作っただけでは、やはり「測定はしているが判断できない」という状況は変わりません。次に必要だったのは、明確な評価基準の設定でした。

CSAT方式の応用による評価基準の設定

そこで参考にしたのが、CSAT（Customer Satisfaction Score）という顧客満足度の測定手法です。

CSATは顧客満足度調査で広く使われている手法で、「満足」「やや満足」と回答した人の割合を算出するシンプルな指標です。この考え方をSPACEの計測に応用することにしました。

実施概要は以下の通りです：

実施頻度: 四半期に1回
設問数: 各指標につき9問
回答形式: リッカート尺度（1〜5の5段階）

そして、CSATの算出方法を以下のように決めました。

5段階評価のうち、4（やや満足）と5（満足）を選択した人の割合を算出

具体例で説明すると、ある設問に10人が回答し、内訳が以下だったとします。

5（満足）: 3人
4（やや満足）: 4人
3（どちらでもない）: 2人
2（やや不満）: 1人
1（不満）: 0人

この場合、4と5を選択した人は7人なので、CSATは70%となります。

このCSATの値に基づいて、以下のように分類することにしました。

CSAT	分類	解釈
80%以上	Elite	チームの大多数が満足している優良な状態
70〜80%未満	High	概ね満足している良好な状態
50〜70%未満	Medium	改善の余地がある状態
50%未満	Low	早急な改善が必要な状態

この基準設定により、例えば「コミュニケーションのCSATが65%でMediumレベル」という具合に、現状を客観的に評価できるようになりました。さらに、設問ごとのCSATも算出することで、「チーム内のレビューは75%でHighだが、他部署との連携は45%でLow」といった詳細な分析も可能になりました。

作成したダッシュボードは以下のようなものです。
今はさらに改良してBottom 2 Boxという指標も入れています。
これは、1（不満）と2（やや不満）を選択した人の割合を示すもので、こちらは低いほど良い状態を示します。
ダッシュボードは全てClaude Codeで作成しました。

チームの変化

判断基準を設けてダッシュボードを公開した結果、チームの反応に明確な変化が現れました。

例えば以下のような会話が、指示なく自然と発生するようになりました。

「ドキュメントの充実度合いと情報のアクセスのしやすさに課題があるみたいですね」
「情報量は十分だと思うんですが、探しにくさはあるんですよね」
「じゃあ情報をAIに食わせて、Chat UIベースで探せるようにしてみますか？」
「集中を妨げる要因の設問も課題がありそうですが、これって問い合わせが多いとかですかね？」
「そうだと思います。」
「じゃあ問い合わせも一次回答をAIが行えるようなもの作ってみましょうか」

やはり、課題が可視化されると、それを改善したくなるのはエンジニアの性ですよね！

以前の「デプロイ頻度が下がっています」「そうですね」で終わっていた定例会議が、
「なぜMediumレベルなのか」「どうすればHighレベルに改善できるか」という前向きな議論の場に変化しました。

特にコミュニケーションに関しては、チーム内で解決できる課題が多いため、各チームが自律的に改善活動を始められています。

「測定結果を確認し、自分たちで改善方法を検討し、実行する」という理想的なサイクルが確立されつつあります。

得られた教訓

この取り組みでは「感想を持てる指標じゃないとほぼ意味がない」という教訓を得ました。

メトリクスの本質は「次のアクションにつながること」です。

単に数値を測定するだけでは不十分で、その数値を見て「良い」「悪い」の判断ができて初めて、「では、どう改善すべきか」という建設的な議論が可能になります。

また、その基準は必ずしも完璧である必要はありません。

今回設定したSPACEの「80%以上がElite」という基準が絶対的に正しいかどうかは、正直なところ確信はありません。

しかし、基準が全くない状態と比較すれば、はるかに効果的でした。

まずは基準を設定して運用を開始し、実践の中で違和感があれば適宜調整していけばよいと思います。

おわりに

今回はラクーンで運用を始めた開発生産性指標の紹介でした。

良い形で運用を始められたので、継続的なカイゼンを続けて行きたいと思います！

もし計測のみで判断基準がないメトリクスがありましたら、参考にしていただければ幸いです。

ラクーンホールディングスでは、マネジメントに興味のあるエンジニアを募集しています！
一緒に組織をカイゼンしていきましょう！！
採用情報はこちら