Will Larson氏と言えば、『エレガントパズル』（2019年）や『スタッフエンジニア』（2021年）の著者ですね。僕もファンで、2冊とも原著の物理本を所有しています。 氏の新作『The Engineering Executive's Primer』（2024年、原著）は未読だったのですが、このたび邦訳を献本いただいたので、ありがたく読ませていただいたところ、非常に面白く、また得るものも多かったため、このレビューを書いています。特に、CTOやVPoEの方々、それらを目指す皆さん、エンジニア組織のリーダーシップ層の人達の行動原理や本音の一端に触れたいと考えている方にお勧めです。
僕自身は、ずいぶん前にはてなのCTOになって以来、幸いにも日米英の3ヶ国で累計15年ほど、いくつかの組織でCTOやVPoE、またはそれのすぐ側のポジションを経験してきました。本書で取り上げられている様々なトピックの7、8割は、自分にも経験がある、過去に想定をしたことと重なるもので、あるいは「いかにもありそうだ」と具体的な情景が目に浮ぶ、というヒット率でした。本書は多岐に渡る事柄を扱っており、それぞれの項目はそれほど長く詳細に書かれているわけではないですが、その短かい記述にも著者の実体験や考えの変化が書かれており、深い共感を感じたり、あまり意識していなかった観点を気付かされたり、経験豊富なシニアなエンジニアリングリーダーの頭の中を覗かせてもらっているようで、とても楽しい読書体験でした。
興味深かったところをいくつか取り上げてみます。
- p.35 「3.9 戦略はボトムアップで立てるべきでは?」
戦略に遭遇するとすぐにそれが力を奪うものだと主張する人がいる。その主張には、次のようなものがある。
- 戦略がトップダウンであることで、実際に作業を行うチームの自律性が奪われている。自律性を重視しているのであれば、チームは自ら戦略を決定すべきだ。
- マネージャー(エンジニアリング統括責任者を含む)は戦略を設定すべきではない。戦略はマネージャーではなくエンジニアが所有すべきだ。
これらの主張は戦略の仕組みを誤解しているように思う。戦略はトップダウンでしか採用できないのだから、トップダウンかボトムアップかという問題ではないのだ。 問題なのは、戦略を持つか否かだ。
CTOになったことがある人には共感してもらえるのではないかと思いますが、CTOとなるとエンジニアリングについての戦略を持つことが期待される、または自らなんらかの戦略を持たねば、となるのがよくある話です。一方で、ここに書かれているようにトップダウンの戦略への否定的な主張をされるのも、非常にあり得そうな話で、有効な戦略を立てることの難しさと同時にその戦略をいかに実行できる状態にしていくことの難しさを感じます。
- p.87 「5.1 バリューはどんな問題を解決するか」
バリューはこれらすべてのシナリオに対して有用だが、バリューによって示される根本的な文化変革を開始するための効果的な手段では決してない。そのことを認識するのが重要だ。むしろ、バリューはすでに進行中の変化を後押しし、それを永続的なものにするのに役立つ
どういうバリューを作るべきか、というのはなかなか指針を得るのが難しい問題ですが、ここの記述は非常に有効な指針と感じられます。世の中の形骸化してしまうバリューの多くは、「根本的な文化変革を開始するための手段」としようとしているのがよくある原因の１つであることは、ありがちなケースなのではないでしょうか。
- p.105 「6章 エンジニアリング組織の測定」
本書では、CEOや他部門の統括責任者との関係の話がよく出てきますが、この一節は、どんな組織でも人間の集合体であって、そのような組織で成果を出していく経験豊富なリーダーの現実的な悟りが表現されているようで、そのバランス感覚が味わい深いところです。
- p.225 「17章 検証を伴う信頼」
今日、初めてマネージャーになった人たちは、仕事中にコードを書くのをすぐにやめるべきだというアドバイスを受けるのが通例だ。...このアドバイスは、ほとんどのマネージャーがマネージャーとしてのキャリアの初期に手にする、次の短いフレーズに要約される。「チームを信頼せよ」
...
このアドバイスはほとんど正しい。しかし、だからこそ誤用しやすい。マネージャーや統括責任者に本当に必要なのは、無条件の信頼ではなく、検証を伴う信頼これは信頼しつつも検証を怠らないというアプローチを指す。
...
新しい検証の規範を極めてうまく導入したとしても、検証を信頼の欠如とみなす幹部から防御的な反応を受けることは覚悟しておこう。そうした不満を受けると自分の行動を変えたくなるだろうが、その誘惑に負けないでほしい。
チームを「信頼」するというのは言うほど簡単ではないことで、細かすぎず粗すぎない「検証」ができることは確かに有効な手段となります。この「無条件の信頼」と「検証と伴う信頼」については、8章のリーダーシップスタイルの開発にもある「マイクロマネジメントに気をつける」と似たトピックとなりますが、実際に組織で行うとなると非常に気をつかうところです。例えば、「検証」と「介入」の違いはどこにあるのか、「検証」に伴なう副作用をどのように抑えるか、そのコストは受容できるのか、など、いくつかの軸で判断が必要となるところです。
- p.291 「22.2 パフォーマンスと昇進」
包括的な評価基準よりも簡潔な評価基準を優先する
昇進には、レベル付けのための完全で明確な評価基準が強く望まれる。しかし、想像しているかもしれないが、多くの人々が基準を巧みにゲーム化するのに長けているという課題がある。たとえば、Stripeの昇進基準にはメンタリングが含まれていたが、他の人との会議を(要請されていないにもかかわらず) スケジュールし、それがメンタリングに該当すると主張する人に遭遇した。 簡潔な評価基準には微妙な解釈が必要となるが、一方で評価基準をゲーム化しようとすると、現実問題としてすべてのオプションに重要な解釈が必要とされることとなる。
CircleCIのエンジニアリングラダーが注目されてから、評価基準の明確化や詳細化のトレンドが一定続いていたかと思いますが、それとゲーム化に対応するために氏が指摘するように簡潔な評価基準を優先するというのは、有効なアプローチの一つだと考えられます。ただ、簡潔な基準は、ここに書かれている通り、個々の基準について「微妙な解釈」が必要となるので、ここのトレードオフも最適解は存在しないところだな、と感じます。
他にも付箋をつけたところが40箇所ほどあり、それぞれ議論を深められそうです。どこかの機会でいろいろな方とそれぞれの論点で語りあってみたいですね。そのためにも、この本は、新任、熟練問わず、エンジニア組織のリーダーシップに携わる方、それを目指す方にお勧めできます。
