2024/10/21

/icons/hr.icon

DORA metrics

DevOps Research and Assessment (DORA)

DevOpsチームがソフトウェアの開発、デリバリー、保守の有効性を測定するために利用できるパフォーマンス指標のフレームワークです。DevOpsチームをパフォーマンスに応じて「エリート」、「高」、「中」、「低」に分類し、パフォーマンスの継続的な改善とビジネス成果の向上に役立つベースラインを提供します。DORAメトリクスは、Google CloudのDORA (DevOps Research and Assessments)チームが、6年にわたって31,000人のエンジニアのDevOpsプラクティスを調査した結果に基づいて定義したものです。

1) デプロイの頻度

成功した本番環境へのコードデプロイまたはエンドユーザーへのソフトウェアリリースの頻度を示します。継続的な開発というDevOpsの目標を達成するには、基本的に、デプロイを1日に複数回行うことが求められます。デプロイの頻度を測定することにより、その目標をどの程度達成できているかを明確化できます。

デプロイの頻度のベンチマークは次のように分類されます。

エリート：1日に複数回のデプロイ

高：1週間～1カ月に1回のデプロイ

中：1カ月～半年に1回のデプロイ

低：半年に1回未満のデプロイ

デプロイが「成功した」と見なす基準は組織によって異なります。また、組織内でもチームによってデプロイの頻度はさまざまです。

2) 変更の平均リードタイム

コードをコミットしてから、そのコードを本番環境にリリースするまでの平均時間を示します。このリードタイムが短いほど、すばやくフィードバックを受け取ってアップデートをリリースできるため、その測定は重要です。リードタイムを算出するには、各プロジェクトの開始から終了までの時間を記録し、すべてのプロジェクトの平均を求めます。

平均リードタイムのベンチマークは次のように分類されます。

エリート：1時間以下

高：1日～1週間

中：1カ月～半年

低：半年超

組織独自のプロセス(専門のテストチームを置く、テスト環境を共有するなど)がリードタイムに影響し、チームのパフォーマンスが低く見積もられる場合もあります。

3) 変更の失敗率

本番環境でただちに修正が必要な問題(サービスの低下や停止)を引き起こしたデプロイの割合を示します。問題への対応に費やす時間が長いと、新しい機能や顧客価値の開発にかけられる時間が減るため、変更の失敗率は低いのが理想です。このメトリクスを算出するには、通常、失敗したデプロイの回数をデプロイの総数で割って、平均割合を求めます。計算式は次のようになります。

(失敗したデプロイ数 / デプロイの総数) x 100

変更の失敗率のベンチマークは次のように分類されます。

エリート：0～15%

高：16～30%

中：16～30%

低：16～30%

4) サービス復旧時間

顧客に影響する問題が発生したときにサービスを復旧するまでの時間を示します。このメトリクスは、平均復旧時間または平均修復時間(MTTR)と呼ばれることもあります。該当する問題には、本番環境でのバグから予定外のサービス停止まで、さまざまなものがあります。

サービス復旧時間のベンチマークは次のように分類されます。

エリート：1時間未満

高：1日未満

中：1日～1週間

低：半年超

DORAはモバイルアプリケーションにも使えるのか？

モバイルアプリにおけるクイックイテレーションの意味

DORA メトリクスの基本的な目標はシンプルです。つまり、物事を壊すことなく、できるだけ早く反復できるようにすることです。これは、世界クラスのモバイル アプリのコンテキストでは何を意味するのでしょうか。

安定したリリース頻度を目指します。

新しいモバイル アプリ バージョンをユーザーにリリースするには、時間と労力が必要です。App Store と Google Play のレビューには時間がかかります。エンド ユーザーはアップデートをすぐにインストールしません。バグの修正には時間がかかり (コストもかかります)、リリース前に手動で QA を実行することが理にかなっています。などなど。

このリリースコストは、変更のたびに App Store や Google Play にリリースするのは現実的ではないことを意味します。実際には、パフォーマンスの高いモバイル アプリ開発チームのほとんどは、1 週間または 2 週間のリリース周期を採用しています。

社内/ベータ ユーザー向けにプレリリース バージョンを出荷します。

新バージョンを本番環境にリリースするにはコストがかかるため、優れたパフォーマンスを発揮するモバイル チームは、変更 (プル リクエストなど) ごとにビルドされ、社内/ベータ ユーザーに自動的に出荷されるプレリリース バージョンを使用します。これにより、チームは実際のユーザー フィードバックを取得し、本番環境に到達する前に品質の問題を発見できる可能性が最大限に高まります。

機能フラグの使用。

優れたパフォーマンスを発揮するモバイル アプリ チームの場合、将来の機能は機能フラグの背後にあるだけで、すでに本番アプリに含まれています。ユーザーが最新のモバイル アプリ バージョンをインストールするには、長い時間がかかることがあります。一部の機能については、十分な数のユーザーがその機能を出荷したバージョンをインストールした後にのみ、展開することが理にかなっています。

機能フラグを使用すると、アプリのリリース サイクルとは独立して機能をリリースできます。また、出荷したコードの一部にバグがあった場合に、迅速にロールバックすることもできます。

世界クラスのモバイル開発チームのベスト プラクティスを見ると、主要な DORA メトリックの定義と測定方法に当てはまらないことがわかります。

週 1 回のリリース サイクルでは、「エリート」な展開頻度と変更リード タイムを達成できません。一部のユーザーだけが不良バージョンをインストールし、一部の機能が機能フラグを使用して出荷される複雑な環境で、変更失敗率や平均復旧時間などの高レベルの集計値を測定するのは、非常に手間がかかりますが、得られるメリットはほとんどありません。

DevOps 研究の一環として開発された対策を採用するのではなく、高パフォーマンスのモバイル アプリ開発チーム向けに設計されたプラクティスに重点を置く必要があります。

安定したリリース サイクルを維持する能力に投資します。 (1) アプリがリリース不可能だったために逃した計画リリースと、(2) 何かが壊れてそれに気づくのが遅すぎたためにリリース サイクル外でリリースしなければならなかった修正プログラムの数を追跡します。(3) (1) と (2) の両方に役立つ自動テストに投資します。

プレリリース版をできるだけ簡単に作成できるようにしてください。これにより、小さな増分 (GitHub を使用している場合は小さな PR など) で作業できるようになり、コード レビューなどの内部プロセスが高速化されます。また、アクティブな内部/ベータ リリース チャネルがあれば、新機能に関するフィードバックを早期に取得でき、テストが難しいバグを見つけるのに役立ちます。

アプリのバージョンと機能の採用状況を追跡します。バージョンの採用状況は、新しい機能をいつリリースするかを決定する上で重要です。機能の採用状況は、最も重要な目標である「顧客とビジネスに価値を届ける」ために不可欠です。

結論

モバイル アプリの DORA メトリクスを本当に追跡したい場合は、追跡できます。ほとんどのモバイル チームにとって、これは意味がありません。追跡することに決めた場合は、頻度の低い製品リリースだけでなく、個々の変更 (プル リクエストなど) のレベルで追跡できることを確認してください。

モバイル エンジニアリング チームは、4 つの主要な DORA メトリックよりも、モバイル アプリ開発用に設計されたメトリックを追跡する方が効果的です。定期的なリリース サイクルに従う能力に投資し、機能フラグを使用してユーザーに機能を確実に提供し、適切なサイズの増分で作業するようにすることで、チームは「エリート」DORA ステータスよりもはるかに高いパフォーマンスを発揮できるようになります。

Space metrics

DORAを生み出した一部の著者によって作られた指標。

この記事では、開発者の生産性に関するよくある誤解や誤った認識をいくつか説明します。これらの誤解を暴露することで得られる最も重要なことは、生産性を単一の次元 (または指標) に還元することはできないということです。これらの誤解が広まっており、それを打破する必要性から、私たちは実用的な多次元フレームワークを開発することにしました。なぜなら、緊張関係にある一連の指標を調べることによってのみ、開発者の生産性を理解し、影響を与えることができるからです。

誤解: 生産性は開発者の活動にかかっている

これは最も一般的な誤解の 1 つであり、望ましくない結果や開発者の不満を引き起こす可能性があります。アクティビティ量の増加は、さまざまな理由で発生することがあります。長時間労働は、開発者が悪いシステムを克服するために「力ずくで」作業しなければならないことや、事前に定義されたリリース スケジュールを満たすための計画の不備を示している可能性があります。一方、アクティビティの増加は、エンジニアリング システムの改善、開発者が効率的に仕事をするために必要なツールの提供、または変更やコード レビューの障害を解消するためのチーム メンバーとのコラボレーションとコミュニケーションの改善を反映している可能性があります。

