開発者の生産性 – 測定方法

人間は本質的に認知的守銭奴であり、複雑な問題を最小限の努力で最も単純な方法で解決する傾向があります。このようにして、私たちは利用可能な最も単純な方法を採用して「開発者の生産性」を測定してきました。

「開発者の生産性」と聞いて最初に思い浮かぶのは何ですか?

これは間違いなく否定的であり、開発チームの間ではこれがほぼタブーであることは疑いの余地がありません。なぜなら、リーダーはこの問題について話すと、チームが細かく管理されている、または管理されていると思われるのではないかと恐れることが多いからです。信頼が欠けている。理由は 2 つあります。開発者の生産性に対する

1. アプローチは、エンジニアリング リーダー (私たちがそう呼んでいます) によって乱用されています。

2. 「開発者の生産性」は公式ではなく、不確実性の中で成長することはできません。そのため、私たちは最も簡単な道を選ぶか、その道から遠ざかることを選択します。

ちょっと考えてみてください。開発チームには毎年数十億ドルが費やされていますが、開発者の生産性を測定する万能の方法があったとしても、それは依然として優れたものとなるでしょうか。神秘？それともこのブログを読みますか？

追記: 最も生産性の高い開発者を評価したり、開発者の昇進や解雇に役立つ数値を取得したりする目的でこのブログを読んでいる場合は、がっかりすることになるので目を背けてください。

では、開発者の生産性を測定してみるべきでしょうか? ＃＃＃＃＃＃＃＃＃はい、そうです！ ！開発者の生産性は、エンジニアリングの結果を向上させることだけではなく、チームの満足度と幸福を確保することも重要であるためです。多くの場合、生産性指標は、開発プロセスのボトルネックや、チームの作業環境や文化の課題を特定するのにも役立ちます。

最も成功したバスケットボールコーチの一人であるフィル・ジャクソンは、次のように見事に表現しています:

「チームの強さは各メンバーの中にあります。各メンバーの強さがチームの力です。」 」 — Phil Jackson

開発チームの文脈では、すべてのチームの成功は、各開発者が最善を尽くし、チームの成功に継続的に貢献するかどうかにかかっています。

さて、開発者の生産性をどのように測定すればよいでしょうか?

2 つの基本的な柱により、開発者の生産性の測定における成功の可能性が最大化されます。

1. 生産性を単一の指標に決して下げないでください

論理的なタスクと創造的なタスクの両方に携わる人々を測定しようとしているため、開発者の生産性を測定することは困難です。そして、認知的守銭奴である私たちは、生産性を指標に落とし込もうとしますが、はっきり言っておきますが、このモデルは失敗します。

代わりに、複数の側面にわたって生産性を把握し、SPACE フレームワーク (S-満足と幸福、P-パフォーマンス、A-アクティビティ、C-コミュニケーションとコラボレーション、E-効率とプロセス) のようなものを活用してください。開発者チームが開発者の生産性を適切な方法で測定できるように支援します。

2. チームとのコミュニケーション

非常によくある誤解があります: 開発者の生産性はマネージャーにのみ適しているということです。これは真実からかけ離れたものではありません。調査によると、開発者の生産性に対する開発者とマネージャーの認識には大きな違いがあることがわかっています。ほとんどの開発者は、より高い生産性をより高いアクティビティと関連付けますが、ほとんどのマネージャーは、生産性をパフォーマンスと効率と関連付けます。

この明らかな認識のギャップは、開発チームが自分たちにとって生産性が何を意味するのか、生産性の追跡における真の意図は何なのかを話し合うときにのみ解消できます。これは、なぜこれが重要なのか、そしてそれをどのように測定すべきなのかを明確にするのに役立ち、また、ほとんどの開発チームが抱いている懸念を取り除くことができます。これが私たちの評価を決める数字なのでしょうか？それとも、リーダーが私たちが仕事をやり遂げることができると信じていないために、私たちはこのようなことをしているのでしょうか？

やるべきこと

