『シンプリシティ―持続可能かつ人間的で効果的なソフトウェア開発』

翻訳を担当した書籍『シンプリシティ―持続可能かつ人間的で効果的なソフトウェア開発』（オライリー・ジャパン）が6月2日に発売されます。本書は、2025年7月に出版されたDave Thomas著『Dave Thomas. simplicity: sustainable, humane, and effective software development. Pragmatic Bookshelf』（Pragmatic Bookshelf）を全訳したものです。

シンプリシティ ―持続可能かつ人間的で効果的なソフトウェア開発

著者であるDave Thomasは、古典的名著として長く読み継がれてきた『達人プログラマー ―熟達に向けたあなたの旅― 第2版』の共著者、さまざまな良質な技術書を継続的に世に送り出してきたPragmatic Bookshelfの共同創設者、そして、現代のソフトウェア開発における価値観を方向づけたアジャイルソフトウェア開発宣言の署名者の一人として知られる人物です。また、RubyやElixirの普及への貢献、DRYやコードカタといった考え方の提唱者としても知られ、現代のソフトウェア開発に大きな影響を与えてきた人物の一人と言えます。

そんなDave Thomasが、改訂ではない書き下ろしとして11年ぶりに刊行したのが、本書『シンプリシティ』です。

本書は、私たちが自ら招き込んでしまいがちな「偶有的な複雑さ」を減らし、日々のソフトウェア開発を持続可能で人間的なものに保つことを、Dave の実践を通して学ぶ一冊となっています。

そうした偶有的な複雑さを減らすため、本書では Dave が大事だと考える 51 のアイデアが、29 のプラクティスを通して紹介されています。テクニック集というよりは、日々の仕事に対する「構え」の本であり、『達人プログラマー』の現代的な語り直しといった趣もある一冊です。

達人プログラマー ―熟達に向けたあなたの旅― 第2版

Dave は繰り返し「真似するな、自分の道を見つけてほしい」と書きます。本書は手順書というよりは、自分にとって「しっくりくる」形を見つけるための、考え方の本です。そのために本書が掲げるアプローチが「Orient, Step, Learn」（方向を見定め、一歩進み、そこから学ぶ）という、地に足のついた小さなフィードバックループです。

そんな本書は、「やることとやり方をシンプルにする」「環境をシンプルにする」「やり取りをシンプルにする」「コードをシンプルにする」という4つのパートから構成されます。

本書の具体的な目次は次のとおりです。

もう一度、世界を変えよう

1章　シンプリシティへのアプローチ

第I部　やることとやり方をシンプルにする

2章　今すぐ減量を
    プラクティス1　不健全な依存関係を削減する
    プラクティス2　フレームワーク：成分表をよく読む
    プラクティス3　作らずに済んだ機能こそ最高の機能

3章　プロジェクトをシンプルにする
    プラクティス4　チームを疎結合にする
    プラクティス5　ミーティング、いまいましいミーティング
    プラクティス6　作法：ミーティングを開かなければならない場合
    プラクティス7　スキルを広げる
    プラクティス8　情報を自由に解き放つ

第II部　環境をシンプルにする

4章　あらゆるものを自動化する
    プラクティス9　デスクトップをあなたのために働かせる
    プラクティス10　ターミナルをあなたのために働かせる
    プラクティス11　他のすべてを自動化する
    プラクティス12　エディタを自分のものにする
    プラクティス13　開発マシンのセットアップを自動化する

5章　「変化を抱擁せよ」
    プラクティス14　実用的なものと趣味的なものを混ぜ合わせる
    プラクティス15　未来で遊び、過去で働く

第III部　やり取りをシンプルにする

6章　ソフトスキル
    プラクティス16　意見の相違はゼロサムゲームではない
    プラクティス17　共感力を鍛える
    プラクティス18　モノへの共感を持つ
    プラクティス19　物語を紡ぐ

第IV部　コードをシンプルにする

7章　データ駆動
    プラクティス20　データに駆動させる
    プラクティス21　テーブルを使ってテストをシンプルにする
    プラクティス22　ステートマシンでロジックをシンプルにする

8章　コードの現場で
    プラクティス23　ノーコメント
    プラクティス24　TODOすべきか、今すべきか、それが問題だ
    プラクティス25　並べる
    プラクティス26　カンマをぶら下げる
    プラクティス27　ソート
    プラクティス28　縦長は横長に勝る
    プラクティス29　ローカルに保つ

9章　おわりに

では、Daveはなぜ、こうした「構え」を説く本を書いたのでしょうか。