アクティビティ メトリックだけでは、これらのどれが当てはまるかはわかりません。そのため、開発者に報酬を与えるため、または開発者にペナルティを与えるために、アクティビティ メトリックを単独で使用することは決してありません。プル リクエスト、コミット、コード レビューの数などの単純なメトリックでも、データのギャップや測定エラーのためにエラーが発生しやすく、これらのメトリックを報告するシステムでは、ピア プログラミングやブレーンストーミングで見られるコラボレーションの利点を逃してしまいます。最後に、開発者は締め切りに間に合わせるために勤務時間を柔軟に調整することが多く、特定のアクティビティ メトリックを生産性の評価に当てにすることは困難です。

SPACE: 開発者の生産性を理解するためのフレームワーク

生産性は、個人やエンジニアリング システムだけに関係するものではありません。単一の指標やアクティビティ データだけでは測定できません。また、管理者だけが関心を持つものでもありません。SPACE フレームワークは、生産性のさまざまな側面を把握するために開発されました。このフレームワークがなければ、先ほど述べたような誤解が残るからです。このフレームワークは、はるかに広い領域で生産性について合理的に考え、指標を慎重に選択する方法を提供します。指標の意味だけでなく、単独で使用した場合や誤ったコンテキストで使用した場合の限界も明らかにします。

満足感と幸福感: Satisfaction & Well-being

満足度とは、開発者が仕事、チーム、ツール、文化にどれだけ満足しているかです。幸福とは、開発者がどれだけ健康で幸せであるか、そして仕事がそれらにどれだけ影響を与えているかです。満足度と幸福度を測定することは、生産性を理解するのに役立ち、おそらく生産性を予測するのにも役立ちます。たとえば、生産性と満足度は相関関係にあり、満足度は生産性の先行指標として機能する可能性があります。満足度とエンゲージメントの低下は、燃え尽き症候群や生産性の低下が近づいている兆候である可能性があります。

たとえば、パンデミック中に多くの場所で在宅勤務が義務付けられたとき、生産性のいくつかの指標 (コードコミットやプルリクエストのマージ速度など) が上昇しました。しかし、定性データでは、一部の人々が幸福に苦しんでいることがわかりました。これは、生産性のいくつかの面を捉えるバランスの取れた指標の重要性を浮き彫りにしています。一部の活動指標は肯定的に見えましたが、満足度の追加指標はより全体的な状況を描き、生産性は個人的なものであり、一部の開発者が燃え尽き症候群に近づいていることを示しています。これに対抗するため、大規模な組織の一部のソフトウェアグループは「メンタルヘルス」デーを導入しました。これは基本的に、人々が燃え尽き症候群を回避し、幸福を向上させるための無料の休日です。

満足度と幸福感が生産性の重要な側面であることは明らかです。これらの特性は、多くの場合、調査によって最もよく把握されます。満足度の側面を評価するには、次の項目を測定できます。

• 従業員満足度。従業員の満足度と、自分のチームを他の人に勧めるかどうか。

• 開発者の効率性。開発者が作業を完了するために必要なツールとリソースを備えているかどうか。

• 燃え尽き症候群。職場での過度かつ長期にわたるストレスによって引き起こされる疲労。

パフォーマンス: Performance

パフォーマンスは、システムまたはプロセスの結果です。ソフトウェア開発者のパフォーマンスを定量化することは困難です。個々の貢献を製品の成果に直接結び付けることが難しい場合があるためです。大量のコードを作成する開発者は、高品質のコードを作成しない可能性があります。高品質のコードは、顧客価値を提供しない可能性があります。顧客を満足させる機能が、必ずしも肯定的なビジネス成果につながるとは限りません。特定の開発者の貢献がビジネス成果に結び付けられる場合でも、それが常にパフォーマンスを反映するとは限りません。開発者は、より影響の大きい作業を選択する権限を与えられず、影響の小さいタスクを割り当てられている可能性があるためです。さらに、ソフトウェアは多くの開発者の貢献の合計であることが多いため、個々の開発者のパフォーマンスを評価することがさらに困難になります。多くの企業や組織では、ソフトウェアは個人ではなくチームによって作成されます。

これらの理由から、パフォーマンスは出力(output)ではなく結果(outcome)として評価するのが最適です。 ソフトウェア開発者のパフォーマンスを最も簡単に表すと、「開発者が書いたコードは、期待どおりに機能したか」ということになります。パフォーマンスの側面を捉える指標の例には、次のものがあります。

• 品質。信頼性、バグの不在、継続的なサービスの健全性。

• 影響。顧客満足度、顧客の採用と維持、機能の使用、コスト削減。

活動: Activity

アクティビティとは、作業の実行中に完了したアクションまたは出力の数です。開発者のアクティビティは、正しく測定されていれば、開発者の生産性、エンジニアリング システム、チームの効率性について、価値あるものの限られた洞察を提供できます。開発者が実行するアクティビティは複雑で多岐にわたるため、そのアクティビティを測定または定量化するのは簡単ではありません。実際、エンジニアリング システムや環境全体にわたって開発者のアクティビティのすべての側面を包括的に測定および定量化することはほぼ不可能です。ただし、適切に設計されたエンジニアリング システムは、ソフトウェア開発ライフサイクルのさまざまなフェーズに沿ってアクティビティ メトリックを取得し、開発者のアクティビティを大規模に定量化するのに役立ちます。比較的簡単に測定および定量化できる開発者のアクティビティには、次のものがあります。

• 設計とコーディング。設計ドキュメントと仕様、作業項目、プルリクエスト、コミット、コードレビューの量または数。

• 継続的インテグレーションとデプロイメント。ビルド、テスト、デプロイメント/リリース、およびインフラストラクチャの使用率の数。

• 運用アクティビティ。インシデント/問題の数または量、およびその重大度、オンコール参加、およびインシデントの軽減に基づいた分布。

これらの指標は、扱いやすい開発者の活動を測定するためのウェイポイントとして使用できますが、既知の制限があるため、個人またはチームの生産性に関する決定を下すために単独で使用しないでください。これらは開始時のテンプレートとして機能し、組織のニーズと開発環境に基づいてカスタマイズする必要があります。前述のように、ソフトウェアの開発に不可欠な多くの活動は扱いにくいものです (チーム ミーティングへの出席、ブレーンストーミングへの参加、問題に遭遇した他のチーム メンバーの支援、アーキテクチャ ガイダンスの提供など)。

コミュニケーションとコラボレーション: Communication & Collaboration

コミュニケーションとコラボレーションは、人々やチームがどのようにコミュニケーションを取り、協力するかを表します。ソフトウェア開発は、チーム内およびチーム間で広範かつ効果的なコミュニケーション、調整、コラボレーションを必要とする、協力的で創造的なタスクです。互いの仕事にうまく貢献し、効率的に統合する効果的なチームは、チーム メンバーの活動とタスクの優先順位に関する高い透明性と認識に依存しています。さらに、チーム内およびチーム間での情報の流れは、作業の効果的な調整と統合に必要なドキュメントの可用性と発見可能性に影響します。多様性と包括性を備えたチームは、より高いパフォーマンスを発揮します。より効果的なチームは、適切な問題に取り組み、新しいアイデアのブレインストーミングに成功する可能性が高く、すべての選択肢からより優れたソリューションを選択します。

チームの成果に貢献したり、他のチーム メンバーの生産性をサポートしたりする作業は、個人の生産性やフロー状態に入る能力を犠牲にして行われる可能性があり、モチベーションや満足度を低下させる可能性があります。ただし、効果的なコラボレーションにより、一部の個人作業 (不要なコード レビューややり直しなど) の必要性が減り、システム パフォーマンスが向上し (プル リクエストのマージが高速化されると、バグが回避されて品質が向上する可能性があります)、生産性を維持し、燃え尽き症候群を回避 (または逆に、正しく行われない場合は、燃え尽き症候群を悪化させる) できます。

しかし、チームの生産性とチーム メンバーの期待を理解して測定することは、目に見えない作業や、チームのタスクを調整および計画するための明確な作業など、測定が難しい項目があるため複雑です。とはいえ、コミュニケーション、コラボレーション、調整を測定するためのプロキシとして使用できる測定基準の例を次に示します。

• ドキュメントと専門知識の発見可能性。

• 作業がどれだけ早く統合されるか。

• チームメンバーが貢献した作業のレビューの品質。

• 誰が誰とどのように接続しているかを示すネットワーク メトリック。

• 新メンバーのオンボーディング時間と経験。

