開発者の生産性を測定する: Google、Notion などの実例

xguru · 2024-01-22T11:06:01+09:00

Google、LinkedIn、Peloton、Amplitude、Intercom、Notion、Postman など17社のテック企業が、開発者の生産性をどのように測定しているかを深掘り分析 1. 17社のテック企業における開発者生産性指標開発者の生産性測定は複雑な問題であり、知識集約型の仕事であるソフトウェアエンジニアリングにおいて「生産的」とは何を意味するのか自体が曖昧開発者生産性（DevProd）または開発者体験（DevEx）チームと呼ばれるチームが、開発者が高品質なソフトウェアを容易にデプロイできるよう支援しているこれらのチームは、エンジニアリングチームの生産性や障害要因を測定し、自分たちの仕事が実際に影響を与えているかを追跡するために、開発者生産性指標を必要としているこれらの企業で使われている開発者生産性指標デリバリーのしやすさ（Amplitude, GoodRx, Intercom, Postman, Lattice）実験速度（Etsy）サービス/アプリの安定性（DoorDash） SPACE 指標（Microsoft）エンジニア1人あたりの週間集中時間（Uber）企業規模ごとに4つを選定 Google : 従業員数 100,000人以上 LinkedIn : 10,000人以上 Peloton : 1,000人以上10,000人未満スケールアップ（エンジニア100人以上1,000人未満）: Notion, Postman, Intercom, Amplitude, GoodRx, Lattice 2. Google のアプローチ Google は開発者生産性測定のベストプラクティスとしてよく言及されるが、Google ほどの投資を真似するのは大半の企業にとって不可能だという主張もある Google の Developer Intelligence チームは、開発者の生産性を測定し、リーダーにインサイトを提供する専門部門 Google は単一の指標では生産性を捉えきれないと考え、速度、容易さ、品質の3つの次元から生産性を見ている Speed 速度: コードレビューが完了するまでにどれくらい時間がかかるか? Ease 容易さ: 開発者にとってコードレビューのプロセスを進めるのはどれほど簡単または難しいか? Quality 品質: コードレビューで受け取るフィードバックの品質はどの程度か? Google は定性的・定量的な測定を組み合わせて指標を計算している 3. LinkedIn LinkedIn は Microsoft 内で独立して運営されており、10,000人以上の従業員を雇用している LinkedIn には、開発者の生産性と満足度を測定し、組織全体にインサイトを届ける Developer Insights チームがある LinkedIn は四半期ごとのアンケート、リアルタイムのフィードバックシステム、システムベース指標を使って指標を取得している四半期アンケート: Developer Insights チームは四半期アンケートを通じて、さまざまなツール、プロセス、活動全般における開発者体験を評価アンケートには約30の質問が含まれ、開発者はおよそ10分以内で回答できるアンケートは Developer Insights チームが開発・運用する独自プラットフォームを通じて提供され、リアルタイムフィードバックや指標システムで収集したデータに基づいて、質問項目を高度にカスタマイズ・パーソナライズできるリアルタイムフィードバックシステム: 四半期アンケートの合間にフィードバックを集めるため、LinkedIn は開発者が開発ツール内で行うイベントや操作を追跡し、特定のトリガーに応じて対象を絞ったアンケートを送るリアルタイムフィードバックシステムを開発このシステムはスマートなスロットリング機構を使い、開発者にフィードバック依頼が過剰に集中しないようにしているシステムベース指標: LinkedIn はシステムデータを使って指標も算出しており、ビルド時間やデプロイ頻度などについて高精度の測定値を提供している Developer Insights チームは、このデータを収集・分析するためのグローバルシステムを維持しており、それを開発者インサイトハブ（iHub）と呼んでいるこのシステムにより、LinkedIn の全チームがそれぞれのニーズに合わせたカスタムダッシュボードやメトリクスを作成できる LinkedIn は定性的・定量的指標の両方を考慮している開発者ネットユーザー満足度（Developer Net User Satisfaction, NSAT）: 開発者が LinkedIn の開発システム全体にどれだけ満足しているかを測定。四半期ごとに測定開発者ビルド時間（Developer Build Time, P50 および P90）: 開発中にローカルでビルドが完了するのを待つ時間を秒単位で測定コードレビュアー応答時間（Code Reviewer Response Time, P50 および P90）: コードレビュアーが作成者の各コードレビュー更新に応答するまでにかかる時間を、勤務時間ベースで測定コミット後 CI 速度（Post-Commit CI Speed, P50 および P90）: 各コミットが継続的インテグレーション（CI）パイプラインを通過するまでにかかる時間を分単位で測定 CI 決定性（CI Determinism）: テストフレークの反対概念。テストスイートの結果がエラーではなく有効な結果である確率を意味するデプロイ成功率（Deployment Success Rate）: 本番環境へのデプロイがどれだけの頻度で成功するかを測定ウィンザー化平均（Winsorized Means）: 外れ値を含むメトリクス内で改善を認識するための方法。最大値と最小値を中央寄りの数値に置き換えて計算する開発者体験指数（The Developer Experience Index）: LinkedIn がチームに提供する特別な指標。この指数は、前述の複数の指標を基にした総合スコア 4. Peloton Peloton は約3,000〜4,000人の従業員を抱える大企業で、LinkedIn よりはかなり小さい Peloton の測定アプローチは、まず開発者体験アンケートを通じて定性的なインサイトを得ることから始まり、その後に定量指標と組み合わせて使われた Peloton はエンゲージメント、速度、品質、安定性の4つの主要領域に焦点を当てて生産性を測定しているエンゲージメント（Engagement）: 開発者満足度スコア速度（Velocity）: 全新入社員の最初のPRおよび10本目のPRまでの時間、リードタイム、デプロイ頻度品質（Quality）: 250行未満のPRの比率、行カバレッジ、変更失敗率安定性（Stability）: サービス復旧時間これら指標の多くを測定する開発者体験アンケートは、プロダクトオペレーション組織の一部である Peloton の Technical Enablement and Developer Experience チームが主導 Technical Enablement and Developer Experience チームは、アンケート結果を分析し、組織全体のリーダーと共有する役割も担っている 5. スケールアップ企業と小規模企業 Notion、Postman、Amplitude、GoodRx、Intercom、Lattice など複数のスケールアップ企業は、100人から1,000人のエンジニアを雇用しているこれらの企業は「動かせる指標（Moveable Metrics）」に焦点を当てている動かせる指標とは、開発者生産性チームが仕事に良い影響または悪い影響を与えることで実際に「動かせる」指標のこと。開発者生産性チームが自分たちの影響力を示すのに役立つ共通指標デリバリーのしやすさ（Ease of Delivery, moveable）: 多くの企業は、開発者が作業を進めるのをどれだけ簡単または難しいと感じるかという定性的な尺度として、デリバリーのしやすさを測定している複数の DevProd リーダーは、チームの目標が開発者の生活をより楽にすることだからこそ、この指標を仕事の「ノーススター」と見なしていると語っているこの指標はかなり動かしやすいため、影響力を示すのにも有用理論的な観点では、この指標は認知負荷やフィードバックループといった開発者体験の主要な側面も捉えているエンゲージメント（Engagement）開発者が仕事にどれだけ興味を持ち、刺激を受けているかを測るエンゲージメントを追跡通常は HR のエンゲージメント調査で測定されるが、DevProd チームも同じ理由からエンゲージメントを重視している開発者のエンゲージメントと生産性は密接に関連している。つまり、「幸せな開発者は生産的な開発者」という言葉があるように、開発者エンゲージメントは生産性の指標と見なせるエンゲージメント測定の真の利点は、速度を強調する他の指標とのバランスを取れること。ソフトウェアをより速く届けるのは良いが、開発者の幸福度低下を代償にすべきではない時間損失（Time Loss, moveable） GoodRx と Postman は平均的な時間損失に注目しているこれは、作業環境の障害物によって失われた開発者の時間の割合として測定されるこの指標は、開発チームの仕事が直接影響を与えられる動かせる指標を提供するという点で、デリバリーのしやすさと似ているコスト換算できる点が大きな利点であり、そのためビジネスリーダーは時間損失を容易に理解できるたとえば、エンジニアリング人件費が1,000万ドルの組織で、施策によって時間損失を20%から10%に減らせれば、100万ドルのコスト削減につながる変更失敗率（Change Failure Rate）これは DORA（DevOps Research and Assessment）研究プログラムの4つの主要指標の1つ Amplitude や Lattice を含む複数の企業で追跡される最上位指標 DORA チームは変更失敗率を次のように定義している: 「本番環境またはユーザー向けのリリース変更によってサービス劣化（例: サービス障害またはサービス停止）が発生し、その後に修正（例: ホットフィックス、ロールバック、前方修正、パッチ）が必要になった割合」 6. 興味深い発見 DORA および SPACE 指標は選択的に使われており、すべての企業が定性的・定量的な測定を併用している DORA : DevOps Research and Assessment SPACE : Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow 「集中時間」が大きく重視されており、Stripe と Uber は「十分な集中時間を確保できた日数」や「エンジニア1人あたりの週間集中時間」といった具体的な指標を共有しているユニークな指標 Adoption Rate（DoorDash, GoodRx, Spotify） Design Docs Generated per Engineer（Uber） Experiment Velocity（Etsy） Developer CSAT/NSAT（Chime, LinkedIn） 7. 自分なりの指標を選ぶ方法 Google の Goals, Signals, Metrics (GSM) フレームワークを使って、指標選定を導くのがよい解決したい問題に対する目標をまず定義し、その目標を達成したことを示すシグナルを見つけ、それから適切な指標を選ぶ目標の定義 Google: 「開発者が優れたプロダクトをすばやく簡単に提供できるよう支援する。」 Slack: 「すべてのエンジニアにシームレスな開発環境を提供する。」 Stripe: 「ソフトウェアエンジニアリングをより簡単にする。」目標から逆算して最上位指標を定義する開発者にとってソフトウェアのデリバリーがどれだけ容易か（Ease）: Ease of Delivery, Deployment Lead Time, Build Failure Rate 開発者がソフトウェアをどれだけ速くデリバリーできるか（Speed）: Perceived Delivery Speed, Perceived Productivity 提供されるソフトウェアの品質（Quality）: Incident frequency, Perceived Software Quality あなたが CTO、VPE、エンジニアリングリードなら最良のアドバイスは「問題を再定義すること（reframe the problem）」 3つのバケットから指標を選ぶことビジネスインパクト今これを構築すべき理由は何か? このプロジェクトは、どのように収益を生み出すか、あるいはビジネス目標を支援するのか? このプロジェクトは順調に進んでいるのか、それとも遅延しているのか? システムパフォーマンスエンジニアリングシステムは高速で安定しているか? インフラは安全で適切に保守されているか? ユーザーは利用しているサービスに満足しているか? エンジニアリング効率定性的指標と定量的指標を組み合わせて測定することは、すべての企業に共通して見られる傾向各社が使う多様な測定項目から着想を得るとよい各社の優先順位やエンジニアリング文化によって、重点的に測定する項目には大きな違いがある