Daveは、アジャイルなソフトウェア開発の方法論を世に広めた第一人者の一人です。ですが近年は、固定化しやすい方法論や組織論そのものよりも、一人ひとりが変化のなかで学び、調整しながら動けるようになること、そしてそのための考え方やアプローチのほうが大切だと説くようになっています。

その最もプリミティブな実践が、「自分にとってしっくりきているか」という感覚を手がかりに、物事をシンプルにしていくこと、つまり本書なのです。

本書の最後で、Daveはこう書いています。「コードを、コーディングを、できれば人生さえも、もう少しシンプルにしてみてほしい」。そして、こう続けます。

You deserve that.（あなたにはそうなるだけの価値がある）

シンプルさも、楽しさも、苦しんで勝ち取るものではなく、もともと受け取っていいもの。本書の副題にある「humane（人間的）」の持つ意味が、ここに表れていると訳者は感じます。

本書が、読んでくださった方々のコードを、仕事を、そして働く時間そのものを、より人間的で、いきいきとしたものにしていくための支えとなることを願っています。

シンプリシティ ―持続可能かつ人間的で効果的なソフトウェア開発

達人プログラマー ―熟達に向けたあなたの旅― 第2版

『プログラミングRuby 第5版』の翻訳原稿をレビューいただける方を募集します

『Programming Ruby 3.3(5th Edition)』の訳書『プログラミングRuby 第5版』について、翻訳原稿のレビュアーを若干名募集します。翻訳は島田浩二（ @snoozer05 ）が行っています。

書籍およびプロジェクトの詳細は、こちらを参照願います:

snoozer05.hatenablog.jp

レビュー期間は2026年4月下旬から1.5ヶ月程度（2026年6月中旬くらいまで）を予定しております。

全体はPDF換算で約820ページ程ありますが、興味のあるトピックを中心に、全体の25%程度(200ページぶんぐらい)には目を通していただけたらと考えています。もちろん、それを超えてたくさん見ていただくのは大歓迎です :-)

日本語としての読みやすさ、わかりやすさ、Rubyの最新バージョンとの差異などについてフィードバックをいただければと考えていますので、ぜひ助けていただけると嬉しいです。

興味を持っていただけた方は、以下に記載する要項にお目通しいただいたうえで、フォームに必要項目を記入のうえ、ご応募くださいますようよろしくお願いいたします。

https://docs.google.com/forms/d/e/1FAIpQLScIKjxBMor3-WnhetP3nKEc9NTtn-jf16No0u8gZsLVebdSgw/viewform?usp=dialog

また、スポンサーしてくださる個人・団体様も引き続き募集しております。ご支援の方も何卒お願いいたします。

www.snoozer05.org

『ソフトウェアアーキテクチャの基礎 第2版 ― エンジニアリングに基づく体系的アプローチ』

翻訳を担当した書籍『ソフトウェアアーキテクチャの基礎 第2版 ― エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン）が3月6日に発売されます。本書は、2025年4月に出版されたMark Richards, Neal Ford著『Fundamentals of Software Architecture, 2nd Edition』（O'Reilly Media）を全訳したものです。

ソフトウェアアーキテクチャの基礎 第2版 - O'Reilly Japan

本書について

本書は、ソフトウェアアーキテクチャという分野が持つ多様な側面を現代的な視点から整理し、その基礎を詳しく解説した書籍です。本書の第1版は、2020年（邦訳は2022年）の刊行以来、国内外で高く評価され、ソフトウェアアーキテクチャに入門するための定番書としての地位を築いています。

本書の概要について詳しくは、第1版の邦訳刊行時に書いた次の記事をご覧ください。

『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』 - snoozer05's blog

第2版での改訂について

第1版の刊行から5年が経過し、ソフトウェア開発の前提は大きく変化しました。アーキテクチャが時代とともに進化するように、本書もまた、著者らの新たな知見とこの間の技術的潮流を取り込み、大幅な改訂が行われています。

具体的には、クラウド活用、データアーキテクチャ、ガバナンス、チームトポロジー、生成AIなど、この数年で重要性を増したトピックが加わりました。加えて、もともとあった内容も全体的に深掘りされ、構成も再整理されています。分量も第1版の約430ページから約560ページへと大きく増え、読み応えのある一冊になっています。

『ソフトウェアアーキテクチャの基礎』第1版と第2版の厚さの比較画像です pic.twitter.com/0UcafsCV0B

— Koji Shimada / 島田浩二 (@snoozer05) 2026年3月4日