効率と流れ: Efficiency & Flow

最後に、効率性とフローとは、個人またはシステムを通じて、中断や遅延を最小限に抑えて作業を完了したり、作業を進めたりする能力を指します。これには、チーム内およびチーム間のアクティビティがどの程度うまく調整されているか、継続的な進捗が達成されているかどうかなどが含まれます。

一部の研究では、生産性は、気を散らしたり中断したりすることなく複雑なタスクをこなす能力と関連付けられています。この 生産性の概念化は、多くの開発者が作業中に「フロー状態に入る」こと、またはフロー状態を見つけて最適化することの難しさについて語るときに反映されており、多くの書籍やディスカッションでは、このポジティブな状態を制御された方法で実現する方法を取り上げています。個人の効率 (フロー) については、生産性を高め、生産性を維持するために境界を設定することが重要です。たとえば、集中期間の時間を確保するなどです。個人の効率は、多くの場合、中断のない集中時間または価値を生み出すアプリ内での時間によって測定されます (たとえば、開発者が統合開発環境で過ごす時間は、「生産的な」時間と見なされる傾向があります)。

チームおよびシステム レベルでは、効率はバリュー ストリーム マッピングに関連しています。バリュー ストリーム マッピングは、ソフトウェアをアイデアから作成してエンド カスタマーに提供するまでの手順をまとめたものです。バリュー ストリームのフローを最適化するには、遅延とハンドオフを最小限に抑えることが重要です。DORA (DevOps Research and Assessment) フレームワークでは、チーム内のフローを監視するためのいくつかのメトリックが導入されました。たとえば、デプロイメント頻度は、組織が本番環境に正常にリリースする頻度を測定し、変更のリード タイムは、コミットが本番環境に移行するまでにかかる時間を測定します。

システムを通じての変更の流れに加えて、知識と情報の流れも重要です。効率と流れの特定の側面は測定が難しい場合がありますが、バリュー ストリーム内の非効率性を特定して排除することは多くの場合可能です。顧客やユーザーにとって価値を生み出さないアクティビティは、ソフトウェア開発の無駄と呼ばれることがよくあります。たとえば、重複した作業、作業が正しく行われなかったために発生するやり直し、時間のかかる定型的なアクティビティなどです。

効率性とフローの次元を捉えるメトリックの例は次のとおりです。

• プロセス内の引き継ぎの数、プロセス内の異なるチーム間での引き継ぎの数。

• 流れを維持し、仕事を完了できる能力があると認識される。

• 中断: 量、タイミング、間隔、開発作業とフローへの影響。

• 時間はシステムを通じて測定されます: 合計時間、付加価値時間、待機時間。

効率は、すべての SPACE 次元に関連しています。個人、チーム、システム レベルでの効率は、満足度の向上と正の相関関係にあることがわかっています。ただし、効率を高めると、他の要因に悪影響を与えることもあります。たとえば、フローと速度を最大化すると、システムの品質が低下し、顧客に見えるバグの数が増える可能性があります (パフォーマンス)。中断を減らして個人の効率を最適化すると、コラボレーション能力が低下し、他の人の作業が妨げられ、チームのブレインストーミング能力が低下する可能性があります。

SPACE フレームワークを説明するために、図 1 に 5 つの次元のそれぞれに該当する具体的なメトリクスを示します。この図には、個人レベル、チームまたはグループ レベル、およびシステム レベルの測定例が示されています。これらのメトリクスについて、3 つの簡単な説明があります。まず、コード レビューに関するメトリクスの例を示します。これは、定義方法とプロキシ方法に応じて、SPACE フレームワークのすべての次元を網羅します。次に、フレームワークの 2 つの選択された次元 (アクティビティ、効率とフロー) について追加の例を示します。このセクションの最後には、フレームワークの使用方法 (開発者の生産性を総合的に理解するためにメトリクスを組み合わせる方法、および注意事項) について説明します。付随する補足記事では、インシデント管理における生産性の理解にフレームワークを使用する方法を示します。

https://scrapbox.io/files/67176b970710842a9a3e28cb.png

まず、コード レビューを例に挙げて、フレームワークの構成方法と使用するメトリックに応じて、SPACE フレームワークの 5 つの側面すべてをカバーできる一連のメトリックを示すシナリオから始めましょう。

• 満足度。コードレビューに関する認識の尺度は、開発者がその作業を良いと見ているか悪いと見ているかを明らかにします。たとえば、コードレビューによって学習、指導、コードベースを形成する機会が得られるかどうかなどです。これは重要です。なぜなら、開発者 1 人あたりのコードレビューの数は、一部の開発者が常に不釣り合いな量のコードレビューを割り当てられ、他の作業に費やす時間が少なくなっていると感じている場合、不満の兆候となる可能性があるからです。

• パフォーマンス。コード レビュー速度はレビューの速度を表します。これは、個人がレビューを完了する速さとチームの制約の両方を反映できるため、個人レベルとチーム レベルの両方のメトリックです。(たとえば、個人は割り当てられてから 1 時間以内にレビューを完了できますが、チームでは、すべてのチーム メンバーが提案された変更を確認できるように、すべてのレビューを 24 時間開いたままにするというポリシーを設定できます。)

• アクティビティ。完了したコードレビューの数は、特定の期間内に完了したレビューの数を捕捉する個別のメトリックであり、最終製品に貢献します。

• コミュニケーションとコラボレーション。コードレビュー自体は、開発者がコードを通じてコラボレーションする方法であり、コードレビューの品質や熟慮度を測る指標やスコアは、コラボレーションとコミュニケーションの質的な指標として優れています。

• 効率とフロー。コード レビューは重要ですが、ワークフローを中断したり、遅延によってシステムに制約が生じたりすると、問題が発生する可能性があります。同様に、コード レビューを待たなければならないと、開発者が作業を継続できなくなる可能性があります。コード レビューをまとめて行うことで、開発者のコ​​ーディング時間が中断されず (個々の測定に影響)、システムのスループットが遅延することもないため (システムの測定に影響)、チームは効率的にコードを配信できます (チーム レベルの測定)。したがって、コード レビューのタイミングが個人、チーム、システムの効率とフローに与える影響を測定することが重要です。これは、レビューの完了にかかる時間と中断の特性 (タイミングや頻度など) を捕捉する知覚的またはテレメトリ測定によって行うことができます。

SPACE フレームワークを、(1) アクティビティと (2) 効率とフローという側面をさらに詳しく見てみましょう。この例では、アクティビティの測定は、コミット数、コーディング時間 (合計時間または 1 日の時間帯)、完了したコードレビュー数という個人レベルの指標です。これらは、作業パターンと行動が開発者が作業するチームと環境によって影響を受けることを理解した上で、最終製品に直接貢献する作業を最もよく表しています。

効率とフローには、より幅広いメトリクスの組み合わせがあります。自己申告による生産性の測定は、個人レベルでとらえるのが最適です。開発者にチームの生産性があるかどうかを尋ねると、盲点が生じますが、そのメンバーが生産性を感じたか、または最小限の妨害で作業を完了できたかを尋ねることは、有用なシグナルとなります。また、システムを通じて、コード、ドキュメント、またはその他の項目の作業フローを測定し、かかる時間、またはソフトウェア配信パイプラインでのハンドオフ、遅延、エラーの数などのメトリクスをとらえることもできます。これらは、その値がワークフロー全体またはシステム全体での作業項目の行程をとらえるため、システムレベルのメトリクスを構成します。

フレームワークの使い方

開発者の生産性を測定するには、チームやリーダー (および個人) がフレームワークの複数の側面から複数の指標を取得する必要があります。少なくとも 3 つが推奨されます。たとえば、すでにコミット (アクティビティ指標) を測定している場合は、プル リクエストの数とコーディング時間を指標ダッシュボードに単純に追加しないでください。これらはどちらもアクティビティ指標です。これらを追加すると、生産性のアクティビティ側面を取得する方法が充実しますが、生産性を本当に理解するには、2 つの異なる側面 (生産性の認識とプル リクエストのマージ時間など) から少なくとも 1 つの指標を追加します。

もう 1 つの推奨事項は、少なくとも 1 つの指標に、調査データなどの知覚的尺度を含めることです。人々の生活体験に関する認識を含めることで、生産性のより完全な全体像を構築できます。多くの場合、知覚データは、計測システムの動作のみから観察できる情報よりも正確で完全な情報を提供します。10

