IT翻訳者Blog

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

カテゴリ: 書評

2017年10月に、翻訳業界調査をしているNimdzi社のRenato Beninatto氏らが「The General Theory of the Translation Company」(翻訳会社の一般理論)という書籍を出した。当時(海外の)業界ではそこそこ話題になっていたが、やっと最近読み終わった。




名前の通り、同書では「翻訳会社」の機能や仕組みを解説している。1枚の図で表すとこうである(同書より引用)。



まず中央の黄色い部分が翻訳会社の中核機能(Core Functions)である。これには3つが挙げられている。

 ・ベンダー管理(Vendor Management)
  ※ここでベンダーとは発注先(フリーランス翻訳者や翻訳会社)
 ・プロジェクト管理(Project Management)
 ・営業(Sales)

また、その外側にあるのが支援活動(Support Activities)で、8つ挙げられている(図だとやや文字が読みにくい)。

 ・経営(Management)
 ・企業組織(Structure)
 ・企業文化(Culture)
 ・財務(Finance)
 ・施設(Facilities)
 ・人的資源(Human Resources)
 ・テクノロジー(Technology)
 ・言語品質保証(Language Quality Assurance)

一番外側にあるのは、市場に影響を与えるもの(Market Influencers)である。

 ・新規参入者(New Entrants)
 ・顧客(Customers)
 ・代替品(Substitutes)
 ・競合他社(Rivalry)
 ・供給業者(Suppliers)



翻訳会社の機能については、以前自分のブログ記事でもまとめたことがあった(同じ2017年の1月だった)。見出しだけまとめる。

 【クライアント側から見た機能】
  A. コーディネーション機能
  B. プロジェクト管理機能
  C. 品質保証機能
  D. 編集/校正機能

 【翻訳者側から見た機能】
  a. 営業機能
  b. 教育/サポート機能

こう見ると、Beninatto氏らの言う中核機能と支援活動に該当するものが含まれている。

 ・ベンダー管理 → A. コーディネーション機能
 ・プロジェクト管理 → B. プロジェクト管理機能
 ・テクノロジー → (一部)b. 教育/サポート機能
 ・言語品質保証 → C. 品質保証機能

一般的な企業でも必要な「企業文化」や「財務」などを除くと、翻訳会社特有の機能についてはかなり認識は一致しているように思える。



ただし「品質保証」については異論がある。

Beninatto氏らが品質保証を(中核機能ではなく)支援活動に入れているのは、品質保証が付加価値を生み出さないからというのが理由だ。どの会社でも「高品質」をうたうため、それは差別化要因にならない。例として配管工事が挙げられていた。配管工事を依頼したらきちんと直るのが当然であり、翻訳もそれと同じだという話らしい。

これは品質のうち「当たり前品質」しか見ていないのだと思う。当たり前品質とは「不充足だと不満、充足されて当たり前」(参考)という品質である。確かにそういう面もあるが、翻訳には「不充足でも仕方がない(不満には思わない)が、充足されれば満足」(参考)という「魅力品質」の面もある。たとえばゲームの翻訳が素晴らしく、世界観に引き込まれるようなケースだ。こういう翻訳は明らかに差別化要因になる。



しかし「当たり前品質」こそを品質とみなすのは、グローバルな翻訳ビジネスでは当然なのかもしれない。
同書では、翻訳業界を次のような階層構造として見ている。

(同書より引用)

つまり、一番上にクライアント(LSB)がおり、その下に多言語翻訳会社(MMLSPやMLSP)がいる。さらに下に各地域の多言語翻訳会社(RMLSP)、その下に単言語翻訳会社(SLSP)、そして翻訳実作業をするフリーランス翻訳者(CLP)がいる。

こういう階層構造を想定すれば、下から上まで一貫した品質の翻訳が求められる。ある意味、自動車のような工業製品に近い。用語集などで仕様をがっちり固め、それを守る。下流で部品を上流に納品し、それを組み立ててさらに上流に納品する。仕様を守ることで完成品の品質は安定する。だから多言語を扱う中で、ある言語だけ「魅力的品質」を備えていたら、むしろ品質管理に困る。安定した品質が求められる大量生産の工業製品においては、いち職人の名人芸は面倒を増やす。

翻訳の部品化は良い悪いという話ではなく、階層構造を持つグローバルな翻訳ビジネスを想定するのであれば、当たり前の現実なのかもしれない。
このエントリーをはてなブックマークに追加

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



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



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

978-4-297-10404-7_p173

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

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



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


このエントリーをはてなブックマークに追加

Thierry Poibeau著『Machine Translation』(MIT Press、2017年)(英語版のみ)



