ソフトウェア開発者の生産性を測定する価値はあるでしょうか?

ほとんどの企業はデジタル戦略に取り組んでおり、従業員の生産性を向上させる方法を模索していますが、同時に開発者が不足しており、新しいソフトウェアの需要が高まっています。ガートナーのシニアディレクター兼アナリストであるキース・マン氏は、これが開発者の生産性を理解し、測定することへの関心を高めたと語る。 「企業は限られた数の開発者を最大限に活用する必要がある」と同氏は述べた。「ガートナーの調査と顧客からの問い合わせデータから、開発者の生産性がソフトウェアエンジニアリングのリーダーにとって依然として最優先事項であることが確認された。」

カリフォルニア州のデルタ・デンタルの最高情報責任者、ドミニク・ティットコム氏は、GenAI をめぐる最近の進歩が新しい働き方を刺激しており、ソフトウェア開発をスピードアップするために AI を適用することについて多くの議論がなされていると付け加えた。 「この分野では、開発者が生産性を高め、向上させるために使用できる、GitHub Co-Pilot のような素晴らしいツールが明らかに存在します」と彼は語った。

買掛金自動化ソフトウェアおよび支払いソリューションのプロバイダーである AvidXchange の CIO である Dominic Titcombe 氏は、開発者のワークフローから摩擦を取り除くことでアジャイル イノベーションを強化できることに同意しています。 「イノベーションとテクノロジーの導入に重点を置くことで、テクノロジーチームの妨げとなっている障害を特定し、取り除くことができます」と彼女は述べ、さらに「ソフトウェア開発の成果を測定することはITのデジタル化にとって重要ですが、健全なチーム力を維持するためには慎重な展開も必要です。連携したチームはより大きなオーナーシップと責任を示し、生産性の向上につながります」と付け加えた。

合理化により生産性を最適化

アジャイルソフトウェア開発はイノベーションと競争力の維持に不可欠であるため、エンジニアリングリーダーはソフトウェア開発者の生産性を測定するだけでなく、それを効果的に行う方法を理解し、落とし穴に注意する必要がある、とマン氏は述べた。 「正しく実施すれば、生産性を測定することで、開発チームがユーザーや顧客にさらに価値を提供する方法についての洞察が得られ、それがビジネスにプラスの影響をもたらすのです」と彼は語った。

Titcombe 氏も同様に、ソフトウェア開発者の生産性を評価することは価値があると考えており、それが IT 部門が最終消費者に高品質の製品を提供するという目標を達成するのにどのように役立つかを指摘しています。 「生産性の向上を図り、より少ないリソースでより多くの成果を上げる方法を見つけることは、どの企業にとっても義務です」と同氏は述べた。「顧客体験を創造する上で重要なのは、優れた製品を提供しながら、これを迅速かつコスト効率よく行うことです。」

ただし、ソフトウェア開発チームが成功に向けて準備されていない場合、優れたデジタル製品を提供するのは困難になる可能性があります。ギブソン氏は、IT部門はしばしば大量の機能のバックログに対処しなければならないため、新しい分野での開発が妨げられている、と述べた。 「いったんバックログが発生すると、生産を再開するまでの時間が重要になります」と彼女は語った。

ギブソン氏は、開発チームは複雑なコード、複雑なアーキテクチャ、不十分な自動化やテストなど、ワークフローがスムーズに進行するのを妨げるボトルネックにも頻繁に遭遇すると付け加えた。ソフトウェア開発プロセスにおける摩擦は生産性を低下させる可能性があるため、チームの妨げとなる要因を回避するには、こうした障害を理解することが不可欠だと彼女は述べた。

摩擦はイノベーションを遅らせ、企業全体の収益と利益に影響を及ぼす可能性があります。 「ネットフリックスがシームレスな技術開発でブロックバスター社に対抗したように、このプロセスを簡素化する企業は市場の革新を加速し、収益と利益性を高めることができる」とギブソン氏は語った。

しかし、すべてのマネージャーが開発者の生産性測定が実用的な結果を生み出すことができると確信しているわけではなく、むしろプロセスの合理化に重点を置くことが最も重要である可能性があります。 「開発者の生産性に焦点を当てることは無駄な努力です」と、コードテストプラットフォームCTO.aiのCEO兼創設者であるカイル・キャンベル氏は言います。「より経験豊富で実践的なリーダーは、チームの成果が、仕事をうまく行うために注力しなければならないサポートのレベルに直接相関していることを知っています。」