複数の次元と測定タイプからのメトリクスを含めると、しばしばメトリクスが緊張状態になります。これは意図的なものです。バランスの取れたビューにより、作業とシステムで何が起こっているかをより正確に把握できるからです。このよりバランスの取れたビューにより、チーム メンバー間でより賢明な決定とトレードオフが強化されます。そうでなければ、当然のことながら、チーム メンバーは作業の 1 つの側面に集中し、システム全体に悪影響を与える可能性があります。

一例として、ストーリー ポイントがあります。これは、アジャイル開発プロセスでチーム レベルの進捗を評価するためによく使用される指標です。チームがストーリー ポイントのみで評価されると、メンバーは自分のポイントを最適化することに集中し、他の開発者の進捗や会社にとって重要な、他のチームとのコラボレーションや将来の開発者のオンボーディングを意味する目に見えない可能性のある作業を完了する妨げになります。また、リーダーが開発者に迅速に作業する能力について尋ねることなくストーリー ポイントを使用して進捗を測定した場合、何かが機能していないためにチームが回避策を講じて燃え尽きているのか、新しいイノベーションが特にうまく機能していて、苦労している可能性のある他のチームを支援するために使用できるのかを識別できません。

これは、指標とそれがチームや組織に与える影響に関する重要なポイントにつながります。指標は、何が重要かを伝えます。組織で何が重要かを間接的に把握する方法の 1 つは、測定されているものを確認することです。これは、評価されている内容が、多くの場合、何が重要かを伝え、人々の行動や反応に影響を与えるからです。たとえば、従業員の健康、幸福、定着率に配慮する企業は、生産性の測定に満足度と幸福の側面を含める可能性が高いでしょう。結果として、指標を追加または削除すると、行動を促せます。それは、何が重要かを伝えるからです。

たとえば、「生産性 = コード行数」のみのチームと、「生産性 = コード行数、コード レビューの品質、顧客満足度」のチームでは大きく異なります。この場合、生産性と出力に関する (問題のある、しかしおそらくは組み込まれた) 指標はそのままにして、生産性に関する認識を、チームワーク (思慮深いコード レビューを重視) とエンド ユーザー (顧客満足度を重視) の両方を重視する方向に少しずつ進めています。

メトリクスは行動を形作ります。そのため、2 つのメトリクスを追加して評価するだけで、チームと組織の変化を形作るのに役立ちます。フレームワークの複数の側面から確実に引き出すことが非常に重要なのは、このためです。これにより、チーム レベルとシステム レベルの両方で、はるかに優れた成果が得られます。この例では、チームが改善と反復を続けるにつれて、アクティビティ メトリクスのコード行数をコミット数などに置き換えることができます。

注目すべき点

メトリクスが多すぎると、混乱が生じたり、モチベーションが低下したりすることもあります。フレームワークが役立つためには、すべての側面を含める必要はありません。たとえば、開発者やチームにメトリクスと改善目標の広範なリストが提示された場合、それらを満たすことは達成不可能な目標のように感じられるかもしれません。この点を念頭に置いて、生産性の適切な測定基準は、少なくとも 3 つの側面にわたる少数のメトリクスで構成されることに注意してください。これらは全体的な視点を促し、改善を促すのに十分な場合があります。

測定パラダイムはどれも慎重に使用する必要があります。なぜなら、完璧な代理指標になることはあり得ないからです。一部の測定指標は、ノイズの多い近似値であるため、測定基準として適切ではありません (図 1 にいくつかの例を示します)。従業員の満足度を測定するために定着率がよく使用されますが、これは満足度以上のものを捉えることができます。報酬、昇進の機会、チームの問題、さらにはパートナーの異動を反映することもあります。チーム レベルでは、マネージャーの中には自分の定着率評価を守るために異動をブロックする人もいます。定着率が満足度を反映していたとしても、それは時差のある測定基準であり、チームは手遅れになるまで変化に気づきません。ストーリー ポイントの使用に固有の制限については、別の場所で説明しました。9 ストーリー ポイントは、重要なプロジェクトでのコラボレーションを犠牲にして、チームに自分の仕事に集中する動機を与える可能性があります。

チームや組織は開発者のプライバシーを認識し、チームまたはグループ レベルで匿名化された集計結果のみを報告する必要があります (一部の国では、個人の生産性を報告することは違法です)。ただし、個人レベルの生産性分析は、開発者にとって有益な情報となる可能性があります。たとえば、以前の調査では、開発者の一般的な勤務シフトは開発の段階によって異なり、開発者は 1 日のうちでより生産性の高い時間帯がある可能性があることが示されています。14開発者は、これらの種類の分析を選択して、日々の業務を最適化し、エネルギーを管理するための貴重な洞察を得ることができます。

最後に、あらゆる測定パラダイムでは、バイアスと規範をチェックする必要があります。これらは、測定を変えたり影響を与えたりする可能性のある外部の影響です。ここにはいくつかの例が含まれていますが、網羅的ではありません。すべてのチームは、データに存在する可能性のある外部の影響を探して検討することをお勧めします。

• ピアレビューと性別。調査によると、女性はコードレビューで否定的なコメントを受け取る可能性が高く、肯定的なコメントを受け取る可能性が低いことがわかっています。16レビュープロセスの満足度を分析する場合は、自分の環境でこの点を確認する必要があります。組織やチームにパターンがなくても、開発者はテクノロジー業界全体から影響を受けている可能性が高いことを理解してください。これらの影響を考慮に入れてください。

• 時間の経過に伴う測定の標準化。チームは、特に長期間にわたる時間の標準化に使用する方法には注意する必要があります。たとえば、1 年間の測定基準を調べると、育児休暇を取っている人に不利なバイアスがかかります。

• 知覚的尺度。チームや組織は文化的規範に留意し、それを受け入れる必要があります。文化によっては、自然に高い数値を報告するものもあれば、低い数値を報告するものもあります。これは知覚的尺度が信頼できないという意味ではなく、単にこれらの異なる文化からの尺度はベースラインが異なるため、互いに比較すべきではないという意味です。

LeadDev Engineering Team Performance Report

https://scrapbox.io/files/6716c3b29fcbbbbb2ae179fd.png

【要約】

このレポートは、エンジニアリングチームのパフォーマンス測定に関する現状と課題を調査したものです。600以上のエンジニアリングマネージャーへの調査結果をまとめています。

【解説】

ソフトウェアエンジニアリングチームのパフォーマンス測定は長年の課題であり、DORA、SPACEなどのフレームワークが登場しているものの、まだ完全な解決策はないことが指摘されています。このレポートは、現在の業界のベストプラクティスを確立し、測定方法の動向を理解することを目的としています。

【和訳】

本について書かれ、コンサルタントがそれを解決できるというPowerPointデッキを設計し、開発者がダッシュボードを構築・再構築し、学者が複雑なフレームワークを開発してきましたが、私たちはまだソフトウェアエンジニアリングチームのパフォーマンスを測定し最適化する合意された方法を持っていません。

チームがソフトウェアを構築することは知っていますが、個人ではありません。しかし、すべての組織がより良いビジネス決定を行うためにそれらのチームのパフォーマンスを測定する方法を渇望していることも知っています。個人もキャリアを進歩させたいと考えており、そのパフォーマンスを客観的に測定する方法を見つけることは、世界中のエンジニアリングマネージャーにとって難しい問題のままです。

DORA、SPACE、およびその他多くのフレームワークの出現にもかかわらず、開発者チームのパフォーマンスを測定する単一の方法はまだ存在せず、より広い会社の目標に対してチームの出力を定量化する任務を負うエンジニアリングリーダーの認知負荷が増加しています。これは、各組織がこのパフォーマンスを最適化したいものが異なるためです。私たちが知っているのは、チームパフォーマンスの効果的な測定は、生の出力データと開発者チームの健康の両方を考慮しなければならないということです。

このレポートでは、エンジニアリングマネージャーにとってのベストプラクティスを確立し、どの測定方法が上昇し、どれが下降しているかをよりよく理解し、エンジニアリングパフォーマンスを最も効果的に管理している組織を特定することを目指しました。

この夏、私たちはEtsy、Shopify、Stripeなどの数十人のエンジニアリングマネージャーと話し、600人以上のエンジニアリングマネージャーを調査して、ほとんどの組織がどのようにチームパフォーマンスを測定し、それを行う上で直面する最大の課題を明らかにしました。これがあなたのチームパフォーマンスの旅の中で自分がどこにいるかを特定し、おそらくパフォーマンスをより良く測定する方法についていくつかのアイデアを生み出すのに役立つことを願っています。

さあ、素晴らしいチームを作り上げましょう！

Scott Carey

Editor in Chief, LeadDev

https://scrapbox.io/files/6716c43d5044548e23b65a2c.png