(newsletter.pragmaticengineer.com)

53 ポイント投稿者 xguru 2024-01-22 | 1件のコメント | WhatsAppで共有

Google、LinkedIn、Peloton、Amplitude、Intercom、Notion、Postman など17社のテック企業が、開発者の生産性をどのように測定しているかを深掘り分析

1. 17社のテック企業における開発者生産性指標

開発者の生産性測定は複雑な問題であり、知識集約型の仕事であるソフトウェアエンジニアリングにおいて「生産的」とは何を意味するのか自体が曖昧
開発者生産性（DevProd）または開発者体験（DevEx）チームと呼ばれるチームが、開発者が高品質なソフトウェアを容易にデプロイできるよう支援している
これらのチームは、エンジニアリングチームの生産性や障害要因を測定し、自分たちの仕事が実際に影響を与えているかを追跡するために、開発者生産性指標 を必要としている
これらの企業で使われている開発者生産性指標
- デリバリーのしやすさ（Amplitude, GoodRx, Intercom, Postman, Lattice）
- 実験速度（Etsy）
- サービス/アプリの安定性（DoorDash）
- SPACE 指標（Microsoft）
- エンジニア1人あたりの週間集中時間（Uber）
企業規模ごとに4つを選定
- Google : 従業員数 100,000人以上
- LinkedIn : 10,000人以上
- Peloton : 1,000人以上10,000人未満
- スケールアップ（エンジニア100人以上1,000人未満）: Notion, Postman, Intercom, Amplitude, GoodRx, Lattice