第2版の目次は次のようになっています。

本書への推薦の言葉
はじめに

1章　イントロダクション
    1.1　ソフトウェアアーキテクチャの定義
    1.2　ソフトウェアアーキテクチャの法則
    1.3　アーキテクトへの期待
        1.3.1　アーキテクチャ決定を下す
        1.3.2　アーキテクチャを継続的に分析する
        1.3.3　最新のトレンドを把握し続ける
        1.3.4　決定の順守を徹底する
        1.3.5　多様な技術に触れ、経験している
        1.3.6　ビジネスドメインを理解している
        1.3.7　対人スキルを持ち合わせている
        1.3.8　政治を理解し、かじ取りする
    1.4　本書の構成

第I部　基礎

2章　アーキテクチャ思考
    2.1　アーキテクチャと設計
        2.1.1　戦略的な決定と戦術的な決定
        2.1.2　労力の度合い
        2.1.3　トレードオフの重要性
    2.2　技術的な幅
        2.2.1　20 分ルール
        2.2.2　パーソナルレーダーの開発
    2.3　トレードオフを分析する
    2.4　ビジネスドライバーを理解する
    2.5　アーキテクティングとコーディングのバランスを取る
    2.6　アーキテクチャ思考はもっと広い

3章　モジュール性
    3.1　モジュール性と粒度
    3.2　モジュール性の定義
    3.3　モジュール性の測定
        3.3.1　凝集度
        3.3.2　結合度
        3.3.3　コアメトリクス
        3.3.4　主系列からの距離
        3.3.5　コナーセンス
    3.4　モジュールからコンポーネントへ

4章　アーキテクチャ特性
    4.1　アーキテクチャ特性とシステム設計
    4.2　アーキテクチャ特性の（部分的な）リスト
        4.2.1　運用アーキテクチャ特性
        4.2.2　構造アーキテクチャ特性
        4.2.3　クラウドアーキテクチャ特性
        4.2.4　横断的アーキテクチャ特性
    4.3　トレードオフと最も現実的なアーキテクチャ

5章　アーキテクチャ特性を明らかにする
    5.1　ドメインの関心事からアーキテクチャ特性を捉える
    5.2　複合アーキテクチャ特性
    5.3　アーキテクチャ特性を導き出す
        5.3.1　カタを使う
    5.4　事例：シリコンサンドイッチ
        5.4.1　明示的なアーキテクチャ特性
        5.4.2　暗黙的なアーキテクチャ特性
    5.5　アーキテクチャ特性の制限と優先順位付け

6章　アーキテクチャ特性の測定と統制
    6.1　アーキテクチャ特性の測定
        6.1.1　運用アーキテクチャ特性の測定
        6.1.2　構造アーキテクチャ特性の測定
        6.1.3　プロセスアーキテクチャ特性の測定
    6.2　統制と適応度関数
        6.2.1　アーキテクチャ特性の統制
        6.2.2　適応度関数

7章　アーキテクチャ特性のスコープ
    7.1　アーキテクチャ量子と粒度
    7.2　同期通信
    7.3　スコープの影響
        7.3.1　スコープとアーキテクチャスタイル
        7.3.2　カタ：Going Green
    7.4　スコープの決定とクラウド

8章　コンポーネントベース思考
    8.1　論理コンポーネントの定義
    8.2　論理アーキテクチャと物理アーキテクチャ
    8.3　論理アーキテクチャの作成
        8.3.1　核となるコンポーネントを識別する
        8.3.2　コンポーネントにユーザーストーリーを割り当てる
        8.3.3　役割と責務の分析
        8.3.4　アーキテクチャ特性の分析
        8.3.5　コンポーネントの再構成
    8.4　コンポーネントの結合
        8.4.1　静的結合
        8.4.2　一時的結合
        8.4.3　デメテルの掟
    8.5　事例：「Going, Going, Gone」におけるコンポーネントの発見

第II部　アーキテクチャスタイル

9章　基礎
    9.1　スタイルとパターン
    9.2　基礎的なパターン
        9.2.1　巨大な泥団子
        9.2.2　ユニタリーアーキテクチャ
        9.2.3　クライアント／サーバー
    9.3　アーキテクチャの分割
        9.3.1　カタ：シリコンサンドイッチにおける分割
    9.4　モノリシックアーキテクチャと分散アーキテクチャ
        9.4.1　誤信1：ネットワークは信頼できる
        9.4.2　誤信2：レイテンシーがゼロ
        9.4.3　誤信3：帯域幅は無限
        9.4.4　誤信4：ネットワークは安全
        9.4.5　誤信5：トポロジーは決して変化しない
        9.4.6　誤信6：管理者は一人だけ
        9.4.7　誤信7：転送コストはゼロ
        9.4.8　誤信8：ネットワークは均一
        9.4.9　その他の誤信
    9.5　チームトポロジーとアーキテクチャ
    9.6　特定のアーキテクチャスタイルへ

