『エンジニアリング統括責任者の手引き―組織を成功に導く技術リーダーシップ』

翻訳を担当した書籍『エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ』（オライリー・ジャパン）が2025年6月3日に発売となります。

本書は、2024年3月に出版されたWill Larson著『The Engineering Executive's Primer: Impactful Technical Leadership (English Edition)』（O'Reilly Media）の全訳となります。

エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ

著者は、StripeやUberといった名だたるテック企業でエンジニアリング組織の責任者を歴任し、現在はCartaのCTOを務めるWill Larson氏です。Will Larson氏には、これまでに次の著作があります。

• エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのか
• スタッフエンジニア　マネジメントを超えるリーダーシップ

いずれも、エンジニアリングマネジメント・エンジニアリングリーダーシップを扱った書籍として高い評価を受けています。

氏の3冊目の著作となる本書は、エンジニアリング組織全体の運営に焦点を当てた一冊となっています。戦略立案や人材育成、組織構造の設計など、エンジニアリング組織のトップとしての視点を養い、組織に真のインパクトをもたらすための実践的な知見を学べる内容となっています。

1章　エンジニアリング統括責任者のポジションに就く
    1.1　なぜエンジニアリング統括責任者を目指すのか
    1.2　一点もの
    1.3　現在の会社でエンジニアリング統括責任者のポジションに就く
    1.4　別の会社でエンジニアリング統括責任者のポジションに就く
    1.5　面接プロセス
    1.6　契約交渉
    1.7　オファーを受ける決断
    1.8　ポジションを得られない
    1.9　まとめ

2章　最初の90日間
    2.1　まず何を学ぶべきか
    2.2　適切なシステム変更を行う
    2.3　最初の90日間の作業
    2.4　まとめ

3章　エンジニアリング戦略を立てる
    3.1　戦略の定義
    3.2　戦略例
    3.3　策定プロセス
    3.4　全社戦略が存在しない場合の対処法
    3.5　診断を確立する
    3.6　基本方針を確立する
    3.7　基本方針の視点の高さを保つ
    3.8　首尾一貫した行動を選ぶ
    3.9　戦略はボトムアップで立てるべきでは？
    3.10　まとめ

4章　計画の仕方
    4.1　標準的な計画プロセス
    4.2　計画の3つのフェーズ
    4.3　第1フェーズ：財務計画を立てる
    4.4　第2フェーズ：組織内のリソース配分を決定する
    4.5　第3フェーズ：ロードマップに合意する
    4.6　避けるべき落とし穴
    4.7　まとめ

5章　効果的なバリューを作る
    5.1　バリューはどんな問題を解決するか
    5.2　エンジニアリング組織はバリューを持つべきか
    5.3　効果的なバリューの条件
    5.4　エンジニアリングバリューとエンジニアリング戦略はどう違うか
    5.5　いつ、どのようにバリューを展開するか
    5.6　私が役に立ったと感じたバリュー
    5.7　まとめ

6章　エンジニアリング組織の測定
    6.1　自分のために測定する
    6.2　ステークホルダーのために測定する
    6.3　アプローチの順序
    6.4　アンチパターン
    6.5　まとめ

7章　M&Aへの参加
    7.1　複雑なインセンティブ
    7.2　同じ視点を持つ
    7.3　統合計画を策定する
    7.4　今すぐに異議を唱えよ。さもなくば永遠に沈黙せよ
    7.5　買収される
    7.6　まとめ

8章　リーダーシップスタイルの開発
    8.1　統括責任者に複数のリーダーシップスタイルが必要な理由
    8.2　ポリシーで導く
    8.3　コンセンサスで導く
    8.4　信念で導く
    8.5　リーダーシップスタイルの開発
    8.6　リーダーシップスタイルのバランスを取る
    8.7　まとめ

9章　優先順位とエネルギーの管理
    9.1　「会社、チーム、自分自身」フレームワーク
    9.2　エネルギーの管理はポジティブサム
    9.3　持続可能な互恵関係
    9.4　不整合の反射鏡
    9.5　直交はしているが対立はしていない
    9.6　柔軟性を保つ
    9.7　まとめ

10章　効果的なエンジニアリング組織のためのミーティング
    10.1　ミーティングが必要な理由
    10.2　必要不可欠な6つのミーティング
    10.3　他のミーティングについては？
    10.4　誰がミーティングを運営するか？
    10.5　ミーティングのスケーリング
    10.6　まとめ

11章　社内コミュニケーション
    11.1　随時発信を維持する
    11.2　ブロードキャストする前にテストする
    11.3　パケットを作る
    11.4　短くまとめる
    11.5　あらゆるチャンネルを使う
    11.6　まとめ