2. Google のアプローチ

Google は開発者生産性測定のベストプラクティスとしてよく言及されるが、Google ほどの投資を真似するのは大半の企業にとって不可能だという主張もある
Google の Developer Intelligence チーム は、開発者の生産性を測定し、リーダーにインサイトを提供する専門部門
Google は単一の指標では生産性を捉えきれないと考え、速度、容易さ、品質 の3つの次元から生産性を見ている
- Speed 速度: コードレビューが完了するまでにどれくらい時間がかかるか?
- Ease 容易さ: 開発者にとってコードレビューのプロセスを進めるのはどれほど簡単または難しいか?
- Quality 品質: コードレビューで受け取るフィードバックの品質はどの程度か?
Google は定性的・定量的な測定を組み合わせて指標を計算している

3. LinkedIn

LinkedIn は Microsoft 内で独立して運営されており、10,000人以上の従業員を雇用している
LinkedIn には、開発者の生産性と満足度を測定し、組織全体にインサイトを届ける Developer Insights チームがある
LinkedIn は四半期ごとのアンケート、リアルタイムのフィードバックシステム、システムベース指標を使って指標を取得している
- 四半期アンケート:
  - Developer Insights チームは四半期アンケートを通じて、さまざまなツール、プロセス、活動全般における開発者体験を評価
  - アンケートには約30の質問が含まれ、開発者はおよそ10分以内で回答できる
  - アンケートは Developer Insights チームが開発・運用する独自プラットフォームを通じて提供され、リアルタイムフィードバックや指標システムで収集したデータに基づいて、質問項目を高度にカスタマイズ・パーソナライズできる