10章　レイヤードアーキテクチャ
    10.1　トポロジー
    10.2　スタイルの詳細
        10.2.1　レイヤーの分離
        10.2.2　レイヤーの追加
    10.3　データトポロジー
    10.4　クラウドに関する考察
    10.5　一般的なリスク
    10.6　統制
    10.7　チームトポロジーに関する考察
    10.8　スタイルの特徴
        10.8.1　いつ使うか
        10.8.2　いつ使わないか
    10.9　例とユースケース

11章　モジュラーモノリス
    11.1　トポロジー
    11.2　スタイルの詳細
        11.2.1　モノリシック構造
        11.2.2　モジュラー構造
        11.2.3　モジュール間通信
    11.3　データトポロジー
    11.4　クラウドに関する考察
    11.5　共通のリスク
    11.6　統制
    11.7　チームトポロジーに関する考察
    11.8　スタイルの特徴
        11.8.1　いつ使うか
        11.8.2　いつ使わないか
    11.9　例とユースケース

12章　パイプラインアーキテクチャ
    12.1　トポロジー
    12.2　スタイルの詳細
        12.2.1　フィルター
        12.2.2　パイプ
    12.3　データトポロジー
    12.4　クラウドに関する考察
    12.5　一般的なリスク
    12.6　統制
    12.7　チームトポロジーに関する考察
    12.8　スタイルの特徴
        12.8.1　いつ使うか
        12.8.2　いつ使わないか
    12.9　例とユースケース

13章　マイクロカーネルアーキテクチャ
    13.1　トポロジー
    13.2　スタイルの詳細
        13.2.1　コアシステム
        13.2.2　プラグインコンポーネント
        13.2.3　「マイクロカーネル性」のスペクトラム
        13.2.4　レジストリ
        13.2.5　コントラクト
    13.3　データトポロジー
    13.4　クラウドに関する考察
    13.5　一般的なリスク
        13.5.1　コアシステムの高い変動性
        13.5.2　プラグインの依存関係
    13.6　統制
    13.7　チームトポロジーに関する考察
    13.8　スタイルの特徴
    13.9　例とユースケース

14章　サービスベースアーキテクチャ
    14.1　トポロジー
    14.2　スタイルの詳細
        14.2.1　サービスの設計と粒度
        14.2.2　ユーザーインターフェイスのオプション
        14.2.3　API ゲートウェイのオプション
    14.3　データトポロジー
    14.4　クラウドに関する考察
    14.5　一般的なリスク
    14.6　統制
    14.7　チームトポロジーに関する考察
    14.8　スタイルの特徴
    14.9　例とユースケース

15章　イベント駆動アーキテクチャ
    15.1　トポロジー
    15.2　スタイルの詳細
        15.2.1　イベントとメッセージの違い
        15.2.2　派生イベント
        15.2.3　拡張可能なイベントを送信する
        15.2.4　非同期処理機構
        15.2.5　ブロードキャスト機構
        15.2.6　イベントペイロード
        15.2.7　「ブヨの群れ」アンチパターン
        15.2.8　エラー処理
        15.2.9　データロスの防止
        15.2.10　リクエスト・リプライ処理
        15.2.11　メディエーター型イベント駆動アーキテクチャ
    15.3　データトポロジー
        15.3.1　モノリシックデータベーストポロジー
        15.3.2　ドメインデータベーストポロジー
        15.3.3　専用データベーストポロジー
    15.4　クラウドに関する考察
    15.5　一般的なリスク
    15.6　統制
    15.7　チームトポロジーに関する考察
    15.8　スタイルの特徴
        15.8.1　リクエストベースモデルとイベントベースモデルの選択
    15.9　例とユースケース

