rnishino

IT翻訳者Blog

翻訳、英語、ローカリゼーション、インターナショナリゼーションなどについて書いています。

12 4月

翻訳品質評価ガイドラインのポイント2つ

日本翻訳連盟(JTF)から「翻訳品質評価ガイドライン」が出されて半年ほど経つ。
同ガイドラインには、一般的な感覚と必ずしも合致しない説明もあると思うので、重要なポイントを2つだけ解説したい。

(1)翻訳の「品質」の定義
品質とは「翻訳成果物が、関係者間で事前に合意した仕様を満たす程度のこと」であると定義している(同ガイドラインp. 5)。
一般的には、たとえば「直訳なら品質が低い」や「こなれた和訳なら高品質」といった考え方がある。もちろんこれは間違いというわけではない。
ただ、同ガイドラインが想定する翻訳ビジネスにおいては、こういった考え方が当てはまらないケースもある。

たとえば、翻訳を発注するクライアントには「原文が透けて見える和訳が欲しい」といったリクエストをする人もいる。要するに、原文である英文の構造が分かるような「直訳」ということだ。原文の雰囲気を感じ取りたいというのが理由かもしれない。
もしこのクライアントの要望に沿おうとするなら、"低品質"の訳文を納品することになってしまう。

また、何度か本ブログで取り上げているが「サンシャイン牧場」というゲームの例も同様だ。
これは2009年に流行したゲームで、もともと中国語だったが日本語に翻訳された。当初は日本語が変だった("低品質")ため、きちんとした日本語に直した("高品質")。しかしその変な日本語(「サン牧語」)が気に入っていたユーザーからクレームが来たという話である。

また、サン牧内の言葉は基本的に中国語の直訳になっており、日本語としてやや不自然なところも目立つ。だが、一風変わった日本語が一部では「サン牧語」と呼ばれて人気なのだという。「一度正確な日本語に訳しなおしたら、ユーザーに『戻してくれ』と言われ、戻したことがあるんです。
https://ascii.jp/elem/000/000/477/477173/index-2.html

一般的な翻訳の感覚からは考えられないが、日本語としての質を落とす方向に進んだのである。

つまり、たとえば「直訳かどうか」や「日本語としてこなれているか」といったポイントで品質を定義しようとすると、困った事態が発生する場合もあるのだ。翻訳者はわざと"低品質"の翻訳をしてしまうことになる。
だから同ガイドラインでは「その翻訳案件で目指すところ(=仕様)は関係者どうしで決めてください。その目指すところが達成できていれば高品質です」としている。
実はこの「仕様を満たす程度」を品質とする考え方は同ガイドラインのオリジナルではなく、海外においてはすでに広まりつつある考え方だ(ASTM F2575やMQM)。

(2)重大度は現実への影響
同ガイドラインでは、エラーベースの評価モデルを提示している。要するに減点方式なのだが、エラーの「重大度」に応じて減点幅が変わる。
この重大度については次のように説明している(p. 20)。

あるエラーがどのくらい重いのかを示す程度。重大かどうかは翻訳の目的(例:マニュアルなら機器を操作ができる、広告なら顧客を獲得できる)を達成できるかどうかという視点から判断する。

そして重い順に「深刻」「重度」「軽度」の分類がある。たとえば深刻は「翻訳成果物の使用が不適当となるエラー。その訳文を読んだ結果、健康被害、経済的損失、社会的な評価毀損などをもたらす可能性がある」ものだ。

訳文でたとえば数字の桁が間違っていたら、誤訳の指摘が入るだろう。桁間違いはやってはいけないミスだ。医薬品の場合だったら人命に関わることすらあるので「深刻」で不思議はない。しかし、桁間違いなら自動的にすべて「深刻」になるわけではない。
たとえば誰かの日記ブログの和訳に「自宅から500メートル先にあるコンビニに行った」とあったとする。ところが実は1桁間違えていて、本当は「50メートル」が正しかったとしよう。日記ブログを読む側からすれば、コンビニが実際に500メートル先か50メートル先かは大した問題ではない(重大な被害や損失が発生するわけではない)。そのため「軽微」という判断で問題ないだろう。

このように、翻訳の目的に照らし合わせた上で、あるエラーが現実世界に与える影響で重大度を判断することになっている。