Swarmiaでの私たちのミッションは、現代のソフトウェアチームに彼らの最高の仕事をするために必要な洞察力を提供することです。そのため、LeadDevの友人たちとのZoomミーティングでこの研究プロジェクトをサポートすることを決定するのに1回のミーティングしかかかりませんでした。私たちは、このプロジェクトをエンジニアリングリーダーがチームのパフォーマンスを測定し改善する際に直面している課題と機会についてもっと学ぶユニークな機会として見ました。

私たちにとって、この研究の結果は、すでに顧客から聞いていたことを嘆いています：高パフォーマンスのエンジニアリングチームをリードするには、継続的な改善への強い取り組みと測定に対する全体的なアプローチが必要です。

実際、今日の最高パフォーマンスのソフトウェアチームは、「すべてを支配する1つの指標」のアイデアを放棄し、代わりに3つの主要な分野にわたって努力を測定するマスターになっています：

• ビジネス成果：最も高い認識されたビジネスインパクトを持つ仕事に焦点を当てる

• 開発者の生産性：デリバリーの妨げになるものを体系的に排除する

• 開発者の経験：待ち時間と中断の負の影響を最小限に抑える

そして、ツールはパズルの一部に過ぎませんが、遅かれ早かれ、追加の可視性、健全な洞察、および自動化が便利になることに気づくでしょう。その時が来たら、swarmia.comで私たちを見つけることができます。

https://scrapbox.io/files/6716c495b4b1861cfa9a4bce.png

【要約】

レポートの主要な調査結果を一目で分かるようにまとめています。

【解説】

エンジニアリングリーダーの3分の2が測定に対するチームの抵抗を主要な課題と感じていること、5分の1の回答者がエンジニアリングチームの目標を設定していないこと、DORAメトリクスとSPACEフレームワークに精通している回答者の半数がそれらを効果的または非常に効果的な測定フレームワークだと考えていることなどが分かります。

【和訳】

一目で分かる

1. エンジニアリングリーダーの3分の2が、測定に対するチームの抵抗を主要な課題だと感じています。

2. 回答者の7%がエンジニアリングチームの目標を全く設定していません。

3. DORAメトリクスとSPACEフレームワークに精通している回答者の半数が、それらを効果的または非常に効果的な測定フレームワークだと考えています。

4. リーダーの半数が、適切なメトリクスを見つけることがチームパフォーマンスの測定における主要な課題だと言っています。

5. 1サイクルタイムが最も有用なエンジニアリング生産性メトリクスとしてランク付けされました。

https://scrapbox.io/files/6716ece5335bbef6740a9035.png

【要約】

エンジニアリングチームの目標設定プロセスについての調査結果を示しています。

【解説】

多くの組織が四半期ごとのOKR（目標と主要な結果）を使用していることが分かります。また、OKRとKPI（主要業績評価指標）の組み合わせも人気があります。目標設定の頻度や方法は、組織の規模や業界によって異なる可能性があります。

【和訳】

目標

「なぜここにいるのか？」は、エンジニアにとって実存的な質問ではありません。目標と目的は、エンジニアリングチームが働き、成功を測定する構造を提供します。達成しようとしている目標を知らなければ、チームのパフォーマンスを測定することはできません。

全社的な目標と主要な結果（OKR）が、ビジネス目標を定義し伝達する広範なコンセンサスの方法であるように見えますが、これをどのくらいの頻度で行うかが重要です。今年明確に見てきたように、物事は変化しやすく、しかも急速に変化します。そのため、回答者の半数が四半期ごとのOKRを設定し、4分の1弱が年次でこの演習を行うのを見るのは驚きではありません。

目標を設定するための他の主要なフレームワークは主要業績評価指標（KPI）でしたが、それだけに依存している組織はわずか14％でした。

別の26％がOKRとKPIの組み合わせを使用し、2番目に人気のあるアプローチとなっています。

目標を設定するための最も人気のあるプロセスは四半期ごとのOKRです

Q：チーム内で目標を設定するプロセスは何ですか？

四半期ごとのOKR：52%

OKRとKPI：26%

年次OKR：24%

KPI：14%

別のフレームワーク：12%

私のチームでは目標を設定していません：7%

https://scrapbox.io/files/6716ed512bb680c013c99cfd.png

OKRとKPI以外の世界もあります。一部の組織やチームは、目標・現実・選択肢・意志（GROW）フレームワークを使用したり、主要結果領域（KRA）を定義したりするかもしれません。他の組織は独自のハイブリッドまたはより非公式なアプローチを開発するかもしれません。それでも、回答者のわずか12％が目標設定のための「別のフレームワーク」を挙げました。これにより、チームで全く目標を設定していない回答者はわずか7％となります。

同様に興味深いのは、北米の回答者の四半期ごとのOKRへの熱意が顕著に低下していることでした - 48％がこのプロセスを選択したのに対し、EMEAとラテンアメリカの回答者では55％でした。

四半期ごとのOKRの人気は、キャリアラダーを上がるにつれてさらに強化されました。ソフトウェアエンジニアリングディレクターは、OKRとKPIの組み合わせを見る可能性が他の人よりも大幅に高く、その33％がこのアプローチを使用していました。これは、エンジニアリング責任者の13％が組み合わせアプローチを使用していたのと比べて大幅に高くなっています。設定された目標なしで働いていると言ったエンジニアリング責任者の割合は17％に上昇しました。

四半期ごとのOKRはすべての職種で最も人気がありますが、ソフトウェアエンジニアリングディレクターは他の人よりもOKRとKPIを使用する可能性が大幅に高くなっています

Q：チームで目標を設定するプロセスは何ですか？

table:answer

項目 エンジニアリングマネージャー エンジニアリング責任者 ソフトウェアエンジニアリングディレクター

四半期ごとのOKR 54% 48% 48%

OKRとKPI 24% 13% 33%

年次OKR 24% 17% 28%

KPI 15% 9% 12%

別のフレームワーク 11% 13% 15%

目標を設定していません 6% 17% 8%

https://scrapbox.io/files/6716ef9846fb16d1d1b9aa38.png

【要約】

会社の戦略的ビジネス目標の理解度と、エンジニアリングチームのパフォーマンスを測定する方法についての調査結果を示しています。

【解説】

多くのエンジニアリングマネージャーが会社の戦略的目標を理解していると回答していますが、完全に理解している人は少数派です。ユーザー成長とユーザー満足度が、ビジネス目標に対するエンジニアリングの影響を測定する上で最も重要なメトリクスとして挙げられています。

【和訳】

ビジネス目標

OKR、KPI、またはそれらの組み合わせは、チームがビジネスの戦略的目標を達成するのを支援するために使用できます。しかし、これを成功させるには、それらの目標が組織全体に伝達されていることを前提としています。

上級リーダーシップチームがビジネス目標を伝達する主な責任を負っていることは明らかで、回答者の83％がこれを組織全体でビジネス目標を共有する主要な方法として挙げています。しかし、エンジニアリングリーダーの半数以上が、ビジネス目標はプロダクトマネージャーによって伝達されると述べています。そして、10人に1人弱が、ビジネス目標はサービスレベル目標（SLO）を通じて伝達されると言っています。

誰がこのイニシアチブを推進しているかにかかわらず、エンジニアリングマネージャーのわずか26％が組織の戦略的ビジネス目標を完全に理解しており、約3分の2が良好な理解を持っていると言っています。これは高いように見えるかもしれませんが、エンジニアリングパフォーマンスをそれらの目標を満たすように導くことを保証するのに「良好な理解」で十分でしょうか？

これにより、心配な12％の回答者がまだ会社の戦略について暗闇の中にいることになります。

Q：あなたの会社の戦略的ビジネス目標をどの程度理解していますか？

完全な理解：26%

良好な理解：62%

ある程度の理解：11%

わずかな理解：1%

全く理解していない：1%

https://scrapbox.io/files/6716f0725044548e23b743f4.png

進捗の測定

会社のより広範な戦略的目標が何であれ、エンジニアリングリーダーはチームがそれらにどのように貢献しているかを測定する方法が必要です。これは歴史的に困難であることが証明されています。ソフトウェアエンジニアリングを構成する複雑な入力の網が測定可能な結果に整然とマッピングされないため、各マネージャーにはパズルを組み立てる作業が残されています。

多くの人が最初に目を向けるのはユーザーです。エンジニアリングパフォーマンスをより広範なビジネス目標にリンクするための最も高くランク付けされたメトリクスはユーザー成長で、ユーザー満足度が続きました。次に投資収益率（ROI）が来て、SLOの達成が5位でした。

