home‎ > ‎

IT翻訳入門【クライアント編】05:翻訳を発注する

発表機会:『通訳・翻訳ジャーナル』(イカロス出版)2001年3月号掲載(雑誌記事)

1999年から一年あまり『通訳翻訳ジャーナル』(イカロス出版)という業界誌に「IT翻訳入門」というタイトルで連載記事を書かせていただく機会がありました。現在同誌は年四回発行ですが当時は月刊誌でした。このホームページの内容は、雑誌向けの原稿に加筆修正し、連載と並行して当時のホームページに公開したものです。『通訳・翻訳ジャーナル』の概要は下記のリンクから参照できます。


利用上の注意:このホームページは執筆当時(1999-2000年)の状況について述べており、すでにかなりの記述が「時代遅れ」となっていますが、原則として当時のままの内容を修正せずに公開しています。ご注意ください。

翻訳を発注する

発注先の翻訳ベンダーが決まったら次は発注の手配です。翻訳を外注するにあたっては翻訳仕様を指定する必要があります。ここではその翻訳仕様の内容と、発注に関連して話題になりがちなポイントをいくつか解説します。

翻訳仕様でおさえておきたいこと

翻訳仕様として必ず指定しないといけないのがスタイルガイドです。これを指定しなくても、翻訳ベンダーにはデフォルトのスタイルガイドが存在するのでそれに沿って翻訳を進行してくれますが、 デフォルト スタイルガイドが翻訳ベンダーによって異なるために、後日ベンダーを代えたときに翻訳の整合性が保てません。TRADOS による旧版のリサイクルが一般化しつつある現状では、旧版と新版でスタイルガイドの指定内容を変更するのにもコストがかかりますから、やはりクライアント側がスタイルガイドを指定するという主体性が欲しいところです。

