こんにちは、柴田です。万博で発売されているミャクミャクコラボのパイン飴を大量に買ってしまい、毎日午後のお菓子にパイン飴を食べて暮らしています。
今日は 2025 年 6 月 3 日に発売された「エンジニアリング統括責任者の手引き」という書籍のレビューをした時の感想と本の見どころについてご紹介します。
書籍レビューに参加した経緯
訳者である島田さんは書籍のレビューアを公募することが多く、今回もfacebook でたまたま見かけた時に応募したというのがきっかけでした。以前も他の書籍で見かけて応募したものの落選、であるとか数日油断していると募集終了していた、ということがありましたが、今回は無事レビューに参加することができました。
私は現在はマネジメントは担っていませんが、前職では執行役員 VPoE 兼技術部長として評価制度の設計、採用戦略の策定、技術選定... というようないわゆる「エンジニアリング統括責任者」の一翼を担っていました。そのため当時の経験と学びから有用なレビューとフィードバックができるだろうという意気込みで参加しました。
技術としての「マネジメント」は流行り廃りはあれど、人を対象とする領域なので数年前の知識、なんなら数十年以上前のドラッカーの書籍が今でも使われるように、陳腐化するスピードはIT技術に比べれば遥かに遅く、自分が持っている経験をベースにしてもレビューに役に立てると考えたためです。
レビューに参加して感じたところ
レビューは GitHub を用いて、issue でのフィードバックと pull reqeust を用いて直接修正案を出すという2つを用いて行いました。特に GitHub Actions を用いて、修正されたものが即座に反映され PDF として読むことができるシステマチックな執筆環境なのは驚きました。
レビューは私以外にも多数の方が参加しており、読み方や指摘の方法も人それぞれでしたが、主に以下のようなパターンがあるように感じました。
- 英語の原文を確認した上で、邦訳の間違いやニュアンスの指摘
- 邦訳された文章の誤植などの間違いの指摘
- 邦訳された文章が日本語の書籍として整合性が取れているかの指摘
私は自分の英語力では、他の方が原著を読んで指摘する以上のことは難しいと判断して、最後に記載された翻訳済みの文章を、日本語の書籍として妥当かどうか、という視点で通読しました。累計で最初から最後まで3回読みました。
この書籍は、著者である Will Larson の秘伝のメモ、というような構成で作られており、最初から通読していくと、章の番号順では解説されていない用語が突然登場したり、後になって用語の解説が行われたり、という箇所が多々ありました。島田さんとも相談しながら、「この話はなんの話だったっけ...」ということは可能な限り順序立てるか、訳註などでジャンプできるようにしてはどうか、とフィードバックを行いました。
レビューで一番盛り上がったところ
さて、訳者である島田さんのエントリにもあるように、この書籍で一番の目玉はタイトルにあると個人的には思います。原著は 「The Engineering Executive's Primer」というタイトルであり 「Engineering Executive 」をあまり考えないで訳すと技術担当執行役員、であるとか技術担当役員に当たると思います。
日本の会社法で定められている役員とは「取締役」「会計参与」「監査役」の3種類なわけですが、技術担当役員、という訳語と使ってしまうと対象は「取締役」向けの本になってしまいます。
一方で会社法には定められていないものの取締役に次ぐ役職の執行役員、という用語を用いてもう少し幅を広げたとしても、本書の中では CEO である社長がレポートラインとして描かれている場面もあり、「実際にそういうこともあるだろうけど、技術担当の役員がいるなら社長ではなく、その役員がレポートラインだよなあ」という感想を持ちました。他にも取締役でも執行役員でもないが CTOとして技術組織の責任を負っている、技術部長という役職ではあるがエンジニア採用の責任者である、など経営に近いレイヤーでは肩書きと実行する内容が組織によって異なることはよくある話です。
対象が狭い用語を書籍のタイトルに使ってしまうと、使用したジョブタイトル以外の役職者には届きにくくなってしまうため、できるだけ「自分向けの本」と感じられるようなタイトルの方が良いと思い、自分は最終的に「技術系経営幹部」という案を提案しました。他のレビューアの方からも「VP」「CTO」「エンジニアエグゼクティブ」「技術責任者」など複数の案が出されつつ、最終的に島田さん自ら「エンジニアリング統括責任者」という案が出され、「これだ...!」となった経緯があります。
本書のハイライト
本書はタイトルから連想できるように、エンジニア組織の運営手法について豊富に記載されています。現在エンジニアリングマネージャやテクニカルリードを担っている人は間違いなくおすすめの本です。特に「14章 エンジニアリング組織の幹部層を団結させる」はすべてのミドルマネジメントを担う方に読んでいただきたいです。
一方で、エンジニアリング統括責任者に代表されるトップマネジメント職は「悩みの多くは誰にも相談できないが、成果は求められる」非常にタフな仕事です。本書が他の書籍で置き換えられない箇所は、紹介文にもある誰にも相談できない内容について著者の経験をもとにした手法やプロセスが紹介されていることです。
エンジニアリングマネージャーまでの立場なら、同僚や上司など、社内に相談できる相手やアドバイスを求める相手はたくさんいます。しかし、エンジニアリング組織の責任者に就くと、社内に相談できる相手はほとんどいなくなります。エンジニアリング組織の責任者には、高い学習曲線が待ち受けています。意欲を持ってその立場に就いた多くの人が、それに心を折られ、1年半も経たないうちに挫折してしまいます。
例えば、エンジニアリングマネージャのあなたは来月から VP や CTO になります、最初の仕事は「M&A」の対象企業の評価を技術的な観点から行なってほしい、というオーダーが来たとしましょう。そもそも M&A が行われるということを相談できる相手は、それが明らかにされている経営幹部だけか、場合によっては役員の中でも CEO と CFO の2人だけかもしれません。そのような中で、本書の「7章 M&Aへの参加」には判断軸を持って CEO にフィードバックするための内容が記載されています。
また、本書ではエンジニアリング以外の組織であるプロダクト、マーケティング、セールスなどの統括責任者との協業の仕方や CEO との関係性の構築についても「13 章 CEO、統括責任者陣、エンジニアリング組織との協働」で触れられています。
エンジニアの IC やエンジニアリングマネージャとして開発組織の中でキャリアを積んできた後に統括責任者として経営チームに参加する場合、エンジニアリングでほとんどのことが解決できた場とは異なるパワーダイナミクスがあることをまず理解する必要があります。経営チームが持つ会社の課題に対しては「エンジニアには関係ないので」という態度ではなく、エンジニアリング(=技術)部門の長として、会社の課題をどうすれば解決できるのか、他の部門とどう協力すると良いのか、という発想に切り替えるヒントが13章に書かれています。
他にも、財務諸表の読み方、対外ブランディングの方法、採用、そして退職についても書かれています。退職の章は私も実際に行った身としては、「この本が当時にあれば良かった...」となる章の1つです。
まとめ
「エンジニアリング統括責任者の手引き」という書籍のレビューに参加して感じたことと、本書の見どころについて紹介しました。マネジメントと呼ばれる領域についてエンジニア向けの経験に基づいたプラクティカルな書籍が増えていくことを嬉しく思います。私もいつまたマネジメントを担うことになるか分かりませんが、その際には改めて本書を読み直したいと思います。
アンドパッドでは、現在はテクニカルリードを担いながら将来エンジニアリング統括責任者を目指すエンジニアを募集しています。
