開発生産性の指標を個人の評価に使うか

生成 AI や AI コーディングツールを入れた組織では、経営から「生産性は上がったのか」と聞かれます。答えるために Four Keys などの指標を測り始めると、次の問いがすぐに来ます。その数字を、個人の評価にも使うのか。

「開発生産性 評価」で検索すると、上位に並ぶのは指標の解説と、計測ツールの導入事例です。指標を誰の何に使うかを、各社の実例で比べたものは見つかりませんでした。

この記事は、使い道を 3 つに分けて整理します。

この 3 つごとに、指標の作り手である DORA と SPACE の論文が何と書いているか、国内外の会社が実際にどこまで使ったかを並べます。

現場の不安と経営の説明要求

現場は「監視されるのでは」と感じている

SmartHR のチームは、開発生産性に向き合い始めたときの空気をこう書いています。

「数字が一人歩きしてしまわないか、開発の現場に対して監視や抑圧をされてしまうのではないか」

チームは、変更のリードタイムをチームの振り返りの中で扱いました。数値を目標にするとグッドハートの法則に陥るリスクにも触れています（SmartHR、2024年3月19日）。グッドハートの法則は「指標が目標になると、良い指標ではなくなる」という経験則です。

MonotaRO の EC システム部門では、現場から次の声が上がっていました（MonotaRO、2025年11月18日）。

「これ以上、個々のタスクを速くこなすのは限界がある」

この声のあと、部門が何を変えたかは後の章で見ます。

測り始めている組織と、まだの組織が拮抗している

ファインディが 2025年4月2日から5月21日に、開発に関わる 798 名に聞いた調査があります（ファインディ、2025年8月19日）。

同じ調査は、組織によってコード行数・バグ数・残業時間など重視する指標がばらばらだとしています。取り組みの是非より前に、何を測るかが揃っていないのが国内の現状です。

なお、この調査には「指標を人事評価に使っているか」「評価に使われることへの不安」を聞いた設問はありません。評価への使用の割合を示す公開の数字は見つかりませんでした。生成 AI の導入をきっかけに、指標の使い方を個人の評価の面で変えたという国内の一次情報も見つかっていません。

指標が個人の評価に流れ込む理由

この章は、公開事例をもとにした編集部の整理です。指標が評価に入り込むのは、悪意からではなく、仕組みの側に理由があると考えます。

測れるものは、先に資料に載ります。 経営への説明にはグラフが要ります。グラフにできるのは、デプロイ頻度・PR 数・サイクルタイムのように自動で取れる数字です。一度チームの数字として資料に載ると、「では誰が上げて、誰が下げたのか」を分解したくなります。

チームの数字は個人の数字に分解できてしまいます。 PR もコミットも、作った人の名前が付いています。集計の切り口を 1 つ変えれば、個人の一覧表になります。

作り手の指針が誤って伝わります。 よく「DORA は個人の評価に使うなと言っている」と紹介されますが、DORA の公式の文書に、そう明言した一文は見つかりませんでした。DORA が書いているのは比較と目標化への注意です（次の章で詳しく見ます）。指針の中身が正確に伝わらないと、「禁止されていないなら使ってよい」という判断も生まれます。

PharmaX の共同創業者は、経営者の立場から別の食い違いを指摘しています。Four Keys などの多くの指標は「チームの作業量」の段階しか測っておらず、経営が求める事業への影響とは段階が違う、という整理です（PharmaX、2024年11月7日）。経営が知りたいことと、指標が答えられることがずれたまま、数字だけが評価の資料に流れていく構図です。

エンジニア組織で個人の数字が当てにならない理由

営業の売上のように、個人の成果が個人の数字に表れる仕事もあります。ソフトウェア開発はそうなりにくい仕事です。SPACE の論文（Forsgren、Storey ほか、2021年）は、その理由を具体的に書いています（ACM Queue）。

GitLab の例が、この指摘を数字で裏付けています。GitLab は、メンテナとしてレビューを多く受け持つ人は MR Rate（月の MR 数）が低くなると書いています（GitLab、2020年8月27日）。チームのために働く人ほど、個人の活動量の数字は下がります。

育成の目線で読むと、さらに 2 つの問題があると編集部は見ています。

• 新人を教える人の数字が下がります。 ペアプロで新人と一緒に書いた時間、新人の PR を丁寧にレビューした時間は、教えた側の PR 数に表れません
• 新人自身の数字は低く出ます。 新人は小さな仕事から入り、レビューの往復も多くなります。活動量やサイクルタイムで比べれば不利になるのは当然で、それは成長の遅れを意味しません

指標の作り手と各社の使い道

作り手は何と書いているか

まず指標の作り手の指針を、原文に沿って整理します。