すでに自社のスタイルガイドが存在する場合はよいとして、そうでない場合、新しくゼロから自社オリジナルのスタイルガイドを書きおこすのは大変ですが、裏技?があります。日本のIT翻訳ベンダーではマイクロソフトが制定しているスタイルガイドがデファクト スタンダードになっていますから、その仕様をそのまま自社の翻訳仕様とすれば、ベンダーが異なってもスタイルガイドの整合性を保つことができます。ただし、マイクロソフトは自社のスタイルガイドを公開していませんし、ベンダーは入手できてもクライアントであるソフトウェア メーカーがそれを入手することはできない建前ですから、そういう意味でこれは裏技にすぎません。なお、マイクロソフトのスタイルガイドとの互換性を保ちつつオープンであるスタイルガイドを目指して、筆者がいるエクストランスではウェブサイト (http://xtrans.com/) で『エクストランス スタイルガイド』を公開していますので、適宜参考にしてください。

スタイルガイドの制定で難しいのは、どれだけ規定を厳密に行うかということではなく、どこまで規定を減らせるかということです。細かいことまで決めすぎたスタイルガイドは、覚えにくく、使いにくく、翻訳品質にも悪影響を及ぼすため、益より害のほうが大きくなります。翻訳仕様の規定がややこしくて細かいほど、翻訳者は仕様への準拠に注意力と時間を奪われ、本来の仕事である翻訳品質の改善に充てる時間とエネルギーが減ってしまうからです。可能な限りシンプルな規定で期待する成果を実現してこそ優れたスタイルガイドと言えます。

スタイルガイドに続く翻訳仕様の二番手はグロサリ (訳語集) です。こちらは翻訳済みの文書量が増えるとともに自然に育っていくものですから、最初はなくてもかまいません。ただ、3 万ワードを越える文書の翻訳では複数の翻訳者が参加する可能性が高まりますから、クライアントが支給しなくても、ベンダー側は自主的になんらかのグロサリを作成するのが普通です。翻訳終了後にベンダーが自主作成したグロサリを納品させるのもひとつの方法ですが、本来はグロサリは翻訳開始前に作成するのが望ましいものです。翻訳開始前にベンダーにグロサリの作成を依頼して、その訳語をクライアントが査閲してから本文の翻訳に反映させるのが模範的な方法です。

翻訳仕様として指定されるその他の項目には、UI (User Interface) の訳語、各マニュアルのタイトル、TRADOS のバージョン (Build 番号)、Word のバージョン、などがあります。これらの項目についても、余計なことを指定すると逆効果になる一方で、指定すべきことを指定しないと翻訳者が現場で混乱しますから、クライアントは現場を視野に入れたリーダーシップを発揮することが望まれます。

また、元原稿が FrameMakerやPageMakerの紙マニュアルを翻訳する場合、レイアウト イメージの PDF 出力を翻訳者に渡すようにベンダーに指示するとよいでしょう。これらのアプリケーションでは、変換後のTRADOS形式ファイルのレイアウトが元原稿とまったく異なってしまうだけでなく、図の情報が欠落するため、Word ファイルだけでは翻訳者が内容を理解しづらいからです。

翻訳外注費の支払いは月締めが有利

翻訳に 1 ヶ月以上要する案件の場合、たいていはファイル単位での分納をスケジュールします。クライアント側は最終納期を指定すれば、分納スケジュールは翻訳ベンダー側で立案してくれますので、その内容を吟味すればよいでしょう。分納に関連する (ベンダーにとっての) 重要項目は、月次の締め日です。数ヶ月にわたるプロジェクトの場合、すべてを納品してから一括で請求するのは資金繰り負担が重くなるためどのベンダーもつらいのですが、特にSOHO/個人翻訳者は生活に窮してしまうため、毎月の締め日を定めて、その月に分納されたファイルについて検収し、経理から支払ってもらうよう手配しないと次から仕事を受けてもらえなくなります。

米国本社の原稿リリースが遅れた場合

すでに手元にすべての英文ファイルがある場合は問題ありませんが、時間を節約するために英文のライティングと日本語への翻訳を並行して流れ作業で処理する場合、翻訳対象英文のリリースが予定よりも遅れると、困った事態になります。翻訳者は予定通り英文ファイルが支給されることを想定して他の仕事を断ってスケジュールを空けていますから、予定した仕事が遅れると、スケジュールの再調整が必要になる上に作業できなくて収入が減るというダブルパンチに見舞われます。

このような事態は繰り返し発生するため、翻訳ベンダー側もある程度は他の仕事と調整してできるだけ翻訳者のスケジュールが無駄に空かないように工夫しますが、遅れの規模が大きくなると対処にも限度があります。予定より原稿リリースが遅れたからといってクライアントがベンダーに金銭的ペナルティを支払った話は聞いたことがありませんが、遅れで迷惑をかけたクライアントは次回以降、相手ベンダーから「疑いのまなざし」を向けられるようになりますので、発注交渉においてもベンダー選択においてもマイナス要因になります。クライアントとして配慮が必要なところです。

校正のタイミングは難しい

翻訳を外注する場合、通常はクライアントとして 1 ~ 2 回の校正を行うことになります。注意が必要なのはTRADOSを使う翻訳における校正のタイミングで、TRADOS形式のファイル (Workbench RTF) を上書き校正する場合はクライアント側もTRADOS の操作にある程度慣れていないと、クライアントがファイルを破損するという笑えない結果を招きます。それを嫌ってすべてをプリンタで紙に出力してボールペンで校正してもらう翻訳ベンダーもあり、一つの見識ではありますが膨大に森林資源を浪費する有様をみると、私個人としてはなんだかなあと感じます。

TRADOS形式のファイルを破損しないためには TRADOS の後処理 (CleanUp) を済ませた後の Word ファイルを校正すればよいわけですが、これだと校正した内容が翻訳メモリに反映できません。また、TRADOS形式ファイルにせよ後処理後のファイルにせよ、元原稿が FrameMaker や PageMaker から S-Tagger や Story Collector を使って抽出されたタグ付きテキストの場合、Word で開いたファイルを見てもレイアウト イメージとかけ離れているため、いったい自分が今どの箇所を校正しているのか分からなくなり、仕事の精度と効率が低下します。

うちも一度これで失敗したので、今では、FrameMaker や PageMaker のファイルは、DTP まで済ませて PDF 上で校正してもらう方が良いのではないかと考えています(ただこれだと、上に述べたように校正内容が翻訳メモリに反映されません...困ったもんですね)。

(2000年12月6日執筆)

利用上の注意:このホームページは執筆当時(1999-2000年)の状況について述べており、すでにかなりの記述が「時代遅れ」となっていますが、原則として当時のままの内容を修正せずに公開しています。ご注意ください。