生産性の指標

開発の生産性を「書いたコードの行数」や「コミット数」で測るのは誤りです。よく使われるのは、DORA（DevOps Research and Assessment）の調査から生まれた Four Keys です。速さ（2つ）と安定性（2つ）を組にして見るのが特徴で、片方だけを上げる無理な改善に気づけます。

小さな変更をこまめに出すチームほど、速さと安定性の両方がよい傾向がある、というのが DORA の調査の大きな結論です。大きな変更をまとめて出すと、1回の失敗の影響も原因の切り分けも大きくなるからです。

なお DORA は指標の定義を調査のたびに見直しています。近年は5つ目の指標としてデプロイのやり直し率（本番の障害に対応するための、予定外のデプロイの割合）を加え、「スループット（速さ）」と「不安定さ」の2つのまとまりで整理しています。まずは Four Keys の4つを測れるようにし、慣れてきたら追加を考えるとよいでしょう。

指標の使い方と、使ってはいけない使い方

「指標が目標になると、よい指標ではなくなる」（グッドハートの法則）を覚えておきます。たとえばデプロイ頻度を目標にすると、意味のない小さなデプロイが増えるだけです。

数字だけでは「なぜ遅いか」は分かりません。開発者が日々どれだけ気持ちよく仕事ができるか（DevEx：Developer Experience）も合わせて見ます。よく使われる見方は次の3つです。

• フィードバックの速さ：テスト・ビルド・レビューの結果がどれだけ早く返ってくるか。
• 認知負荷：仕事に必要な知識の量。手順が複雑・ドキュメントがないと重くなる。
• 集中できる時間：会議や割り込みに邪魔されず作業できる時間がまとまってとれるか。

四半期ごとなどに短いアンケート（「CI の待ち時間に困っていますか」「まとまった作業時間がとれていますか」など5段階）をとり、Four Keys の数字と並べて見ると、手を打つべき場所が見えてきます。満足度・成果・活動・コミュニケーションと協力・効率とフローの5つの観点で見る SPACE という枠組みも知られています。どの枠組みでも、1つの数字で生産性を決めつけないのが共通の考え方です。

テストと配信の自動化（CI/CD）、PR ごとに動作を確かめられるプレビュー環境、速いビルドは、チームの生産性の土台です。CI が20分かかれば、1日に何度も待たされ、その間に集中が切れます。

ボトルネックの見つけ方

「PR を作ってから本番に出るまで」を区間に分けて、それぞれの時間を測ります。どこで一番待っているかが分かれば、打ち手が決まります。

GitHub などのデータから、区間ごとの時間の中央値と、遅いほうの1割（p90）を見ます。平均だけだと、一部の極端に遅い PR に引っぱられます。メンバーへの「一番待たされているのはどこ？」という質問も、数字と同じくらい役に立ちます。

高速化の具体的な方法は SRE の「ビルド・CIの高速化」で。

Four Keys とあわせて、チームの中の仕事の流れを見る指標もよく使います。

この3つには、平均でリードタイム ＝ WIP ÷ スループットという関係があります（リトルの法則）。人を増やさなくても、同時に抱える量を減らすだけでリードタイムは短くなります。「みんな忙しいのに、なかなか終わらない」ときは、まず WIP を数えてみます。

数字では分からない「なぜ」は、短いアンケートで聞きます。続けて比べられるよう、同じ質問を定期的にとります。

一番大事なのは結果を返して、何か1つは変えることです。答えても何も変わらないアンケートは、回を重ねるごとに回答が減り、本音が書かれなくなります。

指標は、チームが毎週見る場所にまとめておくと使われます。見るたびに全部を細かく読む必要はなく、変化に気づけることが大事です。

• 週1回、チームの定例で5分ほど見る。大きく動いた数字だけ話す。
• 1つの週の上下より、数週間の傾向を見る。
• 数字が悪くなったら「誰のせいか」ではなく「何が変わったか」を聞く。

最初から全部をそろえようとせず、すぐ取れる2〜3個から始めて、使われるものだけ残します。

経営や事業側への報告では、エンジニアの言葉の指標をそのまま見せても伝わりにくいです。事業の成果と結びつけて説明します。

• 成果と投資をセットで：「何に時間を使い、何がよくなったか」を並べる。
• 悪い数字も出す：隠すと、あとで信頼を失う。理由と打ち手を添える。
• 個人の数字は出さない：チーム単位の傾向だけを報告する。

「エンジニアの生産性を上げてほしい」と言われたら、まず何に困っているのか（機能が届くのが遅い・障害が多い・費用が高いなど）を聞き、それに合う指標を選んで合意します。