12章　個人と組織のプレゼンスを高める
    12.1　ブランドとプレゼンス
    12.2　プレゼンスを築くことはあなたにとって価値があるか？
    12.3　不定期の高品質コンテンツでプレゼンスを演出する
    12.4　プレゼンスの測定は地雷原
    12.5　まとめ

13章　CEO、統括責任者陣、エンジニアリング組織との協働
    13.1　あなたは支持されているか、容認されているか、それとも嫌われているか？
    13.2　暗黙のパワーダイナミクスをかじ取りする
    13.3　ナラティブの架け橋になる
    13.4　過去の経験にとらわれない
    13.5　団結する習慣を育てる
    13.6　変更を少数に絞り込む
    13.7　衝突はあっても良いが、未解決のままにしない
    13.8　同僚のパニックを切り抜ける
    13.9　まとめ

14章　エンジニアリング組織の幹部層を団結させる
    14.1　幹部層の分析と確立
    14.2　幹部層の運営
    14.3　幹部への期待
    14.4　幹部間の争い
    14.5　まとめ

15章　ネットワークの構築
    15.1　ネットワークの活用
    15.2　近道はあるか？
    15.3　ネットワークを構築する
    15.4　他の種類のネットワーク
    15.5　まとめ

16章　同格の統括責任者のオンボーディング
    16.1　同格の統括責任者のオンボーディングが重要な理由
    16.2　統括責任者のオンボーディングとエンジニアのオンボーディング
    16.3　メンタルフレームワークの共有
    16.4　役割を明確にする
    16.5　信頼は時間とともに育まれる
    16.6　どの程度の進歩が可能か
    16.7　まとめ

17章　検証を伴う信頼
    17.1　信頼による管理の限界
    17.2　信頼だけではマネジメント手法とは言えない
    17.3　検証を伴う信頼がより良い理由
    17.4　検証の道具
    17.5　組織に検証を取り入れる
    17.6　まとめ

18章　基準の調整
    18.1　基準のズレがもたらす危険
    18.2　組織の基準に合わせる
    18.3　慎重にエスカレーションする
    18.4　ロールモデルとして振る舞う
    18.5　基準の調整
    18.6　まとめ

19章　エンジニアリングプロセスの進め方
    19.1　プロセス運用の一般的な発展の過程
    19.2　パターンの長所と短所
    19.3　「ベースライン」パターンの運用
    19.4　予算編成の現実に対処する
    19.5　トレンドサイクルのかじ取り
    19.6　まとめ

20章　採用
    20.1　採用プロセスの確立
    20.2　完璧よりも効果的なものを狙う
    20.3　採用の進捗状況と問題点をモニタリングする
    20.4　重要な候補者のクロージングを支援する
    20.5　候補者をレベル付けする
    20.6　報酬の詳細を決定する
    20.7　採用の優先順位を管理する
    20.8　採用責任者をトレーニングする
    20.9　社内やネットワーク内から採用する
    20.10　採用で多様性を高める
    20.11　エンジニアリングブランドを構築する
    20.12　採用委員会を導入すべきか？
    20.13　システムはあなたをサポートするために存在する
    20.14　まとめ

21章　エンジニアリング組織でのオンボーディング
    21.1　現実世界の例
    21.2　オンボーディングの基礎
    21.3　オンボーディングプログラムが失敗する理由
    21.4　会社全体のオンボーディングとの統合
    21.5　オンボーディングを優先するタイミング
    21.6　まとめ

22章　パフォーマンスと報酬
    22.1　相反する目的
    22.2　パフォーマンスと昇進
    22.3　報酬
    22.4　どのくらいの頻度でサイクルを回すべきか
    22.5　完璧を追い求めない
    22.6　まとめ

23章　企業文化診断データの活用
    23.1　企業文化診断結果の読み方
    23.2　企業文化診断に基づいて行動を起こす
    23.3　企業文化診断に用いる質問を変更するタイミング
    23.4　いつ始めるべきか、どのくらいの頻度で実施すべきか
    23.5　まとめ

24章　エンジニアリング統括責任者のポジションを離れる
    24.1　辞める前の引き継ぎ計画
    24.2　去就を決める
    24.3　在任期間の短さをどう考えるか
    24.4　次の職を得てから退職するか、それとも得ずに退職するか
    24.5　CEOに伝える
    24.6　退職パッケージの交渉
    24.7　コミュニケーション計画の確立
    24.8　引き継ぎと実際の退社
    24.9　決断の再検討
    24.10　まとめ

25章　結び

「エンジニアリング統括責任者」という用語・訳語について

タイトルにある「エンジニアリング統括責任者」という用語・表現について、あまり耳馴染みがなく、気になった方もいるかもしれません。翻訳にあたって、本書では原書での「Engineering executive」という用語に対して「エンジニアリング統括責任者」という訳語をあてています。そうした判断をした背景について、ここで説明しておきます。

