原稿翻訳レビューについて
2025年5月ごろ、以下の記事にて翻訳書の原稿レビューワーが募集されていたので、応募しました。
この記事は、その翻訳原稿レビューに参加したレポートになります。
要約
- 翻訳書の原稿レビューワーとして29名が参加し、GitHubベースのモダンな環境、かつ誰でも気軽に参加できる環境が整備されていた
- レビューワーには用語や表現の理解しやすさ、読者が引っかかる点の指摘が期待された
- 35日間かけて計画的に通読し、訳の自然さ、否定形の読みやすさ、主語の明確性などを中心に、59件のIssueを起票してレビューに貢献した
- AI翻訳が普及する中で、翻訳書を出版するプロセスや意義について実体験を通じて考察する機会となった
書籍情報
Vlad Khononov著”Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems”（2023）が、島田 浩二さんの翻訳によって『ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則』（2025）として出版されました。
この本は、その重要性にも関わらず「結合」について深く理解されていないのが実情という背景の下、まず構造化設計やオブジェクト指向設計に用いられてきた「結合」に関するモデルや評価手法を包括的に解説。さらに、複雑性を管理し、モジュール性を高める設計ツールとして「結合」を使用する新たなアプローチを提案します。
著者は『ドメイン駆動設計をはじめよう』（オライリージャパン）と同じVlad Khononov氏となります。
ちなみにこの方、今度のFindyアーキテクチャカンファレンス2025でもキーノートスピーチがあります。
この書籍の個人的なおすすめポイントは以下です
- ソフトウェアコンポーネントの観点で「結合」「複雑性」の解像度が上がります
- 特に、良いとされている「疎結合」とは一体どの程度が疎なのか？という問いへの解答があります
- 本書では、曖昧になってしまった結合を再定義し、3つの次元（強度、距離、変動性）を導入して、そのバランスを考える設計手法を提唱しています
書籍の内容については、以下で記事化したので参考にしていただけると嬉しいです。
レビューの目的と参加の目的
レビューワーへの期待値（レビュー依頼の目的）は以下です。
- 用語や表現などが想定対象読者層にとって、理解できるものであるかを確かめたい
- 読者が読んでいて引っかかった、理解しづらかった点を明らかにしたい
私自身のレビュー参加の目的は以下でした。
- 翻訳書が出版されるプロセスを（一部でも）知りたかった。どこまで訳にこだわるのか、原著の味をどう伝えて残すのか。
- Webブラウザで翻訳が当たり前の時代に翻訳書を出す意義はあるのか考えたかった。特に、O’Reilly Platformでの機械翻訳読み放題ができる中で。
- 原著の内容に興味があり、通読するためのモチベーションを得る機会だと考えた
原稿翻訳レビューの流れ
今回参加したのは翻訳原稿のユーザーレビューという全体の中の一部部分です。
翻訳者の島田さんが準備された環境は、勝手な想像よりもモダンで、実際のソフトウェア開発現場でのバージョン管理されたドキュメントレビューそのものでした。
GitHubに章ごとのRe::View 形式プレーンテキストファイルがpushされていました。
レビューワーがGitHub Issueを起票して、修正がpushされるとGitHub ActionsによってPDFが生成され、いつでも最新版が閲覧できるようになっていました。
また、レビュー説明書（README）も丁寧で、レビュー体験を考慮していただいてるなと感じる節が至る所にあります。
レビューのハードルを下げようとされる努力が伝わってきました。なので、誰でも気軽に作業できる環境となっていました。
ちなみに、今回のレビューワーは29名でした。
レビュースタイル
29名もいるので、後から参加された場合にはコメント数が減ってきたかなと思います。
なので、がっつり貢献したい場合には前半からの参加が良いかなと思います。
一方で、完成品に近くなった後半から通読することで、積み重ねた修正の整合性や、N=1の意見で反映された修正に対する第三者レビューにもなるので、後半参加もとても意味のあるスタイルかなと思います。
自分は通読したかったので、読書計画を立てていました。
1日5〜10ページで、35日くらいで読み終わりました。ガントチャート作っていたので、ノルマが分かりやすかったです。こんな読み方をしたのは初めてでした。
実際のレビュー内容
Issueは総数600件ほど、自分も59件起票しました。
私が実際に起票したIssueをピックアップして紹介します。原稿翻訳レビューに興味ある方の参考になればと思います。
訳が不自然に感じたもの
事例1: 静的コナーセンスは、モジュールが相互に通信するために調整する必要がある、異なるインターフェイスの決定を示している。
原著
Static connascence describes the different interface decisions modules need to coordinate to communicate with each other.
原稿初版
静的コナーセンスは、モジュールが相互に通信するために調整する必要がある、異なるインターフェイスの決定を示している。
出版初版
静的コナーセンスは、モジュールが相互に通信するために調整しなければならない、さまざまなインターフェイスの合意事項を示している。
コメント
ここでの“decisions”が単なる「決定」よりも「決定事項」や「合意事項」という表現の方が普段使いに近いという主旨のコメント。
事例2: 可能な偶発的な複雑性の排除を伴う
原著
the elimination of possible accidental complexities
原稿初版
可能な偶発的な複雑性の排除を伴う
出版初版
偶有的な複雑性の排除を伴う
コメント
“possible”が重複感があるという主旨のコメント。
事例3: 静的コナーセンスと動的コナーセンスのレベルは平行である
原著
The levels of static and dynamic connascence are parallel.
原稿初版
静的コナーセンスと動的コナーセンスのレベルは平行である
出版初版
静的コナーセンスと動的コナーセンスのレベルはどちらが高いとは一概にはいえない
コメント
「レベルが平行」という表現が聞き馴染みないという趣旨のコメント
否定形が読みにくく感じるもの
事例4: 複雑なシステムは試行錯誤の面倒なプロセスを経なければ変更できなくする
原著
a complex system can only be changed through a tedious process of trial and error
原稿初版
複雑なシステムは試行錯誤の面倒なプロセスを経なければ変更できなくする
出版初版
複雑なシステムは面倒な試行錯誤のプロセスを経なければ変更できない
コメント
「変更できなくする」が否定形＋まどろっこしい表現という主旨のコメント
事例5: 変更が予想されないコンポーネント間の結合が理想的なものでなかったとしても、それは必ずしも深刻な問題ではない。
原著
less-than-ideal coupling between components that are not expected to change is not necessarily a severe issue.
原稿初版
変更が予想されないコンポーネント間の結合が理想的なものでなかったとしても、それは必ずしも深刻な問題ではない。
出版初版
変更頻度が低いコンポーネント間であれば、理想的でない結合があっても深刻な問題とはならない。
コメント
否定形が3箇所もあって難しいという主旨のコメント
主語が曖昧になるもの
事例6: 知識がソフトウェアシステム内を流れるための「パイプ」は、ソフトウェアシステム内のモジュールの設計、そしてより重要なのが、モジュール間の相互作用である。
原著
The “pipes” through which this knowledge flows in software systems are the design of its modules and, more significantly, the interactions between the modules.
原稿初版
知識がソフトウェアシステム内を流れるための「パイプ」は、ソフトウェアシステム内のモジュールの設計、そしてより重要なのが、モジュール間の相互作用である。
出版初版
知識をソフトウェアシステム内に流すための「パイプ」は、モジュールの設計そのものであり、とりわけ重要なのが、モジュール間の相互作用である。
コメント
主語「パイプ」と補語「モジュールの設計」の関係が分かりにくいという主旨のコメント
事例7: ある決定を再検討する必要がある場合、変更はその決定を「隠ぺいする」モジュールのみが影響を受けるべきであり、
原著
If a decision has to be revisited, the change should only affect one module, the one that “hides” it,
原稿初版
ある決定を再検討する必要がある場合、変更はその決定を「隠ぺいする」モジュールのみが影響を受けるべきであり、
出版初版
ある決定を再検討する必要がある場合、その決定を「隠ぺいする」モジュールのみが変更の影響を受けるべきであり、
コメント
「変更は」が主語に見えてしまったという主旨のコメント
直訳が難しいもの
事例8: 数年後にコードベースをメンテナンスしなければならなくなったとしたら、システムの挙動を予測し、影響を受けるコンポーネントの変更の影響を理解できるだろうか？
原著
If you had to maintain the codebase years from now, would you be able to predict the system’s behavior and understand the impact of changes to any affected components?
原稿初版
数年後にコードベースをメンテナンスしなければならなくなったとしたら、システムの挙動を予測し、影響を受けるコンポーネントの変更の影響を理解できるだろうか？
出版初版
数年後にコードベースをメンテナンスしなければならなくなったとしたら、システムの挙動を予測し、変更によるコンポーネントへの影響を理解できるだろうか？
コメント
「影響を受けるコンポーネントの変更の影響」という表現が認知負荷が高いという主旨のコメント
原著バグと思われるもの
事例9: 第6章では、非公開インターフェイスを介して通信することがより多くの知識を共有し、したがって接続されたコンポーネント間の結合が強くなることを説明した。
原著
Chapter 6 discussed how communicating through private interfaces shares more knowledge, and thus results in stronger coupling between the connected components.
原稿初版
第6章では、非公開インターフェイスを介して通信することがより多くの知識を共有し、したがって接続されたコンポーネント間の結合が強くなることを説明した。
出版初版
第5章では、非公開インターフェイスを介して通信することで、より多くの知識が共有され、その結果、接続されたコンポーネント間の結合が強くなることを説明した。
コメント
参照先の章が間違っているのでは？という主旨のコメントです。
非公開インターフェイスを介して通信すること云々は、第5章の構造化設計の内容結合の内容に思えました。
翻訳者さんも断言が難しいようでしたが、お互いに原著バグかも知れないという結論に至り修正されました。
専門用語の訳
事例10: インターフェイスフットプリント
原著
the interface footprint
原稿初版
インターフェイスフットプリント
出版初版
インターフェイス量
コメント
聞き馴染みがないという主旨のコメント
事例11: 線形/スーパーリニア/サブリニア
原著
Linear/Superlinear/Sublinear
原稿初版
線形/スーパーリニア/サブリニア
出版初版
線形/サブリニア（劣線形）/スーパーリニア（優線形）
コメント
線形とリニアという表現が混在して統一感がないという主旨のコメント。
数学では劣線形、優線形という表現があることから、それらを併記することで統一感を演出させる提案。
事例12: アイデンティティのコナーセンス
原著
Connascence of Identity
原稿初版
アイデンティティのコナーセンス
出版初版
同一性のコナーセンス
コメント
他のコナーセンスとは違ってカタカナだったので、その意図を確認の上、「識別」とも訳されるアイデンティティをそのまま使うよりも「同一性」とした方が分かりやすいという提案。
過去の翻訳書「ソフトウェアアーキテクチャの基礎」との整合性よりも分かりやすさ重視で採用いただいた。
読者目線でシンプルに不明だったこと
事例13: このシリーズは、リアクティブ、オブジェクト指向
原著
The series emphasizes organic refinement with a variety of approaches—reactive, object,
原稿初版
このシリーズは、リアクティブ、オブジェクト指向
出版初版
[変更なし]
コメント
ここでいうリアクティブとは何なのか分からなかったという主旨のコメントです。
訳者さんからは以下の返信があり、変更などは特にしない方針となりました。
リアクティブシステムやその周辺の考え方のことと考えています。
参考：https://www.reactivemanifesto.org/ja
Vaughn Vernon自身が「Reactive Messaging Patterns With the Actor Model」という書籍を書いていたりするのもありますし、シリーズの中でいうと「Architecture for Flow: Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies」あたりがこれに当たる書籍なのかなと考えています。
10年前くらい？は上記のリアクティブ宣言もあって結構盛り上がっていた印象があったのですが、確かに最近は聞かないので、もはやわからない人多そうですかねえ...
Reactive Messaging Patterns With the Actor Model：https://www.amazon.co.jp/dp/0133846830
Architecture for Flow: Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies：https://www.informit.com/store/architecture-for-flow-adaptive-systems-with-domain-9780137392810
事例14: 新しいイベントの追加や既存イベントの変更によってSCM のイベントソースモデルが進化した場合
原著
When the SCM’s event-sourced model evolved—either by adding new events or by modifying existing ones—
原稿初版
新しいイベントの追加や既存イベントの変更によってSCM のイベントソースモデルが進化した場合
出版初版
新しいイベントの追加や既存イベントの変更によってSupport Case Managementのイベントソースモデルが進化した場合、
コメント
SCMがSupport Case Managementの略であることが分からなかったという主旨のコメントです。
読んでいて分かりにくい部分は、原著の説明からどこまで崩すべきか
意訳とは、発話者（書き手）の意図、感情、ニュアンス、語感の込められた文章を、文脈や文化的背景も考慮して、深く調査して訳すものである。原文
翻訳は原著の表現をそのまま移植したいという気持ちと、分かりやすさなどのローカライズを優先させたいという異なるものの両立が難しいのかなと思います。
なので、意訳がどこまで許されるのか気になっていました。
そこで、実際の指摘事例を通して、確かめました。
結論としては、「原文忠実：分かりやすさ＝６：４」くらいのバランスに感じました。
直訳に近い形で無理が出てくれば、分かりやすさ優先で改変することがありました。
小説と違って技術書なので、分かりやすさの比重が大きめなのは納得です。
意訳よりも原文忠実だったケース
原文
The system has two different implementations of the algorithm.
システムはアルゴリズムの 2 つの異なる実装を持つ
レビューによる提案
それぞれのモジュールは実装されているアルゴリズムが異なっている
訳者の意見
なるべく原文から離れすぎないようにできると良いなと考え、以下のように対処することで修飾関係のわかりにくさを改善してみようと思います。
結果（出版初版）
システムはアルゴリズムに対する2つの異なる実装を持つ
原文表現を削除したケース
原文
Global complexity turns into local complexity when the system is observed from a higher level of abstraction. In other words, changing the perspective turns the system into a component in another, larger system. Consequently, global complexity turns into local complexity when observed from a higher level of abstraction.
より高い抽象化レベルからシステムを観察すると、大域的複雑性は局所的複雑性に変わる。言い換えれば、視点を変えることで、システムはより大きな別のシステムのコンポーネントになる。結果として、より高い抽象化レベルから観察すると、大域的複雑性は局所的複雑性に変わる。
レビューによる提案
「より高い抽象化〜」というフレーズが繰り返されていて、誤植かな？と思ってしまいました。言い換えただけなのに、「結果として、〜」と言われると重複感があるなという感想です。原著でも繰り返されていました。
訳者の意見
ここは構造上無くても情報落ちなさそうなので、思い切って削ってしまおうと思います
結果（出版初版）
より高い抽象化レベルからシステムを観察すると、大域的複雑性は局所的複雑性に変わる。言い換えれば、視点を変えることで、システムはより大きな別のシステムのコンポーネントになる。
専門用語の訳は特殊なケース
原文
architecting distributed systems
アーキテクトする
レビューによる提案
アーキテクティングする
アーキテクチャを設計する
設計する
構築する
訳者の意見
出身会社によっては、「アーキテクトする」が一般的なところもあるのですが、個人的には名詞と混ざるので耳に馴染まないところがあり。「アーキテクティング」なら行為を指すという使い分けは通用しそう。
結果（出版初版）
アーキテクティングする
タイトル翻訳の熱い議論
翻訳書のタイトルについては、最初からIssueが提起され、やっと最後にクローズするほど、参加者全員で考えていました。
原著タイトル
Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems
原稿初版タイトル
ソフトウェア設計における均衡結合の実現：モジュラーシステムのための普遍的原則
素直な訳で、これでも分かるという感じでしたが、提起された論点は以下でした。
- 「Balancing Coupling」の訳
- 「モジュラーシステム」の意味が曖昧
タイトル候補案
- ソフトウェア設計の均衡結合：実装・進化・保守を容易にするモジュール化―体系的知識と実践
- 均衡結合：ソフトウェアの実装・進化・保守を容易にするモジュール化 ― 体系的知識と実践
- バランスの取れた結合を導くソフトウェア設計の原則と理論：持続可能な成長を支えるモジュール設計
- バランスの取れた結合を導く原則と理論：持続可能な成長を支えるモジュール設計
- バランスの取れた結合を導く原則と理論：ソフトウェアシステムの持続可能な成長を支えるモジュール設計
- 結合を制するソフトウェア設計：モジュール化の普遍的原則
- バランスのとれたソフトウェア設計：持続可能なシステムを構築するための普遍的原則
- ソフトウェア設計における結合バランス：持続可能なシステムを構築するための普遍的原則
- ソフトウェア設計における結合：持続可能なシステムを構築するためのバランスのとれたモジュール化原則
出版されたタイトル
ソフトウェア設計の結合バランス：持続可能な成長を支えるモジュール化原則
訳の正しさも重要ですが、書籍タイトルというのはマーケティング要素もあるために幅広い検討が必要でした。
途中、編集担当者さんによる確認にて、以下の要望が追加された上で、このタイトルに決まりました。
- メインタイトルでソフトウェア設計カテゴリーであることがわかるようになっていて欲しい
- 構成要素をもっと少なく
私自身も、「Balancing Coupling」の訳はタイトルと本文で分けても良いという考えでした。
書籍タイトルにも影響を与えれるのは、原稿レビューでも、とても貴重な体験でした。
O’Reillyをブラウザで機械翻訳したときの読みやすさとの比較
原著はO'Reilly Platform会員なら読み放題です。なので、WebブラウザでGoogle翻訳などすれば、日本語でも読めます。
どちらかが常に読みやすい、という訳ではなくGoole翻訳が読みやすいときもあれば、そうでない場合もありました。
翻訳書を読んでいて、違和感を感じた部分は、たいてい機械翻訳の方が分かりやすい、という意外な発見もありました。
機械翻訳が苦手そうだなと感じたのは、意訳することやカタカナに翻訳される外来語です。
具体的には、ブラウンフィールド、ヒューリスティック、アーキテクト、ポリグロット、シリアル化という用語は、カタカナのまま訳され、それが読み手に普及されている表現かどうかは関係ありません。
翻訳書の場合は、いい感じに修飾語を追加したり、訳注による解説を付けることができます。なので、翻訳書の方が理解しやすいかと思います。
また、以下の太字部分はGoogle翻訳と初版原稿の比較です。私は短く簡潔なGoogle翻訳のほうが分かりやすいと感じましたが、個人差がありそうです。
- 原文「Its interface exposes the knowledge of its functionality and how to integrate with the component.」
- Google翻訳「そのインターフェースは、その機能に関する情報と、コンポーネントとの統合方法を公開します。」
- 翻訳書「上流コンポーネントのインターフェイスは、そのコンポーネントの機能とそのコンポーネントとの統合に関する知識を公開する。」
生成AI時代に翻訳書を出す意義はどこにあるか
この記事にもあるとおり、AI翻訳されたと思われるものが実際にオンライン配信、出版される時代になりました。
私は今回の作業を通じて、翻訳書を出す意義について自分なりの考えをしてみたかったです。
翻訳原稿レビューの中で気付いたのは、この作業は機械翻訳の70点を90点に引き上げる作業であることです。
全体の文脈理解や重要事項の理解のためには70点の翻訳で大丈夫だと思います。
なので、まずは需要喚起のために機械翻訳版を公開し、反響に応じて訳者を付けるなど、ある種のマーケティング戦略上の異なる手法という位置付けとも考えられそうです。
実際、上記の記事内で引用された2つの書籍は、LLMや生成AIの応用に関する書籍で、内容の寿命が相対的に短そうなものかなと推察します。
逆に、以下のような単なる翻訳以外の体験、価値を提供するには70点では物足りないのかな、とも思いました。
- 長く愛用して欲しい気持ち
- 言語でつまづかないで本質を理解して欲しいという思い
- クソな翻訳にお金を払いたくない気持ち
- 幅広い読者への配慮
- 原著者へのリスペクト
良い内容の本だから、その意図をしっかりと伝える手段として人間による作業が入ってるのかなと。この辺は生成AIとの付き合い方と同じですね。
今回のようなボランティアレビューという仕組みも特徴的だと思いました。この辺はソフトウェアエンジニアリングの活発なコミュニティやgivingな文化に支えられている側面もあるから成立していそうで、分野が変われば翻訳の意義やROIも変わってきそうです。
まとめ
レビュー参加の目的も果たせ、レビューはとても良い経験となりました。
また、特殊なスキルは不要で、誰でも参加できるこの取り組みはとてもおすすめです。
翻訳書を出す意義は健在でニーズも高いと感じました。一方で、機械翻訳でも十分分かりやすいとも感じたので、これまで翻訳の機会がなかった鮮度が重要な書籍やニッチな書籍についても機械翻訳出版が増えてきそうな感触も得ました。