16章　スペースベースアーキテクチャ
    16.1　トポロジー
    16.2　スタイルの詳細
        16.2.1　処理ユニット
        16.2.2　仮想化ミドルウェア
        16.2.3　メッセージンググリッド
        16.2.4　データグリッド
        16.2.5　処理グリッド
        16.2.6　デプロイメントマネージャー
        16.2.7　データポンプ
        16.2.8　データライター
        16.2.9　データリーダー
    16.3　データトポロジー
    16.4　クラウドに関する考察
    16.5　一般的なリスク
        16.5.1　データベースからの頻繁な読み取り
        16.5.2　データの同期と整合性
        16.5.3　高データ量
        16.5.4　データ衝突
    16.6　統制
    16.7　チームトポロジーに関する考察
    16.8　スタイルの特徴
    16.9　例とユースケース
        16.9.1　コンサートチケット販売システム
        16.9.2　オンラインオークションシステム

17章　オーケストレーション駆動サービス指向アーキテクチャ
    17.1　トポロジー
    17.2　スタイルの詳細
        17.2.1　分類
        17.2.2　再利用……と結合
    17.3　データトポロジー
    17.4　クラウドに関する考察
    17.5　一般的なリスク
    17.6　統制
    17.7　チームトポロジーに関する考察
    17.8　スタイルの特徴
    17.9　例とユースケース

18章　マイクロサービスアーキテクチャ
    18.1　トポロジー
    18.2　スタイルの特徴
        18.2.1　境界づけられたコンテキスト
        18.2.2　粒度
        18.2.3　データ分離
        18.2.4　API レイヤー
        18.2.5　運用面での再利用
        18.2.6　フロントエンド
        18.2.7　通信
        18.2.8　コレオグラフィとオーケストレーション
        18.2.9　トランザクションとサーガ
    18.3　データトポロジー
    18.4　クラウドに関する考察
    18.5　一般的なリスク
    18.6　統制
    18.7　チームトポロジーに関する考察
    18.8　スタイルの特徴
    18.9　例とユースケース

19章　適切なアーキテクチャスタイルを選ぶ
    19.1　アーキテクチャの「トレンド」の変化
    19.2　判断基準
    19.3　モノリスのケーススタディ：シリコンサンドイッチ
        19.3.1　モジュラーモノリス
        19.3.2　マイクロカーネル
    19.4　分散アーキテクチャのケーススタディ：Going, Going, Gone

20章　アーキテクチャパターン
    20.1　再利用
        20.1.1　ドメインによる結合と運用による結合の分離
    20.2　通信
        20.2.1　オーケストレーションとコレオグラフィ
    20.3　CQRS
    20.4　インフラストラクチャ
        20.4.1　ブローカーパターン

第III部　テクニックとソフトスキル

21章　アーキテクチャ決定
    21.1　アーキテクチャ決定に関するアンチパターン
        21.1.1　資産防御アンチパターン
        21.1.2　グラウンドホッグデーアンチパターン
        21.1.3　メール駆動アーキテクチャアンチパターン
    21.2　アーキテクチャ上重要なもの
    21.3　アーキテクチャデシジョンレコード
        21.3.1　基本構造
        21.3.2　例
        21.3.3　ADR の保管
        21.3.4　ADR をドキュメントとして使用する
        21.3.5　ADR を標準として使用する
        21.3.6　既存システムでのADR の使用
        21.3.7　アーキテクチャ決定における生成AI とLLM の活用

22章　アーキテクチャ上のリスクを分析する
    22.1　リスクマトリクス
    22.2　リスクアセスメント
    22.3　リスクストーミング
        22.3.1　フェーズ1：識別
        22.3.2　フェーズ2：合意
        22.3.3　フェーズ3：リスク軽減
    22.4　ユーザーストーリーリスク分析
    22.5　リスクストーミングのユースケース
        22.5.1　可用性
        22.5.2　弾力性
        22.5.3　セキュリティ
    22.6　まとめ

23章　アーキテクチャの図解
    23.1　図解
        23.1.1　ツール
        23.1.2　図解標準：UML、C4、ArchiMate
        23.1.3　図解ガイドライン
    23.2　まとめ

24章　効果的なチームにする
    24.1　コラボレーション
    24.2　制約と境界
    24.3　アーキテクトのパーソナリティ
        24.3.1　コントロールフリークアーキテクト
        24.3.2　アームチェアアーキテクト
        24.3.3　効果的なアーキテクト
    24.4　どの程度関与すべきか？
    24.5　チームの警告サイン
        24.5.1　プロセスロス
        24.5.2　多元的無知
        24.5.3　責任の分散
    24.6　チェックリストの活用
        24.6.1　開発者向けコード完成チェックリスト
        24.6.2　ユニットテスト・機能テスト用チェックリスト
        24.6.3　ソフトウェアリリース用チェックリスト
    24.7　ガイダンスの提供
    24.8　まとめ

