ソフトウェア開発における生産性について書かれたものの大半はクズだ。だが、NicoleとAbiの書籍は注目すべき例外である。出版されたばかりの彼らの書籍に書いた私のまえがきを転載する。

上級技術マネージャーたちと昼食を共にしていると、そのうちのひとりが自身の開発チームの生産性向上の取り組みについて語り始めた。彼は昇進や解雇の判断に使えるように、チームやスタッフの生産性を計測する指標プログラムを導入したそうだ。仕事の場だったので、私は呆れた顔をしないように必死にこらえながら、「どのような指標を使っているんですか？」と聞いた。続けて「ビジネスのアウトカムについては考慮していますか？少なくとも測定と関連付けようとしていますか？」と質問した。残念ながら、私の質問は通じなかったようだ。街灯の下ではなく、鍵を落とした茂みのなかを探すように説得するのは難しいと思い知らされた。

私がこれまでに出会ったほぼすべてのエンジニアリングマネージャーはチームの生産性の向上を望んでいたが、私がこれまでに出会ったほぼすべての開発者は自分たちの仕事を効果的に進めたいと思っていた。先ほどの昼食会の話を開発者が耳にすると、生産性は揺るぎないグッドハートの法則（ある指標を目標に設定すると良い指標ではなくなる）を無視した、単純化された測定にすぎないと冷笑的に考えてしまう。

しかし、開発者の生産性を研究しながらも、安易な考え方に陥らない人たちに出会うこともある。たとえば、NicoleとAbiがそうだ。

本書の重要なポイントは、人々の生産性を強制的に高めようとするのではなく、生産性を低下させる摩擦の要因を特定しようとしているところにある。摩擦とは、数日前に書いて内容を忘れたコードをプルリクエストしなければならないことや、単純なAPI呼び出しで済むはずだったのにインフラの整備に2日間かけてしまったことである。こうした摩擦点を取り除くことが、開発者体験の向上（さらには有用なソフトウェアをユーザーにいち早く届けること）の本質だ。

彼らは効果的な開発者体験を3つの要素で表している。それは「フィードバックループ」「フロー状態」「認知的負荷」だ。正しい道を進んでいるかどうかを判断するには、迅速なフィードバックが不可欠だ。地図アプリで青い点が動く間隔が長ければ長いほど、間違った方向に進んでいると気づくまでの時間は長くなる。フィードバックが迅速であれば、第二の要素「フロー状態」を維持できる。これはスムーズかつ迅速に物事を成し遂げることができ、プロダクトやモチベーションを高めることのできる状態である。フロー状態を維持するには、自分が何をすべきかを理解する能力も重要である。つまり、構造化されていないコード、不完全なテスト、フローを中断させる妨害などで、「認知的負荷」が高まらないように注意を払う必要がある。

開発者体験の向上とは、これらの3つの要素の阻害要因を特定することである。開発者体験を改善すれば、ビジネスのアウトカムにつながる。インフラの整備に手間取った結果、開発者の人件費がムダになっただけでなく、ソフトウェアが本番投入されるまでの収益の損失にもつながったのである。

本書の大部分は、こうした摩擦点を特定するプログラムの開発方法（多くの問題を引き起こしている部分を特定して修正する方法）について述べている。指標も含まれているが、開発者体験を深く理解するために使用するものである。コミットの頻度は取得が簡単な単純な指標だが、それだけでは全体像を把握できない。適切に設計された開発者アンケートであれば、無視されがちな視点を明らかにできる。開発者にインタビューすれば、数値データに重要な背景を追加できる。これらを収益と結びつけることは簡単ではないが、もしそれが可能であれば、効果的な運営の指針となるだろう。

グッドハートの法則は測定に関する大好きな格言だが、他にも最近気に入っている格言がある。

不完全な測定であっても、それを判断材料ではなく手がかりとして扱うのであれば、まったく測定しないよりもマシだ。 ―Jessica Kerr

本書は、こうした手がかりを見つけるためのガイドブックである。