ゴースト狩り：開発者の本当の貢献を見抜くには

「ゴーストエンジニア」――開発者の10人に1人は、忙しく働いているように見せながら、実際にはほとんど価値のある仕事をしていない。副業、燃え尽き、あるいは単なる怠慢といった本当の理由は、長いあいだ経営側に気づかれないこともあります。(2024年スタンフォード研究：元スレッド)

開発者は、自分たちの生産性が話題になるのを好みません。この職業の長い「黄金時代」を経て、業界には一つの素朴な問いを口にしづらい空気ができました。開発の成果は、投じた時間とお金に見合っているのか。しかし、ゴーストエンジニアにいら立つのは同僚の開発者も同じです。そして多くの場合、問題に最初に気づくのは経営陣ではなくチームです。

ロシアには昔から「密告」を嫌う空気があります。そのため、問題を知っている人が何人もいても、誰も口を開きたがりません。なぜ他人のもめ事に巻き込まれなければならないのか。結局、全員の我慢が限界に達してから、ようやく表面化します。

でも、そのゴーストたちは放っておけばいいのでは？ 会社のお金が少しくらい減っても、大したことではないでしょう。

ところが、そう簡単ではありません……。

私が言う「低いパフォーマンス」とは、Alexが必死に取り組んでいるのにBenより成果が10％少ない、といった話ではありません。毎回のスタンドアップで、チーム全員がまた新しい苦労話を聞かされる状況です。別チームが足を引っ張った、チケットの内容が曖昧だった、運が悪かった。でも明日には絶対に終わります。約束します、と。

ただし、その「明日」は昨日も、一昨日も聞いた言葉で、いつの間にか恒例行事になっています。

チームはこうしたことにすぐ気づきます。実際に仕事を背負っている人たちが、「話をうまく作れば何も問われないのに、なぜ自分だけ身を削って働くのか」と思い始めるのは当然です。

しかし、問題に気づくだけでは足りません。数字や事実がなければ、話し合いはすぐ水掛け論になります。チームは「成果が出ていない」と言い、本人は「仕事をさせてもらえない」と返す。たいてい本格的な調査が始まるのは、皆の我慢が尽き、チームがマネージャーに交代を求めた後です。

そこから長い物語が始まります。事実を集め、双方の話を聞き、フィードバックを伝え、改善のための時間を与える。私の経験では、多くの場合、最後はゴーストが次の――とても幸運な――雇用主のもとへ移っていきます。

問題は、単に一人の仕事量が少ないことではありません。会社は二重に代償を払います。まず、完了しない仕事にお金を払い、次に、同僚やマネージャーが確認し直し、穴を埋め、なぜ進まないのかを調べる時間にお金を払う。最終的にパフォーマンスが落ちるのは一人ではなく、チーム全体です。

チームの我慢が尽き、会社が時間とお金を失う前に、マネージャーは異常を見つけ、背景を尋ね、調査を始められないのでしょうか。

経験を重ねると、いくつかの特徴的な行動パターンから、こうした状況を早めに察知できることがあります。

• 成功はすべて自分の手柄、失敗はすべて他人の責任。
• まだ作業を始めてもいないのに、失敗したときの言い訳を用意する。
• 足りない実力を、過剰な話術で補おうとする。
• 時間がたつほど、特にマネージャーが「悪者」にされる。
• 本当に苦戦している人とは違い、率直なフィードバックを受けても行動が改善しない。

とはいえ、疑いだけでは足りません。デジタルな足跡が必要です。

開発パフォーマンスを測る代表的な手段を見ながら、ゴーストを見つける助けになるかを考えてみましょう。

比較の前に、明白な利益相反をお伝えしておきます。これはDevGhostの公式ブログであり、私はその創業者です。ここに書くのは著者としての見解であって、独立した研究ではありません。

ビジネスやプロダクト全体ではなく、ソフトウェア開発そのものを評価するとき、私は「スピード、品質、量」という単純な三つの軸を使います。スピードはDORAメトリクスで、品質はテストや不具合で見られます。難しいのは量です。ここはまだ十分に開拓されておらず、私たちが探すゴーストが隠れやすい場所でもあります。

