エンジニアリング改善の 3 つのポイント: 聞く、行動する、学ぶ

エンジニアリングメトリクスの解説は豊富に存在します。多くの場合、チームが測定する理由、あるいは純粋に改善しているかどうかについて明確にせず、メトリクスにこだわっていることがわかります。

GitHub では、聞くことの意識、実行可能な投資、学ぶ思考を通じて測定へのこだわりから有意義な改善に転換するという、もっと良い方法があると考えています。

エンジニアリングシステム全体に改善をもたらすため、エンジニアリングチームが実行できる 3 つの重要な転換について紹介します。

転換 1: すべてを測定することから、必要なものを (賢明に) 測定すること

メトリクスは強力ですが、目的に一致している場合に限ります。多くの場合、チームはするべきよりも、単にできることが理由としてすべてをトラッキングします。その結果、どうなったでしょうか？混乱、注意散漫、集中力の喪失。

GitHub では、目標の明確化から開始します。達成する必要があるビジネスの結果とは? エンジニアリングパフォーマンスがこのような結果にどのような影響を直接与えるのか? エンジニアリング測定を明確なビジネス影響 (例えば、ユーザー満足度や収益増加など) にわかりやすくリンクすることにより、メトリクスがチームの最終的な目的を実現できるようにします。

コンパスとストップウォッチの隠喩を紹介します。ストップウォッチは秒単位で記録しますが、正しい方向に向かっているかどうか示すことはできません。一方でコンパスは正しい目的地に向かって行動できるように案内します。大切な目標は、有意義なビジネス結果です。

2 つのエンジニアリングチームがソフトウェアをデプロイしていることを想定します。チーム A は毎日のデプロイメント数を正確に数えてスループットにこだわり、最大デプロイメント頻度を目指します。チーム B はデプロイメントを明確なビジネス影響に合わせて、ユーザー体験の向上またはカスタマーが報告する不満の減少を大幅に実現することを重視します。チーム B は単にデプロイメント量にこだわるのではなく、顧客が報告したバグ、ユーザー満足度スコア、機能の導入をトラッキングし、ビジネス目標に向かって進むようにします。チーム B は長期的なビジネス結果を促進する可能性が高くなります。

測定のメリットとデメリットのバランスを取ることが不可欠です。重要な情報はすべて複雑なテレメトリや広範囲なツールが必要とは限りません。多くの場合、質的なアプローチ (例えば、デベロッパーアンケートやユーザーの直接なフィードバックなど) が質的なメトリクスにコスト効果が高くて強力な補足情報をもたらします。

DORA 情報: DORA レポートで発行される年間のベンチマークデータは、アンケート回答に基づいています。このアンケートの大規模なサンプリングサイズに加え、質問内容はデベロッパーが正確かつ実現可能性に基づいて回答できるように作成されています。デプロイメント時間を秒単位で改善を測定することが目標である場合、テレメトリが適しています。ただし、広範囲な機能とトレンドを理解するため、DORA アンケートのアプローチは実用的でコスト効果が高いソリューションを提供します。

転換 2: 実行の報告から出資まで

測定だけでは改善を促進しません。実行も必要です。出資したフォロースルーがないメトリクスは、治療計画がない診断結果のようなものです。多くの場合、チームはメトリクスダッシュボードに投資しても、データを理解または対処するために必要なリソースや時間を割り当てません。改善をもたらす目標の行動を策定せず、そのイニシアチブを実行しないことを指します。

GitHub では、改善は意図した投資が必要であると考えています。メトリクスとフィードバックから優先順位を明確に特定し、リソースを行動に明確に活用することです。デベロッパーエクスペリエンスのイニシアチブ、信頼性の改善、技術的な負債の処理に対して出資することを意味する場合があります。行動は自発的に起こりません。意図して優先順位を付けて出資する必要があります。

エンジニアリングチームがアンケートとメトリクスを活用し、デベロッパーが不安定なテストスイートによって生産性が大幅に失われることを特定する状況について紹介します。ダッシュボード上でこの問題を報告するだけではなく、テストインフラを安定化して改善するため、成功する改善にはエンジニアリング時間が必要です。この出資された行動は、品質とデベロッパーの士気を直接改善し、最終的にはビジネス結果も改善します。

転換 3: メトリクスのゲーミフィケーションから真の学習まで

有意義な行動に対応するサポートなしで測定が行われると、チームはメトリクスにゲーミフィケーションをすることが推奨されます。実質的な改善よりも数字を最適化することにこだわります。結果として、根深い問題よりも表面的な修正につながります。

メトリクスのゲーミフィケーションに関連する 2 つの一般的なシステムアーキタイプには、__裏目に出てしまう修正__と__負担の転嫁__があります。

__裏目に出てしまう修正__のアーキタイプは、メトリクスを迅速に改善することを意図した短期的ソリューションが、ネガティブな副作用をうっかり引き起こし、最終的に元の問題を悪化させた場合に発生します。例えば、チームがプルリクエストレビュー時間の短縮させるため、コードレビューを焦って行うか、徹底したテストを省略すること。プルリクエストレビュー時間のメトリクスは最初は改善をもたらしますが、結果となる技術的な負債と増加したバグは、最終的にチームに余計に遅延をもたらすことになります。

__負担の転嫁__のアーキタイプは、チームが根本的な原因に対処することよりも、一時的な回避策に繰り返し依存することによって発生し、表面的な修正に長期的な依存関係を作るきっかけになります。例えば、チームは適切なインフラ改善に時間をかけるのではなく、不安定なサーバーが失敗するたびに手動で再起動します。時間の経過ともに、繰り返される手動の対処はより多くのリソースを消費し、原因となる問題に対処する能力が少なくなり、消化のサイクルを強化します。

GitHub では、メトリクスのゲーミフィケーションよりも真の学習の社風を促進します。心理的な安全の育み、実験の推奨、透明性の称賛を実践します。失敗や挫折をオープンに共有することも含まれます。コミュニティの目標は見える変化を起こすことではなく、継続的な上達と持続可能な成長を促進することです。短期的なメトリクス上の進歩よりも、誠実さと実質的な改善を優先します。

"聞く・行動する・学ぶ"の思考を受け入れる

測定へのこだわりから明確な目標設定と有意義な改善の実践に変換することは安易ではありませんが、不可欠です。測定を表面的なメトリクスによる改善よりも、明確なビジネス目的、実行の出資、真の学習の優先に合わせることで、チームの本来の潜在能力を発揮することができます

"聞く・行動する・学ぶ"はこの過程でガイドし、メトリクスは目標ではないことを再認識させます。良いシステム、強いチーム、本格的に影響をもたらすエンジニアリングを構築するツールキットの一部には過ぎません。

GitHub での AI やその他のイノベーションの戦略的役割について、さらに詳しく知りたいですか? エグゼクティブインサイトで、テクノロジーとビジネスの将来について、ソートリーダーシップの詳細をご覧ください。