25章　交渉とリーダーシップのスキル
    25.1　交渉とファシリテーション
        25.1.1　ビジネスステークホルダーとの交渉
        25.1.2　他のアーキテクトとの交渉
        25.1.3　開発者との交渉
    25.2　リーダーとしてのソフトウェアアーキテクト
        25.2.1　アーキテクチャの4 つのC
        25.2.2　プラグマティックでありながらもビジョナリーであること
        25.2.3　手本を示してチームをリードする
    25.3　開発チームに溶け込む
    25.4　まとめ

26章　アーキテクチャと交わるもの
    26.1　アーキテクチャと実装
        26.1.1　運用上の関心事
        26.1.2　構造上の整合性
        26.1.3　アーキテクチャの制約
    26.2　アーキテクチャとインフラストラクチャ
    26.3　アーキテクチャとデータトポロジー
        26.3.1　データベーストポロジー
        26.3.2　アーキテクチャ特性
        26.3.3　データ構造
        26.3.4　読み書きの優先順位
    26.4　アーキテクチャとエンジニアリングプラクティス
    26.5　アーキテクチャとチームトポロジー
    26.6　アーキテクチャとシステム統合
    26.7　アーキテクチャと全社標準
    26.8　アーキテクチャとビジネス環境
    26.9　アーキテクチャと生成AI
        26.9.1　生成AI をアーキテクチャに組み込む
        26.9.2　生成AI をアシスタントとして活用する
    26.10　まとめ

27章　ソフトウェアアーキテクチャの法則（再考）
    27.1　第一法則：ソフトウェアアーキテクチャはトレードオフがすべてだ
        27.1.1　共有ライブラリと共有サービス
        27.1.2　同期メッセージングと非同期メッセージング
        27.1.3　必然的帰結その一：トレードオフの見落とし
        27.1.4　必然的帰結その二：一度だけではできない
    27.2　第二法則：「どうやって」よりも「なぜ」の方がずっと重要だ
        27.2.1　コンテキスト無視アンチパターン
    27.3　極端な選択肢の間のどこか
    27.4　最後のアドバイス

この大幅な増補改訂により、本書は、これからソフトウェアアーキテクチャを学ぶ方々のための入門書として、いっそう完成度の高いものに仕上がったと感じています。

とはいえ、本質的なメッセージは第1版から変わりはありません。本書が繰り返し強調する最も重要なメッセージは、ソフトウェアアーキテクチャに絶対的な正解はなく、すべてがトレードオフの上に成り立っているという点です。

新しい技術やプラットフォーム、製品を広めたい人たちによる「正解」が、世の中にはどうしても溢れています。ですが、アーキテクトが実際に向き合うのは、制約も状況も少しずつ変わっていく現実です。現実世界のアーキテクトの仕事に「正解」はありません。だからこそ、トレードオフを見据えながら、イテレーティブにアーキテクチャを育てていく姿勢が大切になります。

本書は、そのための道具立てを与えてくれる一冊です。この第2版が、これからソフトウェアアーキテクチャについて学ぶ方、そして現場で悩んでいる方のえとなる一冊になることを、訳者として切に願っています。ボリュームのある一冊ではありますが、ぜひ手に取っていただけると幸いです。

ソフトウェアアーキテクチャの基礎 第2版 ―エンジニアリングに基づく体系的アプローチ

ソフトウェア開発におけるシンプリシティを扱った翻訳書籍の原稿をレビューいただける方を募集します

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

---

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

書籍は現代のソフトウェア開発をシンプルにするためのプラクティスを扱った内容となっています。具体的な書名は募集時点では規約により明かせないため、レビューに参加頂いた方のみにお知らせいたします。悪しからずご理解くださいませ。

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

興味を持っていただけた方は、以下に記載する要項にお目通しいただいたうえで、フォームに必要項目を記入のうえ、ご応募ください。

https://forms.gle/oeqp1U1oL1hZU4R46

自分自身をレジリエントマネジメントする方法を学ぶ

拙訳『スタッフエンジニアの道 ―優れた技術専門職になるためのガイド』の中にも何度か登場するLara Hoganさんの著書『レジリエントマネジメント』を読みました。

レジリエントマネジメント　荒波に立ち向かい、困難を乗り越えるチームの育て方（リフロー版）

マネジメントに取り組む皆さんにとって、チームに訪れる危機を乗り越え、より強い組織にしていくことは、永遠の課題ではないでしょうか？
チームの結成時期におけるフェーズごと（形成期・混乱期・統一期・機能期）に起こる危機に対して、マネージャーが行うべきことや対処にあたっての考え方をまとめました。