しかし、これらがチームが監視している唯一の主要メトリクスではありません。一部のチームは収益と年間経常収益のチャーン、維持率、ネットプロモータースコア（NPS）、ソーシャルメディアの盛り上がりと感情を、彼らの仕事の影響の指標として測定することを選んでいます。

このインパクトをどのように測定するかについては、半数以上のエンジニアリングチームが四半期ごとのレビューを使用し、やや少ないチームがマネージャーがレビューするための独自の目標を設定しています。コード品質は40％が追跡し、わずか6％が事前検討を使用しています。バグクォータやスプリントポイントの持ち越しなどの指標は5分の1未満が使用しています。

これは、リーダーがチームの影響をより全体的に見ていることを示唆しており、データポイントの寄せ集めを集めるのではなく、より包括的なアプローチを取っていることがうかがえます。

ユーザー成長とユーザー満足度が、戦略的ビジネス目標に対する影響を測定するためにエンジニアリング組織で使用される最も重要な2つのメトリクスとしてランク付けされました

Q：戦略的ビジネス目標に対する影響を測定するために、あなたのエンジニアリング組織で使用されている以下のメトリクスのうち、どれが最も重要ですか？

1. ユーザー成長

2. ユーザー満足度

3. ROI

4. ユーザーコンバージョン

5. SLOの達成

https://scrapbox.io/files/6716f1d7a6b60f28f19626b5.png

【解説】

この部分では、エンジニアリングチームの貢献を測定する方法について詳しく説明しています。ユーザー関連のメトリクス（成長や満足度）が最も重要視されていることが分かります。また、多くのチームが四半期ごとのレビューを行っていることも明らかになっています。これらの結果は、エンジニアリングチームの成果をビジネス目標により直接的に結びつける傾向が強まっていることを示唆しています。

【和訳】（続き）

ここでは、職位による違いに注目すべき点がありました。エンジニアリングマネージャーとソフトウェアエンジニアリングディレクターの両方が、全体的な数字に沿って四半期ごとのレビューを選択する可能性が最も高かったのです。エンジニアリング責任者の22％だけが四半期ごとのレビューを挙げました。しかし、エンジニアリング責任者はコード品質と顧客苦情の数に焦点を当てる可能性がはるかに高く、この群の52％がこの両方を挙げました。

四半期ごとのレビューが戦略的目標の達成を追跡するための最も人気のあるメカニズムであったにもかかわらず、パフォーマンスはより頻繁に、少なくとも戦術的に監視されていることは明らかです。5人に1人の回答者が週次でパフォーマンスを報告し、それよりもわずかに多くの人が月次で報告しています。ソフトウェアエンジニアリングディレクターは四半期ごとに報告する可能性が最も高いコホートでした。

Q：チームのパフォーマンスについて、どのくらいの頻度で報告する必要がありますか？

週次：19%

月次：22%

四半期ごと：23%

その他の頻度：25%

報告する必要がない：11%

https://scrapbox.io/files/6716f240c50cd5875d5dcaa1.png

【要約】

チームパフォーマンスの報告に使用されるツールと、チーム間の調整頻度についての調査結果を示しています。また、Gorgiasという会社の事例研究も紹介されています。

【解説】

GitLabとJiraが最も多く使用されているツールであることが分かります。また、多くのチームが週次または日次で他のチームと調整を行っていることも明らかになっています。事例研究では、チーム間の協力を改善することでエンジニアの認知負荷を軽減し、顧客の問題解決に集中できるようになった事例が紹介されています。

【和訳】

報告ツールに関しては、エンジニアリングマネージャーにとって選択肢が不足していることはありません。この市場への新規参入者の波にもかかわらず、まだ2つの明確な突出したものがあります：GitLab（66％）とJira（65％）で、控えめなダッシュボードが38％で次に来ています。他の報告ツールはそれほど人気がなく、6％の使用率を超えるものはありませんでした。一方、3分の1がGoogle Sheetsを含む他のツールを挙げました。

より大きな課題は、正確なメトリクスを選択することです。回答者の67％がここで苦労しており、41％がツールやダッシュボードの不足を課題として挙げています。興味深いことに、エンジニアリングリーダーの5分の1だけが、測定されることへのチームの抵抗を主な課題の1つとして特定しました。

これは、ソフトウェア開発者がパフォーマンスを測定されることを嫌うという長年の疑念を反映していません。また、大多数のエンジニアリングマネージャーがコード行数のような粗雑なメトリクスを使用して個人のパフォーマンスを測定しようとする罠に陥っていないことを示唆しています。

一方で、マネージャーはどのメトリクスを選択するかに注意を払い、チームがこれらの測定値を「ゲーム化」するインセンティブを避けるための効果的なカウンターバランスを特定する必要があります。代わりに、あなたとあなたのチームにとって最も重要なメトリクスを慎重に組み合わせることで、生の出力ではなく、品質の高い仕事と実際の影響を協力して提供するようにチームを導くことができます。

GitLabとJiraが最も多く引用されたチームパフォーマンス報告ツールでした

Q：チームのパフォーマンス報告を支援するためにどのようなツールを使用していますか？

GitLab：66%

Jira：65%

ダッシュボード：38%

その他：34%

Haystack：6%

Code Climate：5%

Jellyfish：4%

Pluralsight Flow：3%

Linear B：3%

Swarmia：2%

https://scrapbox.io/files/6716f31d54b53e835b437231.png

チーム調整

しかし、どのチームも完全に孤立して存在するわけではありません。リーダーの75％が週次または日次で他のチームと調整していると報告し、22％が時々調整していると報告しました。めったに調整しないと言ったのはわずか2％でした。

しかし、それは協力が簡単であることを意味するわけではありません。タスクの優先順位付けは、回答者の71％が協力への主要な課題として挙げており、所有権と説明責任が67％で近い2位でした。情報と可視性の欠如は回答者の半数強にとって問題でした。しかし、リモートワークや同期作業に関するすべての議論にもかかわらず、回答者の22％だけがこれを問題として見ていました。

Q：他のチームとの作業調整をどのくらいの頻度で行う必要がありますか？

毎日：33%

週次：42%

時々：22%

めったにない：2%

事例研究

Gorgiasがチーム間の協力に焦点を当てることでエンジニアの認知負荷を最小限に抑える方法

Gorgiasは、Eコマース企業向けに特化したSaaSカスタマーサービスプラットフォームです。現在、彼らのエンジニアリング組織は80人以上のソフトウェアエンジニアで構成され、10のチームに分かれ、さらにトライブとスクワッドに分割されています。

多くのソフトウェア組織と同様に、Gorgiasはモノリシックアーキテクチャから始まり、チームがまだ小さかった頃はうまく機能していました。時間が経つにつれてビジネスの規模と複雑さが増大し、新しい統合とアプリケーションが追加されるたびに明確な亀裂が現れ始めました。突然、エンジニアは依存関係をナビゲートすることにより多くの時間を費やし、チームに割り当てられた特定の顧客の問題を解決することに費やす時間が少なくなりました。

共同創設者兼CTOのAlex Plugaruによると、最大のボトルネックの1つはチーム間の協力でした。特に、エンジニアに対して生み出された認知負荷でした。モノリシックアーキテクチャは、コアチームが他のチームからの新しいコードの大部分をレビューできる唯一のチームとなり、ますますボトルネックになっていました。

待ち時間とチーム間の依存関係を減らすための単純な解決策はありませんでしたが、Alexはモノリス内部でサービス指向アーキテクチャを導入し、新しい専用のスタンドアロンサービスを導入することから始めました。さらに、Gorgiasはチーム間の協力におけるコンクリートなボトルネックを認識し対処するためにSwarmiaの使用を開始しました。エンジニアに彼らを遅らせているものをより可視化することで、彼らは遅延の根本原因を積極的に分析し対処することができ、最終的には顧客の問題を解決することにより多くの時間を集中できるようになりました。

https://scrapbox.io/files/6716f4045044548e23b782d7.png

【要約】

チームパフォーマンスの測定理由、方法、および使用されるメトリクスについての詳細な調査結果を示しています。また、DORAメトリクスとSPACEフレームワークの有効性についての評価も含まれています。

【解説】

エンジニアリング速度の向上が最も一般的なパフォーマンス測定の理由であることが分かります。サイクルタイムが最も有用な生産性メトリクスとして挙げられています。DORAメトリクスとSPACEフレームワークは、それらを知っている人の間では効果的だと考えられていますが、まだ広く知られていないことも明らかになっています。

【和訳】

パフォーマンスメトリクスと測定

