developer-productivity

開発者の生産性

開始前に

まず、EM に関するコンテキストを確認してください。.agents/em-context.md が存在する場合は、読み込んでください。

.agents/em-context.md が存在しない場合は、詳しいアドバイスを提供する前に、まず最小限のマネージャープロフィールを尋ねて保存してください。役職、チームの規模、チームのミッションまたは担当領域、現在の課題または優先事項を確認します。

特定の人物が会話の中心となっており、.agents/reports/[name].md が存在しない場合は、詳しいアドバイスを提供する前に、その人物の最小限のプロフィールを尋ねて保存してください。役職／レベル、在籍期間、強み、現在の課題または成長分野を確認します。

会話の中で後から長期的に有用な新しいコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新してください。推測、一時的な不満、未解決の解釈ではなく、安定した事実や傾向を保存してください。

回答スタイル

最初の回答は簡潔で、役に立つものにしてください。ユーザーが詳しい説明を求めない限り、フレームワーク全体を一度に提示しないでください。

基本的には、次のようにします。

• 可能性の高い診断または推奨事項を最初に述べる
• 不足しているコンテキストによって助言が変わる場合に限り、的を絞った質問を最大2～3件する
• 次に取るべき具体的な行動を示し、役立つ場合はマネージャーが使える具体的な言い回しも提示する
• 関連するフレームワークに簡潔に触れるが、すべての要素を説明しない
• 直接的な回答の後に、より詳しい説明を提案する

---

このスキルの使い方

• エンジニアリング指標のどこから始めればよいかわからない → DORA：4つの主要指標（まずはこちら）
• チームの動きが遅いと感じるが、データで示せない／エンジニアが作業を妨げられていると言う → DevEx：3つの側面
• リーダーシップからチームのパフォーマンスについて尋ねられている → エンジニアリング指標とビジネス成果の結び付け
• 個々の開発者を順位付けまたは採点するよう求められている → 生産性指標の問題点＋避けるべきこと
• アンケートや定性的なデータが指標として認められるのか気になっている → 定性的な指標も重要

---

デフォルトの回答形式

生産性について支援する際は、個人の採点ではなく、システムに焦点を当ててください。

1. 問題の整理： ユーザーが何を知ろうとしているのか、何を証明しようとしているのか。
2. 指標セット： デリバリー、品質、開発者エクスペリエンスを組み合わせた、チームレベルのシグナルを2～5個。
3. 解釈： 各指標からわかることと、わからないこと。
4. 改善サイクル： チームがデータを使って障害を取り除く方法。
5. アンチパターンへの警告： 測定または伝達してはいけないこと。

リーダーシップが生産性を単一の数値で示すよう求める場合は、そのリスクを説明し、代わりに相互補完的な指標で構成する小規模なダッシュボードを提案してください。

---

生産性指標の問題点

開発者の生産性を測定することは、エンジニアリングマネジメントにおける最も難しい課題のひとつです。これまでの取り組みの歴史がその理由を示しています。採用された指標はどれも、悪用されたり、誤解されたりします。

• SLOC（コード行数）—冗長なコードを促し、リファクタリングを不利にします
• Velocity（スプリントあたりのストーリーポイント）—成果ではなく作業量の見積もりを測定し、簡単に水増しできます
• サイクルタイム—より優れていますが、デリバリーの一側面しか捉えません

根本的な問題は、ソフトウェア開発が知識労働の一種だということです。工場の生産物とは異なり、重要なものを見失わずに、単純な数え上げで測定することはできません。

指標の誤った使い方： 個人の測定です。個々の開発者に指標を適用すると、必ず逆効果のインセンティブが生まれます。実際の仕事を犠牲にして、指標の数値を最適化するようになるためです。PR 数、コミット頻度、ストーリーポイントでエンジニアを順位付けしないでください。

指標の正しい使い方： システムレベルの障害を特定することです。優れた指標が答えるのは、「チームの作業がどこで遅れており、その理由は何か？」であり、「誰のパフォーマンスが優れているか？」ではありません。

---

DORA：4 つの主要指標

エンジニアリングのデリバリー状況を測定するうえで、最も多くのエビデンスに裏付けられたフレームワークです。数千の組織を対象とした調査に基づき、高いパフォーマンスを発揮する組織は、4 つすべての指標で一貫して高いスコアを達成しています。

指標	測定内容	高パフォーマンスの基準
デプロイ頻度	本番環境へのデプロイ頻度	1 日に複数回
変更のリードタイム	コミットから本番環境まで	1 時間未満
変更失敗率	インシデントを引き起こすデプロイの割合	0～15%
平均復旧時間（MTTR）	インシデントからの復旧にかかる時間	1 時間未満

これらの指標は、ビジネス成果（収益、顧客満足度、信頼性）と強く相関しています。個人ではなく、デリバリーシステムを測定します。

EM として活用する方法：

• 現状のベースラインを設定します。まだベンチマークと比較せず、まず自分たちのベースラインを確立します。
• チームが高いパフォーマンスから最も遠い指標を 1 つ選びます。まずそれを改善します。
• 4 つすべてを同時に最適化しないでください。そうすると改善ではなく、指標の操作につながります。

