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

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


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

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

書籍紹介より

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

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

ソフトウェア工学の黎明期から、結合の適切な管理がモジュラーソフトウェアシステムの設計において不可欠だったことは間違いない。このトピックは長年にわたって広範囲に研究されてきたが、その知識の一部は忘れ去られ、また一部は現代において適用が困難な状況となっている。本書において、著者の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 。

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

参考文献:

*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 Axis2Apache Airavata、WSO2(SiddhiChoreo)といったプロダクトのアーキテクチャ策定に携わってきたソフトウェアアーキテクト、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ページという比較的コンパクトな分量で学べる本書は、これからソフトウェアアーキテクチャという領域にチャレンジされる方々や、より良いアーキテクチャ上の判断を模索されている方々にとって、価値のある一冊になると考えます。

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

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

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が執筆しています。

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

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

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

まとめ

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

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

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

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

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

映画『Everything Everywhere All at Once』より

『Ruby on Railsパフォーマンスアポクリファ』

翻訳を担当した電子書籍Ruby on Rails パフォーマンスアポクリファ』が発売となりました。 書籍は以下から購入できます。

Ruby on Rails パフォーマンスアポクリファ

本書は、2020年に出版されたNate Berkopec著『The Ruby on Rails Performance Apocrypha』の全訳です。原書は訳書と同様、著者の販売サイトで自主出版の電子書籍として出版され、現在はKindleストアでも販売されています。

The Ruby on Rails Performance Apocrypha

本書は、Nateがニュースレター「Speedshop Ruby Performance Newsletter」に公開してきた記事を編集してまとめたものです。Nateが注力し続けている Ruby on Rails アプリケーションのパフォーマンスやスケーリングの話題、ソフトウェアパフォーマンスの一般原則、RubyについてのNateの考えなどがまとめられてます。具体的な目次は次のようになっています。

第1章 原則
1.1  私が大切にしていること
1.2  パフォーマンスの科学
1.3  なぜパフォーマンスか? 
1.4  あなたはコンパイラではない
1.5  10%の高速化が本当に意味すること
1.6  Rails アプリケーション向けのベンチマーク
1.7  自分用のAPMを作る
1.8  フレームグラフを読む
1.9  DRM(データベース、Ruby、メモリ) 
1.10 デザイン空間におけるパフォーマンス 
1.11 マイクロサービスとトレンド 
1.12 Minitestについて 
1.13 Rubyに対する企業のサポート
1.14 なぜRubyは遅いのか?
1.15 人気 
1.16 臭い依存関係 
1.17 なぜキャッシュするのか? 
1.18 スタートアップにおけるソフトウェア品質

第2章 フロントエンド
2.1  簡単なフロントエンドの設定変更
2.2  常にCDNを使用する
2.3  ページ容量とフロントエンドの読み込み時間
2.4  遅延読み込みを簡単に
2.5  リソース優先順位付けとは何か
2.6  HTML ON THE WIRE
    
第3章 Ruby
3.1  例外:静かでもタダではない
3.2  スレッドセーフについて
3.3  GVLとは
3.4  GVLを時分割する
3.5  GVLとC
3.6  肥大化
3.7  最低限必要なRails
3.8  誰も使わなかった奇妙な設定
3.9  オブジェクト割り当て
3.10  常に本番用プロファイラを使用する
3.11  ローカル環境で問題を再現する
3.12  ワーカーキラー
3.13  クエリーキャッシュとは?
3.14  NewRelicのRubyVMタブを読む
3.15 テストセットアップ

第4章 スケール
4.1  消費時間とは
4.2  リクエストキュー時間
4.3  アムダールの法則
4.4  スレッド数
4.5  CPU律速かIO律速か?
4.6  スワップとは何か
4.7  データベースプール
4.8  シングルスレッド性能
4.9  リードレプリカ
4.10  なぜLambdaなのか?
4.11  Performance-Mは決して使わない
4.12  日次での再起動

本書はニュースレターに書かれてきた記事が元になっているため、Railsのパフォーマンスに関して体系的にまとめた書籍というよりも、パフォーマンスをテーマとした技術エッセイ集的側面の強い一冊に仕上がっています。しかしながら、そうした技術エッセイ集的な読み心地には、なんとも言えない「良さ」を感じます。

かつては、『ハッカーと画家 コンピュータ時代の創造者たち』(オーム社)や『BEST SOFTWARE WRITING』(翔泳社)、『プログラマが知るべき97のこと』(オライリージャパン)をはじめとする『〜が知るべき97のこと』シリーズなど、ソフトウェア技術者によるエッセイ集が多く出版されていた時期があり、技術書としても人気を博していました。

Rubyに関わりが深い著者による同系統の書籍として、『達人プログラマー ―熟達に向けたあなたの旅― 第2版』(オーム社)や『情熱プログラマー ソフトウェア開発者の幸せな生き方』(オーム社)などを思い浮かべる方も多いのではないでしょうか。こういったエッセイ集から私たちが学んでいたのは、単なる新しい技術や知識というよりも、ソフトウェア技術者としての哲学や心構え、考え方でした。

しかし、ブログブームの終焉や出版業界の状況なども相まってか、昨今はこうした書籍を商業出版で見かける機会は減ってしまいました。

そういった状況の中で本書を読み、訳者が久々に感じたのは、上記のような書籍を読んでいたときに感じていた「良さ」に似た味わいでした。

本書は、Web(特にRailsによるWebアプリケーションによるWebアプリケーション)のパフォーマンスについての書籍ですが、それと同時に、Nateというソフトウェア技術者の考え方や哲学に触れることで、私たち自身のソフトウェア技術者としての考え方を深めたり、普段の開発への取り組み方を見つめ直したりするきっかけになる書籍でもあります。

本書を通じ、一人でも多くの方に、訳者が感じた原書の味わいが届けられればと願っています。

Ruby on Rails パフォーマンスアポクリファ


Nateは、現在は日本に暮らしており、日本語での情報発信も積極的に行なっています。 本書を気に入られた方、気になった方は、ぜひ彼の活動に触れてみてください。