2017年に出版された機械翻訳の解説書。新しいのでニューラル機械翻訳(NMT)まで扱っている。
技術面というより、歴史的な流れに主眼をおいて説明している。そのため技術者でなくてもあまりストレスを感じず読み進められる(ただし統計翻訳で若干の数式が登場)。
日本で既刊の機械翻訳本は技術者向けのものが多いので、その点では貴重だ。



同書第3章を参考に、簡単に機械翻訳の歴史をまとめるとこうなる。

・〜1940年代:
 研究者は自動翻訳について考えてはいたが、実現方法がなかった。

・1940〜1960年代半ば:
 コンピューターが登場し、動く機械翻訳システムが作られた。期待は大きかった。

・1965-66年:
 機械翻訳の実現に否定的な「ALPACレポート」がアメリカで出され、研究費が出なくなった。

・1966〜1980年代末:
 英米圏で研究は下火だった。ただし計算言語学で進歩があり、構文解析などが進んだ。
 一方、欧州や日本では研究は継続されていた。1980年代に日本の長尾真氏による「用例ベース」(Example-based)の機械翻訳が登場し、第8章はまるまるこの解説に当てられている。

・1990年代〜:
 統計とバイリンガル・コーパスを使ったアプローチが登場した。基礎になっているのは1980年代後半〜90年代初頭に行われたIBMでの研究(同書内でも詳しく解説している)。

・2010年代半ば〜:
 ディープラーニングに基づく新アプローチが登場(ニューラル機械翻訳のこと)。



同書でやや残念なのは、2017年に出版されたため、その直後に一気に普及したニューラル機械翻訳の解説が少ないという点だ。そのため、最新の機械翻訳だけを集中して知りたいという人にとっては物足りないかもしれない。
ただし歴史全体を知るには良い書籍であり、Kindle本で1,400円弱、洋書でも1,700円弱(2018年6月時点)なので、比較的買いやすい。

このエントリーをはてなブックマークに追加


光藤京子・著(秀和システム)2016/12/24

◆ ◆ ◆

訳文の誤りを「エラーカテゴリー」で分類することで、翻訳能力向上を図る方法を示した書籍である。

各エラーカテゴリーにおける具体例が豊富で、翻訳を学ぶ学生にとって役立つだろうと感じた。エラーカテゴリーを利用する翻訳評価手法は一般的に「エラー評価」と呼ばれるが、それを具体例とともに解説した日本語の一般書はないため、その点でも有用だろう。

同書のエラーカテゴリーは合計15個あり、大きく3種類に分けられている(p. 25-26)。

  1. 「正確に訳されているだろうか?」:「歪曲」や「情報の欠如・付加」など8個のカテゴリー

  2. 「分かりやすく訳されているだろうか?」:「違和感のある語彙選択」など4個のカテゴリー

  3. 「細かいところに気が配られているだろうか?」:「表記ミス」(スタイルガイド違反)など3個のカテゴリー


これは業界で用いられているエラー評価分類と似ている部分もある。例えばDQF-MQMでは「正確さ」(上記の1)、「流暢さ」(上記の2)、「スタイル」(上記3の一部)という大カテゴリーを設けている。同書にこういった既存エラーカテゴリー(DQF-MQM以外にもいくつか存在する)との比較研究があれば、実務家にとってより有益だったかもしれない。

さらに、同書内では業界の基本的な実務知識(翻訳プロジェクトの流れなど)にも簡単に触れられている。全体として翻訳者を目指す人向けの書籍と言えるだろう。
(ちなみに、スタイルガイドの例として『JTF日本語標準スタイルガイド』が挙げられていた。作成に関わっている者としてお礼を申し上げたい)

◆ ◆ ◆

ここでは同書に関連するものの、書かれていなかった点について考えてみたい。特にエラーカテゴリーを評価に使う際の課題である。

A. エラー評価に対する批判

実はエラーカテゴリーを用いたエラー評価は、以前から実務翻訳で使われている。
一般的にエラー評価では、原文と訳文を1文ごとに対照させ、訳文中にあるエラーを発見する。そしてエラーの重大度に応じて点数(「深刻」なら10点、「重度」なら5点、「軽度」なら1点など)を付け、合計がしきい値を超えたら「不合格」にするといった運用をする。

このやり方については主に2つの批判がある。
1つめは「木を見て森を見ず」という批判だ。1文ごとに見比べるため、文(=木)というミクロレベルではエラーを見つけやすい。例えば、誤訳、用語集違反、スタイルガイド違反などだ。
ところが、文章全体(=森)として見比べているわけではないため、マクロレベルのエラーは評価できていないという批判である。例えば、学術論文には独特の構成があり、それに合うよう文章が訳されていることが望ましい。

2つめは「さまざまな専門分野に対応できない」という批判である。例えば特許文書とマーケティング資料では、訳文で重視する点が異なる。特許では「正確さ」(例:誤訳のなさ)が重要だし、マーケティング資料では「流暢さ」(例:購買欲を刺激する表現)が重要かもしれない。
もし単一のエラーカテゴリーしかないのであれば、いくつもある専門分野に柔軟に対応できないという批判である。