DORA：スピードとリリースの信頼性

DORAは、チームがどれだけ速く、安定して変更を本番環境へ届けられるかを示します。現在のモデルは、コミットから本番までの時間、デプロイ頻度、障害を起こしたデプロイの割合、復旧時間、予定外の手戻りの割合という5つの指標を使います。

デリバリープロセスを測るには優れていますが、個人の貢献を測るものではありません。一人が三人分の仕事をし、別の一人がチーム全体の成果に隠れていても、DORAからは分かりません。

しかも、これらの指標はKPIとして実に扱いやすい。以前勤めていた会社では2018年から使い倒し、皆が満足したまま、すべてのダッシュボードを見事に緑色にしていました。現在のDORAモデル。

テストと不具合：仕事の質をどう見るか

手法はすでに確立され、現場でも機能しています。コードレビュー、テスト、静的解析で品質を管理し、不具合やインシデントで結果を追います。

ただし、これらのシグナルから仕事量は分かりません。ごく小さく完璧な修正が一つあれば、すべての指標は緑になり、ゴーストは見えないままです。

Jiraとストーリーポイント：何件のチケットを閉じたか

Jiraでは完了したチケットやストーリーポイントを確認できますが、見積もるのはチーム自身です。同じ仕事でも3ポイントにも13ポイントにもなり、5件のチケットに分けることも、1件にまとめることもできます。

ストーリーポイントは計画には役立ちますが、個人の貢献を測るには不安定です。ポイントが目標になった瞬間、人は仕事ではなくポイントを最適化し始めます。

これもまたKPIには便利です。品質ゲートを通すためだけにデータを入力し、チケットを動かす。意味のない手作業が大量に生まれます。

コミット数とコード行数：文脈のない事実

Gitはチームの見積もりに依存しないため、コミット数や行数を数えたくなります。しかし、5つのコミットが小さな修正一つにすぎないこともあれば、1つのsquashコミットが1週間分の仕事を含むこともあります。

フォーマット変更、生成コード、コピー、コードの移動は行数を膨らませます。一方で、難しい修正がわずか10行ということもあります。

Swarmia、LinearB、Waydev：開発全体を一か所で見る

Swarmia、LinearB、Waydevは、Git、課題管理ツール、CI/CDの情報をまとめます。マネージャーはDORAメトリクス、レビュー待ちの列、変更のリードタイム、サーベイ結果を確認できます。

開発システム全体を把握するには有用で、問題が個人ではなくプロセスにあると分かることも少なくありません。ただし、個々の開発者の仕事量を共通の尺度で測ることは、これらのプラットフォームが中心に据える問いではありません。Swarmia、LinearB、Waydev。

GitClear：コードのノイズを除いた後に残るもの

GitClearは、追加・移動・コピーされたコードを区別し、生成ファイルを除外し、新しいコードが後で書き直されたり削除されたりしたかも考慮します。

そこから算出されるのがDiff Deltaです。コードベースに残った意味のある変更を表す、GitClear独自の単位です。コピーされたコードやすぐ捨てられたコードより、本番で動き続けるコンパクトな変更のほうが高く評価されます。Diff Deltaの仕組み。

Diff Deltaが答えるのは、必要だった仕事量ではありません。ノイズや手戻りの後に、意味のある変更がどれだけ残ったかです。GitClearが特に強いのは、コードの持続性や品質、AIの影響を分析する部分です。

かなり近づいてきました。サービスはベンチマークを公開していますが、Diff Deltaは独自単位のままです。適切な比較対象や方法論への理解がなければ、10,000という数字だけを見ても多くは分かりません。「100％が標準」のような明確な基準点もありません。Diff Deltaのベンチマーク。

BlueOptima：同じ問いをエンタープライズ規模で

私はBlueOptimaを実際に使ってきました。2019年にこのプラットフォームを使い始め、その経験が自分のプロダクトを作るきっかけになりました。

Coding Effortアルゴリズムは、ソースコードの変更ごとに複数の静的メトリクスを分析し、変更の大きさ、複雑さ、コードベースの他の部分との関係を考慮します。そして結果を時間で表します。