Executiveという用語は、一般に「役員」と訳されます。日本語で「役員」というと、通常は会社法上の役員すなわち取締役を意味します。しかし、本書はエンジニアリング組織全体の運営に責任を持つ人々に向けて書かれており、必ずしも取締役だけに読者を限定したものではありません。

むしろ、国内の現状だと「執行役員または担当役員（Executive officer、代表取締役または取締役による指名で選ばれた部長以上の役職者）」の範疇にあるような内容も多く含まれています。そのため、訳者としては、そうした読者にも届く訳語を選びたいと考えました。

また、そもそも「役員」という言葉が入ると、どうしても法律上の定義との兼ね合いに気を取られてしまう部分があり、そこから離れて、「エンジニアリング組織のトップ」「エンジニアリング組織の責任者」を端的に表現する訳語を採用する方が、読者がフラットに書籍の内容を受け取りやすくなると考えました。

そうした検討、レビュアーの方々との議論などを経て、最終的に選択したのが「エンジニアリング統括責任者」という訳語になります。耳馴染みがない部分も確かにあるかもしれませんが、自分の仕事を「エンジニアリング統括責任者」だと捉えている方々に本書が届きましたら、訳者としてこの上ない喜びです。

同じ立場に身を置く読者なら、自分との共通点や違いを見つけ、自らの組織における課題や課題解決のヒントを見つける材料として、そうでない読者なら、エンジニアリング統括責任者の役割を理解し、エンジニアリング組織のトップとしての視点を養う材料として、本書は有効な一冊になっていると考えます。

本書が、エンジニアリング組織を運営するという難題に取り組まれている方々にとって有益な手引きになることを願っています。

エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ

エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのか

スタッフエンジニア　マネジメントを超えるリーダーシップ

ソフトウェア設計に関する翻訳書籍の原稿をレビューいただける方を募集します

5/19更新: 数日のうちに、大変たくさんの方々にご応募いただけました。ありがとうございます。募集は終了とさせていただき、結果は選考の上お返事させていただきます

---

2025年秋頃に刊行を予定している翻訳書籍について、翻訳原稿のレビュアーを若干名募集します。翻訳は @snoozer05 が行っています。

翻訳している書籍はVlad Khononov著『Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems』になります。

Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems (Addison-Wesley Signature Series (Vernon)) (English Edition)

書籍紹介より

結合がソフトウェア設計のあらゆる決定にどう影響するかと、それをどうコントロールするかを学ぼう

モジュール化され、進化可能で、回復力のあるソフトウェアシステムを構築したければ、結合を正しく扱わなければならない。あなたが下すあらゆる設計決定が結合に影響し、そして結合は利用可能な設計選択肢を形作る。その重要性にもかかわらず、結合はしばしば相応の注意を向けられることがなかった——これまでは。

ソフトウェア工学の黎明期から、結合の適切な管理がモジュラーソフトウェアシステムの設計において不可欠だったことは間違いない。このトピックは長年にわたって広範囲に研究されてきたが、その知識の一部は忘れ去られ、また一部は現代において適用が困難な状況となっている。本書において、著者のVlad Khononovは、そうした過去の蓄積を活用するだけでなく、それを現代のソフトウェアエンジニアリングプラクティスへと昇華させ、モジュラーソフトウェア設計について新鮮な視点を提供するモデルを構築した。

「結合という用語は、よく使われるにもかかわらず、あまり理解されていない。Vladは「コンポーネントは常に分離すべき」といった単純なスローガンから一歩進んで、複雑性とソフトウェアの進化というコンテキストにおける結合についての深い議論へと私たちを導いてくれる。現代的なソフトウェアを作るのであれば、本書は必読だ」 ——Gregor Hohpe、『The Software Architect Elevator』著者

募集期間は最大で1週間程度(~5/23)としますが、応募状況によっては早めに締め切らせていただきますので何卒ご了承ください。

興味を持っていただける方がいらっしゃいましたら、以下より応募をいただけますと幸いです。

forms.gle

『技術リーダーシップのための14のヒント』

編者を担当した電子書籍『技術リーダーシップのための14のヒント』が、2025年5月1日にオライリー・ジャパンより刊行となりました。オライリー・ジャパンさんのサイトから無料でダウンロードいただけます。

技術リーダーシップのための14のヒント - O'Reilly Japan

本書は、Roy Osherove著『Elastic leadership : growing self-organizing teams』（Manning）の翻訳書籍として2017年に出版された拙訳『エラスティックリーダーシップ : 自己組織化チームの育て方』（オライリージャパン）に、日本語版特典として収録させていただいた日本人執筆者による14のエッセイ部分を、独立した形に再編集したものです。