ここで正確に書いておきます。DORA は「個人の評価に使うな」とは書いていません。 書いているのは、他との比較・目標化・競争への注意と、指標をアプリケーションやサービスの単位で使うことです。個人の評価への使用に直接触れているのは SPACE の論文のほうで、活動量の指標を単独で報酬や罰に使うことを明確に否定しています。

各社はどこまで使っているか

次に、国内外の会社が公開している使い方を、3 つの使い道で並べます。○は公開資料で確かめられた使い方、空欄は公開資料に記述が無いことを示します。空欄は「やっていない」ではありません。

個人の評価に使ったと公開している国内の会社は、確かめられた範囲で ラクスと DMM の 2 社でした。逆に「使わない」と明言しているのは海外の GitLab だけです。ほかの会社はチームの単位で使っており、個人の評価については書いていません。

個人目標に使って、ハックされた例

ラクスは、以前の生産性指標を個人目標に使っていました。工数の見積もりにもとづく独自の指標です。その結果を、自社のブログでこう振り返っています（ラクス、2025年5月1日）。

「見積もりを過大にすることで数値をハックできる」

問題はそれだけではありませんでした。見積もり精度の改善のような取り組みは数値に表れず、評価者が個別に評価する手間も出ていました。ラクスはその後、Four Keys を土台にした計測へ見直しています。

DORA の指針が注意していた「指標を目標にすると操作されやすい」が、国内で実際に起きた例です。

個人の貢献度を評価と育成に使うとする例

DMM のプラットフォーム戦略室は、PR からマージまでの時間や PR 数に加えて「エンジニアの貢献度」を指標に入れています（DMM、2024年11月1日）。

「エンジニアの貢献度を定量化することで、適切な評価や育成に繋げることができます。」

同じ記事は、特定の指標だけに頼ると評価が偏るとも書いています。貢献度がどう算出され、評価制度のどこにどの重みで入っているかは公開されていません。

数値を追っても改善しなかった例

MonotaRO の EC システム部門は、2022年に Four Keys の可視化と定点観測を始めました。しかし指標は改善せず、リードタイムは長くなることさえありました。部門の結論はこうです。

「ただ数値を追うだけでは、本質的な改善には繋がらない」

MonotaRO はそこから、働き方とタスクの分け方を見直しました。前の章の「これ以上、個々のタスクを速くこなすのは限界がある」という声と合わせて読むと、個人に速さを求め続けるのをやめ、仕事の進め方を変えた例です。

対照的に、1 つの指標でチームが変わった例

サイバーエージェントの FANTECH 本部は、Four Keys のうちデプロイ頻度だけを測りました。デプロイの流れを揃え、1 年でデプロイ頻度を 4.5 倍にしています（サイバーエージェント、2024年10月31日）。記事は「可視化すること自体が目的化することなく」進めたと書いています。

MonotaRO との違いは、指標を見ることではなく、流れを変える施策と組み合わせた点にあります。

指標の価値を認める立場

指標を評価から外すべきだという立場ばかりではありません。反対の根拠も並べます。

• ウォンテッドリーは、Four Keys や関連指標は開発生産性をバイアスなく評価するために重要だとしています（ウォンテッドリー、2025年11月4日）。指標の価値そのものは否定していません
• GitLab は MR Rate をチームの指標にしながら、チームが小さいと個人の数字を話さずに MR Rate を上げるのは難しいと認めています
• SPACE の論文自体も、個人単位の分析は本人が希望して使うなら有益だとしています。個人の数字を一律に見ないとは言っていません
• DMM は、前述のとおり個人の貢献度を評価と育成に使うとしています

育成の対話での指標の使い方

ここまでの事実から、育成の対話で指標を使うときの条件を、編集部は次の 3 つと読みます。

本人が自分で見ます。 SPACE の論文は、個人単位の分析は本人が希望して自分のために使えば有益だとしています。GitLab でも、一部の EM が個人の MR Rate を「コーチングと理解のために」見ています。共通しているのは、数字が評価者の手元ではなく、本人との対話の場にあることです。

他人と比べません。 DORA は、最も大事な比較は同じ対象の時系列の比較だとしています。個人に当てはめれば、「先月の自分と比べて PR が小さく分けられるようになったか」は意味がありますが、「同期の A さんより PR が少ない」は意味がありません。

活動量だけを見ません。 SPACE は 3 つ以上の観点にまたがって測ることを勧めています。

1on1 で使うなら、次のような問いにすると比較や査定になりにくい、というのが編集部の提案です。

指標を上げるための行動が、逆に育成を損なうこともあります。ファインディは、指標を上げるためのアンチパターンとして、必要以上に細かい PR に分ける、サイクルタイムを縮めるためにレビューを省く、などを挙げています（ファインディ、2024年6月24日）。レビューを省けば、新人がレビューで学ぶ機会が消えます。

編集部の見立て

以上を踏まえて、この媒体の見立てを書きます。

指標はチームの改善と本人の振り返りに使い、個人の評価には直接入れないのがよいと考えます。

