開発者生産性の神話

概要

別記事で紹介した論文The SPACE of Developer Productivityの中で開発者生産性の一般的な誤解について書いてる部分が面白かったので、所感も込みでまとめてみました。

SPACE自体、多くの研究がされているにも関わらず、開発者の生産性に関しては未だ俗説が蔓延しており、それらを払拭するために開発したと述べられており、これから紹介する内容を理解することはSPACEの理解にも繋がると言えます。

SPACEフレームワークそのものに関しては、手前味噌ですが、論文そのものや、Four Keysだけじゃない開発者生産性フレームワークなどを参照して頂けると幸いです。

Productivity is all about developer activity

開発者のアクティビティデータだけでは生産性を捉えることは出来ない、という内容です。
アクティビティデータというのは、PR数、コミット数、コードレビュー数など、業務を遂行する過程で完了した行動やアウトプットの数を計測したものです。
測定も比較的容易で、わかりやすいメトリクス群ではありますが、ペアプログラミングなどのコラボレーション活動を上手く捉えることが出来なかったり、アクティビティの増加が効率的に仕事が出来るようになったのか、長時間労働した結果なのか、単独では区別がつかない点を問題として指摘しています。
またソフトウェア開発に不可欠な活動の多くは(ドキュメンテーション、メンバーのサポート、etc...)、測定・定量化が難しいため、アクテビティデータだけで生産性を正しく特定すること出来ないと主張しています。

アクティビティデータは使い勝手が良い部分もありますが、コミット数・PR数の増加が本当に生産性向上を意味してるかを、それだけでは読み解くことは出来ません。
一側面としては重要なものではありますが、測定の容易さもあり油断するとアクティビティデータだけで、個人・チームの生産性を判断してしまいがちなため、基本的には一側面でしかなく、単独で使用しないというスタンスを堅持するのがベターだと考えています。

Productivity is only about individual performance

生産性は個人レベルだけでなく、チームスポーツのように選手個人の成績とチームの成功の両方で判断されるべき、という内容です。
自分の生産性のみを考えてる開発者は、チームの生産性を低下させる可能性があります。
コードレビュー、オンコールローテーション、レビューなどのチームとしての活動を疎かにしては全体
としての生産性やコードベース・プロダクトの品質を上げることにも繋がりません。
ただ個人・チーム・組織の生産性を捉える上で、一定コンフリクトが発生することもあるため、適切なバランスとトレードオフの可能性を理解することが重要だと述べられています。
わかりやすい例はコードレビューやオンコールでしょう。これらに参加することは開発者個人で捉えると生産性を阻害してると言えるかもしれませんが、チームとしての生産性を考える上では重要な活動です。
SPACEに、効率性だけでなくコラボレーションの側面が組み込まれているのは、まさしくここの話が理由だと捉えています。

One productivity metric can tell us everything

一つの普遍的な指標は存在しない、という内容です。
多くのケースで言われることですが、生産性はコンテキストに大きく依存するため、どんなチーム・組織にも適用・比較可能な普遍的な指標は存在しません。

そもそもチーム間であっても比較することのハードルの高さもあります。
生産性の測定はコンテキストが全てであり、同じ開発組織内であっても、プロジェクトや開発プロセスなどが異なれば、同じ指標を適用して比較することが本当に有意義であるかは難しい問題です。
Netflixの例で、顧客満足度を重要視しているため、多くのチームで顧客満足度をチームの生産性指標の一つとして採用しているが、社内の人間を顧客に持つチームの満足度は、ユーザー対応チームの満足度よりも低くなる傾向があることが分かっているため、結局比較は難しいという話をある記事で見つけました。
このように、例え同じ指標を適用していたとしてもそれを比較する事が有意義であるかはコンテクストに依存します。

とはいえ指標を全て一から開発する必要があるという話でもなく、自社に当てはめた時にどうなのかをフラットに判断する姿勢が大事だと捉えています。
生産性ではなく、開発チームのパフォーマンスの測定になりますが、Four Keysは現時点でのベストであり、多くのケースで有意義な指標だと言って良いでしょうが、自社に当てはめて多少定義や集計方法、優先度を調整したりする事も多いと思います。
productivity metricも同じことかなーと捉えてます。

Productivity Measures Are useful only for managers

生産性の測定はマネージャーだけのものではなく、開発者が自分自身の生産性を改善するのにも有用、という内容です。
せっかく測定してるのに、開発者目線では無意味で価値を感じられないことは、もったいないことです。
生産性の高さは、仕事に対する満足感や幸福感と高い相関関係があることが、多くの研究によって示されていますが、開発者個人にとっても生産性を測定・改善することは、より満足度の高い日々を過ごすことにも繋がります。

開発者個人に取っても改善に向けて気づきを得られるような指標選定・活用を目指すのは、開発者生産性可視化を行う上で大事なマインドだと考えています。
可視化はスタートですし、開発者個人の生産性に対しても変化を起こせると良いですね

Productivity is only about engineering systems and developer tools

開発者の生産性には、開発ツールやワークフローが大きな影響を与えるが、環境や職場文化などの人的要因も大きな影響を与える、という内容です。
環境や文化を保つための作業は、従来から生産性の測定に使われている測定基準からは漏れてしまうことがあります。
しかし、モラルの向上、メンタリング、知識の共有などは、これらの活動自体がチーム・組織全体の生産性に貢献する不可欠なものであり、開発者生産性を考える上でも重要な側面です。

SPACEフレームワークにおいては、Communication and collaborationの側面でカバーされていますが、State of DevOps ReportやDevOps Capabilitiesにおいても文化の側面が取り上げられている通り、組織文化もパフォーマンスや生産性に影響を与える大きな要因です。

まとめ

神話と誤解の章は、読み終わってみるとそうだよねという内容ですが、納得度高く整理されていて、良い論文だと改めて感じました。