リーダーに求められる立ち振る舞い、コミュニケーションや情報共有をリードする方法、リーダーと開発者の兼任、チームメンバーが自己組織化するために必要なことなど、技術チームをリードするのに必要な考え方と方法についてのエッセイをまとめた書籍です。 伊藤直也、井原正博、海野弘成、岡島幸男、柄沢聡太郎、栗林健太郎、庄司嘉織、関将俊、たなべすなお、永瀬美穂、平鍋健児、まつもとゆきひろ、吉羽龍太郎の13名による14本のリーダーシップをテーマにしたエッセイを収録しています。 チームに対してリーダーシップを発揮するためのヒントをまとめた本書は、チームリーダーやマネージャーはもちろん、チームでプロジェクトに取り組むすべての方にも読んでいただきたい一冊です。

『Elastic leadership : growing self-organizing teams』は、チームを自己組織化へと導くためのリーダーシップモデルである「エラスティックリーダーシップモデル」の解説と、チームリーダーシップをテーマとした技術リーダーたちによるエッセイからなる書籍です。そうした構成の訳書を日本の読者に届けるのなら、国内の技術リーダーの方たちのエッセイも収録した方が、より楽しく価値の高いものになるのではないかと考え、当時私がぜひこの人のエッセイを読んでみたいと思った方々に声をかけて執筆いただいたのが、本書に収録されているエッセイとなります。

はじめに

1章　リードについて
    関 将俊
2章　チームに成長してもらうためのリーダーシップ
    永瀬 美穂
3章　コミュニケーションメンテナになる
    海野 弘成
4章　困難に立ち向かうチームのリーダーへ
    柄沢 聡太郎
5章　コンセプチュアル・リーダーシップ
    栗林 健太郎
6章　OSS開発のリーダーシップ
    まつもと ゆきひろ
7章　「刀は堂々と抜け」〜兼任リーダーの心得'17
    岡島 幸男
8章　リーダーシップは誰のものか
    たなべ すなお
9章　一緒に成長できるリーダーを育てよう
    庄司 嘉織
10章　採用プロセスについてもっと考えよう
    吉羽 龍太郎
11章　あなたは少なくともあなた自身のリーダーである
    井原 正博
12章　うまくいったらどうなるの
    関 将俊
13章　現場リーダーのための6つの原則
    平鍋 健児
14章　大事な問題にフォーカスする
    伊藤 直也

『エラスティックリーダーシップ : 自己組織化チームの育て方』は残念ながら絶版となってしまったものの、これらのエッセイをそのまま埋もれさせてしまうのはもったいないと考え、オライリー・ジャパンさんと相談や調整などを続け、今回、このような形として改めてお届けできることとなりました。

いずれのエッセイも、チームに対してリーダーシップを発揮していくためのヒントが詰まっており、チームリーダーやマネージャーはもちろん、チームでプロジェクトに取り組んでいる方であれば、ぜひ読んでいただきたい内容となっています。

これらのエッセイが改めて多くの人々の目に触れ、さまざまな場所で新たなリーダーシップが育まれるきっかけになることを願っています。

www.oreilly.co.jp

『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』

監修として関わらせていただいた書籍『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』が、2025年4月28日に翔泳社より刊行となります。

今日行われている、ツールを活用しながらテキストベースで非同期に行う軽量なレビュープロセスは、従来の厳格で重厚なコードインスペクションと区別して「モダンコードレビュー（Modern Code Review：MCR）」と言われます。

モダンコードレビューの代表的な例が、本書が前提としている「プルリクエスト（Pull Request：PR）型のコードレビュー」プロセスです。

モダンコードレビュー、とりわけPR型のコードレビュープロセスは、Michael Faganが提唱したコードインスペクション（ビジネスソフトウェアの開発で元来行われていたソフトウェア開発におけるレビュー手法）よりも、オープンソースソフトウェア（OSS）開発で行われていたパッチレビュープロセスの影響を大きく受けています。

実際、PR型のコードレビュープロセスはOSS開発でまず使われ始めたものであり、プルリクエストという仕組みそのものも、メーリングリストベースで行われていたOSS開発のパッチレビュープロセスが進化したものであるからです。

このようにOSS開発のパッチレビュープロセスの影響を受けているモダンコードレビューには、コードインスペクションと比べ、実施する狙いに次のような違いがあります。

	大枠となるプロセス	実施する狙い
コードインスペクション	品質保証プロセス	コードの欠陥の検出
モダンコードレビュー	チーム開発プロセス	コードベースの品質維持に加え、知識の共有、合意形成、コミュニティ（チーム）形成、代替案の創出

こうした違いから分かるのは、問題の指摘を行えば目的を果たせていた従来のレビューと異なり、私たちが今日行うコードレビューでは、レビューを通じたコミュニケーションがより重要であるということです。

たとえば、モダンコードレビューを研究した論文「Expectations, Outcomes, and Challenges of Modern Code Review」では、コードレビューでレビュー担当者がより効果的に貢献するには、コードの背景、変更の意図、設計の全体像などを理解するためのツールや情報が不可欠であり、開発者間のコミュニケーションを促進する手段も重要であると述べられています。