- リアルタイムフィードバックシステム:
  - 四半期アンケートの合間にフィードバックを集めるため、LinkedIn は開発者が開発ツール内で行うイベントや操作を追跡し、特定のトリガーに応じて対象を絞ったアンケートを送るリアルタイムフィードバックシステムを開発
  - このシステムはスマートなスロットリング機構を使い、開発者にフィードバック依頼が過剰に集中しないようにしている
- システムベース指標:
  - LinkedIn はシステムデータを使って指標も算出しており、ビルド時間やデプロイ頻度などについて高精度の測定値を提供している
  - Developer Insights チームは、このデータを収集・分析するためのグローバルシステムを維持しており、それを開発者インサイトハブ（iHub）と呼んでいる
  - このシステムにより、LinkedIn の全チームがそれぞれのニーズに合わせたカスタムダッシュボードやメトリクスを作成できる
LinkedIn は 定性的・定量的指標 の両方を考慮している
- 開発者ネットユーザー満足度（Developer Net User Satisfaction, NSAT）: 開発者が LinkedIn の開発システム全体にどれだけ満足しているかを測定。四半期ごとに測定
- 開発者ビルド時間（Developer Build Time, P50 および P90）: 開発中にローカルでビルドが完了するのを待つ時間を秒単位で測定
- コードレビュアー応答時間（Code Reviewer Response Time, P50 および P90）: コードレビュアーが作成者の各コードレビュー更新に応答するまでにかかる時間を、勤務時間ベースで測定
- コミット後 CI 速度（Post-Commit CI Speed, P50 および P90）: 各コミットが継続的インテグレーション（CI）パイプラインを通過するまでにかかる時間を分単位で測定
- CI 決定性（CI Determinism）: テストフレークの反対概念。テストスイートの結果がエラーではなく有効な結果である確率を意味する
- デプロイ成功率（Deployment Success Rate）: 本番環境へのデプロイがどれだけの頻度で成功するかを測定
- ウィンザー化平均（Winsorized Means）: 外れ値を含むメトリクス内で改善を認識するための方法。最大値と最小値を中央寄りの数値に置き換えて計算する
- 開発者体験指数（The Developer Experience Index）: LinkedIn がチームに提供する特別な指標。この指数は、前述の複数の指標を基にした総合スコア

