読むのがホネな技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第80回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。
さて、今回読む本は「エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ」だ。ちょっと長いので前半では12章まで、後半で残り全部を読む方針にしている。というわけで前半を読み終わったので途中までの感想をアウトプットしておく。
エンジニアリング統括責任者に就任する予定はまったくないし興味もないんだけれど、エンジニアリング組織を統括するようなテーマは割と身近で、興味深く読んでいる。
「エンジニアリング統括責任者の手引き」とは
「エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか」「スタッフエンジニア マネジメントを超えるリーダーシップ」の著者であるWill Larsonさんが書いた三冊目の本「The Engineering Executive’s Primer」の翻訳である。この方はキャリアポジションごとに深い考察を行うようで、キャリアップに従って書籍のテーマが変遷している点は興味深い。「エレガントパズル」ではマネージャーになったときの、「スタッフエンジニア」は上級エンジニアになったときのことが書かれており、本書はタイトル通り、エンジニアリング統括責任者すなわちCTOになったときに著者が考えたことを中心に書かれているようだ。そういう意味では「手引き」と書かれているが理論に基づいたマニュアルというよりは、実践知で組み立てられた引継ぎ資料のような手触り感がある。
一方で注意が必要だと思ったのは、結果として著者がキャリアップするにしたがって過去の考えを見直しているという点である。
本書の中で私が最も好きなのは、エンジニアリング戦略の策定について解説した3章だ。前著『スタッフエンジニア』（日経BP）でも、私はエンジニアリング戦略について解説した。それからわずか3年の開きしかないにもかかわらず、内容は大きく異なっている。
もちろんその内容の変化は視点が変わったことによるものなので、古いものが誤りであったというわけではないが、こういった実践知に基づいた本であることは意識しておいたほうが良いだろう。
前半（12章まで）を読んだ感想
全般的には非常に面白く読んでいるが、「自分には関係なさそうな章」「日本企業向きではない章」なども存在するのでなかなか難しい本というのが第一印象である。ただ、あまり興が乗らないテーマの章であってもエンジニアリングに関する事例や著者の気づきなどにハッとさせられることが多いので、良い読書体験ではある。
- 1章 エンジニアリング統括責任者のポジションに就く：どうやって米国でCTOになるのかという話。ちょっとこれは縁がないわ
- 2章 最初の90日間：ポジションに就任して最初の90日間をどう過ごすか。これはCTOじゃなくてもありうる話であり、非常にためになる
- 3章 エンジニアリング戦略を立てる：「はじめに」で著者も推している章であり、とても参考になった
- 4章 計画の仕方：経営層クラスの計画立案の方法であって興味深いけど、ちょっと縁遠い内容
- 5章 効果的なバリューを作る：組織のビジョンやバリューの話。これもなかなかうまく実行できていないので、たいへんにヒントをもらった
- 6章 エンジニアリング組織の測定：いろいろなところにある測定論だが「まず自分のために測定する」という点にはハッと気付くものがあった
- 7章 M&Aへの参加：これも縁遠い内容。いつか役に立つかもしれないが
- 8章 リーダーシップスタイルの開発：状況に応じてスタイル変えようぜという話で、参考になる
- 9章 優先順位とエネルギーの管理：これは燃え尽き対策に重要
- 10章 効果的なエンジニアリング組織のためのミーティング：良い話。コミュニケーション計画はいつも悩んでいるので、とても参考になった
- 11章 社内コミュニケーション：これも立場は違えど参考になる。従業員に対してどうコミュニケーションしていくかについて
- 12章 個人と組織のプレゼンスを高める：個人ブランディングの話を含む。著者のブログ論が面白かった
というわけで大変おもしろく、残り後半もしっかりと読んでいきたい。デッドラインは2週間後だ。
エンジニアリング戦略の策定について、前著と本書は何がどう変化したのか
以下は蛇足である。先ほど紹介したとおり エンジニア戦略について著者の考え方が変化しているとあったが、実際のところどう変化したのだろうか。この記事を書くにあたって両方の本を開いたので、ちょっと確認してみた。
「スタッフエンジニア」におけるエンジニアリング戦略の策定
ひとことでいうと、「スタッフエンジニア」におけるエンジニアリング戦略の策定はボトムアップなアプローチである。
「エンジニアリング戦略」を作成するには、5つの「デザイン文書」を書けばいい。その5つに共通する類似点を書き出せば、それがエンジニアリング戦略だ。「エンジニアリングビジョン」を作成するなら、5つの「エンジニアリング戦略」を書いて、それらが2年後にもたらすであろう影響を予測する。それがエンジニアリングビジョンだ。
- スタッフエンジニア マネジメントを超えるリーダーシップ、2章 スタッフとしての役割
なお、興味深いのはこの時点でもルメルトの「良い戦略、悪い戦略」が引き合いに出されている点だ。この本を読んで考え方が変わったというわけではなく、ポジションの変化で変わったという事がわかる。
「エンジニアリング統括責任者の手引き」におけるエンジニアリング戦略の策定
「スタッフエンジニア」ではエンジニアリング戦略の策定はボトムアップに行われていた。しかし本書では一転してトップダウンなアプローチを推奨している。
これらの（引用註：戦略はボトムアップで立てるべきという）主張は戦略の仕組みを誤解しているように思う。戦略はトップダウンでしか採用できないのだから、トップダウンかボトムアップかという問題ではないのだ。問題なのは、戦略を持つか否かだ。戦略の施行に社会的圧力を利用できる小規模でゆっくりと成長する組織を除いて、トップダウンのリーダーシップ（またはその権限を委譲されたグループ）だけが、効果的な戦略に必要な慣行を施行できる。
- エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ、3章 エンジニアリング戦略を立てる より
まあCTOのポジションに立つならば、それはそうだと思う。なお前著で書かれた持論については、上級エンジニアが効果的に仕事を推進するという点においては最適であるというコメントがされている。つまり上位から適切なエンジニアリング戦略が示されなければ、ボトムアップで戦略を立てざるを得ないということなのだろう。
さて、いったんこの記事は終わりにして、続きを読むことにしよう。邪魔が入らなければ、2週間後に後編の記事をポストする予定だ