しかし、今日の多くの開発者は、コードレビューの方法やフィードバックの受け止め方、より良いコミュニケーションの仕方を学ぶ機会がないまま、日々の仕事の中でコードレビューを行っています。

私たちは、より良いコードを書く方法を学ぶのと同様に、より良いレビューの方法も学んでいく必要があります。

そこで、本書『伝わるコードレビュー』です。

本書では、日常のコードレビューで生じがちなさまざまな問題を取り上げ、それがなぜ問題なのか、どう改善すればよいのかを、イメージしやすいエピソードとともに学ぶことができます。

伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書

（以下、書籍紹介分より引用）

コードレビューは、チームで開発するプロダクトの品質を高める重要なプロセスです。しかし、オンライン上のテキストコミュニケーションが基本となるコードレビューでは、「意図が正しく伝わらない」「受け手がネガティブに受け取ってしまう」などのすれ違いが頻発し、手戻りや誤解を生んでしまうことも少なくありません。 本書は、そんな意図や感情のすれ違いを起こさない「伝わるコードレビュー」の技法を解説した書籍です。具体的な19の事例シーンをもとに、わかりやすいプルリクエスト・レビューコメントの書き方や効果的なレビューの進め方を詳しく解説します。 事例シーンは、
・緊張感のあるレビューコメントが返ってきたとき
・説明不足のPRが提出されたとき
・考え方や価値観が食い違ったとき
など、開発現場のコードレビューでよくあるミスコミュニケーションのケースを収録。かわいいキャラクターとともに、問題の原因と対策を整理し、実践的な解決アプローチを提案します。 「レビューのつもりが指摘合戦になってしまう」
「何を伝えたいのかわからないコメントが飛び交ってしまう」
そんな悩みを抱える開発チームにとって、本書はよりよいコードレビューの指針を示すガイドラインになるはずです。レビューの指摘が的確に伝わり、レビューを受ける側も納得感をもって改善できる―そんなスムーズなコードレビューの技法を、本書で身につけましょう。

モダンコードレビューについては、GitHubを用いたフローなど、ツール面から解説された書籍はあるものの、その鍵となるコミュニケーション方法について学ぶための書籍は、英語圏も含めてまだあまり存在しません*1 。

そんな中で、本書はモダンコードレビューにおけるコミュニケーション方法を学ぶための貴重なリソースとなるはずです。本書を通じて、モダンコードレビューにおけるコミュニケーションについての理解や議論が深まることで、さまざまな現場のコードレビューがより良いものになることを願っています。

参考文献:

• オープンソースソフトウェアの育て方
• Expectations, Outcomes, and Challenges of Modern Code Review
• Modern Code Review: A Case Study at Google

伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書

"Looks Good to Me": Constructive code reviews (English Edition)

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド

*1: 2025年3月時点だと、参考になる書籍には、モダンコードレビュープロセス全般を扱った書籍として『"Looks Good to Me"』、コラボレーションプロセスとしての批評を扱った書籍として『みんなではじめるデザイン批評　目的達成のためのコラボレーション&コミュニケーション改善ガイド | 株式会社ビー・エヌ・エヌ』などがあります。

『ソフトウェアアーキテクトのための意思決定術 リーダーシップ／技術／プロダクトマネジメントの活用』

翻訳を担当した書籍『ソフトウェアアーキテクトのための意思決定術　リーダーシップ／技術／プロダクトマネジメントの活用』（インプレス）が明日2024年12月11日に発売となります。

本書は、2023年12月に出版されたSrinath Perera 著『Software Architecture and Decision-Making: Leveraging Leadership, Technology, and Product Management to Build Great Products』（Addison-Wesley Professional）の全訳となります。

ソフトウェアアーキテクトのための意思決定術　リーダーシップ／技術／プロダクトマネジメントの活用

著者は、Apacheのオープンソース開発者として20年以上のキャリアを持ち、Apache Axis2、Apache Airavata、WSO2(Siddhi、Choreo)といったプロダクトのアーキテクチャ策定に携わってきたソフトウェアアーキテクト、Srinath Perera氏です。

本書は、そうした豊富な経験を持つ著者が、ソフトウェアアーキテクチャにかかわる意思決定を効果的に行うために必要な知識や考え方を整理・解説した書籍です。

具体的には、ソフトウェアアーキテクチャにおける意思決定の原則や基本、そしてパフォーマンス、一貫性の保証、セキュリティ、高可用性、スケーラビリティといったソフトウェアアーキテクチャで考えるトピックごとに、知っておくべき前提、原則の適用の仕方、効果的な判断を行うために考えるべきことが学べる内容となっています。

