開発者の満足度が生産性の指標として最適な理由

これはエンジニアリング リーダーにとって悩みの種であり、記述されたコードの行数、プルリクエストの速度、デプロイの頻度といった、指標への固執を業界全体で生み出しています。GitHub では、ダッシュボードを開発し、フレームワークを作成して、開発者の成果を定量化するために膨大な時間を費やしてきました。

ですが、もし間違ったものを測定しているとしたら、どうでしょうか?

GitHub では、自社のエンジニアリングチームの拡大を通じて、生産性を測るのに最適な指標はコミット数やデプロイの指標ではなく、開発者の満足度であることを学びました。満足度の高い開発者はより良いコードを書くだけではなく、より困難な問題を解決したり、より効率的に協力し合ったり、より優れた製品を構築します。

この記事では、開発者の満足度が単なる快適さの指標ではなく、エンジニアリングの生産性を測定し、改善するための強力なツールである理由について詳しく説明します。

生産性の測定における問題

テクノロジー業界は指標や最適化に固執していますが、その中核には著しい矛盾が生じています。ほとんどの組織で開発生産性を測る体系的な方法がないのです。

この測定の穴は見落としではありません。これには、週初めには誰も気づいていなかった問題を個々のコントリビュータが数日かけて解決するといった、生産性の定量化における複雑さが反映されています

この測定の課題解決に対する業界の試みは、主に DORA などにより普及したデプロイ指標を中心に行われてきました。 

• デプロイ頻度 (DF): コードが実稼働環境にデプロイされた頻度。頻度が高いということは、チームが迅速に反復作業を行い、価値を提供し、タスクを溜め込まず、仕事が滞りなく進むようにしていることを示しています。

• 変更のリード タイム (LT): コミットから実稼働環境へのコード移行にかかる時間の測定。時間がかかる場合、プロセスに摩擦が生じ、イノベーションが遅れ、士気が低下します。リード タイムが速いほど、アイディアをユーザーのもとに早く届けることができ、開発者に自身の作業をライブで見てもらうことで、満足度を維持できます。

• 復旧時間 (TTR): MTTR とも呼ばれ、インシデント発生後から通常状態に戻すまでの時間。インシデントは必ず発生します。完璧なチームなどありません。しかし、迅速に復旧できれば、回復力のあるシステムを構築し、チーム (そしてユーザー) の健全性を守ることができます。

• 変更失敗率 (CFR): 実稼働環境で問題を引き起こした変更の割合。数値が低いほど良く、質の良い変更がデプロイされ、問題解決に追われていないことを意味します。すべてのデプロイメントで問題が発生する場合は、システムとテストに問題があることを示しています。速度を落とさずに失敗を減らすことを目標に、チームが自信を持ってデプロイできるようにしましょう。

これらの指標は、運用上の貴重なインサイトを提供する一方で、コードのデプロイにおいて「速度」や「頻度」といったソフトウェア提供の機械的な側面にのみ着目しています。満足度、革新性、労力などの重要な要素は考慮されていません。

間違った機能を構築したり、致命的な技術的負債を蓄積しながらも、チームが迅速なデプロイを得意としている場合があります。これは、料理の質や料理を作るシェフの意見を無視し、料理の提供の速さだけでレストランの成功を測ることと似ています。

最も見込みのある方法は常識に反するかもしれません。組織は、直接的な生産性指標に目を向けるのではなく、開発者の満足度を優先すべきなのです。 

Nicole Forsgren 博士らの研究によると、高パフォーマンスのエンジニアリング組織は、一貫して開発者の満足度スコアが高い傾向にあると示唆しています。これは理にかなっています。十分な準備ができており、権限が与えられ、エンゲージメントが高いと感じる開発者は、複雑な問題を効率的に解決し、生産的に協力し合い、技術面において適切な意思決定を行う可能性が高くなります。

開発者の満足度には、従来の指標では見落とされている重要な要素が含まれています。それは、ツールやワークフローの品質、チーム構造の有効性、日々の業務における労力、機能提供と技術投資のバランスなどです。 

開発者が高い満足度を報告した場合、それは最高の成果を上げるために必要なリソース、自主性、サポートが揃っていることを示しています。

開発者の満足度が重要な理由

GitHub では、開発者の満足度が優れたエンジニアリングの基盤であることを認識しています。開発者の満足度とは、単に快適な職場をもつことではなく、人々が最高の仕事ができる環境を作ることです。言い換えれば、満足度の高い開発者は意欲的な開発者であるということです。 