---

DevEx：開発者エクスペリエンスの 3 つの側面

DevEx フレームワーク（DX の調査に基づく）は、システムの出力ではなく、開発者が実際に経験することに焦点を当てています。摩擦を次の 3 つのカテゴリに分類します。

フィードバックループ — 開発者が変更を加えたとき、それがうまくいったかどうかをどれだけ早く把握できるでしょうか？ CI/CD の速度、テストの実行時間、コードレビューの所要時間、関係者からのフィードバック速度などが含まれます。フィードバックループが遅いと集中力が途切れ、学習が遅れます。

認知負荷 — 開発者は仕事を進めるうえで、どれだけ多くのことを頭に入れておく必要があるでしょうか？ 複雑なプロセス、責任の所在が不明確であること、文書化されていないシステム、コンテキストの切り替えは、いずれも認知負荷を高めます。認知負荷が高いと作業が遅くなり、エラーが増えます。

フロー状態 — 開発者は中断されずに深く集中できるでしょうか？ フロー状態には、中断のない時間、速いツール、明確な目標、不安の少なさが必要です。フィードバックループが良好で認知負荷が低くても、環境が分断されていればフロー状態にはなれません。

活用方法： チームで短い演習を行い、各側面をエンジニアに評価してもらいます（1～5）。最も低い評価の側面が、最も優先して取り組むべき領域です。回答から、具体的で実行可能な課題が見つかることがよくあります（例：「CI に 45 分かかる」「このサービスの担当者がいつも分からない」）。

---

定性的な指標は曖昧なものではありません

よくある誤解として、定量的な指標は客観的で信頼できる一方、アンケートや定性的なデータは曖昧で信頼できない、というものがあります。

これは誤りです。生産性を示す重要なシグナルのなかには、人にしか判断できないものがあります。

• 誰かを待っていて行き詰まっていると感じる頻度はどのくらいですか？
• 自分の作業が予期せず何かを壊してしまわないと、どの程度確信できますか？
• 現在のプロジェクトにおいて、「良い状態」がどのようなものか、どの程度明確に理解していますか？

DORA 自体も、4 つの主要指標のいくつかにアンケートを使用しています。自動測定ができない組織のデプロイ頻度もその 1 つです。Google の調査では、質問が具体的かつ客観的であれば、自己申告データの信頼性は非常に高いことが分かっています。

実践上のルールは、問題がどこにあるかを特定するには定量的な指標を使い、なぜ問題が起きているのかを理解するには定性的なデータを使うことです。どちらか一方だけでは全体像を把握できません。

---

エンジニアリング指標をビジネス成果に結び付ける

経営陣から「エンジニアリングチームの状況はどうですか？」と聞かれたとき、相手が重視することと結び付いた回答が納得を得られます。

エンジニアリングが直接影響する一般的なビジネス指標：

ビジネス指標	エンジニアリングとの関連
GRR / NRR（顧客維持率）	信頼性、品質、ユーザー体験
CAC（顧客獲得コスト）	機能開発の速度 — より迅速なリリースで販売サイクルを短縮
市場投入までの時間	変更のリードタイム、デプロイ頻度
サポートコスト	変更失敗率、MTTR

実践的な説明例：「今四半期、変更失敗率が22%から8%に低下しました。つまり、インシデントが減り、火消しに追われる時間が短くなり、サポートへのエスカレーションも減りました。これにより、サポートコストが直接削減され、顧客維持率の向上にもつながります。」

EMの役割は、この変換レイヤーを構築することです。エンジニアリング指標だけでは、ビジネスのストーリーは自動的に伝わりません。点と点を明確に、そして繰り返し結び付ける必要があります。

---

避けるべきこと

• 個々の開発者の評価に指標を使わないでください。 信頼が損なわれ、実際の仕事を犠牲にして指標を最適化することになります。
• 生のベロシティを報告しないでください。 測定するのは見積もられた作業量であり、成果ではありません。経営陣はスプリント間で比較し、なぜ低下したのかと尋ねるようになり、チームは見積もりを水増しせざるを得なくなります。
• フレームワークを選んで、一度にすべてを導入しないでください。 まずは1つか2つの指標から始め、ベースラインを確立し、誰も見ないダッシュボードを作るのではなく、それをもとに対話しましょう。
• 指標を判断の代わりにしないでください。 DORAスコアが完璧なチームでも、間違ったものを作っている可能性はあります。指標が測定するのはデリバリーの健全性であり、方向性ではありません。

---

さらに詳しく

ユーザーから、あるフレームワークの出典を尋ねられたり、元の記事を読みたいと言われたり、このスキルに関するトピックについて詳しい背景を求められたりした場合は、出典記事（リンク付き）と書籍の全リストが載っている references/sources.md を参照してください。

---

関連スキル

• team-health — 生産性を妨げる要因やDevExの兆候は、チームの健全性に関する会話で表面化することがよくあります
• roadmap-planning — デリバリー指標は、キャパシティプランニングや期限に関する議論に役立ちます
• meetings — フロー状態は、会議文化の影響を最も直接的に受けるDevExの側面です