第1章 ソフトウェアリーダーシップ入門
    1.1　判断力が果たす役割 
    1.2　本書の目的 
    1.3　パート1: はじめに 
    1.4　パート2: 最も重要な背景 
    1.5　パート3: システム設計 
    1.6　パート4: すべてをまとめる 
第2章 システム、設計、アーキテクチャを理解する
    2.1　ソフトウェアアーキテクチャとは  
    2.2　システムを設計する方法 
    2.3　5つの質問 
    2.4　7つの原則：包括的なコンセプト 
    2.5　オンライン書店の設計 
    2.6　クラウド向けの設計 
    2.7　まとめ
第3章 システムパフォーマンスを理解するためのモデル
    3.1　計算機システム 
    3.2　パフォーマンスのためのモデル 
    3.3　最適化のテクニック 
    3.4　レイテンシー最適化テクニック 
    3.5　パフォーマンスへの直感的な理解
    3.6　意思決定における考慮事項
    3.7　まとめ
第4章 ユーザーエクスペリエンス（UX）を理解する
    4.1　アーキテクト向けの一般的なUXの考え方 
    4.2　設計のためのUXデザイン 
    4.3　APIのためのUXデザイン 
    4.4　拡張機能のためのUXデザイン 
    4.5　意思決定における考慮事項 
    4.6　まとめ 
第5章 マクロアーキテクチャ：はじめに
    5.1　マクロアーキテクチャの歴史 
    5.2　現代のアーキテクチャ 
    5.3　マクロアーキテクチャのビルディングブロック 
    5.4　意思決定における考慮事項 
    5.5　まとめ 
第6章 マクロアーキテクチャ：コーディネーション
    6.1　アプローチ1：クライアントからフローを駆動する
    6.2　アプローチ2：別のサービスを利用する 
    6.3　アプローチ3：集中型ミドルウェアを使用する 
    6.4　アプローチ4：コレオグラフィを導入する
    6.5　意思決定における考慮事項 
    6.6　まとめ
第7章 マクロアーキテクチャ：状態の一貫性の保持
    7.1　なぜトランザクションなのか 
    7.2　なぜトランザクションを超える必要があるのか 
    7.3　トランザクションを超えていく 
    7.4　ベストプラクティス 
    7.5　意思決定における考慮事項 
    7.6　まとめ 
第8章 マクロアーキテクチャ：セキュリティへの対応
    8.1　ユーザー管理 
    8.2　相互作用のセキュリティ 
    8.3　ストレージ、GDPR、その他の規制 
    8.4　セキュリティ戦略とアドバイス 
    8.5　意思決定における考慮事項 
    8.6　まとめ 
第9章 マクロアーキテクチャ：高可用性とスケーラビリティへの対応
    9.1　高可用性を加える 
    9.2　スケーラビリティを理解する 
    9.3　現代のアーキテクチャのためのスケーリング：基本的なソリューション 
    9.4　スケーリング：取引のツール 
    9.5　スケーラブルなシステムの構築 
    9.6　意思決定における考慮事項
    9.7　まとめ
第10章 マクロアーキテクチャ：マイクロサービスアーキテクチャでの考慮事項
    10.1　決めること1：共有データベースの扱い 
    10.2　決めること2：各サービスのセキュリティ 
    10.3　決めること3：サービス間のコーディネーション 
    10.4　決めること4：依存性地獄の避け方 
    10.5　マイクロサービスの代替としての緩く結合されたリポジトリベースのチーム 
    10.6　意思決定における考慮事項 
    10.7　まとめ 
第11章 サーバーアーキテクチャ
    11.1　サービスの作成 
    11.2　サービスの作成におけるベストプラクティスを理解する 
    11.3　高度なテクニックを理解する 
    11.4　テクニックの実践 
    11.5　意思決定における考慮事項 
    11.6　まとめ 
第12章 安定したシステムの構築
    12.1　システムはなぜ障害を起こすのか。私たちはそれにどう対処できるのか 
    12.2　既知のエラーに対処する方法 
    12.3　一般的なバグ 
    12.4　未知のエラーに対処する方法 
    12.5　グレースフルグラデーション 
    12.6　意思決定における考慮事項 
    12.7　まとめ 
第13章 システムの構築と進化
    13.1　実際にやってみる 
    13.2　設計を伝える 
    13.3　システムを進化させる：ユーザーから学んでシステムを改善していく方法 
    13.4　意思決定における考慮事項 
    13.5　まとめ

本書を書いたモチベーションについて著者は、多くのソフトウェアアーキテクチャの失敗が知識不足ではなく判断力不足、判断の誤りによるものであるにも関わらず、ソフトウェアアーキテクチャの判断、意思決定について学ぶための書籍が十分にないことにあると語っています。

『ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析』（オライリージャパン）や『ソフトウェア設計のトレードオフと誤り ―プログラミングの際により良い選択をするには』（オライリージャパン）、『Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions』（O'Reilly Media）など、近いモチベーションで書かれた書籍も出てきてはいるものの、確かにそうした書籍はまだまだ多くありません。

