ローカリゼーションなどの実務翻訳では、翻訳の品質を評価したり管理したりすることがあります。一般的には個人翻訳者が納品した訳文を、翻訳会社やソース・クライアントが評価します。
評価に当たってはさまざまな難しさがあります。どのような基準を用いるのか関係者間で意見が割れることがありますし、どういった基準を使うか決められたとしても「言葉」は主観的な部分があるので工業製品のようには測定できないことがあります。
そのため、比較的客観的に評価できる部分だけを評価するという方向に行きがちです。例えば数字の転記ミスはないか、指定された用語が使われているか、スタイル違反はないか、といった項目です。この場合、エラーの数が少なければ良い翻訳だ、ということになります。実際、有名なLISAのQAモデルではエラーに重大度(Minor、Major、Critical)を設定し、減点法で測定するという方法を採用しています。もちろん用語やスタイルの違反がないことは重要なのですが、これらだけが「品質」を構成するとは言えないでしょう。

前のブログ記事で取り上げた『User-Centered Translation』では、ユーザー(最終読者)を中心に据えた翻訳について論じていましたが、そこでUCT(User-Centered Translation)と比較した場合の従来の翻訳品質評価(TQA:Translation Quality Assessment)の特徴を説明している部分(セクション9.1.1)が興味深かったので紹介します。

<従来のTQAの特徴>
  • 最終段階が中心(End focus): 品質の評価と管理は翻訳の最中ではなく、翻訳完了後に1回行われる。

  • エラーが中心(Error focus): 翻訳エラーと未翻訳セグメントを検出。

  • 起点テクストが中心(Source text focus): 翻訳の目的("スコポス")というより、起点テクスト(いわゆる原文)と対照。

  • クライアントが中心(Client focus): プロジェクトにおける決定は、エンドユーザーというよりクライアントの希望による。

  • 専門家が実施(Expert execution): 実際のユーザーを巻き込むというより、専門家が実施。

  • フィードバックがなく、学習サイクルが限定的(Lack of feedback, limited learning cycles): 翻訳者は必ずしもフィードバックを得られない。得られても翻訳中に入手して、方針を変えられることはほぼない。

  • 審判する気風(Judgmental ethos): 翻訳者をサポートするというより、パフォーマンスに対して判定を下す。

  • 自動化(Automation): 簡単に測定できるものを測定し、虚報(false alarms)に終わることが多い。


要するに、クライアントが出す基準を用いながら、原文と見比べて訳文にエラーがないかを最終段階で専門家(チェッカーなど)が評価するという流れでしょう。

これに対して挙げられていたUCTの特徴をざっとまとめると…
  • 反復的なプロセスでユーザビリティー評価をし、最終段階に至る前に翻訳方針や言葉の選択が適切であることを確認。

  • エラー(特に原文との対照で分かるエラー)は、機能(何の役に立っているか)やユーザビリティーと照らし合わせて評価。

  • クライアントの希望だけではなく、エンドユーザーにも焦点を当てる。相反する場合はエンドユーザーを優先。

  • 翻訳チームへのフィードバックが伴う学習システム。


つまり、エンドユーザーを中心に据えつつ、翻訳者にフィードバックを繰り返してユーザビリティーの高い翻訳を作るという流れです。

あらゆる翻訳場面にUCTが適しているわけではないでしょうから、必ずしも従来のTQAが使えないということではないでしょう。
少なくともこうして対比させてみることで、業界で用いられているエラーベースの方法(上記のLISA QAモデルなど)を相対化できるというメリットがあると思います。

以上です。