はじめに
2026年2月19日、Developers Summitの会場に向かう電車の中で、スライドを開いた。40分の発表。500ページの本を翻訳して、そこから何を伝えるか。1ヶ月かけて構成を練った資料が、手元にある。正直、疲弊していた。5人で分担したとはいえ、各章のレビューは全員がやる。1つの用語の訳語を決めるのにSlackのスレッドが50件を超えたことがある。"sociotechnical"を「ソシオテクニカル」とカタカナにするか、意味を取って訳すか。結局カタカナにした。正しい判断かどうかは、今もわからない。画面をスクロールしながら、ふと思った。原書を手に取る前の自分は「モダナイゼーション＝技術的な刷新」だと思っていた。古いシステムを新しく作り直す話だと。あの頃の自分が今日のスライドを見たら、きっと驚くだろう。技術の話が、全体の3割もない。
翔泳社様より『Architecture Modernization』の翻訳書である『アーキテクチャモダナイゼーション』が発売されます。翻訳者として参加しました。本書はレガシーシステム刷新の良い指南書です。DDDやチームトポロジーなどの手法を紹介、技術・組織・戦略の3つの視点からシステムの現代化を解説します。 pic.twitter.com/8kOd7Z400Q
— nwiizo (@nwiizo) 2026年1月16日
Nick Tune & Jean-Georges Perrin著「Architecture Modernization」（Manning, 2024）。原書を読んで、これは日本語で読めるようにしなければならないと思いました。自分から編集者に持ち込んで翻訳を依頼し、スリーシェイクのメンバー5名で翻訳しました。O'Reilly Japanから出版されています。
この記事では、翻訳書を出版するまでの話と、その内容をもとに3回登壇した話を書きます。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。
翻訳で最も難しかったのは英語ではない
技術書翻訳を手がけるたび、わかることが1つ増えるのと引き換えに、わからないことが3つ増えていく。これは自己紹介でいつも書いていることですが、冗談ではなく本当のことです。
「Architecture Modernization」は全17章、6部構成、500ページを超える書籍です。この「6部構成」の設計が、翻訳してみて初めてわかる凄みを持っています。
第1部「Why」で動機を語り、第2部「Discovery」で現状を可視化し、第3部「Design」で未来を描き、第4部「Organization」で組織を設計し、第5部「Technical」で技術を選定し、第6部「Execute」で実行する。一見すると自然な流れに見えます。しかし注目すべきは、技術の話が第5部です。つまり本の後半まで出てこないことです。500ページ中、技術的な実装の話が始まるのは後半に入ってからです。
これは構成上のミスではありません。意図的な設計です。多くのモダナイゼーションが失敗する理由は、技術選定から始めることにある。翻訳しながら、この主張を何度も反芻しました。覚えがある。以前「Kubernetes入れれば解決する」と提案したことがある。技術的には正しかった。だが半年後、誰もマニフェストをメンテナンスしていなかった。導入を決めた自分と、運用する組織の間に、会話が足りなかった。「マイクロサービス化しよう」「Kubernetesを入れよう」という風に手段から入る。なぜその手段が必要なのかを組織が理解していなければ、どんな技術的に正しい刷新も定着しない。著者たちは本の構成自体で、この順序の重要性を体現しています。
翻訳で最も難しかったのは英語ではありません。著者の思考を追体験することでした。なぜEventStormingがWardley Mappingより先に来るのか。EventStormingは「今、何が起きているか」を可視化する手法で、Wardley Mappingは「これからどう進化するか」を予測する手法です。現状が見えていない状態で未来を語っても意味がない。だからEventStormingが先に来る。1つ1つの章の配置に、こうした構造的な理由がある。翻訳者は章の順番を変えられません。だからこそ、その順番の意図を理解しなければ、日本語として自然な接続を作れない。たとえば第7章の"pivotal event"という概念を訳すとき、直訳すれば「転換点となるイベント」ですが、著者がこの言葉に込めている重みが英語の表面からは読み取れなかった。3日間、前後の章を行き来して、ようやく「これはビジネスドメインの境界を定義するための概念だ」と腑に落ちた。1つの概念に3日。追体験できたのかどうかも、正直わからない。著者に「この理解で合っていますか」と聞きたかった場面は、数えきれないほどあります。
ここまでは翻訳者としての実感です。書籍はこの問題をより構造的に捉えています。アーキテクチャモダナイゼーションと聞くと、技術の話をイメージする。古いシステムを新しいアーキテクチャに置き換える。マイクロサービス化する。クラウドネイティブにする。原書を手に取る前の私はそう思っていました。
原書を読んで、その認識が変わりました。読書感想文にも書いたことですが、この書籍が扱っているのは「技術」「組織」「戦略」という3つの変数が相互に影響し合う構造的な問題です。 私はこれを三体問題と呼びました。1つだけを最適化しても解にたどり着けない。技術的に正しい設計をしても、組織がそれを受け入れる準備ができていなければ定着しない。組織を変えようとしても、ビジネスの言葉で語れなければ経営層は動かない。経営層を動かしても、アーキテクチャの制約が可視化されていなければ判断材料がない。この循環が、モダナイゼーションの本質的な難しさです。
では、なぜ翻訳しようと思ったのか。読み進めるうちに気づいたのは、これは自分が業務で経験してきたことそのものだということです。実際にモダナイゼーションに取り組むと、ほとんどが人間や組織と向き合うことになる。コードを書き換える時間より、ステークホルダーと話す時間のほうが長い。チーム間の境界をどう引くか、意思決定のプロセスをどう変えるか、経営層にどう説明するか。これらはすべて技術の外側にある問題です。自分が現場で感じていたことを、この書籍は500ページかけて体系化していた。「これは日本語にしなければならない」と思いました。それが、編集者に持ち込んだ理由です。
翻訳作業を経て、さらに見えてくるものがありました。読書はそもそもかなりの再構築を伴う行為です。著者の思考を自分の中に取り込み、自分の経験や知識と接続し、理解を組み立て直す。だが翻訳は、その再構築したものを読者に伝えなければならない。自分の中で「なるほど」と腑に落ちただけでは足りない。その「なるほど」を日本語の文章として、まだ読んでいない読者に届く形で出力する必要がある。ここに読書と翻訳の決定的な差があります。読書は「なるほど」で終われる。翻訳は「なるほど」を日本語にしなければならない。その過程で、著者の主張の核心が自分の中で言語化されていきました。500ページを訳し終えたとき、自分の言葉として残った結論があります。モダナイゼーションの本質は、完璧なシステムを作ることではない。変化し続ける能力を組織に埋め込むことだ。 技術は手段であって、目的ではない。目的は「組織が変化し続ける能力を持つこと」であり、そのためにはまずビジネスを理解し、現状を可視化し、組織を設計する必要がある。ただし、「変化し続ける能力」を持つ組織を、私は見たことがあるだろうか。変化に適応した組織は見た。だが「変化し続ける」つまり適応を止めない組織は。人間は疲れる。組織も疲れる。この書籍が描く理想は正しいと思う。思うが、理想と現場の間には、この書籍では語りきれない距離がある。その距離を埋めるのが、翻訳者として次にやるべきことだと思っています。
3回の登壇
翻訳が終わり、出版された。嬉しかった。嬉しかったが、同時に気づいたことがありました。500ページかけて体系化された知識は、500ページを読まないと届かない。翻訳しただけでは足りない。「この本の価値をもっと伝えたい」という欲が出てきました。500ページの本を読んでもらうには、まず「読んでみよう」と思ってもらう必要がある。
ただ、同じ内容を3回話しても意味がない。聴衆が違えば、刺さる切り口も違います。開発者は「何をすべきか」を知りたい。書籍を手に取ろうとする人は「どこから読めばいいか」を知りたい。マネージャーは「どう説明すればいいか」を知りたい。同じ書籍を、3つの異なるレンズで切り直しました。全ての資料を公開しています。
1. Developers Summit 2026 — 「意志を実装するアーキテクチャモダナイゼーション」
2月19日、40分。最も力を入れた登壇です。
テーマは「意志」でした。なぜ「意志」なのか。AIがコードを書くコストを劇的に下げた今、技術的な実装力だけでは差がつかない。コードは生成できる。アーキテクチャのパターンも提案できる。だが、ここに落とし穴がある。
生成されたコードを理解せずに受け入れ続けると、モデルごとに確率が違うパチンコを打ち続けているのと変わらない。なぜ動いたのかわからない。なぜ失敗したのかもわからない。わからないまま先へ進み続けて、気づいたときには、自分では何も判断できなくなっている。スキルも知識も積み上がらないまま、コードだけが積み上がっていく。
これはモダナイゼーションの文脈でも同じです。AIに「マイクロサービスに分割して」と頼めば、それらしいコードは出てくる。だが、なぜその境界で分割するのか、その判断の根拠を自分の中に持っていなければ、数ヶ月後に「なぜこの構造なのか」を誰も説明できないシステムが残る。技術的負債の新しい形です。「自分たちの組織をどうしたいか」という問いには、AIは答えられない。答えられるのは、その組織にいる人間だけです。 差がつくのは「自分たちの組織をどうしたいか」を決められるかどうかだ。その決断こそが「意志」であり、書籍が提供するのは意志を形にするためのフレームワークだ——という構成で話しました。
書籍の内容を「ビジネスへの意志」「アーキテクチャへの意志」「組織への意志」という3つの軸で再構成しています。この3つは独立していません。技術と組織と戦略が互いに影響し合う。書籍ではこれを「ソシオテクニカル（社会的側面と技術的側面の相互作用）」と呼んでいます。原書を読んだときの感想文で、私はこの構造を「三体問題」と表現していました。デブサミの発表でもそのまま使いました。聴衆に届く比喩だと思ったからです。物理学の三体問題と同じで、3つの変数が相互に影響するため、1つだけを最適化しても解にたどり着けない。アーキテクチャを変えたければ組織を変えなければならない。組織を変えるにはビジネスの言葉で語らなければならない。ビジネスの優先度を変えるにはアーキテクチャの制約を可視化しなければならない。この循環をどこから断ち切るか。書籍が提案する突破口の1つが、コンウェイの法則の逆活用です。コンウェイの法則は「システムの構造は、それを設計した組織のコミュニケーション構造を反映する」と述べています。これを逆手に取り、望ましいアーキテクチャに合わせて組織を再設計する。
持ち帰ってほしかったのは手法ではありません。「自分の組織やシステム全体をどうしたいか」という問いです。
登壇を終えて、質疑応答の時間になりました。最初の質問は「具体的にどのツールから始めればいいですか」だった。手法ではなく問いを渡したつもりが、手法を求められた。そのとき気づきました。自分も原書を読む前はそうだった。「何を使えばいいか」が知りたかった。問いの手前に立っている人に、いきなり問いを渡しても届かない。まず、問いにたどり着くための地図が必要だったのかもしれない。
2. 3-shake SRE Tech Talk 特別回 — 「30分でわかるアーキテクチャモダナイゼーション」
同日の夜、30分。社内イベントの特別回です。デブサミで40分話した数時間後に、別の聴衆の前に立っている。質疑応答で「ツールは？」と聞かれた感覚がまだ残っていました。問いを渡すだけでは届かない。まず地図を渡す必要がある。
こちらは書籍の全体像を掴むための「地図」を提供する発表でした。500ページの本を読む時間がない人に向けて、17章の構成と各章の核心メッセージを30分で伝える。どこから読めばいいかわからない人に向けて、読者のタイプ別に読書ルートを案内する。
500ページの書籍を前にして「どこから読めばいいかわからない」という声は多い。この発表では、読者の立場に応じた入口を提案しました。自分が読者だったら第5部から読み始めていたと思う。技術者はそうなりがちだ。だがそれだと、なぜその技術パターンが必要なのかという文脈が見えない。マネージャーなら第2部、ビジネスとの接続を扱う章から。経営層には第1章をすすめている。全体戦略の俯瞰だ。最短ルートは第1章→第7章→第11章の約60ページで、書籍の骨格が見えます。全体像を先に知ることで、必要な章だけ深掘りできるようになります。
地図を渡すのは、問いにたどり着くための前段です。ツールや手法はAIに聞けばそれなりの答えが返ってくる時代になった。「EventStormingのやり方を教えて」と聞けば、手順は出てくる。だからこそ、登壇で提供すべきは手法の解説ではなく、「なぜそれをやるのか」「自分たちの組織にとって何が必要なのか」を考えるための地図のほうだと思いました。地図があれば、問いにたどり着ける。問いがあれば、手法は自分で選べる。
「モダナイゼーションに『遅すぎる』はない。始めた瞬間から組織は変わり始める。」この一文で締めくくりました。
3. EMConf 2026 — 「技術的負債の泥沼から組織を救う3つの転換点」
3月4日、40分。エンジニアリングマネージャー向けのカンファレンスです。技術の話をする場ではなく、マネジメントの文脈で技術を語る場だった。この聴衆に向けて話す機会は、ありそうでなかった。
登壇では切り口を変えました。デブサミでは「意志」、SRE Tech Talkでは「地図」。どちらも書籍の内容を伝える発表でした。EMConf 2026では、聴衆がエンジニアリングマネージャーです。彼らが日々直面している「技術的負債」を入口にして、書籍の内容を再構成しました。
なぜEMに向けてこの話をしたのか。技術的負債の問題は、エンジニアなら誰でも感じている。だが、エンジニア個人では解決できない。技術的負債の発生と蓄積は、組織の意思決定構造に根差しているからです。それを変えられる立場にいるのがEMです。Stripeの調査によれば、優秀なエンジニアは時間の42%を技術的負債の対応に奪われています。42%です。週5日のうち2日は、新しい価値を生み出すことではなく、過去の負債を返すことに費やされている。これは個々のエンジニアの能力の問題ではありません。構造の問題です。そして構造を変える権限と責任を持つのが、EMという役割です。
技術的負債には負のサイクルがあります。 技術的負債が溜まるとデリバリーが遅延する。遅延すると経営層の信頼が失われる。「成果が見えないから」と投資が削減される。すると、さらに負債が溜まる。見たことがある光景だ。このサイクルが回り始めると、優秀なエンジニアから辞めていきます。負のサイクルの加速です。コードを書き換えても、このサイクルは断ち切れません。なぜなら、サイクルの駆動力は技術ではなく、組織の構造、意思決定のプロセス、投資判断の基準、チーム間の依存関係にあるからです。
この構造的な問題に対して、書籍の内容を3つの転換点として再構成しました。
- 学ぶ力: 外部のソリューションを導入するのではなく、組織が自ら発見する能力を育てる。書籍が紹介するAMET（Architecture Modernization Enabling Team）は、答えを持ち込むチームではなく、組織の学習を促進するチームです。EventStormingやWardley Mappingは道具であって、目的ではない
- 語る力: 技術的負債をビジネスの言葉に翻訳する。「このシステムは遅い」ではなく「この遅さが月間いくらの機会損失を生んでいるか」で語る。書籍のCore Domain Chartは、技術的な資産をビジネス価値の軸で可視化する手法で、経営層との対話を可能にします
- 始める力: 不確実性を前提に設計する。全社一斉のモダナイゼーションではなく、1つのバリューストリームで検証し、3-6ヶ月の学習サイクルを回す。書籍の「Nail it then scale it」。まず1箇所で釘を打ち、うまくいったら広げる
学ぶ力→語る力→始める力。この順番には構造的な理由があります。 学ばずに語れば空論になる。語らずに始めれば孤立する。順番を飛ばせば、その先で必ず壊れる。ただし、現実の現場で「まず学びましょう」が通ったことは、正直あまりない。以前、チームに「EventStormingをやりましょう」と提案したとき、返ってきた言葉は「それ、何日かかるんですか。リリース日は動きませんよ」だった。「いいから早く直してくれ」と言われる。順番が正しいことと、順番通りにできることは、別の問題です。
おわりに
3回の登壇を終えて、残った問いがあります。デブサミでは意志を、SRE Tech Talkでは地図を、EMConfでは3つの転換点を渡しました。だが、これらを手に入れた組織は、その後どうなるのか。翻訳書の帯に、私はこう書きました。
「何度書き直しても、また遅くなる。」
実は書籍にこの一文があるわけではありません。これは私にとっての「だが、ならざるべきか？(Or should I?)」です。500ページを訳し終えて、自分の中にあった言葉です。システムを刷新して、数年後にまた同じ問題に直面する。書き直したのに、また遅くなる。なぜか。コードの問題だけではない。組織が学び続ける仕組みを持っていないからです。技術を刷新しても、組織の学習能力が変わっていなければ、同じ構造が同じ結果を再生産する。
デブサミの発表でバイブコーディングの話をしました。あの話は、実は帯の一文と同じ構造を指しています。
バイブコーディングで動くコードを手に入れた人は、「書き直した」つもりになっている。だが、なぜ動いたのかを理解していない。理解していないから、次に同じ種類の問題が来たとき、また同じパチンコ台の前に座る。モデルが違えば確率が違う。今日は当たるかもしれない。明日は外れるかもしれない。当たっても外れても、自分の中には何も残らない。これを繰り返すうちに、「自分で判断する」という能力そのものが静かに失われていく。怖いのは、失われていることに気づかないことです。動くコードが手元にあるから、能力があると錯覚する。
組織のモダナイゼーションも同じです。技術を入れ替えただけで「刷新した」と思う。だが、なぜ前のシステムが遅くなったのかを組織が理解していなければ、新しいシステムもまた遅くなる。パチンコの台を変えただけだ。当たりの確率が少し上がっただけで、構造は何も変わっていない。
「何度書き直しても、また遅くなる」のは、書き直すたびに学んでいないからだ。 個人がコードを書くときも、組織がシステムを刷新するときも、問われているのは同じことです。あなたはこの経験から何を学んだのか。学ばずに次へ進むなら、それはパチンコだ。
こう書いていて、翻訳者として居心地の悪さを感じています。世の中の技術書の多くは、良いパチンコ台の選び方を教えているように見える。AI開発系の書籍はその典型で、しかも3ヶ月後には設定が変わる。では、この書籍が扱っているアーキテクチャモダナイゼーションの手法はどうなのか。EventStormingやWardley Mappingが3年後も有効だと、私は言い切れるだろうか。正直に言えば、手法としての賞味期限はわからない。だが、この書籍が教えているのは「どの台を選ぶか」ではなく「なぜあなたはパチンコを打っているのか」という問いのほうだと思っています。技術選定の前に、なぜその刷新が必要なのかを組織として理解する。その順序は、手法が入れ替わっても変わらない。たぶん。たぶん、変わらない。
3回登壇して、毎回異なる聴衆に向けて話しました。開発者には「意志を持て」と。書籍を手に取ろうとする人には「地図を渡す」と。マネージャーには「3つの転換点がある」と。切り口は違いますが、伝えたかったことは同じです。モダナイゼーションは技術プロジェクトではない。組織が変化し続ける能力を獲得することです。
冒頭の電車の中の自分に戻ります。原書を手に取る前の自分は「技術的な刷新」の本だと思っていた。あの頃の自分が今日のスライドを見たら驚くだろう、と書きました。3回の登壇を終えた今、もう1つ驚くことがあります。500ページを訳して、3回話して、それでもまだ語りきれていない。BVSSHフレームワーク（ビジネス価値に基づくポートフォリオ評価）、Independent Value Streams、Wardley Mappingとチームトポロジーの接続、1つ1つが独立した登壇テーマになり得る。500ページの密度は、翻訳を終えてなお、自分の中で展開し続けています。一読者としておすすめできるのでぜひ手に取ってみてください。
登壇のご依頼について
イベントや勉強会での登壇のお声がけをお待ちしています。 アーキテクチャモダナイゼーション、技術的負債、ソシオテクニカルな組織設計、翻訳の裏話、テーマは聴衆に合わせて柔軟に対応できます。5分のLTから60分の講演まで、お気軽にお声がけください。X（@nwiizo）へのDMで受け付けています。
