GitHub、ビクトリア大学、Microsoftの研究者グループによる先日の論文には、開発者の生産性を深く探求することによって、その定義、測定、予測のための新たなアプローチが提案されている。InfoQは今回、論文の筆頭著者である、GitHub Research & Strategy担当VPのNicole Forsgren氏に話を聞くことができた。
著者らによると、このSPACEは、開発者の生産性をさまざまな面から把握すると同時に、生産性が作業時間やツールや個人のパフォーマンスに関するものであるという、根強く存在する通説を打破する目的で開発された。
このフレームワークは、生産性をより広い見地から合理的に考え、メトリクスの意味だけでなく、単独で、あるいは誤った状況で使用された場合の制限も明確にする方法で、注意深く選択するための手段を提供する。
SPACEは達成感(satisfaction)、パフォーマンス(performance)、活動(activity)、コミュニケーション(communication)、効率性(efficiency)の頭文字を取ったものだ。これらのディメンションはいずれも、生産性を理解し、計測する上で重要な鍵となる、と研究者らは言う。その上で、それぞれのディメンションに対して、個人、チームあるいはグループ、システムレベルなど、さまざまなレベルで適用されるメトリクスを数多く提案している。興味深いのは、すべてのメトリクスを同時に使用することは推奨せず、逆に、これら3つのレベルすべてにわたって、さまざまな生産性のディメンションを捕捉するメトリクスセットを小さく保つように、注意深く選択することを勧めている点だ。
InfoQは今回、同論文の筆頭著者である、GitHub Research & Strategy担当VPのNicole Forsgren氏と話す機会を得て、SPACEについて詳しく聞くことができた。
InfoQ: 開発者の生産性にフォーカスした研究はたくさんありますが、それにも関わらず、論文でも説明されているように、神話やステレオタイプが幅広く信じられている状況です。生産性はなぜ、これほど捉えどころのないトピックなのでしょうか？
Forsgren: 生産性がいまだ捉えどころのないものであるのは、ひとつのディメンションやメトリックに集約できないものだからです。
10年以上の研究結果から分かったのは、生産性が複雑で微妙なものであることです — ソフトウェア開発チームにとって、これには重要な意味があります。開発者の生産性を、コード行数などの"重要なひとつの指標"によって測ろうとするチームやマネージャがあまりにも多いのです。生産性はそのような単純なものではありません。生産性について人に尋ねれば、作業の完遂、共同作業、"流れ"に乗ること、エンジニアリング成果の改善など、さまざまな話題が出てくるはずです。
InfoQ: 生産性を考える上で、最も望ましくない誤解は何だと思われますか？
Forsgren: 最も一般的な定説のひとつ — 開発者の幸福に対して、考え得る最大の脅威でもあります — は、コード行数やコミット数など、開発者のアクティビティのみで生産性を捉える考え方でしょう。アクティビティの増大にはさまざまな理由があります — 長時間労働は、システムのまずさや計画の不備を克服して所定のリリーススケジュールを守るために、開発者が"力ずく(brute-force)の"作業を強いられている、というシグナルの可能性があります。
実際に、私たちの 2020 Octoverse Reportには、開発者の生産性に関する詳細な検討結果を記載していますが、開発作業は — 作業時間と作業量の両面で — 調査対象のすべてのタイムゾーンで増加しているのです。開発者には自身の時間や労力をフレキシブルに管理できるというメリットがあるのですが、逆にそれが、作業時間増加の一因となっているのです。仕事が個人の時間を代償として、健全なワークライフバランスを損なうようであれば、このペースを長く続けることはできないかも知れません。
一方で、このアクティビティの増加は、エンジニアリングシステムの改良、開発者が自身の仕事を効率的に行う上で必要なツールの提供、あるいは、チームメンバ内のコラボレーションやコミュニケーションの改善による変更やコードレビューのブロック解除という形に反映される可能性があります。
このように、アクティビティというメトリクスだけでは、このいずれのケースなのかを判断することはできません。ですから、メトリクスを単独で使用して、開発者を褒賞したり処罰することがあってはならないのです。プルリクエスト数やコミット数、あるいはコードレビュー回数というような、より直接的なメトリクスであっても、データ内のギャップや計測エラーが原因となって誤った結果を導くことが少なくありません。このようなメトリクスを報告するシステムは、ペアプログラミングやブレインストームで見られるようなコラボレーションのメリットを見落とすことになるでしょう。最後に、開発者は納期に間に合わせるために自身の時間を融通することが少なくないので、生産性の評価を特定のアクティビティの測定に依存するのは難しくなります。
InfoQ: 論文では、開発者生産性に関する通説や誤解から離脱する試みとして、多面的なフレームワークであるSPACEを紹介していますが、このような着想に至った経緯について説明して頂けますか？
Forsgren: SPACEの開発は、ユーザや顧客との過去の経験を出発点にして、彼らの開発者生産性の測定方法にあるギャップを確認するために行いました。
一般的な例として、現在は多くのチームが、開発者の生産性をSPACEフレームワークのたったひとつのディメンション、例えばアクティビティで計測しています。 アクティビティとは、コード行数やコミット数、プルリクエストの所要時間のような、作業過程で実行したアクションや完成したアウトプットの数です。いずれも単独で注目するには狭すぎますし、他の重要なファクタを見落とすことにもなります。
別の例として、PRの所要時間を重視して、1時間というSLAを自らコミットしたチームと一緒に作業したことがあります。これは結果として、チームメンバのコーディング作業時間を中断するものになっていたため、開発者たちはPRを数時間無視して、開発に専念できるようにしていました。これに対応する手段として、リーダやマネージャがすべてのチームメンバに対してアラートをオンにしたため、それがアラート疲労の一因になったのです。メトリクスは意思決定や行動に影響するので、ひとつのメトリクス、あるいはひとつのディメンション内のメトリクスに注目してしまうと、それが行動の変化を生み、意図していない結果(この例ではコーディング時間の中断)を引き起こす、というリスクを抱えることになります。コラボレーションや満足度、パフォーマンスといった、生産性の重要なシグナルを見落とす可能性もあります。
InfoQ: SPACEを使用したい組織は、開発者生産性の測定方法をどのように変えるべきなのでしょうか？
Forsgren: SPACEフレームワークは、生産性をより広い見地から論理的かつシステマティックに捉えて、目標にリンクしてバランスの取れたメトリクスを注意深く選択する手段を提供するとともに、メトリクスが単独や誤った状況で使用された場合に起こり得る制限を提示します。その中で私たちは、読者に対して、自明ではない可能性のあるトレードオフのいくつかを明らかにする上で有用な、チームや組織に関連する５つのカテゴリを確認するように提唱しています。
InfoQ: SPACEがこのテーマの結論ではないと仮定した場合、開発者生産性に関する研究は、今後どのように進展すると思われますか？近い将来については、どのような要因がそれを形成していくのでしょうか？
Forsgren: 新たなテクノロジが開発業務をどのように加速し、どのように進化させていくのか、それが生産性にどのような意味を持つのか、考えるとわくわくします。例えばローコードやノーコードのツーリングは、プロトタイピングの限界費用を低減するものとして、開発者の注目を集めています。これは、開発者自身の実験やイノベーションループに影響を及ぼすに留まらず、そのチームや組織にまで影響範囲を広げていくでしょう。MLやAIは今後も進歩を続けますから、それらは開発者のプロトタイプやツーリングの開発を促進し、新たなソリューション発見の支援へとつながっていくでしょう。
もうひとつの興味深い進化は、グローバルな職場へのシフトです。今回のパンデミックは多くの企業に対して、リモートワークが可能であり、生産的であることを示しました。今後、リモートワークモデルやハイブリッドワークモデルの導入による長期的価値を受け入れる企業が増え、それが分散チームの増加へとつながって行けば、開発者のコラボレーションパターンや柔軟性も変化し、満足度や幸福感も増大することでしょう。