根拠は 3 つです。

1. SPACE の論文が、活動量の指標を単独で報酬や罰に使うことをはっきり否定しています。DORA も、比較と目標化が数字の操作を招くと注意しています
2. 国内で個人目標に使ったと公開しているラクスでは、実際に数値がハックされました
3. 育成を担う人ほど、個人の活動量の数字が下がります。指標を評価に入れると、新人を教える行動に罰を与える設計になります

反対の根拠も重く見ています。DMM は貢献度を評価と育成に使うとしており、その結果は公開されていません。うまくいっているなら、この見立ては修正が要ります。GitLab が書くように、小さいチームでは個人の数字に触れずに改善を進めるのが難しいことも事実です。その場合も、数字を見るのは本人との対話の場に限り、評価者の比較表には載せない、という線の引き方はできるはずです。

評価には何を使うのか、という問いが残ります。この記事の範囲では答えを出せません。少なくとも、指標を外した分の判断を評価者の印象に丸投げしないこと、レビューや新人の育成のようなチームへの貢献を評価の項目として書き出すことは、指標を外す前提として要ります。

うまくいっているかの測り方

指標の使い方がうまくいっているかは、指標だけを見ても分かりません。各社は、指標の推移と開発者自身の感覚を並べて見ています。

ラクーンの例は具体的です。サーベイで 4 と 5 を付けた割合が 80% 以上なら Elite、というように自前の基準を決めたところ、チームが自分たちで改善を始めたと書いています（ラクーンホールディングス、2025年11月27日）。

「感想を持てる指標じゃないとほぼ意味がない」

ラクーンのサーベイには、育成と評価にかかわる設問もあります。

• 「チームメンバー同士の助け合いは評価されると感じますか？」
• 「新しいメンバーが業務に慣れるまでの支援は十分だと感じますか？」

これはチームの単位で測っています。個人の数字を評価に入れずに、助け合いや新人の支援が報われているかを確かめる方法の 1 つです。

指標の使い方を決めたあとに見るとよいものを、まとめます。

• チームの指標の推移。 同じチームの時系列で見る。他チームとは比べない
• 開発者体験の調査。 指標が上がっても、現場が監視されていると感じていれば失敗の兆しです
• 数字の操作の兆し。 PR が不自然に細かくなっていないか、レビューが短くなっていないか
• 育成への影響。 新人の支援やレビューが評価されていると感じているか。ラクーンの設問のように直接聞くことができます

読んだ人が決めること

• 自社の指標は、チームの改善・育成の対話・個人の評価の、どの使い道に使っているか。使い道を書き出すと、混ざっていることに気づくことがあります
• 個人の数字を見るなら、誰が見るのか。本人との対話の場に限るのか、評価者の資料に載せるのか
• 指標を評価から外すなら、レビューや新人の育成への貢献を、評価のどこで扱うのか

出典

• DORA: DORA's software delivery performance metrics（2026年1月5日最終更新） / Accelerate State of DevOps Report 2023
• SPACE: The SPACE of Developer Productivity、ACM Queue、2021年
• GitLab: How we measure engineering productivity at GitLab、2020年8月27日
• ラクス: 開発生産性計測について見直して開発速度向上を狙っている話、2025年5月1日
• DMM: エンジニア生産性の見える化：企画から開発、運用まで、2024年11月1日
• SmartHR: 最短距離で価値検証するために、開発生産性に向き合おうとしている話、2024年3月19日
• MonotaRO: 組織横断で取り組む開発生産性：失敗から学んだ本当にやるべきこと、2025年11月18日
• マネーフォワード: 開発者体験サーベイ、めっちゃよかったんで、おすすめです、2024年3月7日
• ラクーンホールディングス: 開発生産性指標に判断基準を作ったら、チームの自律的な改善が始まった話、2025年11月27日
• ウォンテッドリー: 開発生産性を可視化するために、あえて「社内アンケート」をする理由、2025年11月4日
• サイボウズ: 生産性向上チームを全人類に伝えたい、2024年8月20日
• サイバーエージェント: FourKeys風の指標で開発生産性が4.5倍になった話、2024年10月31日
• ファインディ: 「開発生産性」に関する実態調査レポート概説#1、2025年8月19日 / 開発生産性指標を向上させるためにやってはいけないアンチパターン、2024年6月24日
• PharmaX: 経営者から見た"開発生産性向上"の違和感に向き合う、2024年11月7日

マッキンゼーが 2023年8月に出した記事「Yes, you can measure software developer productivity」は、本文を確かめられなかったため根拠に使っていません。マネーフォワードが Four Keys を採用した時期と決めた人は、原典で確かめられなかったため書いていません。

関連

• 測る（評価・目標設定・生産性の指標）
• サイボウズの研修資料 / サイバーエージェントの研修資料 / ラクスの研修の記録
• AIを新人に使わせるか、使わせないか