SPACE フレームワークを使用して、開発者の生産性を多面的に追跡します。

チーム全体に意図を伝えます。
1. 生産性指標を使用して、改善すべき領域を特定し、ボトルネックを解消します。
3. やってはいけないこと

生産性を単一の指標に引き下げます。

生産性を追跡するための秘密の対策を開発します。
1. 評価を決定するための唯一の指標として指標を使用します。
3. 開発者の生産性メトリクス

次に、空間次元全体で追跡された開発者の生産性メトリクスをいくつか見てみましょう。

開発者の生産性指標:

満足度と幸福度

満足度の高いチームは、生産性の高いチームです。これは、健全なチームと職場文化を示す最大の指標の 1 つです。ただし、満足度は抽象的な概念であり、誰かが「どのくらい満足していますか?」と尋ねても、測定することは忘れてください。この質問に答える前に、あなたにとって満足とは何か、そしてそれを定量化する方法について、きっと数分間考えていただけると思います。この側面を数値的に把握するのは非常に難しいことは承知しています。つまり、ここで見られるのは、開発者の満足度と幸福度のさまざまな側面を最大限に捉えようとする代理指標です。

• 仕事の完了: タスクを完了するたびに、脳からドーパミンが放出され、タスクが完了した直後に満足感とやる気を感じます。したがって、約束された作業と比較して作業の完了率が高いと、開発者は約束された作業を時間内に完了することができ、チームの成功に貢献できるため、非常に満足感を感じることになります。
• 残業: 残業 ≠ 生産性の向上。実際はその逆で、残業は開発者の燃え尽き症候群の最大の原因の 1 つであり、開発者の幸福を害します。週末や深夜などの余分な労働時間を追跡することは、開発者が現在の作業環境に満足しており、良好なパフォーマンスを発揮しているかどうかを理解するのに役立ちます。
  • ビジネスは達成への手段ではなく、達成への障害である
    ——アレックス・スジョン-キム・パン
    
• 離脱: 不満と燃え尽き症候群最も一般的な指標は、チームとチーム活動からの離脱です。開発者のエンゲージメントを測定する 1 つの方法は、コード レビューなどのチーム アクティビティに対する開発者の一般的な応答時間の変化、またはチーム ミーティングでの対話や出席の減少を測定することです。
• 開発者アンケート: 最適な生産性指標を決定するとき、私たちはしばしば、チームに質問し、開発者満足度アンケートを実施して分析することでチームの感情を理解するという最も明白な方法を忘れてしまいます。 「満足しましたか？」などの質問をしてください。 (評価 1-5)」という質問は、これを理解するのに最悪の方法です。ただし、同様の情報をさまざまな方法や次元で取得するのに役立つ質問が他にもあるかもしれません。
• 在職期間: チーム全体の満足度を追跡する良い方法これを測定するには、開発チームのメンバーの平均在職期間を確認します。開発者の傾向の性質を考慮すると、適切な在職期間の範囲は 12 ～ 18 か月です。これより短いと、間違いなく懸念が生じます。

パフォーマンス

開発者と開発チームのパフォーマンスを測定する最良の方法は、出力ではなく結果を測定することです。これらの指標は、開発者が行う作業の品質面を把握するのに役立ちます。開発者にとって、理想的なのは、結果は、「最小限の手戻りで機能を開発し、タイムリーな配信と最大限の顧客満足度を保証すること」です。これは、行われた作業の品質が期待される標準に達していないことを明確に示しています。これを繰り返すと、最終的には機能開発サイクルの延長につながります。この考えは修正がゼロではなく、要件の変更が原因で手戻りが発生することがよくあります。ただし、ある開発者が同じチームの制約内で他の開発者よりも異常に多くの問題に直面している場合、これは間違いなくパフォーマンス ギャップの兆候です。ビジネス リーダーが気にするのは納期の予測可能性です。顧客から伝達される他の多くのビジネス上の意思決定は納期に依存することが多いためです。エンジニアリング プロセス全体で予測可能性を保つには、各開発者もこの品質を吸収することが絶対に重要です。これを測定する 1 つの方法は、次のことを確認することです。開発スプリント/反復中に開発者が送信したタスクの数が完了した数