本書では、マネージャーがチームに様々な困難が訪れた際に、メンバーに対してどのように振る舞えばいいのかという実践的な内容を紹介しています。メンバーとの関わり方や危機に対しての対処法など、チーム運営には無くてはならない知識であるものの、あまり語られてこなかったものばかりです。これを読めば、困難に立ち向かい、危機から脱却し、さらなる強いチームへと成長する、レジリエンスを高めるための方法がきっと身につきます。

Lara Hogan著『Resilient Management』の翻訳書。

副題に「チームの育て方」、タイトルに「マネジメント」。ここで「自分向けではない」と感じてしまう技術職の人もいるでしょう。ですが、本書を読み終えて最初に思ったのは、これは、自分の扱い方を学ぶ一冊だ、ということでした。

各章の結びにある「コーチングの質問」で問われるのは、「あなた」つまり読者自身についてです。

各章で語られるのは「あなた」の行動に関してです。

そして、5章「困難を乗り越える力」における「乗り越えるべき困難」とは、「あなた」が対峙している困難です。

チームが危機に対峙しているということは、すなわちチームでリーダーシップを発揮すべき人達自身が困難さと対峙しているということであり、チームのレジリエンスを高めるというのは、すなわち自分自身としてその困難さを乗り越えていくための方法を身につけていくことなのだと考えます。

ところが、そうしたレジリエントマネジメントの仕方を体系的に学ぶ機会は多くありません。

一方で、前述の『スタッフエンジニアの道 ―優れた技術専門職になるためのガイド』、そして拙訳『エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ』においても、自分のエネルギーを大事に使うこと、すなわち自分自身をレジリエントマネジメントすることの重要性が出てきます。

これは、マネージャーでなくても、組織内での影響範囲が広がるほど、レジリエントマネジメントの重要性は高まっていくことを意味しているのだと考えます。

そういった点で、本書は、マネージャ職か技術職かを問わず、そうした局面いる人にぜひ手に取ってもらいたい、強く薦めたい一冊だと感じました。

レジリエントマネジメント　荒波に立ち向かい、困難を乗り越えるチームの育て方（リフロー版）

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

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

『ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則』

翻訳を担当した書籍『ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則』（インプレス）が2025年10月17日に発売となります。

本書は、2024年10月に出版されたVlad Khononov著『Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems』（Addison-Wesley Professional）の全訳となります。

ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則 (impress top gearシリーズ)

著者は、『Learning Domain-Driven Design』（邦訳『はじめようドメイン駆動設計』）の執筆でも知られるVlad Khononov氏です。

ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法

氏の2冊目の著作となる本書は、ソフトウェア設計における「結合（coupling）」に焦点を当てた一冊となっています。

結合はソフトウェア設計に関する多くの書籍で扱われます。ですが、説明に多くのページが割かれることもなく、説明も断片的になりがちです。対して、本書は一冊まるごと使って、結合を深く掘り下げていきます。

本書の具体的な目次は次のとおりです。

■第I部 結合  
第1章 結合とシステム設計  
第2章 結合と複雑性：クネビン  
第3章 結合と複雑性：相互作用  
第4章 結合とモジュール性  
  
■第II部 次元  
第5章 構造化設計におけるモジュール結合  
第6章 コナーセンス  
第7章 統合強度  
第8章 距離  
第9章 変動性  
  
■第III部 バランス  
第10章 結合の均衡化  
第11章 結合の再均衡化  
第12章 ソフトウェア設計のフラクタル幾何学的性質  
第13章 均衡結合の実践  
第14章 結論  
第15章 エピローグ

第I部では、結合と複雑性・モジュール性の関係を整理して、結合を「避ける対象」から「設計する対象」へと捉え直します。

第II部では、モジュール結合やコナーセンス¹といった歴史的な結合モデルを踏まえた上で、強度・距離・変動性という結合を測る3つの次元を学びます。

そして、第III部では、その3つの次元をバランスさせることでより良い設計を導く「結合均衡モデル（balanced coupling model）」を学びます。第13章では、いくつかののケーススタディを通して、このモデルが、アーキテクチャレベルからコードレベルまで、さまざまな抽象化レベルを跨いで有効であることも示されます。

本書は、これまでの「高凝集・疎結合（high cohesion, low coupling）」という単純なスローガンから、結合の議論を一段引き上げるものです。たとえば、「変動性が低いなら強度の低さを許容し得る」「強度が低い結合は距離を離し、強度が高い結合は距離を縮める」といった判断を、変更コストなどを踏まえた現実的な設計指針として手にできます。