◆背景にある「機能主義」
上記(1)と(2)の考え方の背景には、機能主義的な考え方がある。
機能主義とは、先ほども出てきたように翻訳の「目的」を重視する立場である。翻訳学では「スコポス」とも呼ばれる。たとえば機器マニュアルであれば、読者が「機器の操作を完了する」という目的が達成できるよう翻訳することである。だから現地読者に合うよう、表現などが原文から離れる場合もある。
「サン牧語」に戻した件も、「ユーザーの満足度を上げる」という目的から考えれば、機能主義的には妥当な判断だ。

機能主義は翻訳学上でも大事な概念でもあるし、海外の品質基準(MQMなど)でも前提になっているので、理解しておくと便利かもしれない。
19 2月

書評『ヘルプサイトの作り方』

ヘルプサイトの作り方』(仲田尚央、山本絵理・著、技術評論社)を読んだ。
タイトルにあるように、ソフトウェアといったプロダクトのヘルプを作成する方法を解説している。事例としてサイボウズ社のヘルプサイトも登場する。
目次は上記リンク先から確認できる。



たとえば第6章「記事を作る」では、執筆時に使える手法が具体的に解説されている。文の書き方(例:一画面一手順)や図解の方法(例:ユーザーの視点から描く)などである。
こういった内容はもちろん参考になるが、ライティングの教本などほかの書籍でも取り上げられていることもある。
やはり本書で独特なのは、ヘルプの書き方というより、ヘルプサイトを全体としてどううまく作るかを扱っている点だと思う。
第1章の冒頭にもあるように「文章力」より「設計力」に注目しているのである。



個人的には、翻訳支援ツールと連携したサイボウズのヘルプ管理システムの話が面白かった。
以前、自著に関連してサイボウズを取材させてもらったことがある(記事)。サイボウズでは対訳用語集を自社製品で管理しているという話だったが、ヘルプ管理システム全体としてどう動いているかまでは知らなかった。
本書ではその全体像が(ページは少ないものの)説明されている。以下、173ページから図を引用する。

978-4-297-10404-7_p173

フローとしては、まずヘルプの記事を制作して「GitHub」に取り込んでいることがわかる(図上半分)。
その後、記事を「翻訳支援システム」に渡している(図下半分)。実際の翻訳は、その右側にある翻訳者と「機械翻訳」が行う。その際に左側から「用語」を取得しているのだ。ここで対訳用語集が利用されているということだ。
記事の翻訳が完成するとGitHubに戻し、その後ヘルプとして公開される。

やはりITはアメリカ企業が強く、ヘルプを多言語化している国内IT企業はそれほど多くないように思われる。そのため多言語化のフローはとても参考になるし、事例を提供してくれるサイボウズは貴重な存在である。



なお、第5章「スタイルガイドや用語集を準備する」で、日本語スタイルガイドとして「JTF日本語標準スタイルガイド」を紹介していただいている。
制作に関わっている者として感謝申し上げたい。


5 2月

「アプリ翻訳基礎講座」の連載終了

グローバリゼーションデザイン研究所のウェブサイトに掲載されていた「アプリ翻訳基礎講座」の連載が終了しました。全20回です。

リンク: https://globalization.co.jp/category/basics-of-app-translation/

アプリ翻訳基礎講座のスクリーンショット


本連載は、書籍『アプリ翻訳実践入門』の一部だけを短めに再編集したものです。
もし本連載で興味を持たれたら、ぜひ内容が完全な書籍の方をお求めいただければと思います。

・出版社の書籍ページ(ためし読み可)
https://globalization.co.jp/publication/app-translation/

・Amazonのページ
https://www.amazon.co.jp/dp/4909688005
★6/22発売の翻訳書★
血と汗とピクセル 『血と汗とピクセル』
筆者について
西野 竜太郎
(Ryutaro Nishino)

翻訳者。合同会社グローバリゼーションデザイン研究所・代表社員。日本翻訳連盟・理事。
プロフィールや連絡先などについてはこちらをご覧ください。
Twitterアカウント
RSS フィード
著書
アプリ翻訳実践入門
『アプリ翻訳実践入門』


ソフトウェアグローバリゼーション入門
インプレス刊
『ソフトウェアグローバリゼーション入門』

達人出版会刊
『ソフトウェア・グローバリゼーション入門』


英語語源が魔術に変わる世界では
『英語語源が魔術に変わる世界では』


現場で困らない! ITエンジニアのための英語リーディング
『IT英語リーディング』


アプリケーションをつくる英語
紙版
『アプリケーションをつくる英語』

電子版
『アプリケーションをつくる英語』
第4回ブクログ大賞受賞】