エンジニアは、サポートされ、評価されていると感じる時、単にコードを書くだけではなく、組織の最も困難な問題の解決に全力を注ぎます。仕事に最大限の創造性を発揮し、前提を疑い、人々の固定観念に縛られている限界を打破するのです。

この取り組みは、自然と問題解決の向上につながります。満足している開発者は、単に機能や修正を完了するだけの作業を行っているわけではありません。アーキテクチャ上の決定について熟考し、エッジケースを考慮して、将来のニーズを予測しているのです。潜在的な問題を見つけた場合には声を上げ、その場しのぎの修正ではなく革新的なソリューションを提案する可能性が高くなります。

しかし、おそらく開発者の満足度の影響を最も強く受けるのは、人材定着率でしょう。開発者が満足している場合、長く勤め、深い組織的知識や専門知識が築かれ、それらは時間の経過とともに蓄積していきます。有能な開発者がチームに留まる 1 年は、単にコードを書くだけの 1 年ではありません。状況理解を積み重ね、判断力が磨かれ、チームの関係が強化される 1 年です。

その理由は、満足している開発者は最高の仕事をするからです。コードの品質からシステムの信頼性、イノベーションに至るまで、その他すべてのことがこの基本原則から生まれているのです。

好循環

開発者の満足度に投資すると、驚くべきことが起こります。自己強化的な改善サイクルが生まれるのです。GitHub では、独自のプラットフォームを構築し、進化させる過程で、これを直接目撃してきました。

まずは、デベロッパーエクスペリエンスに意味のある改善を加えることから始まります。これらは大規模な見直しである必要はなく、デプロイ プロセスの合理化や反復タスクの自動化など、焦点を絞ったものでも構いません。重要なのは、開発者が自身の問題点が解決されていると認識することです。

開発者は、自身のフィードバックが実際の変更に反映されているのを見ると、改善プロセスにさらに積極的に参加するようになります。機能している箇所と、そうでない箇所について、詳細でよく考えられたフィードバックを提供する可能性が高くなります。

この質の高いフィードバックは、次の改善の原動力となります。仮定ではなく、実際の現場レベルのインサイトに基づいて作業するため、チームは最も影響の大きい変更に集中できます。1 つ 1 つの改善は前回の改善に基づいて行われ、エンジニアリング カルチャーを変革する勢いを生み出します。

その結果、変化に適応するだけでなく、変化を推進するチームとなります。開発者が作業環境の形成に積極的に参加するようになり、より良いツール、プロセス、そして最終的にはより良い製品へとつながっていくのです。

まとめ

優れたエンジニアリング成果への道は、コード行数の集計や、プル リクエストの速度測定ではなく、開発者の満足度を基盤として築かれます。GitHub での私たちの取り組みは、開発者が満足し、意欲的であるとき、コードの品質が向上し、イノベーションが加速し、チームがより良い製品を提供できる、すべてが順調に進むことを一貫して示してきました。

今すぐ開発者の満足度を測定し始めましょう。来四半期や、次の計画サイクルの後でもありません、今始めるのです。簡単なアンケートから始めて、受け取ったフィードバックをもとに行動に移し、この根本的な方針の転換がエンジニアリング カルチャーをどのように変革していくのかを見てみましょう。

何から始めればよいかわからない場合は、まず開発者にいくつか基本的な質問をしてみましょう。

• 改善の必要があると思うデベロッパー エクスペリエンス (DevEx) の領域は何ですか?

• 業務全般におけるツール導入とワークフローに対してどの程度満足していますか?

• テストに関連する次のツール導入とワークフローに対してどの程度満足または不満を感じていますか?

• ツールとワークフローに関して、最も大きな問題は何ですか?

• リリースの変更に関して、最も大きな問題は何ですか?

• 魔法の杖を持っていて、DevEx について何か 1 つ改善できる (不可能に思えても) とします。何を改善しますか?

組織で GitHub Copilot を活用している場合は、以下のような質問の追加を検討いただくか、当社のアンケートをご利用ください。

• GitHub Copilot にどの程度満足していますか?

• GitHub Copilot の力を借りたいワークフローはどれですか?

• GitHub Copilot を使用していない理由は何ですか?

• GitHub Copilot に関してフィードバックはありますか?

開発者の幸福度は、単にあればよいというものではありません。これは重要な成功要因であり、長期的な生産性の先行指標です。開発者の満足度を優先することは、チームへの投資にとどまらず、より優れたソフトウェア、より強力なイノベーション、より回復力のあるエンジニアリング カルチャーへの投資にもなります。

結局のところ、満足度の高い開発者がより優れたソフトウェアを構築するという、シンプルなことなのです。今すぐ始めて、その違いを確かめてみてください。