そのため、彼は、開発者のワークフロー (CI/CD など) を最適化する方法について批判的に考え、これらの領域における開発者の経験を経験的に測定することで、開発チームを支援することを推奨しています。

コード行数ではなくビジネス成果を測定

ソフトウェア開発ライフサイクル (SDLC) 全体を通じて、アイデアの生成から生産フェーズまで、スムーズなプロセスを確保するために監視する必要があるさまざまな測定ポイントがあります。 「企業がこれらの段階で効率を改善したり、商用技術を導入したりしなければ、競合他社に遅れをとるリスクがある」とギブソン氏は述べた。

しかし、ソフトウェア開発者の生産性を測定したいという要望には、独自の障害が存在します。これを具体的にどのように行うかについてはさまざまな考え方がありますが、技術リーダーの間では、貢献度をミクロの個人レベルで測定することを避けるというのが一般的なコンセンサスです。

「開発者一人当たり1日あたりに生成されるコード行数を数えると、生産性を誤って測定することになる可能性がある」とティットコム氏は述べ、代わりに新機能が提供される速度を調べた方が良いと付け加えた。 「開発者の生産性を全体的に測るより良い方法は、ツールや体験をより早く顧客に届けられるかどうかであり、それが全体としてより大きな利益をもたらすだろう」と彼は語った。

いくつかの生産性指標に関する大きな注意点の 1 つは、それらのいくつかが誤検知につながったり、エンジニアがシステムを不正操作したりする可能性があることです。 「開発者は、自分たちが基準に照らして評価されていることに気付くと、その基準を人為的に高めるようになります」とティットコム氏は言う。「より良い基準は、顧客に提供される結果に重点を置いたエンタープライズ生産性基準です。」

マン氏は、ガートナーでは、特定の開発者生産性フレームワークの実装に顧客が関心を示していると述べ、SPACE はそうしたフレームワークの 1 つであると述べました。 GitHub の研究者によって提案された SPACE は、満足度と幸福度、パフォーマンス、アクティビティ、コミュニケーションとコラボレーション、効率性とワークフローに基づいて、DevOps 研究および評価 (DORA) フレームワークに、より定性的な尺度を提供します。マン氏が実際に使用されているのを見た別のフレームワークは Devex です。

マン氏は、これらのフレームワークの属性は開発者の生産性を測定するのに役立つが、その一部は他のものよりも客観的であると指摘し、それらを実装する際にはリーダーシップが意図的に行うよう奨励した。理想的には、測定活動は特定の貢献者を崇拝するために使用されるのではなく、肯定的なビジネス成果を阻む障壁を明らかにする必要があります。

「測定の目的は、開発者のメトリクスを比較して、どちらが優れているか劣っているかを判断することではありません」とマン氏は言います。むしろ、目標は、関連する開発者の生産性を高めたり低下させたりしている要因を診断することです。たとえば、Spatial Framework を使用しているある顧客が通信障害を発見し、それを修正して品質の問題とやり直しを減らすことができた話をマン氏は語りました。

インテリジェントな生産性監視によって明らかになるこれらの小さなミスにより、企業は損失をより早く利益に変え、利益をもたらすことができます。 「生産性に関しては、企業がアイデアを思いつき、詳細を定義し、アーキテクチャを計画するまでのスピードが重要です」とギブソン氏は言う。「生産性は、市場投入とイノベーションのスピードに直接つながり、最終的には収益に影響します。」

チームワークは生産性を向上させる

ソフトウェア開発の生産性の向上は、指標のみで促進されるわけではありません。全体的な生産性に大きく貢献するもう 1 つの要素は、開発者がチームに対して抱く所有権と責任感です。

「チームの連携は生産性の要です」とギブソン氏は言う。「チームのパフォーマンスを高めるには、メンバーがつながりを感じ、所属するチームへの帰属意識と一体感を持つ必要があります」と彼女は言う。

生産性をより深く理解するには、概念を全面的に再考する必要があるかもしれません。なぜなら、「生産性」に関する業界の一般的な定義は、流動的なソフトウェア設計および開発プロセスにうまく当てはまらないからです。マン氏は、機械部品の製造では各部品の製造プロセスは同じであるが、ソフトウェアはより微妙で絶えず変化し、コンポーネントごとに最終価値が異なるため、従来の生産性測定手法は複雑になると述べた。

