LeanとDevOps生産性の神話(4) - 翻訳についての感想などをつらつらと
今後のスタンダードになりうる素晴らしい翻訳
「LeanとDevOpsの科学」の翻訳についてですが、私は原書「Accelerate」を出版直後の2018年の3月に読んだあと、翻訳を翌年2019年の2月に読みました。翻訳の出版は原書と同年の2018年の11月なので、原書の出版からなんと8ヶ月での翻訳という超スピード翻訳ですね。私はまさか「Accelerate」がそんなに早く翻訳されると思っていなかったのと、邦題が「LeanとDevOpsの科学」となっていて、原書の副々題から採られていることもあって、翻訳が出ていることにまったく気が付かず、翻訳を読むのが出版の翌年と遅くなりました。
日本語版の翻訳はイマイチか？
スクラムフェス福岡2024で今井建男さんが日本語版の翻訳についてこのようにコメントされています。
さて本当に「LeanとDevOpsの科学」の翻訳はイマイチなのでしょうか。
私が翻訳を読んだ時の感想は今井さんとは真逆で、非常に素晴らしい翻訳だとおもいました。これなら、原書読むより翻訳読んだほうがよっぽどいいんじゃ(失礼)。。。
そもそも原書は著者が３人います。おそらく章ごとに担当がいて書いていると思われます。そして、章のあいだの統一性とかはまったくありません。取り上げられている内容は、アジャイル、DevOps、組織論、統計手法と多岐にわたります。さらに第16章は、唐突に３人とは別の著者Steve Bell氏、Karen Whitly氏によるハイパフォーマンス組織論があります。そのため原書は非常に読みにくく、私なら頼まれても絶対こんな大変な本の翻訳はやりたくないと思わせる内容です。
本書の翻訳の素晴らしいところは、技術用語をどのように翻訳するかにあたって、次にあげるさまざまな選択肢から
日本語(漢字)
カタカナ
もともとの英語
適切なものを選び出し、場合によってはルビや括弧を効果的に使って、過不足なく訳出しているところにあります。たとえばアジャイル用語として定着しつつある"Stakeholder"という単語を翻訳する場合にも、ビジネスの文脈では「利害関係者」と訳しながらも同時にルビで「ステークホルダー」と補足しています。こうすることで、対応する日本語の意味を理解できるのと同時にアジャイル用語としての「ステークホルダー」なんだということが理解できるようになっています。
さてでは翻訳の問題と指摘されている内容を一つ一つ見ていきましょう。
DevIOps用語、アジャイル用語の適切な翻訳表現
⚫︎ いくつかのDevOps用語、アジャイル用語が一般的な表現に置き換えられていたり、訳出されていなかったりする
⚫︎ “value stream， “kanban"， "batch"などなど
原書で"value stream"が使われている場所は5ヶ所あり、そのうち4ヶ所はそのまま「バリューストリーム」と翻訳されています。残る1ヶ所は付録Aの「Make the flow of work visible through the value stream」を「全業務プロセスの作業フローの可視化」と翻訳しています。この部分を指して「訳出されていな」いというのでしょうか。
そもそもこの付録Aには図が添付されており、同一項目が「Make Flow of Work Visible」となっているので解説部の訳文の表題に「バリューストリーム」が単語として含まれていないことは大きな問題ではないように思えます。
原書で"kanban"は2ヶ所。すべて既にアジャイル用語として定着しているカタカナの「カンバン」と訳出されています。
原書で"batch"は全部で28ヶ所につかわれており、おおまかに3種類に大別できます。"small baches"が18ヶ所、"batch size"が8ヶ所、"work batched/work in batches"が合わせて2ヶ所。"small baches"は「細分化」、"batch size"は「バッチサイズ」、"work batched"は「分割」"work in batches"は「作業の山を切り崩していく」と訳出されていて、少なくとも私が確認した部分で訳出されていない箇所は見つけられませんでした。
ところで、"kanban"はアジャイル用語として確立していると思いますが、"value stream"や"batch"は確立したDevOps用語かアジャイル用語なのでしょうか？私は不勉強で知らないのだけれどもし知っている方がいたら教えてほしいです。ひょっとしてScaled agile framework (SAFe)で言う"value stream"なのかもしれないけれど、寡聞にしてSAFeがそれほどのポピュラリティを得たとは聞いたことがないです。
すくなくとも私がみた限り「DevOps用語、アジャイル用語が一般的な表現に置き換えられて」いる場所はみつけられませんでした。
原書より明快で文脈を反映した翻訳
⚫︎ けっこう訳に揺れがある
⚫︎ "Lean Practices"など
原書で"Lean Practice"は6ヶ所。対応する翻訳は以下のとおり、
1章「リーンソフトウエア開発」のプラクティス
9章「リーン思考のプラクティス」
9章「リーン思考のプラクティス」(図のキャプション)
10章「リーンマネージメントのプラクティス」(図のキャプション)
10章「リーンマネージメントのプラクティス」(図のキャプション)
11章「リーン開発のプラクティス」
はっきり言って、これは翻訳のほうがいいのではないでしょうか。原書に反映して欲しいくらいですね。原書ではLean Practiceを「リーン開発」「リーン思考」「リーンマネージメント」というそれぞれ異なった文脈で使っているのを、翻訳ではきちんと汲み取って、日本語の読者にわかりやすいように訳文に取り込んでいます。まさにこれこそが翻訳のあるべき姿ではないでしょうか。その労力をまったく理解せずに翻訳の揺れと受け止められたら訳者も浮かばれないですね。
特に第1章の翻訳は秀逸なので原文と付き合わせてみましょう。
A recent Forrester (Stroud et al. 2017) report found that 31% of the industry is not using practices and principles that are widely considered to be necessary for accelerating technology transformations, such as continuous integration and continuous delivery, Lean practices, and a collaborative culture (i.e., capabilities championed by the DevOps movement).
米国の独立系調査会社Forrester Researchの最近のレポート［Stroud et al. 2017］によると、「継続的インテグレーション」「継続的デリバリ」「リーンソフトウェア開発」のプラクティス、協働を重視する組織文化など、テクノロジーの変革を加速させるのに必要だと広く見なされているプラクティスや原則を実践していない（すなわち、DevOpsで重視されている手法を採用していない）組織が業界全体の31%を占めている。
日本の読者のためにForresterが(アメリカ人エンジニアなら誰でも知っている)米国の独立系調査会社であることを補足し、「継続的インテグレーション」「継続的デリバリ」と同じ文脈で読者が理解できるように"Lean Practice"を「『リーンソフトウェア開発』のプラクティス」と訳しています。素晴らしいというしかないですね。プラクティスが重なっているのが気になりますが、これは原文がそうなっているためで訳者の責任ではないです。
ちなみに、ここで調査会社としてGartnerとかじゃなくてForresterが出てくるのには背景があって、DevOps関連の議論でも1,2を争う大論争になった2011年のNoOps論争の当事者だからですね。Forresterのリサーチャーが「俺たちが本当に必要なのはDevOpsじゃなくてNoOpsじゃないのか」という記事を書いたことがきっかけになりNetflixのエンジニアも参加して大きな論争にななりました。原書が出版された2018年当時はまだその記憶があるエンジニアも多かったので、Forresterが出てきてニヤリとした人もいたのではないでしょうか。
さまざまな作業の種類
⚫︎ 「修正」「修正作業」と訳されているところが、原文では
"rework"（手戻り）
原書で"rework"がつかわれているのは20ヶ所。訳文はここで触れられているとおり「修正」「修正作業」となっています。「手戻り」とどちらがいいかは一見趣味のような気もしますが、このような文の場合はどうでしょうか。
significant architectural problems and defects that involve a substantial rework.
defectsはやはり「修正」であって「手戻り」ではないでしょう。そもそも本書では全体を通じて、作業の種類を"new work", "unplanned work", "rework"と三つに分類しています。対応する訳文としては「新規作業」「未計画作業」「修正作業」が妥当でしょう。本書をちゃんと全部読んでいれば"rework"が単に作業をし直すという意味だけではなく、開発計画の中で作業を三つに分類したうちの一つを指していることがわかるはずです。その文脈を踏まえているからこそ「修正作業」という訳文になるわけです。これが「手戻り作業」だと作業の３つの分類の文脈にそぐわないのです。
今後のスタンダードになりうる素晴らしい翻訳
私は本書の内容については批判的な立場ですが、翻訳に関しては本当に素晴らしいと思います。特にまだ技術用語として定着するのかわからない用語をルビや括弧を活用しながら意味を読者に伝えるやり方は非常にクリエイティブだと感じました。
「LeanとDevOpsの科学」の翻訳は今後の技術書の翻訳における非常に高いレベルでのスタンダードを生み出したと言ってもいいのではないでしょうか。素晴らしい仕事をされた訳者の方々に敬意を表したいと思います。
この記事が気に入ったらサポートをしてみませんか？