『エンジニアチームの生産性の高め方』という書籍で開発者生産性について執筆しました

この度、『エンジニアチームの生産性の高め方』（技術評論社）という書籍の共著に携わり、無事に先日発売されました 🎉

なんと、技術評論社の『エンジニアチームの生産性の高め方』という書籍を一部執筆しました！技術基盤チームのキャリアや、どうやって課題発見をするか、どうやって開発者生産性を評価するかという話題で1章書きました。今すぐ予約！！！https://t.co/saqKy2NOW5
— giginet (@giginet) October 9, 2024

雑誌の特集記事などはたまに執筆したけど、ちゃんと流通に乗る書籍を書いたのはなんと10年ぶり。2014年に大学院生のときに350ページ超の単著を執筆して、その時に一生分の執筆パワーを使ってしまったみたい。

giginet.hateblo.jp

いや〜、大変だった。書きながら何度も内容に悩み、安請け合いしたことを後悔したけど、途中で原稿を落とすわけにも行かずに脱稿。なんだかんだで書ききったし、結果的に出版されて喜びも一入。ぜひお手にとっていただければ。

何を書いたの？

僕が担当したのは、第7章の「開発基盤の改善と開発者生産性の向上」*1という章。僕がこれまでのキャリアの中で、開発基盤エンジニアとして働く上で、心がけていたことや、考え方などを盛り込んだ。

また、基盤開発を通して、開発者体験の改善をどのように実行していくか、ステップ毎に紹介している。

後半は開発者体験の向上の評価のために、よく話題に上がる開発者生産性の評価という点にも言及している。生産性評価指標の既存研究である「SPACEフレームワーク」を用い、モバイル開発領域の開発者体験・生産性向上のための応用に挑戦している。ここでは、よくモバイル領域の生産性のメトリクスとして扱われやすいビルド時間やローカルビルドの失敗率という指標を例に挙げ、どのようにメトリクスを読み解くべきか議論している。

特にモバイルアプリ領域のDevOpsに特化した視点から執筆しつつ、なるべく話を一般化して書いているので、いろんな領域のエンジニアの参考になれば幸い。

豪華な執筆陣

「エンジニアチームの生産性の高め方」という書籍が出版されました

元々、この本は、同僚で同じチームである @mntsh *2 の推薦で筆を執ることになった。（ありがてえ）

他の執筆陣として、元メルカリGroup CTOの@kwakasaさんや、Tably CTOの@yoichiroさん、ナレッジワークCTOの@mayahさんなど、各社のCTOやVPoEを歴任した、とても厳つい著者陣の中に名を連ねることになった。非常に光栄なことです。

7つ集めると生産性が上がるという噂のサイン #engprodbook pic.twitter.com/k3HkIqqUmk
— こざわ/とひ (@t_aldehyde) November 1, 2024

非常に下手くそなサインで存在感を出すことができた

正解が見えない中での執筆

こうしてブログ記事を書いたのだから、もう少し販促に繋がることを書くべきなのだろうけど、結果的にどうにも自信がないというのが正直なところ。

本書でも言及しているが、生産性(Developer Productivity)や開発者満足度(Developer Satisfaction)という指標はとりとめのないもので、当然ながら結論を出すことができない。世の中に生産性に関しての議論や研究が溢れているのもその証左だと思う。

前回の書籍はチュートリアル本に近いもので、事実を列挙する側面が大部分なので迷いはなかった。反面、今回は正解が見えない分、執筆している内容の説得力を少しでも出すことに苦心した。書きながらちょっとこれは論拠が弱いだろうと思う部分もあったが、コンテキストの説明や反論に対してのエクスキューズなどを盛り込んでいると一生完成しないので、ある程度は割り切った。その結果、執筆にメチャクチャ時間がかかった*3。非常に大変だったので、また向こう10年は書けないかも。

結局、最後まで悩みながら書いており、あまり殻を破りきれなかった気はする。もうちょっと色を出しても良かったという後悔はある。

月並みだが、執筆を通して言語化できたために、基盤開発や生産性について問われたときに自分なりの答えを持つことができた。というか、売り物にするために強制的に生産性について問答せざるを得ない状況になったというのが正しい。やはり締め切りやプレッシャーは重要。