「ソフトウェアはそれぞれがユニークで、ユニークな価値を持っています」とマン氏は言います。「『先週の2倍のソフトウェアを生産したので、生産性は先週の2倍です』と言うのは意味がありません。今週のソフトウェアの価値は先週の半分かもしれないからです。」結果として、生産性の測定は実際の具体的なメリットがない幻想になることが多いのです。 「我々がすべきことは、生産性、つまり時間やコストの単位あたりに提供する価値を理解することだ」と彼は語った。

もう 1 つの意味は、ソフトウェアは孤立して作成されるのではなく、各スプリントに関与する多くの関係者との共同作業プロセスであることを認識することです。 「ほとんどのソフトウェアは、個々の開発者ではなく、開発者のチームによって作成されます」とマン氏は述べ、そのためリーダーはチームの生産性（マン氏はこれを「時間単位あたりの価値」と表現）を評価し、生産性向上が機能しているかどうかを真に測定するよう努めるべきだと語った。

「チーム間で一貫して価値を評価できれば、生産性を比較することもできます」とマン氏は指摘します。しかし、価値は関係する事業分野に大きく依存し、さまざまな利害関係者間で大きく異なる可能性があるため、これは大きな仮定であると彼は付け加えた。

もちろん、価値を測定することは必ずしも容易ではありません。特にチームのダイナミクスを比較する場合は、柔軟なアプローチが必要であることが強調されます。そのため、特定の一般的な指標に頼るのではなく、問題のチームに関連する傾向を明らかにする方が有益な場合があります。

「傾向を比較して理解し、それをより深い質問の根拠として使う方が理にかなっています」とマン氏は言います。たとえば、あるチームの生産性が上昇傾向にあり、類似のチームの生産性が上昇していない場合は、最初のチームのパフォーマンスの何が違うのかを尋ねることができます。このような質問をすることで、会社全体の知識が明らかになり、他のチームの改善に役立つ可能性があります。

開発者エクスペリエンスの観点では、重点領域は若干異なる性質を帯びます。 「開発成果について話すとき、開発者のエクスペリエンスとチームからのフィードバックの主要な要素を評価することが重要です」とキャンベル氏は言います。彼はこれらの要素を、明確さ (どのようにデプロイするか)、使いやすさ (デプロイに必要な最小限の手順)、機能性 (拡張できる既存のワークフロー、API、SDK があるか)、安定性 (今デプロイすれば、夜中に壊れることはないと確信できる) に分類します。

キャンベル氏は、これらの分野のエンジニアからのフィードバックを聞くことで、経営陣は、最高の成果を上げるためにどの分野にサポートが必要かすぐに理解することができ、それによって IT 部門は生産性を高めてビジネスにプラスの影響を与える改善に最善の投資をすることができると述べています。

開発者と顧客エクスペリエンス

テクノロジーリーダーは開発者の生産性を慎重に測定する必要があり、そうしようとする場合は、その結果が最終消費者にとっての具体的な価値に基づく必要があります。

「経営陣は、生産性指標が顧客体験と成果に重点を置くようにするとともに、新たな機会が生じた際にチームが機敏に対応できるようにする必要がある」とティットコム氏は述べた。「私たちは、現在および将来にわたって患者のケアにテクノロジーが役立つ方法を優先したい」と同氏は付け加えた。

リーダーはまた、精神的なエネルギーには限りがあり、知識労働者にとって燃え尽き症候群は現実的な可能性であることを覚えておく必要があります。したがって、恐怖心を植え付けないようにパフォーマンスを測定する際には、個人ではなくプロセスに焦点を当てることが重要だとギブソン氏は言う。 「プロセス全体の有効性を強調し、測定プロセス自体の効率を評価することで、その枠組みの中で個人がどれだけうまく機能しているかに焦点が移ります」と彼女は語った。

他の人にとっては、開発者の生産性のみを測定することは誤解を招く可能性があります。代わりに、キャンベル氏は、継続的な改善の文化を育み、開発者のワークフローをより標準化するための戦略を発見し、そこからツールチェーンを測定して実用的な開発の洞察を得ることを推奨しています。 「エンドユーザーが目標を達成しようとする際のソフトウェアの影響を測定するのと同じように、社内ツールが目標に与える影響も測定できます」と彼は語った。