上級技術リーダーの役割やあり方に関する翻訳書籍の原稿をレビューいただける方を募集します

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


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

書籍は上級技術リーダーに求められる役割やあり方、スキルについて学ぶ内容となっています。次のような方々を対象とした書籍です:

  • 自分の役割をよりよく理解し、成長させたいと考えているスタッフエンジニアやプリンシパルエンジニア
  • スタッフエンジニアやプリンシパルエンジニアといった個人貢献者コースでのキャリアアップに関心のあるソフトウェア開発者

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

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

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

https://forms.gle/9FCAQzkqKbcHqeVP9

『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』

翻訳を担当した書籍『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』(オライリー・ジャパン)が明日(2024年1月24日)発売となります(電子書籍オライリー・ジャパンのサイトでの購入となります)。本書は、2022年10月に出版されたChristian Ciceri, Dave Farley, Neal Ford, Andrew Harmel-Law, Michael Keeling, Carola Lilienthal, João Rosa, Alexander von Zitzewitz, Rene Weiss, Eoin Woods 著『Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture』(O'Reilly Media)の全訳となります。

本書は、経験豊かな10名のソフトウェアアーキテクトたちによる、ソフトウェアアーキテクチャメトリクスをテーマとした論集となっています。

著者には、次のような著名なソフトウェアアーキテクトたちが名を連ねています。

本書は、ソフトウェアアーキテクチャの分野におけるメトリクスの考え方、取り組み方、実践に対するヒントが学べる一冊となっています。

本書で取り扱われるトピックには、次のようなものがあります。

  • Four Keys メトリクスの計測と可視化の実践
  • アーキテクチャ適応度関数(architectural fitness functions)の考え方を用いてアーキテクチャが目的を満たしているかを検証する方法やヒント
  • モジュール性成熟度指数(Modularity Maturity Index:MMI)を用いて技術的負債を計測する方法
  • DevOps文化に組織が移行できているかを測るのに役立つメトリクス
  • ビジネス目標と結びついた適切なKPIからソフトウェアアーキテクチャメトリクスを導く方法や実践
  • メトリクスベースのフィードバックループを実践して保守性を保つ方法

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

はじめに 

1章 解き放たれた4つのキーメトリクス
    1.1 定義と計測 
    1.2 メンタルモデルのリファクタリング 
    1.3 記録と算出 
    1.4 表示と理解 
    1.5 議論と理解 
    1.6 オーナーシップと改善 
    1.7 結論 

2章 適応度関数テストピラミッド:アーキテクチャテストとメトリクスのためのアナロジー 
    2.1 適応度関数とメトリクス  
    2.2 適応度関数の区分 
    2.3 テストピラミッド 
    2.4 適応度関数テストピラミッド 
    2.5 適応度関数例の評価 
    2.6 より複雑な適応度関数例の評価 
    2.7 適応度関数とメトリクスを開発する 
    2.8 結論 

3章 進化的アーキテクチャ:テスト容易性とデプロイ可能性でアーキテクチャを導く
    3.1 学習と発見の重要性 
    3.2 持続可能な変化を実現するためのツール 
    3.3 テスト容易性:高品質なシステムを構築する 
    3.4 デプロイ可能性:システムの開発をスケーリングする 
    3.5 結論 

4章 モジュール性成熟度指数でアーキテクチャを改善する 
    4.1 技術的負債 
    4.2 技術的負債の発生 
    4.3 MMIによる評価 
    4.4 モジュール性 
    4.5 階層性 
    4.6 パターン一貫性 
    4.7 MMIを算出する 
    4.8 MMIを決定するためのアーキテクチャレビュー 
    4.9 結論 

5章 プライベートビルドとメトリクス:DevOps移行を乗り越えるためのツール 
    5.1 主要な用語 
    5.2 「オーナーシップシフト」 
    5.3 ローカル環境を再び強化する 
    5.4 プライベートビルド 
    5.5 ケーススタディ:不安定なトランク  
    5.6 ケーススタディ:ブロックされたコンサルタント会社 
    5.7 メトリクス  
    5.8 メトリクスの実践  
    5.9 結論 

6章 組織のスケーリング:ソフトウェアアーキテクチャの中心的役割
    6.1 YourFinFreedom社の挑戦:モノリスを壊す 
    6.2 分散した巨大な泥団子となったマイクロサービス 
    6.3 方向性を模索する 
    6.4 ベストエフォートからインテンショナルエフォートへ 
    6.5 メトリクスによって意図的なソフトウェアアーキテクチャを導く 
    6.6 コミュニケーションを通じた期待マネジメント 
    6.7 アーキテクチャの学びと進化 
    6.8 そしてAnnaはどうなる? 
    6.9 結論 

7章 ソフトウェアアーキテクチャにおける計測の役割 
    7.1 ソフトウェアアーキテクチャに計測を加える 
    7.2 計測のアプローチ 
    7.3 システム品質の計測 
    7.4 始め方 
    7.5 架空のケーススタディ 
    7.6 落とし穴 
    7.7 結論 

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 より良いソフトウェアを作るためのいくつかの黄金律 
    9.8 結論

10章 ゴール・クエスチョン・メトリクスアプローチで未知数を計測する
    10.1 GQMアプローチ
    10.2 ケーススタディ:未来を見通す力を身につけたチーム
    10.3 GQMワークショップを開催する 
    10.4 結論

ソフトウェアアーキテクチャ分野のメトリクスに興味のある方や、上記のトピックや目次を見て興味を惹かれた方などには、ぜひ手に取っていただきたい書籍なのですが、本書には注意いただきたい点もあります。それは、本書は「ソフトウェアアーキテクチャメトリクスというトピックを体系的に取り上げた書籍」ではなく、「ソフトウェアアーキテクチャメトリクスをテーマとしたエッセイ集」であるという点です。

原書の書名(『Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture』)からはそのことが分かりづらく、残念ながら、原書では読者の期待との間にミスマッチが生じているケースも見受けられます。訳書では副題を「アーキテクチャ品質を改善する10のアドバイス」とすることで、そうした誤解が少なくなるように工夫しています。

本書は、実践者たちのさまざまな経験やアドバイスからヒントを得る書籍として読むと、得られる部分の多い書籍です。ぜひ『ソフトウェアアーキテクトが知るべき97のこと』や『ビューティフルアーキテクチャ (THEORY/IN/PRACTICE)』、『Making Software ―エビデンスが変えるソフトウェア開発』などに連なる書籍として、そして、まだまだ情報源の多くないソフトウェアアーキテクチャ分野でのメトリクスの活用についてインスピレーションを得る書籍として、多くの方に手に取っていただけたらと考えています。

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

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


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

書籍はソフトウェアアーキテクチャの評価指標について学ぶ入門的な内容となっています。具体的な書名は募集時点では規約により明かせないため、レビューに参加頂いた方のみにお知らせいたします。悪しからずご理解くださいませ。

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

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

https://forms.gle/4H6RPhPj93vv6vpT6

『急な「売れ」に備える作家のためのサバイバル読本』

「急な売れ」を経験したわけでも、作家でもない。けれども、読んでいるとなんだか「心当たりのある」出来事がたくさん出てきて、胸がキュッとなる。そして、最後の4章で著者の「明日への繋ぎ方」をお裾分けしてもらいながら、自分の「明日への繋ぎ方」を考える。朱野帰子さんの『急な「売れ」に備える作家のためのサバイバル読本』を、僕はそんな風に読みました。

techbookfest.org

「急な売れ」や「作家のための」という言葉から、本書を自分とは無関係の本だと思われる方は多いだろうと思います。ですが、本書で語られる「急な売れ」を次のような状況だとイメージしてみたなら、どうでしょう。本書の印象が少し違って見える人はいるのでないでしょうか。

組織(やコミュニティ)内で立場が変わったり能力や名前などを認知されるなどした結果、いろんな人の期待や相談、依頼などが舞い込むようになった状況

本書は、そうした状況(すなわち「急な売れ」)に身を置かれた著者が、自分のキャパシティを超えた仕事量に晒され続けたことですり減ってしまった自分の「職業(profession)」を取り戻す「修復のプロセス」のノンフィクションであり、そうした状況を経た後でも「健やかに仕事をしていく」ためにどうしたらいいかを伝える技術書でもあります。

本書では、その「修復のプロセス」の中で、拙訳『ユニコーン企業のひみつ』の内容が登場します(!!)。

ユニコーン企業のひみつ』は組織の文化や働き方が語られている書籍であるため、このような届き方をしたことには大変びっくりしました。ですが、ジョナサンが『ユニコーン企業のひみつ』に込めたメッセージを思えば、そうしたことも不思議ではないかもしれないな、と改めて思い直しました。

ユニコーン企業のひみつ』は最後、こんな文章で幕を閉じます。

毎朝、仕事に行きたくなるような、全力を尽くしたくなるような、自分らしくいられるような、一日の終わりには満足して家路につけるような、そんな職場づくりにひとりでも多くの人が成功することを願っている - ジョナサン・ラスマセン『ユニコーン企業のひみつ』

ここには、スタートアップであるかとか、ソフトウェア企業であるかとか、組織であるか個人であるかとか、全く関係がないですものね。こうした力強いメッセージがあるからこそ、今回のような届き方が生まれたのかもしれないなあと感じます。

2022年のデブサミで「Ready Player One: 『ユニコーン企業のひみつ』に学べること」というお話をさせていただいた際に、ユニコーン企業のように働けるようになるために重要なパターンとして次の2つを紹介していました。

speakerdeck.com

朱野帰子さんによる「急な「売れ」に備える作家のためのサバイバル読本」は、まさしくこの2つの実践のアウトプットなのだろうと思います(すごい...!!)。

ジョナサンが『ユニコーン企業のひみつ』に込めたメッセージも詰まった本書が、できるだけたくさんの「本書を必要とする人たち」にどうか届きますように。

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

翻訳を担当した書籍『ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析』(オライリー・ジャパン)が本日(10月27日)発売となります(電子書籍オライリー・ジャパンサイトから購入できます)。本書は、2021年10月に出版されたNeal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani 著『Software Architecture: The Hard Parts』(O'Reilly Media)を全訳したものです。

本書は、『ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ』(オライリージャパン)に続く、Neal FordとMark Richardsのタッグによるソフトウェアアーキテクチャを扱った書籍になります。前作には盛り込みきれなかった、現代の分散アーキテクチャでの意思決定が持つさまざまなトレードオフについて、その見極め方や評価の仕方、効果的な意思決定を行っていく方法を解説しています。

本書では、アーキテクチャ上の決定に与える影響としてデータに関するトピックにも深く踏み込んでおり、その領域に造詣の深いPramod SadalageとZhamak Dehghaniの二人が新たに共著者として加わっています1

耳なじみのない「ハードパーツ」という言葉を冠した本書のタイトルは、オライリーの「The Good Parts」シリーズのオマージュから2。ソフトウェアアーキテクチャという「ソフトウェアの中のハード(硬い)な部分」であり「べストプラクティスの存在しない領域」(ゆえに「Good Parts」とは言えない)、そしてそうしたソフトウェアアーキテクチャの「ハードパーツ(難しい問題)」を扱った書籍であることを意味しています。

同月に『マイクロフロントエンド ―マイクロサービスアーキテクチャの概念をフロントエンドに拡張し、信頼性、自律性の高いシステムを構築する』(序文は本書の著者の一人Neal Ford!)も刊行され、12月にはSam Numanの『マイクロサービスアーキテクチャ 第2版』の刊行も予定されていて、ソフトウェアアーキテクチャ周辺の注目書籍が盛りだくさんですが、ソフトウェアアーキテクチャに取り組むたくさんの方に手に取っていただけると嬉しいです。

目次

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

1章 「ベストプラクティス」がないとどうなる?
    1.1 なぜ「ハードパーツ」か?
    1.2 ソフトウェアアーキテクチャについての時代を超えたアドバイス
    1.3 アーキテクチャにおけるデータの重要性
    1.4 アーキテクチャデシジョンレコード
    1.5 アーキテクチャ適応度関数
        1.5.1 適応度関数の使用
    1.6 アーキテクチャと設計:定義をシンプルにする
    1.7 Sysops Squadサーガの紹介
        1.7.1 非チケッティングワークフロー
        1.7.2 チケッティングワークフロー
        1.7.3 悪いシナリオ
        1.7.4 Sysops Squadのアーキテクチャコンポーネント
        1.7.5 Sysops Squadデータモデル

第I部 分解する

2章 ソフトウェアアーキテクチャにおける結合の見分け方
    2.1 アーキテクチャ量子
        2.1.1 独立してデプロイ可能
        2.1.2 高度な機能的凝集
        2.1.3 高度な静的結合
        2.1.4 動的な量子結合
    2.2 Sysops Squadサーガ:量子を理解する

3章 アーキテクチャのモジュール化
    3.1 モジュール化の推進要因
        3.1.1 保守性
        3.1.2 テスト性
        3.1.3 デプロイ性
        3.1.4 スケーラビリティ
        3.1.5 可用性・耐障害性
    3.2 Sysops Squadサーガ:提案書の作成

4章 アーキテクチャの分解
    4.1 コードベースは分解可能か?
        4.1.1 求心性結合と遠心性結合
        4.1.2 抽象度と不安定度
        4.1.3 主系列からの距離
    4.2 コンポーネントベース分解
    4.3 戦術的フォーク
        4.3.1 トレードオフ
    4.4 Sysops Squadサーガ:分解アプローチを選択する

5章 コンポーネントベース分解パターン
    5.1 コンポーネントの特定およびサイズ調整パターン
        5.1.1 パターンの説明
        5.1.2 統制のための適応度関数
        5.1.3 Sysops Squadサーガ:コンポーネントのサイズ調整
    5.2 ドメイン共通コンポーネントの収集パターン
        5.2.1 パターンの説明
        5.2.2 統制のための適応度関数
        5.2.3 Sysops Squadサーガ:ドメイン共通コンポーネントの収集
    5.3 コンポーネントのフラット化パターン
        5.3.1 パターンの説明
        5.3.2 統制のための適応度関数
        5.3.3 Sysops Squadサーガ:コンポーネントのフラット化
    5.4 コンポーネントの依存関係判断パターン
        5.4.1 パターンの説明
        5.4.2 統制のための適応度関数
        5.4.3 Sysops Squadサーガ:コンポーネントの依存関係を特定する
    5.5 コンポーネントドメインの作成パターン
        5.5.1 パターンの説明
        5.5.2 統制のための適応度関数
        5.5.3 Sysops Squadサーガ:コンポーネントドメインの作成
    5.6 ドメインサービスの作成パターン
        5.6.1 パターンの説明
        5.6.2 統制のための適応度関数
        5.6.3 Sysops Squadサーガ:ドメインサービスの作成
    5.7 まとめ

6章 業務データの分解
    6.1 データ分解の推進要因
        6.1.1 データ分解要因
        6.1.2 データ統合要因
        6.1.3 Sysops Squadサーガ:データベース分解の根拠
    6.2 モノリシックなデータを分解する
        6.2.1 ステップ1:データベースを分析し、データドメインを特定する
        6.2.2 ステップ2:テーブルをデータドメインに割り当てる
        6.2.3 ステップ3:データベースコネクションをデータドメインごとに分離する
        6.2.4 ステップ4:スキーマを別個のデータベースサーバーに移動する
        6.2.5 ステップ5:個別のデータベースサーバーへコネクション先を切り替える
    6.3 データベース種別を選択する
        6.3.1 リレーショナルデータベース
        6.3.2 キーバリューデータベース
        6.3.3 ドキュメントデータベース
        6.3.4 列指向データベース
        6.3.5 グラフデータベース
        6.3.6 NewSQLデータベース
        6.3.7 クラウドネイティブデータベース
        6.3.8 時系列データベース
    6.4 Sysops Squadサーガ:ポリグロットデータベース

7章 サービスの粒度
    7.1 粒度分解要因
        7.1.1 サービスの範囲と機能
        7.1.2 コード変動率
        7.1.3 スケーラビリティとスループット
        7.1.4 耐障害性
        7.1.5 セキュリティ
        7.1.6 拡張性
    7.2 粒度統合要因
        7.2.1 データベーストランザクション
        7.2.2 ワークフローとコレオグラフィ
        7.2.3 共有コード
        7.2.4 データ関係
    7.3 適切なバランスを見極める
    7.4 Sysops Squadサーガ:チケット割り当ての粒度
    7.5 Sysops Squadサーガ:顧客登録の粒度

第II部 つなぎ合わせる

8章 再利用パターン
    8.1 コードレプリケーション
        8.1.1 使いどころ
    8.2 共有ライブラリ
        8.2.1 依存関係の管理と変更の制御
        8.2.2 バージョニング戦略
        8.2.3 使いどころ
    8.3 共有サービス
        8.3.1 変更リスク
        8.3.2 パフォーマンス
        8.3.3 スケーラビリティ
        8.3.4 耐障害性
        8.3.5 使いどころ
    8.4 サイドカーとサービスメッシュ
        8.4.1 使いどころ
    8.5 Sysops Squadサーガ:共通基盤ロジック
    8.6 コードの再利用:どのようなときに価値が生まれるか?
        8.6.1 プラットフォームによる再利用
    8.7 Sysops Squadサーガ:共有ドメイン機能

9章 データの所有権と分散トランザクション
    9.1 データの所有権を割り当てる
    9.2 単独所有シナリオ
    9.3 全体共有シナリオ
    9.4 共同所有シナリオ
        9.4.1 テーブルの分割
        9.4.2 データドメイン
        9.4.3 委譲
    9.5 サービスコンソリデーション
    9.6 データ所有権のまとめ
    9.7 分散トランザクション
    9.8 結果整合性パターン
        9.8.1 バックグラウンド同期パターン
        9.8.2 リクエストベースのオーケストレーションパターン
        9.8.3 イベントベースパターン
    9.9 Sysops Squadサーガ:チケット処理のデータ所有権

10章 分散データアクセス
    10.1 サービス間通信パターン
    10.2 列スキーマレプリケーションパターン
    10.3 レプリケーションキャッシュパターン
    10.4 データドメインパターン
    10.5 Sysops Squadサーガ:チケット割り当てのためのデータアクセス

11章 分散ワークフローの管理
    11.1 オーケストレーション通信スタイル
    11.2 コレオグラフィ通信スタイル
        11.2.1 ワークフロー状態管理
    11.3 オーケストレーションとコレオグラフィのトレードオフ
        11.3.1 状態の所有者と結合
    11.4 Sysops Squadサーガ:ワークフローを管理する

12章 トランザクショナルサーガ
    12.1 トランザクショナルサーガパターン
        12.1.1 エピックサーガ(sao)パターン
        12.1.2 伝言ゲームサーガ(sac)パターン
        12.1.3 おとぎ話サーガ(seo)パターン
        12.1.4 タイムトラベルサーガ(sec)パターン
        12.1.5 ファンタジーサーガ(aao)パターン
        12.1.6 ホラーストーリーサーガ(aac)パターン
        12.1.7 パラレルサーガ(aeo)パターン
        12.1.8 アンソロジーサーガ(aec)パターン
    12.2 結果整合性を備えた状態管理
        12.2.1 サーガ状態マシン
    12.3 サーガの管理手法
    12.4 Sysops Squadサーガ:アトミックトランザクションと補償トランザクション

13章 コントラクト
    13.1 厳格なコントラクトと緩いコントラクト
        13.1.1 厳格なコントラクトと緩いコントラクトのトレードオフ
        13.1.2 マイクロサービスにおけるコントラクト
    13.2 スタンプ結合
        13.2.1 スタンプ結合による過結合
        13.2.2 帯域幅
        13.2.3 ワークフロー管理におけるスタンプ結合
    13.3 Sysops Squadサーガ:チケットのコントラクトを管理する

14章 分析データの管理
    14.1 従来のアプローチ
        14.1.1 データウェアハウス
        14.1.2 データレイク
    14.2 データメッシュ
        14.2.1 データメッシュの定義
        14.2.2 データプロダクト量子
        14.2.3 データメッシュ、結合、アーキテクチャ量子
        14.2.4 データメッシュの使いどころ
    14.3 Sysops Squadサーガ:データメッシュ

15章 独自のトレードオフ分析を構築する
    15.1 絡み合う次元の発見
        15.1.1 結合
        15.1.2 結合点の分析
        15.1.3 トレードオフの評価
    15.2 トレードオフ手法
        15.2.1 定性的分析と定量的分析
        15.2.2 MECEリスト
        15.2.3 「コンテキスト外」の罠
        15.2.4 関連するドメインのシナリオをモデル化する
        15.2.5 根拠は示し過ぎず、肝心なものに絞る
        15.2.6 過度な売り込みやエバンジェリズムを避ける
    15.3 Sysops Squadサーガ:エピローグ

付録A 概念や用語の参照
付録B アーキテクチャデシジョンレコードの参照
付録C トレードオフの参照


  1. Pramod Sadalageは『データベース・リファクタリング 』の共著者。Zhamak Dehghaniは注目を集めているデータアーキテクチャのアプローチであるデータメッシュの提唱者。

  2. 日本語で読めるものとしては『JavaScript: The Good Parts』や『Web API: The Good Parts』などがあります。

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

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

www.oreilly.co.jp

ソフトウェアアーキテクチャとは、ソフトウェアシステムの成功に欠かせない重要な土台です。そのためソフトウェア開発者には、効果的なアーキテクチャを実現するスキルが求められます。本書は、そうした効果的なアーキテクチャを設計、構築、維持するアーキテクトになるために必要なスキルや知識を、現代的な視点から整理して包括的に解説する書籍です。 ソフトウェアアーキテクチャの定義から、アーキテクトの役割、モジュールや結合、アーキテクチャスタイルといったアーキテクチャ設計の基礎、チームやステークホルダーと効果的にコラボレーションしていくために必要なソフトスキルまで、さまざまなトピックについて実践的な例とともに説明します。

本書は、ソフトウェアアーキテクチャという分野が持つ多様な側面を現代的な視点から整理し、その基礎を詳述した書籍です。

今の時代を反映したソフトウェアアーキテクチャの書籍として

なぜ、ソフトウェアアーキテクチャの書籍を今新たに書く必要があったかについて、著者らは本書に関するインタビュー1で、今の時代を反映したソフトウェアアーキテクチャの書籍を書きたかったと、その動機を語っています。

たとえば、ソフトウェアアーキテクチャをデザインするときの重要な要素の一つに、アーキテクチャ特性 があります。アーキテクチャ特性とは、品質特性やイリティ(-ility)などとも呼ばれる、可用性(availability)や信頼性(reliability)、弾力性(elasticity)といった、システムがサポートしなければならない性質を指します。

ソフトウェアアーキテクチャを扱った多くの書籍では、システムレベルでこのアーキテクチャ特性を考えるのが、暗黙的な前提となっています。

しかし、マイクロサービスアーキテクチャ登場以降、アーキテクチャ特性はシステムレベルで考えるものではもはやなくなっていると著者らは主張します。そうでなく、共通のアーキテクチャ特性を備えなければならない範囲・境界をアーキテクチャ要素(たとえばマイクロサービスにおけるサービス)として設計していくことこそが、現代のソフトウェアアーキテクチャで重要なプロセスなのだと、著者らは語ります。

本書は、こうした、ソフトウェアアーキテクチャの分野で暗黙的に前提となっていた事柄を現代的な視点で見直し、今の時代に沿った形でソフトウェアアーキテクチャという分野を改めて包括的にまとめた書籍となっています。

開発者がアーキテクトとなるためのガイドとして

また、開発者がアーキテクトとなるための丁度良いガイドが存在していなかったことも、本書を執筆した動機であったと著者らは語っています。

このことが大きく反映されているのが、「1章 イントロダクション」「2章 アーキテクチャ思考」、そして第3部の「テクニックとソフトスキル」でしょう。これらの章では、ソフトウェアアーキテクトはどのような期待を満たすロールであるか、そのためにどのような考え方をしていく必要があるか(開発者というロールから、どのように考え方を変える必要があるか)、有効なアーキテクトであり続けるためにどのようにチームやステークホルダーとコラボレーションしていく必要があるかといった、アーキテクトというロール、キャリアを開いていくにあたっての実践的なヒントが詰め込まれています。

全体を通してメッセージとして語られる、「選択によるトレードオフを分析し、最善ではないかもしれないが少なくとも最悪ではないソリューションを選んでいく」ことも、これからのアーキテクトに向けた重要なアドバイスだと感じます。

新しい技術やプラットフォーム、製品を広めたい人たちによる「正解」が、世の中にはどうしても溢れています。ですが、現実世界のアーキテクトの仕事に「正解」はありません。少しずつ変化していく現実の状況に応じて、イテレーティブにアーキテクチャレベルの改善を重ねていくことが重要です。

訳者として、本書がそうしたアーキテクチャ感が広まる一助になればと良いなと考えます。400ページ弱とボリュームのある一冊となりますが、ぜひ手に取っていただけると幸いです。

目次

本書への推薦の言葉
はじめに:公理を疑う

1章 イントロダクション
    1.1 ソフトウェアアーキテクチャの定義
    1.2 アーキテクトへの期待
        1.2.1 アーキテクチャ決定を下す
        1.2.2 アーキテクチャを継続的に分析する
        1.2.3 最新のトレンドを把握し続ける
        1.2.4 決定の順守を徹底する
        1.2.5 さまざまなものに触れ、経験している
        1.2.6 事業ドメインの知識を持っている
        1.2.7 対人スキルを持ち合わせている
        1.2.8 政治を理解し、かじ取りをする
    1.3 アーキテクチャと交わるもの
        1.3.1 エンジニアリングプラクティス
        1.3.2 運用とDevOps
        1.3.3 プロセス
        1.3.4 データ
    1.4 ソフトウェアアーキテクチャの法則

第I部 基礎

2章 アーキテクチャ思考
    2.1 アーキテクチャと設計
    2.2 技術的な幅
    2.3 トレードオフを分析する
    2.4 ビジネスドライバーを理解する
    2.5 アーキテクティングとコーディングのバランスを取る

3章 モジュール性
    3.1 定義
    3.2 モジュール性の計測
        3.2.1 凝集度
        3.2.2 結合度
        3.2.3 抽象度、不安定度、主系列からの距離
        3.2.4 主系列からの距離
        3.2.5 コナーセンス
        3.2.6 結合度とコナーセンスのメトリクスを統合する
    3.3 モジュールからコンポーネントへ

4章 アーキテクチャ特性
    4.1 アーキテクチャ特性の(部分的な)リスト
        4.1.1 アーキテクチャの運用特性
        4.1.2 アーキテクチャの構造特性
        4.1.3 アーキテクチャの横断的特性
    4.2 トレードオフと少なくとも最悪でないアーキテクチャ

5章 アーキテクチャ特性を明らかにする
    5.1 アーキテクチャ特性をドメインの関心事から捉える
    5.2 要件からアーキテクチャ特性を抽出する
    5.3 事例:シリコンサンドイッチ
        5.3.1 明示的な特性
        5.3.2 暗黙的な特性

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.2.1 事例:Going、Going、Gone

8章 コンポーネントベース思考
    8.1 コンポーネントの分類
    8.2 アーキテクトの役割
        8.2.1 アーキテクチャの分割
        8.2.2 事例:シリコンサンドイッチにおける分割
    8.3 開発者の役割
    8.4 コンポーネントを識別する流れ
        8.4.1 初期コンポーネントを識別する
        8.4.2 コンポーネントに要件を割り当てる
        8.4.3 ロールや責務を分析する
        8.4.4 アーキテクチャ特性を分析する
        8.4.5 コンポーネントを再構成する
    8.5 コンポーネントの粒度
    8.6 コンポーネント設計
        8.6.1 コンポーネントの発見
    8.7 事例:「Going、Going、Gone」におけるコンポーネントの発見
    8.8 アーキテクチャ量子再び:モノリシックアーキテクチャと分散アーキテクチャの選択

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

9章 基礎
    9.1 基礎的なパターン
        9.1.1 巨大な泥団子
        9.1.2 ユニタリーアーキテクチャ
        9.1.3 クライアント/サーバー
    9.2 モノリシックアーキテクチャと分散アーキテクチャ
        9.2.1 誤信1:ネットワークは信頼できる
        9.2.2 誤信2:レイテンシーがゼロ
        9.2.3 誤信3:帯域幅は無限
        9.2.4 誤信4:ネットワークは安全
        9.2.5 誤信5:トポロジーは決して変化しない
        9.2.6 誤信6:管理者は一人だけ
        9.2.7 誤信7:転送コストはゼロ
        9.2.8 誤信8:ネットワークは均一
        9.2.9 分散コンピューティングにおけるその他の考慮事項

10章 レイヤードアーキテクチャ
    10.1 トポロジー
    10.2 層の分離
    10.3 レイヤーの追加
    10.4 その他の考慮事項
    10.5 このアーキテクチャスタイルを採用する理由
    10.6 アーキテクチャ特性の評価

11章 パイプラインアーキテクチャ
    11.1 トポロジー
        11.1.1 パイプ
        11.1.2 フィルター
    11.2 事例
    11.3 アーキテクチャ特性の評価

12章 マイクロカーネルアーキテクチャ
    12.1 トポロジー
        12.1.1 コアシステム
        12.1.2 プラグインコンポーネント
    12.2 レジストリ
    12.3 コントラクト
    12.4 事例とユースケース
    12.5 アーキテクチャ特性の評価

13章 サービスベースアーキテクチャ
    13.1 トポロジー
    13.2 トポロジーの種類
    13.3 サービスの設計と粒度
    13.4 データベース分割
    13.5 アーキテクチャ例
    13.6 アーキテクチャ特性の評価
    13.7 このアーキテクチャスタイルがふさわしいとき

14章 イベント駆動アーキテクチャ
    14.1 トポロジー
    14.2 ブローカー
    14.3 メディエーター
    14.4 非同期の能力
    14.5 エラー処理
    14.6 データロスの防止
    14.7 ブロードキャスト能力
    14.8 リクエスト・リプライ
    14.9 リクエストベースとイベントベースの間を取る
    14.10 ハイブリッドなイベント駆動アーキテクチャ
    14.11 アーキテクチャ特性の評価

15章 スペースベースアーキテクチャ
    15.1 一般的なトポロジー
        15.1.1 処理ユニット
        15.1.2 仮想ミドルウェア
        15.1.3 データポンプ
        15.1.4 データライター
        15.1.5 データリーダー
    15.2 データ衝突
    15.3 クラウドとオンプレミス
    15.4 レプリケーションキャッシュと分散キャッシュ
    15.5 ニアキャッシュの考慮
    15.6 実装例
        15.6.1 コンサートチケット販売システム
        15.6.2 オンラインオークションシステム
    15.7 アーキテクチャ特性の評価

16章 オーケストレーション駆動サービス指向アーキテクチャ
    16.1 歴史と哲学
    16.2 トポロジー
    16.3 分類
        16.3.1 ビジネスサービス
        16.3.2 エンタープライズサービス
        16.3.3 アプリケーションサービス
        16.3.4 インフラストラクチャサービス
        16.3.5 オーケストレーションエンジン
        16.3.6 メッセージフロー
    16.4 再利用...と結合
    16.5 アーキテクチャ特性の評価

17章 マイクロサービスアーキテクチャ
    17.1 歴史
    17.2 トポロジー
    17.3 分散
    17.4 境界づけられたコンテキスト
        17.4.1 粒度
        17.4.2 データ分離
    17.5 API層
    17.6 運用面での再利用
    17.7 フロントエンド
    17.8 通信
        17.8.1 コレオグラフィとオーケストレーション
        17.8.2 トランザクションとサーガ
    17.9 アーキテクチャ特性の評価
    17.10 参考文献

18章 適切なアーキテクチャスタイルを選ぶ
    18.1 アーキテクチャにおけるトレンドの変遷
    18.2 判断基準
    18.3 モノリスの事例:シリコンサンドイッチ
        18.3.1 モジュラーモノリス
        18.3.2 マイクロカーネル
    18.4 分散型のケーススタディ:Going、Going、Gone

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

19章 アーキテクチャ決定
    19.1 アーキテクチャ決定に関するアンチパターン
        19.1.1 資産防御アンチパターン
        19.1.2 グラウンドホッグデーアンチパターン
        19.1.3 メール駆動アーキテクチャアンチパターン
    19.2 アーキテクチャ上重要なもの
    19.3 アーキテクチャデシジョンレコード
        19.3.1 基本構造
        19.3.2 ADRを保存する
        19.3.3 ドキュメントとしてのADR
        19.3.4 標準のためにADRを用いる
        19.3.5 事例

20章 アーキテクチャ上のリスクを分析する
    20.1 リスクマトリックス
    20.2 リスクアセスメント
    20.3 リスクストーミング
        20.3.1 特定
        20.3.2 合意
        20.3.3 軽減
    20.4 ユーザーストーリーリスク分析
    20.5 リスクストーミング例
        20.5.1 可用性
        20.5.2 弾力性
        20.5.3 セキュリティ

21章 アーキテクチャの図解やプレゼンテーション
    21.1 図解
        21.1.1 ツール
        21.1.2 標準ダイアグラム:UML、C4、ArchiMate
        21.1.3 図解ガイドライン
    21.2 プレゼンテーション
        21.2.1 時間を操る
        21.2.2 段階的な構築
        21.2.3 インフォデッキとプレゼンテーション
        21.2.4 スライドは物語の半分
        21.2.5 不可視化

22章 効果的なチームにする
    22.1 チーム境界
    22.2 アーキテクトのパーソナリティ
        22.2.1 コントロールフリーク
        22.2.2 アームチェアアーキテクト
        22.2.3 効果的なアーキテクト
    22.3 どうやって管理する?
    22.4 チームの警告サイン
    22.5 チェックリストの活用
        22.5.1 開発者のコード完成チェックリスト
        22.5.2 ユニットテストと機能テストのためのチェックリスト
        22.5.3 ソフトウェアリリースのためのチェックリスト
    22.6 ガイダンスの提供
    22.7 まとめ

23章 交渉とリーダーシップのスキル
    23.1 交渉とファシリテーション
        23.1.1 ビジネスステークホルダーとの交渉
        23.1.2 他のアーキテクトとの交渉
        23.1.3 開発者との交渉
    23.2 リーダーとしてのソフトウェアアーキテクト
        23.2.1 アーキテクチャの4つのC
        23.2.2 プラグマティックでありながらもビジョナリーであること
        23.2.3 手本を示してチームをリードする
    23.3 開発チームに溶け込む
    23.4 まとめ

24章 キャリアパスを開く
    24.1 20分ルール
    24.2 パーソナルレーダーの開発
        24.2.1 ThoughtWorksテクノロジーレーダー
        24.2.2 オープンソースのビジュアライゼーションビット
    24.3 ソーシャルメディアの使用
    24.4 別れの挨拶

「合宿」というパターン

今支援させていただいているチームのマネージャーさんが使っていて、とても良いなと思った言葉遣いに「合宿」がある。 ここでいう「合宿」とは、別にチームで泊まりで何かをするという意味でない。メタファーとしての「合宿」だ。

私たちは普段リモートベースで働いているけれど、設計を固めるタイミングなど顔を合わせて詰めた方が良い作業が溜まってくることがある。そうしたときに、「そろそろ合宿しませんか」という言葉が出る。

このチームでの「合宿」とは、みんなで合わせて出社して1日かけて色々な作業を一緒にこなすこと。

単に「出社して一緒に作業しましょう」とかじゃないのが、いいなあと思う。 「合宿」はなんか特別だ。みんなで集まった時間を大事に使わないとなと思う。 集まった日に何をするか、しっかりと意識して過ごせる。

これはリモートがあたり前の時代の、出社のための新しいパターンの1つなのかもしれないな、と感じた。