著者による本書の試みは、『Tidy First?』においてKent Beck氏が示した関心とも共鳴しています²。

時間とともに「結合」という言葉の意味は失われ、システム内の要素間のあらゆる関連を指すようになった。「このサービスはあのサービスと結合している」とは言うが、どのように？ どんな変更に関して？ サービスが別のサービスを呼び出すだけでは不十分だ。あるサービスに対するどんな変更が別のサービスの変更を必要とするかを知る必要がある。 -- Kent Beck 『Tidy First? 』「29章 結合」より

本書は、まさにこの課題を解決する1冊となっています。

本書が整理した知識、提示したモデル、そして提案したアプローチが、ソフトウェア設計に携わるすべての方々の助けとなり、ソフトウェア設計の実践をより成熟したものへと導くことを願っています。

ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則 (impress top gearシリーズ)

ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法

Tidy First? ―個人で実践する経験主義的ソフトウェア設計

---

1. コナーセンスについては、Connascence：コードの結合度を測るもうひとつの指標 - snoozer05's blog で過去に紹介しているので、そちらも参考にしてください。↩
2. 『Tidy First?』も本書も、Edward YourdonとLarry L. Constantineによる古典的名著『Structured Design』（邦訳 『ソフトウェアの構造化設計法』）が執筆の契機として挙げられており、この2冊は同時代性を持った2冊であると考えています↩

『プログラミングRuby 第5版』の翻訳プロジェクトについて

現在、『Programming Ruby 3.3 (5th Edition)』（通称ピッケル本）の翻訳を島田の方で進めています。

ピッケル本について

『Programming Ruby』は、Dave ThomasとAndy Huntによって書かれ、2000年11月に出版された、英語圏で最初のRuby書籍であり、アメリカでRubyコミュニティがまつもとさんを呼んで集まるきっかけにもなった、Rubyコミュニティにとって大切な書籍です。

一番最初のカンファレンスですと、デイブ・トーマスとアンディ・ハントの『プログラミングRuby』、 ピッケル本と呼ばれている本が出た時に、それを見て感銘を受けた人たちが、 「じゃあ、みんなで集まりましょう」「遠くだけど、みんなの参加費を集めて、 まつもとの航空券を買って、まつもとを呼んで話そう」みたいな会を開きました。 それ以来、毎年、Ruby Conferenceというものがアメリカで開かれています。 https://logmi.jp/main/technology/279858

原書の表紙にピッケルが描かれていたため、同書は『ピッケル本』という愛称でコミュニティに長く親しまれてきました。

しかしながら、日本では、2001年に『プログラミングRuby: 達人プログラマーガイド』（桐原書店）として第1版が翻訳された後、第3版まで訳書が出版されたものの、現在は日本語で読めない状況が続いています。

翻訳プロジェクトについて

そんなピッケル本について、第2版以降の版元であるオーム社さんからお声がけをいただき、現在島田の方で翻訳を進めています。

翻訳については、『プログラミングRuby 1.9』までの訳者である田和さんにもご了承をいただき、過去の訳文を活かす形で最新の版との差分を確認しながら進め、現在24章まで翻訳が進んでいる状況です。

訳者への支援のお願い

ただ、過去の販売実績などから費用面で課題があり、翻訳の仕事に対していただけるお金はほとんどない状況です。

そのため、書籍の出版に向けて、訳者の仕事に対する援助をしてくださる個人や団体の方々を募集したいと考えました。 主旨に賛同し、書籍スポンサーとして翻訳を支援いただけると大変助かります。

プログラミングRuby 第5版 翻訳支援の募集

現在は、企業・団体様の支援のみ受付を開始した状況となります。なにぶん一人で色々とやっているため...個人で支援してくださるお気持ちの皆様は今しばらくお待ちください。上記のページに問い合わせフォームや応援フォームもそれぞれ開いていますので、何かあればメッセージいただけると嬉しいです :-)

国内のRuby関連書籍の刊行数が少なくなってきている現在、そして、技術書籍の翻訳書の出版という形態もこの先長く続くかどうかの約束のない今だからこそ、ピッケル本の最新版を日本語の紙書籍という形で出版しておきたいと考えています。

何卒ご支援のほどどうぞよろしくお願いします。

Programming Ruby 3.3: The Pragmatic Programmers' Guide (English Edition)

プログラミングRuby 1.9 −言語編−