4. Peloton

Peloton は約3,000〜4,000人の従業員を抱える大企業で、LinkedIn よりはかなり小さい
Peloton の測定アプローチは、まず開発者体験アンケートを通じて定性的なインサイトを得ることから始まり、その後に定量指標と組み合わせて使われた
Peloton は エンゲージメント、速度、品質、安定性 の4つの主要領域に焦点を当てて生産性を測定している
- エンゲージメント（Engagement）: 開発者満足度スコア
- 速度（Velocity）: 全新入社員の最初のPRおよび10本目のPRまでの時間、リードタイム、デプロイ頻度
- 品質（Quality）: 250行未満のPRの比率、行カバレッジ、変更失敗率
- 安定性（Stability）: サービス復旧時間
これら指標の多くを測定する開発者体験アンケートは、プロダクトオペレーション組織の一部である Peloton の Technical Enablement and Developer Experience チームが主導
Technical Enablement and Developer Experience チームは、アンケート結果を分析し、組織全体のリーダーと共有する役割も担っている

5. スケールアップ企業と小規模企業

Notion、Postman、Amplitude、GoodRx、Intercom、Lattice など複数のスケールアップ企業は、100人から1,000人のエンジニアを雇用している
これらの企業は 「動かせる指標（Moveable Metrics）」 に焦点を当てている
- 動かせる指標とは、開発者生産性チームが仕事に良い影響または悪い影響を与えることで実際に「動かせる」指標のこと。開発者生産性チームが自分たちの影響力を示すのに役立つ
共通指標
- デリバリーのしやすさ（Ease of Delivery, moveable）:
  - 多くの企業は、開発者が作業を進めるのをどれだけ簡単または難しいと感じるかという定性的な尺度として、デリバリーのしやすさを測定している
  - 複数の DevProd リーダーは、チームの目標が開発者の生活をより楽にすることだからこそ、この指標を仕事の「ノーススター」と見なしていると語っている
  - この指標はかなり動かしやすいため、影響力を示すのにも有用
  - 理論的な観点では、この指標は認知負荷やフィードバックループといった開発者体験の主要な側面も捉えている
- エンゲージメント（Engagement）
  - 開発者が仕事にどれだけ興味を持ち、刺激を受けているかを測るエンゲージメントを追跡
  - 通常は HR のエンゲージメント調査で測定されるが、DevProd チームも同じ理由からエンゲージメントを重視している
  - 開発者のエンゲージメントと生産性は密接に関連している。つまり、「幸せな開発者は生産的な開発者」という言葉があるように、開発者エンゲージメントは生産性の指標と見なせる
  - エンゲージメント測定の真の利点は、速度を強調する他の指標とのバランスを取れること。ソフトウェアをより速く届けるのは良いが、開発者の幸福度低下を代償にすべきではない