そのため、異なるチームや技術スタックの開発者を、グローバルベンチマークも含めて比較できます。私にとってこれは、「この開発者は何行書いたか」ではなく、「この変更にはどれだけ本質的な仕事が含まれているか」に答えようとした、初めて納得できる試みでした。BlueOptimaの方法論、グローバルベンチマーク。

私の場合、そのエンタープライズ向け機能を使うにはかなり大がかりな導入が必要でした。閉域環境にエージェントを展開しなければならず、価格は高く、結果の解釈には専門家も必要でした。

数千人の開発者を抱える会社なら正当化できるかもしれません。スタートアップや小規模チームには、おそらく難しいでしょう。この隔たりが、後にDevGhostを作った理由の一つになりました。

同じ尺度を、RFPなしで

DevGhostを作ったとき、あらゆる開発メトリクスを詰め込んだ、もう一つの統合プラットフォームを作ろうとしたわけではありません。

BlueOptimaが示してくれたのと同じ答え――変更の背後にどれだけ本質的な仕事があるのか――を、スタートアップの経営者や小規模チームが、RFPも長期導入もコンサルタントのチームもなしに使える形にしたかったのです。

考え方はシンプルです。DevGhostは、何が追加・削除・再構成され、その結果を作って検証するのがどれほど難しかったかという、変更そのものを分析します。フォーマット変更、コードの移動、一括自動置換、生成コードは、本質的な仕事から切り分けます。

結果は「等価時間」で表す工数推定です。コードベースを理解し、AIを使わない中堅開発者が同じコードを書くなら何時間かかるか、という尺度です。実際にキーボードを打っていた時間でも、コードの品質や事業価値の評価でもありません。変更同士を比較するための共通の物差しです。DevGhostの方法論を詳しく見る。

Ghost%は、その推定値を中堅開発者に期待される成果量と比較し、本人が実際に開発へ使う時間の割合も考慮します。100％なら標準どおり。低ければ理由を調べるきっかけになり、高ければ研究し、ベストプラクティスにできる可能性があります。

基準は意図的に「AIなしの仕事」を想定しています。DevGhostは、特定のコードを書いたのが人間か、Copilotか、自律型エージェントかを判定しません。最終的な変更を見て、AIなしの中堅開発者なら作成と検証にどれだけの労力が必要だったかを評価します。

だからこそ、AIの効果はメトリクスの中に埋もれず、目に見える形になります。ある期間に、以前なら2倍、3倍の労力が必要だった成果を一人の開発者が作成・検証できれば、Ghost%に反映されます。フォーマット変更、一括生成、その他のコードノイズで同じ効果が出るべきではありません。

評価する側を、誰が評価するのか

最も当然の疑問は、機械が出した推定をなぜ信じるべきなのか、ということです。短く答えるなら、盲信すべきではありません。

仕事の難しさを見積もる行為は、定義上どうしても主観的です。私たちは、同じ変更を複数の経験豊富な開発者に見積もってもらいましたが、出てきた数字にははっきりした差がありました。仕事の速さも、経験も、難しさの感じ方も人それぞれです。

DevGhostも間違えることがあります。強みは絶対的な真実を知っていることではなく、すべての変更を同じ物差しで評価できることです。そこにひいきも、疲労も、作者への先入観も入りません。

だからGhost%は判決ではなく、シグナルです。低い結果が貢献の弱さを示す場合もあれば、チームリードの責務、アーキテクチャ作業、メンタリング、インシデント対応、ブロッカーで説明できる場合もあります。

数字が示すのは、どこで問いを立てるべきかです。答えを探すのは依然としてマネージャーですが、勘だけではなく、独立したセカンドオピニオンを持って始められます。

「チームの誰がどう働いているかは、もう分かっている」

DevGhostのある顧客は、急成長中のAI企業で開発を率いています。当初、彼は開発パフォーマンスを測るという考え自体に懐疑的でした。優れた開発責任者なら、ダッシュボードがなくても誰がどう働いているか分かっている、というのが彼の考えでした。

