😈

エンジニアのアウトプットを定量的に測る”戦闘力”の紹介

三好力

2025/10/20に公開

こんにちは、三好 力です。
エアークローゼットのエンジニアチームでEMをしているのですが、先日行ったEM系のイベントでエンジニアの評価の話しになり、そこで今回の記事の内容を少し喋ったところ、興味を持ってくださった方が何名かいらっしゃったので書いてみようと思いました。

 なぜアウトプットの定量化が必要なのか？どんな仕組みにもメリット・デメリットがあると思います。

エンジニアのアウトプットをどう測るか・どう評価するかにも、よくある課題が存在します。

 よくある課題アウトプットが見えづらい
自分やチームがどれだけ成果を出しているのかが分かりづらい
「なんとなく頑張っている」状態になりがち
評価が属人的・定性的になりがち
評価基準が人によって異なり、成長実感を得づらい
フィードバックが定量的でないため、改善の方向が見えにくい
AIツール導入の効果が見えにくい
Copilot や ChatGPT などの導入後、成果や効率化が可視化しづらい
コンピテンシー（行動基準）だけでは技術成長が見えない
行動指針を守っても、スキルアップや技術的挑戦が測りにくい
事業成果＝エンジニア評価 になってしまう
プロダクトの業績が良くても、それが個々の技術貢献を正確に反映しない
「事業成果 ≠ 技術スキル」のギャップが生まれる
良いエンジニアの定義が曖昧
チーム内でも「何をもって優れているとするか」が統一されていない
スキルのPDCAが回しづらい
成果を可視化できず、学習や改善の打ち手が立てにくい
短期的に見えにくい貢献が評価されにくい
数字になりにくい日常的な行動が埋もれがち
コードレビュー
良い設計
相談対応
バグ調査
リファクタリング
ナレッジ共有
ドキュメント整備


 これらを解決する "戦闘力" という仕組み
 戦闘力とは？エンジニアが 1日あたりに出力できるポイント数 のことを指しています。

 ポイントとは？タスクの難易度に応じた数値
時間ではなく、難易度に比例してポイントを設定
見積もりにはフィボナッチ数列（1, 2, 3, 5, 8...）を採用

 タスク別のポイント例

カテゴリ
内容
ポイント目安


開発
UI改修
1~3

開発
新規UI構築
5~8

開発
新規API構築
8~13

リリース
デプロイ
1~2

コードレビュー
Pull Request対応・レビューコメント
2〜3

ドキュメント整備
README更新、仕様補足、設計書追記
1〜2

見えにくい貢献も1つずつ棚卸ししています

 集計と可視化の仕組みタスクはBacklogで管理

右の数字がポイントです。


GAS(Google Apps Script)でBacklogAPIを叩いてSpreadsheetに出力
Spreadsheetで集計
計算式: 月合計のポイント数 / 月合計の営業日 = その月の戦闘力
例: 300(point) / 20(days) = 15

メンバーごとに可視化し共有



 チームごとの開発キャパ計算や目標にも各エンジニアの目標戦闘力をベースに、チーム目標を設定し管理しています。

 導入して良かったこと
 PDCAがまわしやすくなった各メンバーの出力データをもとに、日次・週次・月次・四半期等で1on1を実施
得意・不得意が可視化され、課題の解像度が上がった
改善サイクルが短くなり、エンジニアが自分の成長を実感しやすくなった

 目標管理がしやすくなった個人・チーム単位で戦闘力（出力量）目標を設定
進捗がリアルタイムで可視化され、目標未達の早期発見が可能に

 評価の透明性が上がった評価基準を見える数字に落とし込んだことで、上長やメンバー間での認識差が減少
定性的な会話が、定量+行動の根拠をもった対話に変化

 ビジネス側に技術的貢献が伝わりやすくなった今まで見えにくかった技術的貢献を数字で示せるようになった
レビュー、改善提案、リファクタリングなど、短期的な事業成果になりづらい行動の価値を共有できるように

 AI活用の効果も測れるようになったClaudeCode、Copilot、CodeRabbitなどのAIツールを使っており、導入による削減時間や開発効率の向上が数字で分かるようになった
まずは数名でテスト導入してみて、ペイすることが分かれば全体に反映させるという意思決定がしやすくなった

 戦闘力によって生まれた問題と対策
 戦闘力を上げることが目的化してしまう問題
QCD(Quality, Cost, Delivery)でいうとDeliveryが主に測れる指標となったことで、プロダクトのUXのバランスが崩れる可能性が出た
戦闘力が高ければそれだけで良いエンジニアというわけではない
対策
QualityやCostを測れる指標を新たに制定し、QCDのバランスを取れるようにした
プロダクトのUXを作るエンジニアとして、目的を大事にする

 タスクの大小が様々で、ポイント設計が難しい問題
同じカテゴリでもタスクの重さがバラつく
特に大規模なもの（新規事業開発など）の設計フェーズは、ポイントも大きくなることが多いため、難易度設定が難しい
対策
設計や開発が終わったあとに、ポイントの再レビューを実施し、再見積もりを行う
難易度とポイントの擦り合わせを何度も行ってポイントの肌感をチームで揃える

 どこまでポイント化するのか問題問題
教育・調整・サポートなど、アウトプットなのか？という貢献が埋もれる可能性が出た
対策
なにがアウトプットで、なにがアウトプットではないのかを基準をチーム全体で整理する
アウトプットではないが、チームにとって必要なものは、分母となる営業日（稼働時間）を計算上減らす

 個人戦になってしまう問題
個々の戦闘力ばかりに注目すると、チームプレイが弱まる
対策
チーム合計の数値を定例ミーティングで共有
サポートや相談に乗る時間も別の指標で評価できるように

 AI活用によるポイントの扱い問題
ClaudeCodeやCursorによって効率化されたタスクの成果を誰のポイントにするかが曖昧になる
実際には、AIが成果を出しただけで、人のスキルが上がったとは言い切れないケースもあります

対策
AIで削減できた時間を＋αの貢献として可視化
AI使用率・自動生成コード率などを別指標でモニタリング
人が考えた判断・設計部分に重きを置く評価にシフトする

 まとめどんな制度にも副作用はあって、完璧なものはおそらくないんじゃないかなと思っています。

それでも改善を続けながら、これからも良い仕組みを目指していく予定です。
ぜひご意見・ご質問や、実施している仕組み等あれば教えていただけると嬉しいです。

 リクルート情報エアークローゼットでは採用活動も積極的に行っていますので、もし興味あれば以下コーポレートサイトなどを覗いてみてください。


https://youtu.be/w99lPd-Uea0

カテゴリ	内容	ポイント目安
開発	UI改修	1~3
開発	新規UI構築	5~8
開発	新規API構築	8~13
リリース	デプロイ	1~2
コードレビュー	Pull Request対応・レビューコメント	2〜3
ドキュメント整備	README更新、仕様補足、設計書追記	1〜2