(この「A. エラー評価に対する批判」については、JTFジャーナル #285(PDFファイル)の私の記事(p. 26-)でも紹介している。)


B. エラーで翻訳を評価してよいか

こちらはAと比べると、より根源的である。エラーの有無のみで翻訳を評価してよいかという問いである。

翻訳成果物はエラー以外に、さまざまな側面から評価できる。
例えば、訳文には最終読者がいる。最終読者の反応を考慮せず、提供側のエラーカテゴリーのみで良し悪しを決めてしまって良いのだろうか?
また、プロとして翻訳ビジネスをするなら、納期や予算の制約がある。スケジュールも料金も悪い条件で仕事を依頼をされたのに、通常と同じ基準で評価されてしまったら、翻訳者としては納得できるだろうか?

評価すべき翻訳の「品質」が何であるかと議論が従来からあり、最近翻訳業界では「Garvinの5分類」が提唱されている。要するに「品質」が意味するところは主に5つあるということだ。
エラー評価は5分類のうちの「プロダクトベース」に該当する。ほかには上記の最終読者の視点で評価する「ユーザーベース」や、予算との兼ね合いで評価する「価値ベース」などがある。
(Garvinの5分類について詳しくはJTFジャーナル #283(PDFファイル)の私の記事(p. 20-)をご覧いただきたい。)

つまり、エラー評価は、いくつもある方法のうちの1つに過ぎないのである。

業界(や教育)においてエラー評価がよく用いられるのは、その簡便さが理由だと思われる。翻訳提供側でエラーカテゴリーを用意して使えばよいだけだからだ。もし訳文について毎回最終読者にアンケート調査して評価していたら、コストがかかり過ぎてビジネスとして成立しない。

エラー評価は便利ではあるが、それは翻訳品質の1面のみを評価しているに過ぎないという意識を常に持っておく必要がある。

私の好きな話に「街灯の下で鍵を探す」がある。ある公園を夜歩いていると、男が街灯の下で鍵を探している。その男に「確かにここで鍵を落としたのか?」と聞くと、「どこで落としたのか分からないが、ここが明るいのでここを探している」と答えたという話だ。
エラー評価は簡便であるため、翻訳評価でつい使いたくなる。しかしそれが本当に評価すべきものかどうかは分からない。「評価しやすいから評価する」(=探しやすいから探す)のではなく、本当に評価すべきものは何であるかをしっかり見極めなければならない。
このエントリーをはてなブックマークに追加




翻訳のプロであるならば、顧客が満足するようなサービスを提供しなければならないと言われます。ここで「顧客」というのは通常、フリーランス翻訳者であれば翻訳会社、翻訳会社であればソース・クライアントを指します。つまり、翻訳会社やソース・クライアントが満足するようなサービスを提供できるのがプロの翻訳者あるいは翻訳会社というわけです。これは比較的広く受け入れられている考え方ですし、現実のビジネスを見ると確かにそうでしょう。

ここに別の視点を持ち込むのが、本書のタイトルでもある「ユーザー中心翻訳」(UCT:user-centered translation)です。直接の顧客である翻訳会社やソース・クライアントというよりも、訳文の最終読者となるユーザーを中心に翻訳しようという方向です。この背景にあるのが「ユーザビリティー」と「ユーザー体験」(UX)という概念です。ユーザビリティーは例えば「読みやすさ」や「学習しやすさ」、ユーザー体験は「楽しい」といった体験全体に関係します。

ただしこれまで翻訳学においてユーザー(読者)が無視されていたわけではありません。例えば機能主義翻訳では、ドキュメントの目的("スコポス"とも)に沿った翻訳がなされているかどうかに注目していました。UCTが機能主義と異なるのは「ペルソナ」など具体的な分析手法をいくつか提案している点です。ペルソナとは架空の人物のことで、訳文を実際に読みそうな人を具体的に想定し(35歳のネットワーク・エンジニアなど)、その人がどう読むかを考えながら翻訳します(ちなみにペルソナ法はUCTに特有というより、UX研究ではよく知られた方法です)。

このUCTは従来の翻訳ビジネスを置き換えるというより、付加価値や多様性(diversification)をもたらすものでしょう。例えばアプリのUI翻訳です。現在主流の「1ワード何円」という計算方法の場合、画面に数語しか表示されないUI翻訳は、全く儲からない商売です。しかし「UXが高まり(結果的に)売上が伸びる」という方法で進めるなら、これまでとは違うビジネスになる可能性があります。UCTはこのような多様化に資する考え方でしょう。

以上です。
このエントリーをはてなブックマークに追加

↑このページのトップヘ