顧客満足度: 同意、これがあらゆる組織に価値をもたらす最も重要な結果であり、したがって開発チームにとっても同じである必要があります。顧客満足度は、アプリ ストアでのレビューの向上、API サービスの稼働時間の向上と応答時間の短縮、またはプラットフォーム チームにとっては、他のチームが使用する内部ライブラリの使いやすさと報告されるバグの最小化を意味する場合があります。はエンジニアリング チームだけによって推進されているわけではありません。これをパフォーマンスの指標として使用することで、開発チームが構築しているものと連携し続けることができます。製品の実際のユーザーとのつながりを維持し、彼らが正しいことに集中できるようにします。
• アクティビティ
• アクティビティ ディメンション自体は、ディメンションを追跡するのが最も簡単であるため、広範には開発者の生産性と同等です。ただし、アクティビティだけでは開発者の生産性を真に測定することはできません。アクティビティ メトリクスを、さまざまな領域の他のディメンションと組み合わせて追跡します。 SDLC プロセスは、開発者の実際のボトルネックと改善すべき領域を特定するのに役立ちます。
• 解決済みタスク: このフェーズのアクティビティは、開発者が開発タスクにどのくらいの頻度で、どの程度貢献するかを決定するのに役立ちます。開発タスクは常にプロジェクト管理ツールのタスク、ユーザー ストーリー、またはサブタスクとして計画されるため、解決されたタスクの合計を確認することは、開発サイクルのこの部分における開発者の関与を理解するのに役立ちます。
• プル リクエストのレビュー: 通常、変更/プル リクエストをレビューする責任があるのは技術リーダーまたは開発チームのマネージャーだけですが、これは明らかなアンチパターンです。各開発者に同僚のコードをどんどんレビューするよう奨励すると、レビューのボトルネックを解消できます。この指標は、開発者がチームのレビュー負荷に貢献しているかどうかを判断する優れた方法となります。
• デプロイの頻度: チームが実稼働システムに変更をデプロイする回数は、開発プロセスの速度の側面を理解するのに役立ちます。これは DORA 指標の 1 つでもあり、顧客満足度や組織の収益性とも高い相関関係があることが研究で示されており、開発チームの生産性活動の側面を追跡するための優れた指標となっています。

コミュニケーションとコラボレーション

どの開発チームでも、最終製品 (機能、サービス、アプリケーション、機能拡張など) は常にチームの努力の結果です。良好なコミュニケーションとコラボレーションは、効率的な開発チームを構築するための基盤です。開発者の生産性を測定する際にこの側面を組み込むことで、透明性と情報共有の文化を促進できます。これを把握するのに役立つ生産性指標は次のとおりです。

• PR 待機時間とサイクル タイム: 開発チームが良好なコラボレーションを行っている場合、これがレビュー プロセスに明確に反映されます。これはおそらく、開発の最もボトルネックであるためです。開発プロセスは、投稿者とレビュー担当者の間、またはその逆の効果的なコミュニケーションに依存しているためです。開発者がどれだけ協力的であるかを追跡するのに役立つ指標は、プル リクエストが割り当てられた後、その開発者がプル リクエストのレビューを開始するまでにかかる時間を測定することです。次に、プル リクエストの平均サイクル タイムを測定すると、コントリビューターのコミュニケーション スキルを理解するのに役立ちます。
• 一緒に作業するメンバーの数: 開発チームには知識のサイロがあり、チームの他のメンバーとは対話せず、相互にのみ対話する開発者のグループが存在することがよくあります。これも典型的なアンチパターンです。開発者が他のチームメンバーとどの程度コミュニケーションをとっているかを測定することは、この側面を測定する良い方法です。
• 新しいメンバーのオンボーディング時間: 新しい開発者がチームに加わると、最初の学習曲線を経て、ビジネス環境について学び、テクノロジー スタックに精通し、多くの場合、コードのウォークスルーのサポートを受けます。開発者が参加してから最初の影響力のある変更を加えるまでにかかる時間は、開発チームのコミュニケーションにおける重要な生産性指標です。適切なドキュメント化を実践しているチームとして、新規参入者を支援することに積極的に取り組む開発者は、新規開発者ができるだけ早く影響力のある変更を加えられるようにします。目指すべき良いベンチマークは、新しい開発者が最初の 30 日以内に最初の生産的な結果を達成することです。