私たちは、彼がよく知るリポジトリの履歴を分析しました。以前から3人の開発者には懸念がありました。チケットの進みが遅かったものの、別サービスを担当していたため、チームの他のメンバーと比べにくかったのです。DevGhostでは、およそ半年にわたり3人全員が一貫して低い結果を示しました。

その後、彼らが退職し始めたとき、その期間ずっと自分たちのプロダクトも並行して作っていたことが分かりました。DevGhostに理由までは分かりません。ただ、コミット数、プルリクエスト、Slackでの日々の会話からは見えなかった事実――仕事量が期待を明らかに下回っていたこと――を表に出しただけです。

しかし、分析が解雇リストになったわけではありません。別の2人の開発者には、低い結果を材料に具体的なフィードバックを伝え、原因を調べ、パフォーマンスを改善できました。二人ともチームに残っています。

彼が優秀だと考えていた開発者たちも、予想どおりの位置に現れました。しかも、誰が高い成果を出しているかだけでなく、それがどれほど安定しているかも見えるようになりました。

もちろん、一つの事例だけで手法の正確さは証明できません。顧客が驚いたのは、全体像が、それまで感覚でしか分かっていなかったこと――場合によっては後から振り返って初めて明らかになったこと――と非常によく一致した点でした。

一人で三人分の成果を出す開発者がいたら？

ゴースト狩りは、この話で最も注目を集める部分です。しかし、グラフの上側のほうが、実は役に立つかもしれません。

平均の数倍の成果を安定して出す開発者がいるなら、どうやって実現しているのかを詳しく調べる価値があります。

今では、開発者がAIを使っているかどうかは、もはや中心的な問いではありません。多くの人にとってAIは日常の仕事の一部です。大切なのは、エージェントをどれだけ効果的に追加のデリバリー能力へ変えているかです。

オートコンプリートだけで止まる人もいます。一方で、エージェントに適切なコンテキストを渡し、明確なルールを定め、複数のタスクを並行して進め、成果物を丁寧にレビューできる人もいます。同じAIを使えても、生産性の伸びはまったく違います。

高いGhost%は、人とエージェントの組み合わせですでに大きな成果を出している開発者を見つけ、その実践のどこをチーム全体に広げられるかを理解する助けになります。

高い結果が仕事の品質とマネージャーの評価でも裏づけられるなら、その開発者を正当に評価し、引き留め、昇進候補として考えるべきです。そして、その人のやり方を学び、チームに広げるべきでしょう。

物差しを武器にしてはいけない

どんなメトリクスも同じ運命をたどります。遅かれ早かれ、誰かがKPIにしようとする。Ghost%はその用途には向きません。

Ghost%をチームKPIにすれば、人は仕事を指標に合わせて最適化し始めます。ランキングを公開すれば、信頼が消えます。スコアを解雇ボタンにすれば、間違いは避けられません。

私なら、次の4つのルールを定めます。

• 1回の測定や短い期間だけで結論を出さない。
• その人の役割、開発に使う時間の割合、コード外の仕事を考慮する。
• 結果を本人に見せ、背景を説明する機会を与える。
• Ghost%だけを雇用上の判断の根拠にしない。

低い結果が続くなら、マネージャーはまず理由を調べるべきです。本当に仕事を遂行できていないのかもしれません。あるいは、アーキテクチャ作業をしている、他人のインシデント対応を引き受けている、チームのプロセスに阻まれているのかもしれません。

問題が確認できたら、具体的な改善計画を作り、合意した期間の後にもう一度評価します。

メトリクスを拒んでも、人の評価そのものはなくなりません。残るのは感覚、スタンドアップで語られる物語、そしてマネージャー個人の好みです。

スピード、品質、量には、それぞれ別の道具が必要です。DORAは変更が本番へ届く流れを示し、テストと不具合は品質を示します。DevGhostは、コード変更の背後にある仕事量の推定を加えます。

どのメトリクスも、マネージャーに代わって判断を下すべきではありません。

数字の価値は、判決を出すことではありません。難しい対話をもっと早く、事実に基づいて始められることにあります。

皆さんは開発者の仕事量をどう評価していますか。そして、有益な透明性と監視の境界をどこに引きますか。