最近、「エンジニアリング統括責任者の手引き」(原題: The Engineering Executive’s Primer)という本を読みました。本自体はいろいろ読むのですが、久しぶりに自分の今考えていることを記録しておきたいと思い、章ごとに読書感想文として残します。
きっかけ
各種ソーシャルメディアや、身近な人で読んでいる人がいることがいたのがきっかけです。今、僕はITエンジニアリング組織の中間管理職(部長, Sr. Engineering Manager)をしています。今の立場を踏まえると、今後いつか来るかもしれないステップアップの機会があるとしたら、それは CTO をはじめとしたエンジニアリング統括責任者(以下、統括責任者)の立場であると想像しています。その時になってみないとわからないことはたくさんありそうですが、その前に本を通じて何かを知ることができればと思い、手に取ることにしました。
1章: エンジニアリング統括責任者のポジションに就く
統括責任者のポジションは、ICや中間管理職までのポジションとは違い、巷に求人情報(JD)として流れてくることは稀です。そのポジションをいかに探し、選考プロセスに入り、条件交渉をし、そして就くのか、全く知らない景色でした。特に「一点もの」という言葉はすごくよく響きました。その組織に求められている統括責任者の在り方はそれぞれ違っていて、 CEO との相性も含め熟慮を要するポジションなのだなということを知りました。
とはいっても、先に述べたように JD が流れてくるわけではないので、ポジション探しそのものが難しいのだろうなとも感じました。しかるべき人脈が整っているか、または何かふとした出会いが必要そうです。やっぱりこういう点でも一点ものなのでしょう。
2章: 最初の90日間
僕は幾度となく転職をしているので、転職してから最初の90日間、多くは試用期間となりますが、それをいかに過ごすかは一定の経験はありました。
では、統括責任者となったときに決定的に違うと思ったのは、決めることはすでに始まっているということです。情報収集をしてしかるべき時を見計らって行動するというのは転職してすぐの時は慎重にやるものです。それ以上に、信頼関係がそこまで出来上がっていない段階で決定して組織を動かす必要があるようです。これはいきなりバーが高い要求です。まず、これをやる覚悟があるかどうかを試されると理解しなければなりません。
3章: エンジニアリング戦略を立てる, 4章: 計画の仕方
戦略、というのは便利な言葉ですが、それをいかに定義して組織に浸透させるかは統括責任者だから携われる大切な課題です。これはアプローチが丁寧に書かれているのでまずは実践するしかなさそうです。ただ、ここの文章に書かれていない難しさが待っている気がしますが、それは今は分かりません。
5章: 効果的なバリューを作る
この章を読み始めた時、自分の幸運に感謝しました。ひとつは、日本のIT企業でミッション・バリューを有名にしたメルカリで会社が小さな時から勤めていて、それが組織拡大に伴ってどう普及してどのようなことが起こったのかを目の前で知っていたことです。もうひとつは、 Amazon (AWS)という 世界企業で Our Leadership Principles (OLP) がどのように浸透し運用されているのかを実体験していたことです。未来、自分が組織のバリューを作ることになったとき、どうやって言葉を込めるのかを他の新任統括責任者に比べて知見を持って取り組める気がしています。
6章: エンジニアリング組織の測定
どのような軸で測定し、それを意思決定や組織運営に活用するのかの観点が述べられています。部長ぐらいになると、この手の話題に触れることが増えてくるので、今はちょうどいい学習の時期なのかもしれません。
7章: M&Aへの参加
この本を読んでいて最もイメージが湧かなかったのがこの章です。正直、その時にならないとここに書いてある意味はわからないかもなと思っています。 IPO とはまた違うのはわかります。
8章: リーダーシップスタイルの開発
これは、今、部長をやっていて少しずつ形成しはじめている能力です。ただ、何で導くかを明確に意識しながらできていたかというと、そうではなかったかもしれません。文中では「ポリシー」「コンセンサス」そして「信念」の3つで導くとありますが、自分のスタイルをこの3つに分類して整理して考えた時、「信念」が強すぎ、「ポリシー」はそれなり、「コンセンサス」は自分が結構苦手としている分野であることを発見しました。何に注力すべきか、僕にとって今からでも始められることが書かれていました。
途中に「統括責任者が意欲を失う理由」というページがあります。これ、今も起きえる問題が述べられていて、これもすぐに試せることがいくつかありました。
9章: 優先順位とエネルギーの管理
職位があがっていくと、MP(Magic Point, RPGゲームで魔法を使うためのエネルギーのことで、ひいては精神力をここでは意味します)を消費する頻度が上がるのを実感しています。MPをいかに消費しないかを今まで考えていましたが、そうではなくいかにMPを増やす取り組みをするかが書かれています。この考えは、チームメンバーのエネルギーコントロールの考え方にも応用できそうです。
10章: 効果的なエンジニアリング組織のためのミーティング
どのようなミーティングをどうのような観点で実施すると良いのかが書かれています。自分は、書かれていることが割とできているなと思って、少し自信を持ちました。また、「直属の部下はあなたのミーティングを手本にする可能性が高い」というのも実感があり、自分の運営方法にはかなり責任があるんだなということもここで理解しました。
11章: 社内コミュニケーション
距離がある組織のカウンターパートの人といかに紐帯を結ぶか、僕には足りない要素かもしれません。この本ではブロードキャストする方法を中心に述べられていますが、今自分が置かれている立場だとこの方法ではないほうがいいかもしれません。ただ、その場合は何か発明か探究が必要そうです。
12章: 個人と組織のプレゼンスを高める
この章を読んで自分のプレゼンスがどこまであるか、生成AIサービスで Deep Research をしてみました。すると、これまでの経歴がきれいに、僕自身が下手にまとめるより網羅的に出てきました。そうです、僕自身のプレゼンスは十分に今あり、プレゼンスを高めるために更なる活動はそこまで重要ではないことがよく分かりました。ブランド作りは今はしていないのですが、無理にしなくても個人的にはうまくいっている実感があり、かつそういう事例も書かれていることからやはり無理をすることはないんだなと思いました。
ただ、講演やこうやってブログを書くことは自分の活力につながる実感があるので、今の仕事の優先順位は考慮しつつ続けたい気持ちも同時に芽生えました。
13章: CEO、統括責任陣、エンジニアリング組織との協働
今はICの時に比べたらずいぶん広い人間関係があるようになりました。ポジションが高くなると、人間関係の比率はより高まるでしょう。そのときに、どういった心持ちで臨むべきか、今からでも適用できるノウハウが詰まっていました。特に「複雑な問題にぶつかったら、問題解決に突き進む前にスピードを落とし」とあるのが印象的でした。思わずスピードを出そうとする自分に対しての忠告として受け取りました。
14章: エンジニアリング組織の幹部層を団結させる
これも、部長という立場なら今すぐ実践できる、または意識せずともしているが改めて振り返ることができる項目が並べられています。それと、このくらいまで読むとわかってくるのですが、この本ではとにかく人間関係の分析の重要性とその方法についてかなりの文章をさいていることがわかってきます。エンジニアリング組織のマネジメントの手法の本はいくつか読みましたが、ここまで泥臭い本に出会ったのは初めてかもしれません。
15章: ネットワークの構築
これは主に社外人脈のことを指しています。これも、これまで十何年とエンジニアコミュニティと関係を作り、そしてつながっていただいている人に感謝しないといけないことだと振り返っています。その一方で、 VC や起業家との関係は希薄なので、これからの課題です。
16章: 同格の統括責任者のオンボーディング
この章は、M&Aの次に実感が湧かない章でした。正直ちょっと読み飛ばしています。25章ある本ですので、1〜2章は飛ばすようなことがあっても良い気がしています。
17章: 検証を伴う信頼
信頼による管理の限界と、それを解決する手法が少し述べられています。僕は、自分がこれから学びたいことだと感じていて、もう少し深く理解するための知見に触れたいと思いました。 AWS にはこのノウハウはたくさんあったように思い起こしています。
18章: 基準の調整
17章とともに、もう少し深く理解するための知見に触れたい章でした。そして、やはり AWS のことを同時に思い出しました。
19章: エンジニアリングプロセスの進め方
組織拡大に伴う、職能組織の設計について述べられています。これは、実は生成AI時代になってまた変わるところが出ると思っています。というのも、生成AIがひとりひとりの能力を拡張した結果、これまで程に細分化した職能組織は求められなくなり、これまでよりは少ない人数で生産性を発揮する組織構造が求められる時代に入っていると僕は考えているからです。
20章: 採用
採用の仕組みそのものの設計の話題です。大きな会社にいるとすでに仕組みがありそのレールの上で動きますし、小さな会社だと逆に求人広告掲載で手一杯ということも経験してきました。これは、自分がどちらの組織も経験していること、そしてこれまで面接官やオファー面談を担当していることから、多角的な経験ができていることは武器になりそうと感じました。
21章: エンジニアリング組織でのオンボーディング
オンボーディングの仕組みの成熟度は、僕の経験では組織の成熟度に一定の相関があるように思いますし、本でもそのような感じで書かれています。ところで、「継続的にこのプログラムを称賛する」という記述があるんですが、こと海外の優れた企業は、組織の仕組みと評価をうまくリンクさせて仕組みを持続可能にしていることは注目に値します。
22章: パフォーマンスと報酬
この章は、いかにも外資っぽい評価制度だなと思いながら読みました。これだけで色々な本があるので、特に日本の実情を鑑みるならそちらの本を読むことも大切だと考えています。
23章: 企業文化診断データの活用
僕は、こういった調査を回答する側に回ったことがあります。それが、どういった背景で行われているのかを知るよいきっかけになった章でした。ダンパー数の話題も出ていますが、自分がそれを担当することになったらもう一度意味を理解し直すために読むことになりそうです。
24章: エンジニアリング統括責任者のポジションを離れる
この本、25章、374ページあります。24章が事実上の最終章です。割とじっくり読むと数日かかりまして、ここにようやく辿り着いた感がありました。立つ鳥跡を濁さずなのですが、たぶんいかなる立場でも通用する大切なポイントがまとめられています。辞め方というのは、人が出るものです。この章から読み始めても良い気がします。
おわりに
統括責任者になろうとすることは、今までの中間管理職・ICとは違う次元に進むことを覚悟せねばならないと理解するには十分な本でした。その一方で、中間管理職の今でも始められる取り組みも数多くあり、次のステップを見据えながら自分を鍛えていく指標を得るのにもとてもよい本でありました。
今すぐどうこうというものではないのですが、始めるのには早すぎるということはなさそうです。