- 時間損失（Time Loss, moveable）
  - GoodRx と Postman は平均的な時間損失に注目している
  - これは、作業環境の障害物によって失われた開発者の時間の割合として測定される
  - この指標は、開発チームの仕事が直接影響を与えられる動かせる指標を提供するという点で、デリバリーのしやすさと似ている
  - コスト換算できる点が大きな利点であり、そのためビジネスリーダーは時間損失を容易に理解できる
  - たとえば、エンジニアリング人件費が1,000万ドルの組織で、施策によって時間損失を20%から10%に減らせれば、100万ドルのコスト削減につながる
- 変更失敗率（Change Failure Rate）
  - これは DORA（DevOps Research and Assessment）研究プログラムの4つの主要指標の1つ
  - Amplitude や Lattice を含む複数の企業で追跡される最上位指標
  - DORA チームは変更失敗率を次のように定義している:
  「本番環境またはユーザー向けのリリース変更によってサービス劣化（例: サービス障害またはサービス停止）が発生し、その後に修正（例: ホットフィックス、ロールバック、前方修正、パッチ）が必要になった割合」

6. 興味深い発見

DORA および SPACE 指標は選択的に使われており、すべての企業が定性的・定量的な測定を併用している
- DORA : DevOps Research and Assessment
- SPACE : Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow
「集中時間」 が大きく重視されており、Stripe と Uber は「十分な集中時間を確保できた日数」や「エンジニア1人あたりの週間集中時間」といった具体的な指標を共有している
ユニークな指標
- Adoption Rate（DoorDash, GoodRx, Spotify）
- Design Docs Generated per Engineer（Uber）
- Experiment Velocity（Etsy）
- Developer CSAT/NSAT（Chime, LinkedIn）

7. 自分なりの指標を選ぶ方法

Google の Goals, Signals, Metrics (GSM) フレームワークを使って、指標選定を導くのがよい
解決したい問題に対する目標をまず定義し、その目標を達成したことを示すシグナルを見つけ、それから適切な指標を選ぶ
- 目標の定義
  - Google: 「開発者が優れたプロダクトをすばやく簡単に提供できるよう支援する。」
  - Slack: 「すべてのエンジニアにシームレスな開発環境を提供する。」
  - Stripe: 「ソフトウェアエンジニアリングをより簡単にする。」
- 目標から逆算して最上位指標を定義する
  - 開発者にとってソフトウェアのデリバリーがどれだけ容易か（Ease）: Ease of Delivery, Deployment Lead Time, Build Failure Rate
  - 開発者がソフトウェアをどれだけ速くデリバリーできるか（Speed）: Perceived Delivery Speed, Perceived Productivity
  - 提供されるソフトウェアの品質（Quality）: Incident frequency, Perceived Software Quality
あなたが CTO、VPE、エンジニアリングリードなら
- 最良のアドバイスは 「問題を再定義すること（reframe the problem）」
- 3つのバケットから指標を選ぶこと
  - ビジネスインパクト
    - 今これを構築すべき理由は何か?
    - このプロジェクトは、どのように収益を生み出すか、あるいはビジネス目標を支援するのか?
    - このプロジェクトは順調に進んでいるのか、それとも遅延しているのか?
  - システムパフォーマンス
    - エンジニアリングシステムは高速で安定しているか?
    - インフラは安全で適切に保守されているか?
    - ユーザーは利用しているサービスに満足しているか?
  - エンジニアリング効率
定性的指標と定量的指標を組み合わせて測定することは、すべての企業に共通して見られる傾向
- 各社が使う多様な測定項目から着想を得るとよい
- 各社の優先順位やエンジニアリング文化によって、重点的に測定する項目には大きな違いがある

1件のコメント

demorier 2024-01-24

以前のマッキンゼー関連の記事の頃から関心を持っていましたが、要約とリマインドになっていて良かったです。