エンジニアリングリーダーにはチームパフォーマンスを測定する複数の理由がありますが、これを人事問題として扱うことはめったにありません。これは、提出するプルリクエスト（PR）の数によってキャリアが左右されるのではないかと恐れている、より抵抗のあるチームメンバーを安心させるはずです。

チームパフォーマンスを測定する最も引用された理由は、速度を上げる機会を特定すること（37％）で、4分の1がボトルネックを特定する欲求を挙げました。わずか6％が進歩、昇進、または解雇の決定を知らせる方法として見ていました。これは、広範な人員削減の影響を受け続けている業界にとって心強いことです。

チームパフォーマンスを測定することが重要な理由

Q：チームのパフォーマンスを測定することが重要な理由は何ですか？

エンジニアリング速度を向上させる機会を特定する：37%

プロセスのボトルネックを特定する：26%

説明責任を作り出すため：20%

上層部への報告のため：9%

進歩、昇進、解雇の決定を知らせるため：6%

その他：3%

https://scrapbox.io/files/6716f519303c52cef449eee1.png

同様に、チームパフォーマンスを測定する主要な方法は、主に個人に焦点を当てていませんでした。締め切りの遵守が最も高くランク付けされ、生産性メトリクスまたは完了したチケット数が続きました。より質的で時間のかかるパルス調査はずっと下位にランク付けされ、重量級の年次開発者調査が最下位でした。

最も有用な生産性指標については、サイクルタイムが最も高くランク付けされ、デプロイメント頻度とリードタイムが続きました。リストの最下位は労働日数で、測定可能な成果が生の労力測定よりも重要視されています。

チームパフォーマンスを測定するために通常使用する方法のランク付け

Q：あなたの組織でチームパフォーマンスを測定するために通常使用する方法をランク付けしてください。

1. 締め切りの遵守

2. 生産性メトリクス

3. レトロスペクティブ

4. インシデント数

5. 顧客フィードバック

6. パルス調査

7. 年次調査

これらの生産性メトリクスの有用性のランク付け

Q：これらの生産性メトリクスを有用性の順にランク付けしてください。

1. サイクルタイム

2. デプロイ頻度

3. リードタイム

4. 変更失敗率

5. 進行中の作業のバランス

6. コンテキスト切り替えの頻度

7. 平均復旧時間

8. 完了したストーリーポイント

9. やり直し比率

10. 労働日数

https://scrapbox.io/files/6716f5973dcd08cf5b6e2cc8.png

これらのメトリクスの多くは、DevOps Research and Assessment（DORA）メトリクスに触れたことがある人には馴染みがあるでしょう。2014年に初めて発表されたこれらのメトリクスは、組織が開発者と運用チームをどれだけ効果的に結びつけて、より良いソフトウェアをより速く提供しているかを測定することを目的としていました。同様に、サイクルタイムはアジャイルソフトウェア開発に起源があり、特定のタスクを完了するのにかかる時間を測定することを目的としています。

これら2つのフレームワークは、業界標準に近いものとして他のものから際立っていますが、パフォーマンス測定におけるDORAメトリクスの効果について尋ねられたとき、回答者の29％が知らない、または確信が持てないと答えました。そして、より新しいSPACEフレームワークについては、半数以上が意見を述べることができませんでした。

しかし、これら2つのフレームワークに精通している人々の間では、反応は概して熱心でした。回答者のおよそ半数がSPACEを非常に効果的または効果的なフレームワークと見なし、DORAについてもほぼ同じでした。10人に1人未満の回答者が、どちらのフレームワークも効果がないと感じていました。

コメントした人々の中で、50％がSPACEフレームワークを効果的/非常に効果的だと考えており、48％がDORAメトリクスを効果的/非常に効果的だと考えています

Q：DORAとSPACEはチームパフォーマンスの測定にどの程度効果的ですか？

SPACEフレームワーク：

非常に効果的：8%

効果的：26%

やや効果的：31%

効果的でない：6%

分からない/不確か：29%

DORAメトリクス：

非常に効果的：5%

効果的：18%

やや効果的：18%

効果的でない：4%

分からない/不確か：55%

https://scrapbox.io/files/6716f61e303c52cef44a030e.png

【解説】

この部分では、チームパフォーマンスの測定方法と、使用されるメトリクスについて詳細に説明しています。エンジニアリング速度の向上が最も一般的な測定理由であること、サイクルタイムが最も有用な生産性メトリクスとして認識されていることが分かります。また、DORAメトリクスとSPACEフレームワークについての認識と評価も示されていますが、これらはまだ広く知られていないことも明らかになっています。

【和訳】（続き）

これらのメトリクスは人気を博していますが、会社が測定するようになった他の多くのものがあります。開発者とQAの間でチケットが循環する回数から、時間利用率、機会コストまでさまざまです。これらはすべて、チームとビジネスの優先事項に応じて測定し組み合わせることができます。

また、認知負荷、チームの幸福度、コンテキスト切り替えの頻度など、一般的な開発者のウェルビーイングメトリクスを確立することへの明確な関心もあります。チームの健康状態を測定する最も有用な方法については、単純な1対1のミーティングが明確なリーダーで、回答者の94％が挙げており、継続的なフィードバックメカニズムが79％で挙げられました。

予想通り、回答者に避けるべきメトリクスとその理由について尋ねたとき、強い意見が表明されました。コード行数は一般的に「ゲーム化可能」で、品質よりも量を測定する安易な方法として特定されました。同様に、速度は有用であるためには明確な定義が必要です：それはチームが速く動いていることを意味する可能性がありますが、間違ったことに取り組んでいる可能性もあります。

満足度、ウェルビーイング、協力に焦点を当てることで、より伝統的な出力メトリクスと並行して、エンジニアリングリーダーはエンジニアリングチームの全体的なパフォーマンスを測定する効果的な方法を確立し始めることができます。

https://scrapbox.io/files/6716f83c9de165ecccece850.png

【要約】

エンジニアリングチームが使用するツールとプロセス、そしてチームの生産性を阻害する要因についての調査結果を示しています。

【解説】

JiraやCI/CDツールが最も効果的なツールとして挙げられていますが、同時に生産性を阻害する可能性もあることが指摘されています。アジャイル方法論が最も一般的なプロセスであることも分かります。また、エンジニアリングチームの主要なボトルネックとして、優先順位付けの明確さの欠如と人員配置の問題が挙げられています。

【和訳】

エンジニアリングツールとプロセス

エンジニアリングリーダーは、彼らが取り組んでいるOKR、KPI、および出力メトリクスについて明確にしたいと考えるでしょう。しかし、そこに到達するために使用しているツールとプロセスは非常に多様です。

Jiraは最もファッショナブルなツールではないかもしれません - 多くの実践者が複雑すぎる、扱いにくい、制限的だと不満を漏らしています - しかし、最高の仕事をするためにチームが使用するツールについて尋ねられたとき、回答者の61％がJiraを挙げました。

継続的インテグレーション/継続的デリバリー（CI/CD）ツールはそれぞれ57％が挙げており、バージョン管理システムのGitHubが48％で続きます。報告ダッシュボードとコラボレーションプラットフォームのSlackが多くの組織を支援している一方で、悪名高く複雑なコンテナオーケストレーションツールのKubernetesが最高の仕事をするのを助けていると言った組織はわずか10％でした。

チームが最高の仕事をするために使用する最も効果的なツールは、JiraとCI/CDです

Q：チームが最高の仕事をするために使用するツールは何ですか？

Jira：61%

CI/CD：57%

GitHub：48%

報告ダッシュボード：44%

Slack：39%

Wiki：10%

Kubernetes：10%

VSCode：6%

その他のツール：10%

https://scrapbox.io/files/6716f8a74c0a5f184cb9c696.png

エンジニアリングツールとプロセス

同様に、アジャイル方法論は新しくも刺激的でもありませんが、質の高い仕事を可能にする最も引用されたプロセスで、71％が挙げています。次はカンバンとスクラムで、どちらもアジャイルな働き方を実装するための確立されたアプローチで、約30％の回答者が挙げています。

DevOpsとその急速に台頭しているいとこのプラットフォームエンジニアリングは、それぞれ37％と22％が挙げています。これは、ヘッドラインを飾るものがしばしば実際の価値を提供し、エンジニアリングプロジェクトを完了させるのに時間がかかることを思い出させてくれる良い例です。

しかし、これらのツールはどれも完璧ではありません。生産性を阻害するツールについて尋ねられたとき、ラインナップはほぼ同じで、Jiraが27％、CI/CDが24％で挙げられています。Slackの容赦ない通知音が3位に入りました。注目すべきは、29％のエンジニアリングリーダーがチームの生産性を阻害するツールは何もないと感じており、多くの優れたビルダーが自分のツールを非難することを拒否していることを示しています。