効率とプロセス

これは、開発者がよく話す「プロセスに入る」という側面です。ここでのメトリクスは、開発サイクルに中断が何回あるか、タスクが開始から終了までどれだけスムーズに流れるかを理解するのに役立ちます。頻繁な中断は開発者の生産性に影響を与えるだけでなく、ストレスや疲労のレベルの上昇につながる可能性があります。

• 中断のない開発時間: 開発者にとって、プロセスに参加し、開発活動に時間を投資するために毎日十分な中断のない時間を確保することは非常に重要です。最大の障害の 1 つはチーム会議です。多くの場合、開発時間を長くするために、チームは会議のない勤務日を採用したり、チーム会議をスケジュールできる厳密な時間帯を採用したりします。中断のない開発時間が長くても、必ずしも開発者の生産性が高いことを示すわけではありません。しかし、開発者に中断されない十分な時間がなければ、開発に必要なプロセスを達成できないことは確かです。
• コミット リード タイム: 開発サイクルの中断が増え、引き継ぎが増え、タスクを頻繁に再開しすぎることは、開発タスクの効率とフローが低下していることを示しています。コミット リード タイムは、変更がエンド ユーザーに影響を与えるまでにかかる合計時間を測定するため、これを正確に把握します。コミット リード タイム (CLT) が比較的長いということは、明らかに開発チームの効率とフローの低下を意味します。 CLT も DORA 指標の 1 つです。詳細については、こちらをご覧ください。
• 平均的な進行中の作業 (WIP) チケット: コンテキストの切り替えは間違いなく生産性を低下させます。同時により多くのことを行うと、すべてを完了するためにより多くの時間が必要となり、不必要な精神的疲労にもつながる可能性があります。
  • 2 つの並列タスク - コンテキストの切り替えにより 20% が失われます。
  • 3 つの並列タスク - コンテキストの切り替えにより 40% が失われます。
  #— ジェラルド・M・ワインバーグ

#

WIP チケットは、開発者が並行して作業しているタスクの数を完全に記録します。この生産性指標を追跡し、それを 3 つのタスク未満に抑えるように努めることは、開発チームにとって良い出発点です。

変更エンゲージメント

開発者の生産性を向上させる指標に注目すると、変化を促進するのに役立つアクションは、開発プロセス。チームが推進している変更に対する開発者の関与を測定することは、チームのプロセスを修正するために各個人がどれだけ熱心に取り組んでいるかを理解するのに役立ちます。各プロセス変更には、プロセスがどの程度適切に実行されているかを把握するメトリクスを関連付けることができ、これらのメトリクスを追跡するリーダーボードは、どの開発者がプロ​​セス変更イニシアチブによく貢献しているかをゲーム化して理解するのに役立ちます。

これは全員です！

開発者の生産性は、実際に重要な指標ではなく、単一の指標または追跡しやすい指標として誤解されていることがよくあります。 SPACE のようなフレームワークからインスピレーションを得て、開発者の生産性を追跡し、開発者の生産性を向上させるための総合的なアプローチを採用することが絶対に重要です。いくつかの指標から始めるのが最善ですが、少なくとも 3 つの側面に沿ってこれらの指標を選択することが重要です。ディメンションの完全なリストと各ディメンション内の多くの指標について説明しました。次に、あなたとあなたのチームは、最も影響力のある適切なディメンションと適切な指標を見つけ出す必要があります。

以上が開発者の生産性 – 測定方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。