また、ADR（Architecture Decision Record）に取り組む組織も増えてきており、ソフトウェアアーキテクチャの意思決定については、ますます注目されている／重要性が増してきている状況もあります。

そうした中で、ソフトウェアアーキテクチャにかかわる意思決定についての原則や基本、全体像を、A5判304ページという比較的コンパクトな分量で学べる本書は、これからソフトウェアアーキテクチャという領域にチャレンジされる方々や、より良いアーキテクチャ上の判断を模索されている方々にとって、価値のある一冊になると考えます。

前述の類書と合わせて、本書がソフトウェア開発でより良い意思決定をしていくための一助となると幸いです。

ソフトウェアアーキテクトのための意思決定術　リーダーシップ／技術／プロダクトマネジメントの活用

ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析

ソフトウェア設計のトレードオフと誤り ―プログラミングの際により良い選択をするには

Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions

技術執行役員の仕事に関する翻訳書籍の原稿をレビューいただける方を募集します

10/2更新: 1日しない間に、大変たくさんの方々にご応募いただけました。ありがとうございます。募集は終了とさせていただき、結果は選考の上お返事させていただきます

---

2025年初めに刊行を予定している書籍について、翻訳原稿のレビュアーを若干名募集します。翻訳は @snoozer05 が行っています。

書籍は技術執行役員（あるいはCTOやVPoE、技術統括など）としてエンジニアリング組織をリードする立場になった後に遭遇する課題やそれを乗り越えるためのアプローチ、考え方、スキルについて学ぶ内容となっています。次のような方々を対象とした書籍です:

• 現在エンジニアリング組織を運営する立場にいる方
• これからエンジニアリング組織を運営する立場に就く方
• 技術執行役員の仕事に興味がある方

具体的な書名は募集時点では規約により明かせないため、レビューに参加頂いた方のみにお知らせいたします。悪しからずご理解くださいませ。

募集期間は最大で1週間程度(~10/8)とし、応募状況によってはそれよりも手前で締め切らせていただきます。

興味がある方がいらっしゃいましたら、以下のURLよりぜひご応募をお願いします。

『スタッフエンジニアの道ー優れた技術専門職になるためのガイド』

翻訳を担当した書籍『スタッフエンジニアの道ー優れた技術専門職になるためのガイド』（オライリー・ジャパン）が来週（2024年8月26日）発売となります（電子書籍はオライリー・ジャパンのサイトでの販売となります）。本書は、2022年にO'Reilly Mediaより刊行されたTanya Reilly著『The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change』の全訳となります。

スタッフエンジニアの道 ―優れた技術専門職になるためのガイド

本書は、技術専門職としてのキャリア成長に必要な考え方やスキルを、20年を超えるキャリアを持ち、現在も現役で上級技術専門職を務めている著者が、自身の経験をもとに整理・解説した書籍です。

具体的な目次は次のようになっています。

第I部　大局的な思考

1章　では、具体的に君はここで何を？
    1.1　スタッフエンジニアとは一体何なのか？
    1.2　ご高説ごもっとも。で、私の仕事は何？
    1.3　役割を理解する
    1.4　スコープ、形状、重点事項を一致させる
    1.5　まとめ

2章　3つの地図
    2.1　あれ、誰か地図は持ってきた？
    2.2　ロケーターマップ：観点を手にいれる
    2.3　トポグラフィックマップ：地形を学ぶ
    2.4　トレジャーマップ：向かう先は？
    2.5　あなた自身の旅
    2.6　まとめ

3章　全体像を描く
    3.1　シナリオ：SockMatcherには計画が必要です
    3.2　ビジョンとは何か？ 戦略とは？
    3.3　働きかけ
    3.4　作成
    3.5　ローンチ
    3.6　ケーススタディ：SockMatcher
    3.7　まとめ

第II部　実行

4章　限りある時間
    4.1　全部やる
    4.2　時間
    4.3　リソース制約
    4.4　プロジェクトを選ぶ
    4.5　まとめ

5章　大規模プロジェクトをリードする
    5.1　プロジェクトのライフサイクル
    5.2　プロジェクトの始まり
    5.3　プロジェクトの推進
    5.4　まとめ

6章　なぜ止まってしまったか？
    6.1　プロジェクトが動いていない。動かすべき？
    6.2　あなたは迷子
    6.3　たどり着いた……どこに？
    6.4　まとめ

第III部　レベルアップ

7章　今はあなたがロールモデル（お気の毒さまながら）
    7.1　良い仕事をするとはどういう意味？
    7.2　有能であること
    7.3　責任ある行動を取ること
    7.4　目的を忘れないこと
    7.5　先を見据えること
    7.6　まとめ