生産性を阻害するプロセスについては、スクラムが27％で挙げられ、アジャイルが21％で続き、プラットフォームエンジニアリングが18％でトップ3に入りました。しかし、35％の回答者が生産性を阻害するプロセスを挙げることができませんでした。

アジャイルは引き続きチームが良い仕事をするのを助けています

Q：チームが最高の仕事をするために使用するプロセスは何ですか？

アジャイル：71%

カンバン：40%

スクラム：38%

DevOps：37%

プラットフォームエンジニアリング：22%

その他のプロセス：5%

https://scrapbox.io/files/6716f925d789db97145aaa06.png

しかし、ツールとプロセスは生産性の最大の障害になることはあるでしょうか？今日のエンジニアリングチームの最大のボトルネックを特定するよう求められたとき、2つの主要な要因がそれぞれエンジニアリングリーダーの4分の1以上によって挙げられました：明確さと優先順位付けの欠如、および人員配置と人員の問題です。

他のチームとの連携と脆弱なシステムが次に多く挙げられた犯人で、それぞれ12％と11％でした。メトリクスがボトルネックとして挙げられたのはわずか2％でした。

エンジニアリングマネージャーとその上司の両方が、明確さや優先順位付けの欠如を主要な問題として挙げましたが、ソフトウェアエンジニアリングディレクターは人員配置と人員の問題が最大のボトルネックであることを明確に示しました。これは、人員配置の問題が組織を下に流れ、途中で明確さと優先順位付けの問題に変化していくことを示唆しています。どちらも良くありません。一緒になると時間とともに致命的になる可能性があります。

競合する優先事項と限られたリソースは、集中を困難にし、一方でプロダクトマネージャー（PM）間の対立は最も明確なビジョンさえも損なわせます。同様に、チーム間の協力は、それぞれが異なる優先事項を持っているときに損なわれます。

一部のチームは今年の人員削減、採用凍結、離職からの痛みを間違いなく感じていますが、他のチームは単に有能な人材を見つけ、内部でリーダーシップスキルを開発することに苦労しています。さらに、他のチームはジュニアとシニアのスタッフメンバー間の世代ギャップが人員配置の頭痛の種を複雑にしていると指摘しています。

これらは組織を台無しにする可能性のある種類のシステミックな問題であり、メトリクス、方法論、ツールだけでは解決できません。

今日のエンジニアリングチームの最大のボトルネックは、明確さや明確な優先順位付けの欠如でした

Q：今日のチームの最大のボトルネックは何ですか？

明確さ/優先順位付けの欠如：27%

人員配置と人員：26%

他のチームとの連携：12%

脆弱なシステム：11%

ビジネスとの整合性：7%

上級管理職からの支持：5%

ドキュメンテーション：3%

メトリクス: 2%

その他：5%

https://scrapbox.io/files/6716fa2343ab67dc9ac1f165.png

【解説】

この部分では、エンジニアリングチームが使用するツールとプロセス、そしてチームの生産性を阻害する要因について詳細に説明しています。JiraやCI/CDツールが最も効果的なツールとして挙げられていますが、同時に生産性を阻害する可能性もあることが指摘されています。アジャイル方法論が最も一般的なプロセスであることも分かります。

特に注目すべきは、エンジニアリングチームの主要なボトルネックとして、優先順位付けの明確さの欠如と人員配置の問題が挙げられていることです。これらの問題は、組織の階層を通じて異なる形で現れる可能性があり、単純なツールや方法論の変更だけでは解決できない複雑な課題であることが示唆されています。

【要約】

レポートの結論部分で、調査結果の総括と今後の展望が述べられています。

【解説】

この部分では、エンジニアリングリーダーが直面している課題の多様性と複雑性が強調されています。特に、人員配置の問題や優先順位付けの明確さの欠如など、組織全体に影響を与える要因が重要であることが指摘されています。また、チームの健康とウェルビーイングの重要性も強調されています。

【和訳】

最終的な考察

私たちは皆、技術業界における急激な変化の時期を生きています。変化と混乱のサイクルがますます圧縮され、エンジニアリングリーダーはこれらの変化をマッピングしナビゲートする任務を負っています。

この研究は、エンジニアリングリーダーがチームのパフォーマンスを測定し改善する際に直面している課題の範囲を強調しています。これらの一部 - 特に人員配置と人員の問題 - が部分的に彼らのコントロール外の力によるものであることは明らかです。しかし、上級管理職はこれらの要因が組織を通じて波及する方法、特にそれらがどのように伝達され、組織の優先事項にどのように影響するかに影響を与えることができます。

また、エンジニアリングリーダーがチームまたは組織レベルで目標を設定し、それらの達成に向けての進捗を測定するために依然として利用しているアプローチ、プロセス、ツールの多様性も強調しています。これにより、チームのパフォーマンスをベンチマークすることが難しくなり、DORAや、増加しつつあるSPACEが実装されたときのリーダーの満足度を説明するかもしれません。

もちろん、個人は特定の方法やツールが夢と現実のギャップにどのように寄与しているかについて、時には経験に基づいて、時にはそうでない場合もありますが、自分なりの見解を持っているかもしれません。Jiraとアジャイルはたくさんのエンジニアリングリーダーによって最高の仕事をするのに役立つと見なされていますが、逆に、多くのエンジニアが時代遅れの阻害要因として見ています。

これらすべての課題の中でも、チームと個人のウェルビーイングに焦点を当てているリーダーがたくさんいることは安心できるはずです。現時点ではこれらを確定的に測定することは難しいままですが、SPACEのような取り組みにより、時間とともにエンジニアリングリーダーがそうすることが容易になり、これらの要因の重要性を他のチームメンバーや上級管理職に示すことができるようになるかもしれません。

この研究があなた自身の課題を業界の残りの部分と文脈化するのに役立ち、それらに対処するために取っている行動を導くのに役立つことを願っています。来年、あなたがどのように対処したかを聞くのを楽しみにしています。

https://scrapbox.io/files/6716fa4e4066c27b7d384338.png

【要約】

調査の方法論について説明しています。

【解説】

この調査は、北米、EMEA(Europe, the Middle East and Africa)、APAC、ラテンアメリカの605人のエンジニアリングリーダーを対象に実施されました。回答者の大多数がチームを管理しており、エンジニアリングマネージャー、エンジニアリング責任者、エンジニアリングディレクターなどの役職に就いています。

【和訳】

方法論

このレポートは、北米（39％）、EMEA（52％）、APAC（5%）、およびラテンアメリカ（4%）の605人のエンジニアリングリーダーを対象とした調査に基づいています。

回答者の中で、95％がチームを管理しており、71％がエンジニアリングマネージャー、4％がエンジニアリング責任者、25％がエンジニアリングディレクターです。

デジタル調査は2023年8月18日から9月1日まで実施されました。

71% エンジニアリングマネージャー

25% エンジニアリングディレクター

4% エンジニアリング責任者

52% EMEA

39% 北米

5% APAC

4% ラテンアメリカ

https://scrapbox.io/files/6716fa8d0fe7604107c5a608.png

方法論残りの部分は、LeadDevが提供するリーダーシップ開発のためのリソースや機会を紹介する広告的な内容です。主要な内容は以下の通りです：

【要約】

LeadDevが提供するリーダーシップ開発のためのさまざまなオプションを紹介しています。

【解説】

LeadDevは、エンジニアリングリーダーのスキル向上を支援するためのさまざまなリソースを提供しています。無料の記事やビデオから、専門家主導のウェビナーやワークショップ、グループ学習コース、ネットワーキングイベントやカンファレンスまで、幅広い選択肢があります。

【和訳】

成功するリーダーは学習を止めません

LeadDevによるリーダーシップ開発のオプション：

- 無料の記事とビデオ

- 専門家主導のウェビナー、ワークショップ、グループ学習コース

- ネットワーキングとミートアップ

- インスピレーションを与えるカンファレンス

LeadDevは、あなたの予算や経歴に関わらず、マネジメントスキルを向上させるのを支援できます。

詳細はleaddev.comをご覧ください

LinkedIn、YouTube、Twitterでフォローしてください：

- LinkedIn: Linkedin.com/company/leaddev

- YouTube: @LeadDev

- Twitter: @TheLeadDev

これらの情報は、LeadDevが提供するサービスやリソースを紹介し、潜在的な顧客やユーザーにアピールすることを目的としています。エンジニアリングリーダーのための継続的な学習と成長の機会を強調しています。