「生産性とは、これまでできなかったことができるようになることです。」
生成 AI はほぼすべての組織の注目を集めており、このテクノロジーがどのように使用されているかを見るのは興味深いことです。現在、ほとんどの AWS 顧客は生産性の向上 (たとえば、カスタマー サービス スタッフが情報を取得し、理解しやすくする) の達成に重点を置いています。2 番目に、はるかに少数の顧客は、生成 AI のより破壊的な使用を検討していますが、業界を再定義するほどではありません。これらのユース ケースは、Accor と Booking.com での顧客体験の再考から、合成データを使用した医薬品研究の加速まで多岐にわたります。ほとんどの組織では、効率化によって人材と投資が解放され、業界を再考して再発明する好循環が生まれる可能性が高いでしょう。
ここまではすべて順調です。しかし、企業は次のように問い始めています。生産性をどのように測定するのか、そしてそれは重要なのか?
生産性について一般的な観点から話すのではなく、開発者の生産性に焦点を当てましょう。開発者の生産性に関する私のブログ記事で説明したように、平均的な企業では膨大な時間が無駄になっていることがわかっています。ここで課題があります。プロセスの変更と Amazon Q Developer の使用によって開発者の時間を 20 時間節約できる場合、その時間を有意義な領域に投資するでしょうか、それとも貴重なリソースを無駄にする独創的な新しい方法を見つけるだけでしょうか。
このトピックについてさらに詳しく知るために、私は AWS の Builder Experience チームのプリンシパルスペシャリストである Joe Cudby と時間を過ごしました。
Joe さん、開発者の生産性という用語は比較的新しいもので、元開発者の私にとって馴染みのない用語でした。AWS では通常この用語は使用されません。それはなぜですか?
私のチームは、AWS のお客様とソフトウェア開発の過程について定期的に話し合っています。開発者の生産性をどのように捉え、測定するかについても話し合っています。しかし、個々の開発者の生産性に焦点を絞るという狭い考え方から、組織レベルおよび SDLC レベルでのチーム開発の生産性をより広範に理解するという考え方へと、明確な変化が起こっています。この変化は、それ以前の DevOps の採用と同様に、エンジニアリングを超えてビジネス リーダーシップ、製品管理、エンド ユーザーと交わるコラボレーションの強化と組み合わせた真の文化的変化を必要とします。このような幅広い考慮をせずに、単に 1 人の個人の生産性を測定するだけでは、通常は役に立たないことがわかりました。
個人ではなくチームに重点を置くようになったきっかけは何ですか?
全体的な生産性や進捗の完全かつ微妙な状況を把握できる単一の単純な指標はありません。開発されたコード行数などの指標は何年も前に信用を失いましたが、ストーリー ポイントなどの過度に単純化された指標 (主観的で、価値ではなく労力の指標) は今でもよく使用されています。ストーリー ポイントの使用は、作業の計画と見積もりを行う優れた方法ですが、生産性の指標としては誤って使用されることがよくあります。この問題は、同じ会社内であっても個人とチームの生産性を比較しようとすると、より顕著になります。チームは、テクノロジ スタックとアーキテクチャの異質性または同質性に応じて、非常に異なる課題と機会に直面します。これらのアプリケーションとテクノロジ スタックのそれぞれにおいて、複数の言語、フレームワーク、および技術的負債が長年にわたってさまざまなレベルで蓄積されてきました。システムの保守と新規開発の違いでさえ、生産性に大きな違いが生じます。
では、組織はどのようにして開発者の生産性ではなく開発の生産性について考え始めることができるのでしょうか?
AWS は、生産性だけにとどまらない 3 つのコアディメンションを使用しています。1 つ目はシステムの健全性です。これは、製品の品質、パフォーマンス、可用性、機能の採用など、エンドユーザー中心の結果を測定します。結局のところ、生産性が高くても間違った結果を生み出すのは矛盾です。2 つ目は、CI/CD プロセスの有効性、つまり、デプロイ頻度、コミット間のリードタイム、変更失敗率などのボリュームと速度のメトリックを確認します。これは単なる速度測定だと思うかもしれませんが、これには品質とセキュリティの基準を満たすという要件が暗黙的に含まれています。最後に、定期的な従業員調査とスコアリングに基づく、仕事の満足度、離職リスク、燃え尽き症候群の指標などの要素にわたってチームの健全性を確認します。これはソフトな測定セットのように思えるかもしれませんが、燃え尽き症候群は生産性の低下と非常に相関しています。
組織が採用できるフレームワークは他にも多数あります。たとえば、従業員の満足度と幸福、成果、コードやタスクの出力メトリックなどのアクティビティ メトリック、コミュニケーションとコラボレーション、フロー効率の 5 つの側面を網羅する SPACE フレームワークなどです。DORA フレームワークはおそらく最もよく知られており、テスト自動化、アーキテクチャ プラクティスなどを評価することで、技術能力と生産性を結び付けます。これらは、リード タイムや展開頻度などの生産性メトリックを推進し、組織全体のパフォーマンスと従業員の幸福に直接つながります。
これらはどれも単純な単一の指標ではありません。これは、開発生産性が、個々のエンジニア、チーム、および会社のレベルでのこれらすべてのさまざまな要因の相互作用と交差に依存するという事実を反映しています。開発生産性を理解する鍵は、システムレベルの結果、エンジニアリングの出力と活動、および主観的な開発者の感情の定期的な調査とスコアリングに関する客観的なデータを組み合わせることです。この 3 つの側面からの洞察は、優秀な人材を維持する持続可能な文化に役立ちます。古いことわざを言い換えると、間違ったものを測定することは多くの場合簡単ですが、正しいものを測定することは難しいかもしれませんが、報われます。
これらの開発生産性指標はどのように悪用されるのでしょうか?
これらの指標は、多くの場合、雇用、解雇、報酬ではなく、健全性を示すことを目的としています。これらは、チームの改善と自己監視を支援するために使用する必要があります。避けるべきアンチパターンの 1 つは、たとえば開発効率の尺度が目標になるグッドハートの法則です。よくある誤用は、前に概説したテクノロジーと課題の違いにもかかわらず、指標を使用してチームを比較することです。これらの指標は、チームが改善領域を特定できるようにし、作業方法の有効性を監視し、これらすべてが持続的に行われるようにするために、意図されている目的で使用してください。
Amazon Q Developer などのツールの導入は開発生産性にどのような意味を持つのでしょうか?
Amazon Q Developer は、British Telecom などの企業で、コードの推奨、品質とセキュリティの問題の特定、テストの自動化、パーソナライズされた生産性に関する洞察の提供などの分野で使用されています。Amazon Q Code Transformation は、.NET や Java のバージョンのアップグレードなど、大規模な技術的負債の削減に役立つもう 1 つのツールです。これにより、開発チームは、自分たちとその企業が望んでいること、つまりビジネス成果の提供に戻ることができます。創造性を発揮してください。AWS のお客様は、これらのツールを使用して、合成テストデータと単体テストスクリプトの作成、機能の開発、トラブルシューティング、潜在的な脆弱性の修正などを行っています。これらのツールの重要な副次的な利点は、AI ベースの開発者ツールの使用が幸福度の向上と相関関係にあることが新たな研究で示されていることです。
開発生産性の向上について、どのようなアドバイスをいただけますか?
開発生産性の向上は、一度きりの「特効薬」を求めるのではなく、時間をかけて少しずつ成果を上げていく継続的で漸進的な取り組みと見なすべきです。まずは、現在持っているデータと指標を使用してベースラインを作成します。これらの多くは、速度を測定する CI/CD ツールから取得されますが、コードの品質とセキュリティ体制を確認することも忘れないでください。定期的な主観的な調査を追加するのは簡単な追加ステップです。生産性を向上させる方法を知っているのは、測定対象である人々であることが多いため、彼らの意見を求めてください。開発チームで変更を試行し、その影響を評価します。Amazon Q Developer などのツールを、気を散らすものを最小限に抑え、進行中の作業と依存関係を減らし、最も付加価値の高い作業にチームを集中させる作業変更と組み合わせて使用します。
AWS のお客様の多くは開発をアウトソーシングしています。彼らに何かアドバイスはありますか?
最終的には、アウトソーサーと AWS の顧客はそれぞれ異なる目標を持っているかもしれませんが、開発チームが生産的であること、有意義な成果に向けて取り組んでいること、そして利用可能なツールを使用してチームの成果を継続的に改善していることを確実にしたいと、私は信じざるを得ません。こうした成熟した契約のほとんどは、開発に費やした時間に対して料金を請求するだけでなく、真に価値を提供することが価値であることを理解しています。私は、AWS の顧客とそのパートナーが、このブログで説明した指標の透明性を確保し、それを使用して改善点を探すのを見てきました。Amazon Q Developer などのツールの使用を契約で奨励することは、この方向への一歩です。
ソフトウェア開発者にとって、今はエキサイティングな時代です。この仕事に長く携わってきた人にとって、これは私たちが成長してきたツールのさらなる進化であり、貴重なビジネス成果と価値の提供にさらに重点を置く能力が向上しています。ジョーが開発生産性に焦点を当てていることで私が気に入っているのは、今日のほとんどの組織にとって生産性の単位は個人ではなくチームであるという暗黙の認識です。おそらく私たち技術者は、組織内の他の場所にいる同僚にもこの教訓を受け入れてもらうことができるでしょう。
Phil Le-Brun は、Amazon Web Services (AWS) のエンタープライズストラテジスト兼エバンジェリストです。この役割において、Phil はエンタープライズのエグゼクティブと連携し、クラウドがスピードと俊敏性を高め、顧客により多くのリソースを割くためにどのように役立つかについて、経験と戦略を共有しています。AWS に入社する前、Phil は McDonald's Corporation で複数の上級技術リーダーを務めていました。Phil は、電子工学と電気工学の BEng、経営管理の修士号、実践的なシステム思考の MSc を取得しています。