8章　良い影響力を広げる
    8.1　良い影響力
    8.2　アドバイス
    8.3　教育
    8.4　ガードレール
    8.5　機会
    8.6　まとめ

9章　この先は？
    9.1　あなたのキャリア
    9.2　現在の役割
    9.3　ここからの道のり
    9.4　リセットする準備
    9.5　選択が重要
    9.6　まとめ

スタッフエンジニアについて

スタッフエンジニアの「スタッフ（staff）」は、軍事用語における「参謀（staff）」を指します。

参謀 - Wikipedia

参謀（さんぼう、独: Stab、英: staff、仏: État-Major）とは、作戦・用兵などに関して計画・指導にあたる将校 ...（略）... 軍隊において部隊の指揮系統は単一であるために、あらゆる決心は指揮官が単独で行う。しかしながら高級指揮官は軍事作戦を指揮統制するために処理すべき情報や作業が膨大なものとなる。これを組織的に解決するために参謀組織が情報収集、情報処理などの面で高級指揮官を補佐することとなる。そのために指揮官に対する発言権は認められていたとしても、部隊の指揮権は持たない。

こうした役割を求められるスタッフエンジニアという具体的な職も存在する一方、シニアよりも上位の技術専門職（インディビジュアルコントリビューター, IC）には、一定こうした役割が期待されます。そのため、職位としてのスタッフエンジニアと区別して、こうした働きが求められるシニア以上の技術専門職をまとめた総称として「スタッフ+（スタッフプラス）」という呼称も出てきています。

本書は、ソフトウェアエンジニアリングの専門家として、組織やビジネスを現場から独立した形で支えることが期待される、そうした上級技術専門職に求められる考え方やスキルを解説した書籍です。

『スタッフエンジニア』との差分

スタッフエンジニア、スタッフプラスの役割を解説した書籍としては、もう一冊、Will Larsonの『Staff Engineer: Leadership beyond the management track』（邦訳『スタッフエンジニア：マネジメントを超えるリーダーシップ』）が存在します（本書の著者であるTanya Reillyが序文を書いています）。

スタッフエンジニア　マネジメントを超えるリーダーシップ

ソフトウェアエンジニアが、マネジャーやCTOといったマネジメント職に進むのではなく、技術力を武器にテクニカルリーダーシップを発揮して、エンジニアリング職のキャリアパスを登っていくための「指針」と「あり方」を示します。

Will Larson自身はスタッフエンジニアではなくマネージャーであり、Will Larsonの方の書籍は、実際のスタッフエンジニアへのインタビューなども含め、スタッフエンジニアの仕事を外側から整理した書籍となっています。

一方、本書『スタッフエンジニアの道』の著者であるTanya Reillyは長いキャリアを持つ現役のスタッフエンジニアであり、本書はスタッフエンジニアの仕事を内側から整理した書籍となっています。

両方の書籍に目を通すことで、スタッフエンジニアという役割がより立体的に理解できると考えます。

『エンジニアのためのマネジメントキャリアパス』との関係

本書の序文は『エンジニアのためのマネジメントキャリアパス』（オライリージャパン）のCamille Fournierが執筆しています。

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

本書は、技術系マネージャーとそれを目指すエンジニアに向けて、IT業界の管理職に求められるスキルを解説する書籍です。テックリードからCTOになった経験を持つ著者が、管理職についたエンジニアが歩むキャリアパスについて段階をおって紹介します。インターンのメンターから始まり、テックリード、チームをまとめるエンジニアリングリード、複数のチームを管理する技術部長、経営にかかわるCTOやVPと立場が変わることによって求められる役割について、それぞれの職務を定義しながらくわしく説明します。

経緯は序文に詳しいですが、『エンジニアのためのマネジメントキャリアパス』の原書のタイトルは『The Manager's Path』、本書のタイトルは『The Staff Engineer's Path』となっており、両者は姉妹本の関係にあります。

エンジニアリングのトラックに進むのか、マネジメントのトラックに進むのか。それぞれの書籍は、自身の今後のキャリアを考えるヒントになってくれます。今後のキャリアについて考えている/ 考えたいという方は両方に目を通してみると、良いキャリアパスのヒントが得られると考えます。

まとめ

多くの研究や文献が存在するマネジメント職と異なり、技術専門職のキャリアを進める際に参照できる情報はまだまだ多くありません。

日本国内でも、昨年（2023年）にWillの書籍の訳書が出版され、スタッフエンジニアという役割についての理解が少しずつ広まりつつあります。そこに本書も加わることで、国内でも上級技術専門職の仕事や役割への理解、そしてエンジニアリングリーダーシップについての議論がますます深まっていくことと思います。

本書が、エンジニアリングリーダーシップの道を進んでいく方々にとって有益なガイドになることを願っています。

「エブリン……何してる？」

「あなたの戦い方を学んでいる」

映画『Everything Everywhere All at Once』より