エンジニアリング組織開発の執筆
この度、技術評論社よりエンジニアリング組織開発を出版させていただきました。 出版に関わって頂いた皆様、特に校正で大変お世話になった担当編集者様、組版担当者様に感謝申し上げます。
元々、本のタイトルは「開発組織開発」（開発組織と組織開発を掛け合わせた造語）で考えていました。
個人的にはシャレが効いていて気に入っていたのですが、率直なフィードバックとして「分かりづらい」という声もあり、現在の「エンジニアリング組織開発」という形に落ち着きました。
「Engineering Organization Development」という英語部分にもその名残が見られます1。
表紙のデザインも気に入っており、落ち着いていてなおかつ格好良いものをご提案頂けました。
完全に個人として執筆しているため、純粋に個人的な好みでデザイン案を選んでいたのですが、表紙のカラーが Belong のコーポレートカラーに近いことはデザインを決めてから気づきました。
この一冊には、私のエンジニアとしてのキャリアを通じて学んできたことが、惜しみなく詰まっています。 具体的には、エンジニアリング組織を率いるためのリーダーシップ、ピープルマネジメント、プロダクト開発のプロセス設計と運用プラクティス、開発ガバナンスといった多岐にわたるテーマを網羅しています。
これまでのキャリアを振り返ると、Goldman Sachs では、プロフェッショナルとしてのソフトウェア開発マインドセットや、 統制のとれた SDLC（ソフトウェア開発ライフサイクル）のあり方を学びました。 続く Google では、「プラネットスケール」と呼ばれる規模でのサービス運用経験を通じて構築されたクラウド環境の裏側や（なお私が構築に携わったわけではない）、 その上でサービスを開発するプラクティス、SRE（Site Reliability Engineering）を含むプロダクトの運用・サポート体制について深く学びました。 これらの組織は文化こそ異なれど、開発体制構築において重視する要点は驚くほど近しく感じられました。 こういった環境で働く中で、仕組みの意図を抽出・整理することで、開発組織にとって本質的に重要なことを学び、審美眼を養うことができたと考えています。
そして、Belong の CTO として、それまでの学びを基盤に、自身でゼロから組織を構築する機会を得ました。 ただし、グローバルで成功している企業とは異なり、ヒト・モノ・カネといったすべてのリソースが限られている状況下での実行が求められました。 この制約の中で、より現実的かつ、規模の小さな企業でも実現可能な方法論や考え方を培うことができました。
本書には、そうした経験から得られたエッセンスが詰まっています。
執筆にあたって、私が考えていたこと
以前から、私は本の執筆に興味を持っていました。 特に自身の 20 代は、多くの先人たちの知見（巨人の肩）に立つことで成長させていただきました。 いつかは自分も、そのようなアウトプットを生み出し、コミュニティに貢献したいという強い思いがありました。
本を書くなら、トム・デマルコ2やジェラルド・ワインバーグ3、Uncle Bob（Robert C. Martin）4といった 著名な著者らの諸書籍や、 『人月の神話』、若かりし頃の私のバイブルだった『達人プログラマ』のように、 時代を超えて読み継がれる、年月を経ても色褪せない普遍的な価値を持つものを書きたいと考えていました。 非技術書であれば、『考える技術・書く技術』、『ロジカルシンキング』、『イシューからはじめよ』となどが私にとってのそれに当たります。
これらの書籍は、当時のトレンドや特定の技術フレームワーク、小手先のテクニックに終始するのではなく、
5 年、10 年経っても参考になるような「本質」を含んだものだと感じています。
代々先輩から後輩に「とりあえずこれは読んでおけ」と伝えられるような、
そうした普遍的なエッセンスを、自身の書籍でも表現したいという気持ちがありました。
『エンジニアリング組織開発』には、長期的に成長を続ける組織に必要だと私が考えている要素を詰め込んでおり、 読者の皆様にとっても、「普遍的な価値」を持つ一冊になれているのではないかと、親バカ的に考えています。
執筆中、AI を活用した開発が市民権を得て、物事の進め方やスピードが急激に変化していく様子を目の当たりにしましたが、本書ではあえてその点には触れていません。 本書で述べている仕組みの「構築の主体」の多くは、将来的には人から AI に取って代わられる可能性があります。 その一方で、本書で触れている、サステナブルなエンジニアリング組織体制を構築するために「何を行うべきか」という部分は、主体が人であれ AI であれ、変わらず必要とされる本質的な要素だと考えているためです。
本書では、開発プロセスやプロダクトの構築論について、基礎的な部分に焦点を当てています。 これは、応用は基本概念の理解なくしては難しいという考えに基づいています。 基本をしっかりと抑えることが、あらゆる実践への近道であり、応用はすぐにキャッチアップ可能であると信じています。
プロダクト運用の部分では、レイヤードサポートモデルの考え方や、実践的なインシデントマネジメントの方法などに触れており、 外資系テック企業がよく取る手法だが、あまり言語化されていない部分に踏み込めたのではないかと考えています。 （特に若い）エンジニアは、開発手法や使用するツールに目が行きがちですが、「本番環境」というように、作って運用してからが真の勝負です。 本書では、運用時の考慮事項や、問題発生時の適切な所作など、リアルな現場で役立つポイントを数多く盛り込むことを意識しました。
こういった背景から、この本は、「ひとつのエンジニアリング組織に一冊はあっても良い」 仕上がりになったと自負しております （もちろん、一人一冊手に取っていただけると、著者としてはこれ以上嬉しいことはありません！）。;)
エンジニアリング統括責任者の手引きとの相互補完性
この本の執筆中、2025 年 4 月に エンジニアリング統括責任者の手引き という本が 6 月頃に出ることを知り、思わず担当編集者さんへ連絡しました。 『スタッフエンジニア』や『エレガントパズル』を執筆した Will Larson が、ターゲット読者層が重なりそうな本を先行して出版されるという状況になったためです。 目次を眺めた際に、「これは面白そうだ」と感じたことを覚えています。
『エンジニアリング統括責任者の手引き』（以下、Primer）を読んでみて、本書『エンジニアリング組織開発』（以下、EOD）とは補完関係にあることに気づきました。 それぞれが触れていないトピックがあり補完しあうという意味もありますが、 Primer では抽象度高く示されている「方向性」について、EOD ではより具体的な「中身」を提示している箇所がある点に気づいたのです。 また逆に、EOD で一部の具体例を示しているトピックについて、Primer では他の考え方も含めて、より広範な方向性を示している部分もありました。 そのため、いずれかの本に興味を持たれた読者層は、もう片方の本も読むことで、より深い理解を得られるはずです。
Primer の「リーダーシップスタイルの開発」における「ポリシーで導く」という内容や、 意思決定の方法論で「トップダウン」「ボトムアップ」「ハイブリッド」といったトピックは、EOD でも触れており、 主張が重なる部分も見つけましたが、こういった共通点があるということは、逆に「この本に記した内容はやはり間違っていない」という自信にもつながりました。
おわりに
この本を執筆する過程は、これまでの自身の歩みを振り返るとともに、うまくいっている点、そして「もっとこうすればよかった」と改善点を見つめ直す、まさに学びの連続でした。
組織のリーダーは、現実には正解のない状況下で、「ものを決める」というストレスフルな行為に日々向き合い続けなければなりません。
本書が、すでにそのような役割を担っている方々、そしてこれからその立場になる方々の一助となれば幸いです。
また、エンジニアなど意思決定の「フォロワー」として、
経営者など組織のミッションを委譲する「スポンサー」として、開発組織のリーダーたちの傍らにいる皆様にも、物事がどのような思惑で決定されているのかを理解し、
リーダーたちをより効果的にサポートしていただけるようになることを願っています。
ぜひ、本書を手に取って、エンジニアリング組織開発の奥深さに触れていただければ幸いです。
P.S. 本の書き方などの学びもあったので、別途ブログを書きたいと思います。