home‎ > ‎

IT翻訳入門05:失敗しない初仕事

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

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


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

はじめての仕事

トライアルに合格した新人翻訳者には、翻訳会社側からなんらかのコンタクトをとってきます。多くの場合、最初は翻訳会社と個人翻訳者の間で「機密保持契約」を結ぶことになります。これであなたの名前は翻訳者名簿に登録されますので、あとはその翻訳会社が「新人向けの仕事」を受注するのを待ちます。

トライアル合格からしばらく期間があいて翻訳会社から連絡がきたら、たぶんそれは初仕事の打診でしょう。そして、新人に打診される初仕事は、多くの場合、悪条件の仕事です。悪条件とここで言うのは、納期が短い、単価が安い、など要するに他の翻訳者がやりたがらないような仕事という意味で、もって行き場に困ったコーディネーターが名簿を頼りにダメもとで新人へ電話をかけてくるケースが少なくありません。

「そんな仕事、受けられないよ」と断るのは自由ですが、ここで断るとその翻訳会社との縁が切れてそれっきりになってしまうので、新人であれば最初は勉強のつもりで受けてみるという思い切りも大事かもしれません。そうは言っても、納期や単価など、一通 りの発注条件は確認してください。それでこそ相手も一目置きます。あと、自分が利用できる作業環境で手に負える業務かどうかも。

いきなり大量の翻訳を引き受けても失敗したときの挫折感が大きいので、最初は数千ワードから1万ワード程度の分量 を引き受けるとよいでしょう。もっとも、まともな翻訳会社であれば新人にいきなり数万ワードもの仕事を依頼することはまず考えられませんので、発注ワード数は少ないのが普通 です。

こうやって初仕事を受け、評判がよければ繰り返しその翻訳会社から翻訳の仕事を頼まれるようになります。そのようにして、何度かその会社の仕事をこなしていくと、だんだん仕事のバリエーションや自分流の仕事術も見当がつくようになるでしょう。そうなったら今度は2社目の得意先を開拓してみるとよいでしょう。複数の得意先を持つことは、得意先を評価する力を付ける上で非常に有益です。得意先が複数できたら、その後はだんだん仕事や得意先を選ぶようになると理想的でしょう。


得意先に確認すること

仕事の開始時点で得意先から受け取る資料には、翻訳対象英文ファイル、 スタイルガイド、 グロサリの 3 つが含まれるのが普通です。翻訳対象英文ファイルの形式は仕事ごとに異なり、html (ウェブサイトのコンテンツや HTMLHelp の場合)、rtf (WinHelp の翻訳や TRADOS を利用する場合)、doc (Microsoft Word で作成された紙マニュアルの場合) などの形式が代表的です。

スタイルガイドは訳文の文体や書式を指定する文書で、得意先ごとに指示が微妙に異なります。グロサリは仕事ごとに作成される訳語集であり、その製品独自の訳語がまとめてあります。仕事によっては旧版の日本語訳が存在せず、そのためグロサリが支給されないこともありますが、スタイルガイドは通 常必ず指定されます。スタイルガイドとグロサリについては、この講座の別の回に詳しく解説する予定です。

仕事を受注するとき得意先に最低限確認すべき項目として、納期、単価、翻訳の納品方法、翻訳報酬の振込期日があります。得意先から電話がかかってきたら、まず業務内容の確認しましょう。具体的には、作業内容は翻訳かリライトか? 分野と難易度は自分にとって適当か? 分量と納期は自分にとって適当か? 作業対象のファイル形式は何か? 必要な環境 (TRADOS などのツールを含む) は用意できるか?などの点を確認します。業務内容が理解できたら、相手が提示する翻訳単価 (仕事の報酬) と入金予定日を確認し、 総合的に判断して自分にとって納得できる条件であれば交渉成立です。

余裕があれば、その他にもプロジェクトの全体像に関する情報をこの機会に仕入れておきましょう。どんな製品なのか、得意先はどういうスタンスなのか、品質要求が高いのかそれとも納期優先なのか、自分の他に何人位 の翻訳者が参加するのか、翻訳中に出てきた質問事項はだれに聞けばいいのか、などの点について情報を得ておくと、仕事がスムーズに運びます。ただし、これらの点について得意先の担当者を質問責めにして相手に辟易されても良くないので、雰囲気が悪くならない範囲で情報を得るというスタンスが無難でしょう。

その他、実際に仕事を進める上で確認する必要がある細々した項目として、旧バージョン流用の有無、 ベータ版ソフト支給の有無、 リソース (画面に表示されるコマンド名やメッセージ類をこう呼びます) 日本語化の有無、 WinHelp の場合は脚注翻訳の有無、 サンプル プログラム日本語化の有無、プログラム内コメントの日本語化の有無、 画面とコールアウトの日本語化の有無、翻訳者コメントのつけ方、テンプレート ファイルの有無、などの点があげられます。

これらの詳細については、翻訳開始時点に文書などでコーディネーターから指示されるのが普通 です。まずはもらった指示をよく読み、欠落した項目や不明瞭な点がある場合に質問をしてみる、という段取りでよいでしょう。


データの送受信方法

英文を受領する手段としては、電子メール添付または FTP サーバーの利用が主流です。事前に以下の作業が問題なく行えることを確認しておくとよいでしょう。いきなり練習なしに翻訳会社とのファイルのやりとりに臨んでジタバタと手際が悪いと、相手もだんだんうんざりしてきますので要注意です。実際の仕事で必要に迫られる前に、下記の作業が行えることを予行演習で確認しておくことをお薦めします。

  • 英文ファイルが添付された得意先からの発注メールを受信できるか?
  • 電子メールに添付された英文ファイルを分離して保存できるか?
  • FTP サーバーへのファイルのダウンロード/アップロードができるか?
  • 圧縮されているファイル (たいてい zip 形式) を解凍できるか?
  • 解凍したファイルを上書きして翻訳できるか?
  • 翻訳が済んだファイルを (zip 形式に) 圧縮できるか?
  • 圧縮したファイルを納品メールに添付して送信できるか?


自分の値段をどう決めるか

フリーランスの翻訳者になると、自分の翻訳単価を自分で決める必要があります。もちろん翻訳会社側から「ワード15円でお願いできますか?」というように単価を提示されることが多いのですが、「どのくらいの単価でお願いできるのですか?」と逆に希望単価を聞かれることもしばしばあるからです。これは簡単なようで難しい質問です。あまり高く言えば敬遠されるかもしれないし、逆にあまり安く言うと仕事はとれるかもしれないが仕事しながら「なんでこんなに安いんだよう」とフラストレーションが溜まるからです。

こういう場合、私は「後悔最小化の原則」に従って自分の単価を決めることにしています。高すぎる値段をふっかけて失注したときの後悔の強さは単価を横軸にしてグラフ化すると右肩上がりの曲線になります。一方、安すぎる値段で仕事を受注して仕事しながら低い時給に泣くときの後悔の強さを同じ座標に記入すると右下がりの曲線になります。そして、両方の後悔曲線が交差する点を自分の単価とすれば、後悔の期待値を最小化できるわけです。いかかがでしょう、この方法?(発明者:ジェラルド・ワインバーグ)


リライトやチェックについて

翻訳会社から翻訳以外の仕事、すなわち他の翻訳者の翻訳のリライトやチェックの仕事を打診されることもあります。リライトというのは、人の翻訳を修正して品質を高める作業のことです。これらの作業は、受注すべきでしょうか?

一般的にはリライトは金銭的に割の合わない仕事になります。というのも、リライトというのはもともとの翻訳者が期待どおりの品質で納品しなかった場合の尻拭い的な仕事なので、リライトを行う段階ですでにそのプロジェクトの予算が残っていないことが多く、結果 的にリライトする人に支払える報酬があまり無いからです。それではむげに断ればいいかというと、たとえば翻訳会社に貸しを作っておきたいときなどには受注するという判断もあり得ます。

翻訳会社側も、力量を評価していない翻訳者に対してリライトを依頼することはありませんから、翻訳会社側がリライトを依頼してきたということは、相手はあなたの翻訳力をそれなりに高く評価していると考えていいでしょう。 ただし、リライトをまじめにやると、ほとんどの場合新規翻訳と同じくらいかまたはより長い時間がかかってしまいますから、どうやっても赤字になるということは忘れないようにしてください。1万ワードのリライトを受注するということは、同じワード数の新規翻訳ができるはずの時間を消耗してしまうわけですから、約 5-10 万円の損になります。仮に 4 万ワードのリライト仕事を請け負えば 20-40 万円の損ですから、よほどの理由がないとリライトを大量 に引き受けるのは避けた方が無難でしょう。

翻訳会社側にしても、ベテランの翻訳者にリライトを打診してもことごとく断られるため、リライトの打診はリライトという作業の金銭的不利をあまりよく分かっていない新人翻訳者に向かいがちです。悪く言えば、翻訳力がある程度以上あってしかもだましやすい翻訳者がリライト依頼の標的になるわけです。誰か知らないよその下手な翻訳者の尻拭いを押しつけられるスケープゴートにならないように、くれぐれも注意してください。

それではチェックの仕事はどうでしょうか?チェックも他の人が翻訳した文章を見直すという意味ではリライトと似ていますが、リライトと違うのは文章の訳し直しを要求されているわけではなく、スタイルガイドに準拠しているかどうか、誤字脱字や訳抜けがないかどうか、といった基本的な検査項目を確認する仕事であるということです。リライトと比較して、チェックは検査する項目が初心者にも分かりやすいので、チェックの仕事は翻訳初心者に打診されることになります。単価はリライトよりさらに安く、1 ワードあたり 1-3 円がいいところでしょう。

翻訳初心者がチェックの仕事を引き受けるのは、かなり勉強になるという大きなメリットがあります。他人の翻訳をたくさん読むということは、思いの他翻訳の勉強になるものなのです。そのことは多くの翻訳者が証言していますので、間違いないところです。もしもあなたに「自分は新人だから勉強したい」という気持ちがあるのであれば、積極的にチェックの仕事を引き受けるというのもなかなかよい作戦だと思います。もっとも、あまりにも複雑なチェックをあまりにも安い単価で依頼されて結果 的に時給が 200 円程度になってしまう危険と隣り合わせであることは忘れないでください。いやな仕事を断る勇気は常に必要でしょう。


翻訳中に心がける点

最初の翻訳ではすべてが手探りです。スタイルガイドの約束事をまもり、訳語はまずグロサリを検索する、という翻訳者の基本に従うのは当たり前として、その他に翻訳中こころがけるとよいと思うことをまとめてみます。

意味がわからなくても納品しなければならない

限られた時間内で、翻訳者が原文で解説されているテーマに関して原文のライターと同レベルの理解度に到達することは普通 は困難です。したがって、ほとんど常に、翻訳対象の中によく意味の分からない箇所が出てきます。そういう箇所が少しでも減るようにウェブや参考書をよく調べるのは大切なことですが、それですべての疑問が解けるわけではないという覚悟もまた、重要だと思います。そして、よく理解ができていない場合でも、納期が来たら翻訳を納品しなければなりません。このあたりが仕事として行う翻訳のつらいところです。

この問題に対処する心構えとして大切なのは、100 点満点の理解でなくてもかまわない、という考え方です。他の翻訳者も同様の制約の下で仕事していますから、たとえあなたの納品した翻訳が仮に 70 点の理解度だとしても、翻訳会社側の名簿に掲載された他の翻訳者が全員 60 点以下の理解度であれば、次の仕事もあなたに発注されるでしょう。つまり、翻訳者の評価は絶対評価ではなく相対評価なのです。

そういうわけですから、完全な理解にもとづく完璧な翻訳、という見果てぬ夢を追わないように忍耐強く辛抱して、翻訳会社から切られない水準の翻訳を納期内に安定して納品していくスタンスのほうが、長続きすると思います。

翻訳に必要な情報は自力で手に入れる

翻訳対象の製品に関する情報は、ソースクライアント (いちばん最初の発注元) であるソフトウェアベンダーの手元には大量 に存在するはずです。そして、それらの情報が翻訳者の手元にあれば、翻訳者が翻訳中に感じる疑問点の 80 %はたちどころに解消するでしょう。しかし、現実にはソースクライアントクライアントからそれらの情報が提供されるケースはまれです。

ソースクライアントが翻訳者に対する情報提供の重要性を理解していないケースや、理解はしていても提供するだけの時間的余裕がないケース、また途中に介在する翻訳会社の担当者がずぼらをしてソースクライアントから提供された情報を自分の手元でせき止めてしまい翻訳者に提供しないケースなど、理由はさまざまでしょうが、現実的には英文ファイルとごく簡単な作業指示しか翻訳者の手元には届かない場合がほとんどです。

しかし、だからといって翻訳者が情報を収集せずに翻訳しても、いい翻訳ができるわけがありません。したがって、翻訳者は自力で翻訳対象のソフトウェアやコンテンツに関する情報を収集する必要が生じるわけです。

この情報収集活動は、ウェブが登場したおかげで本当に劇的に楽になりました。ウェブが登場する以前は、名前を聞いたこともないソフトウェア製品の情報など、事実上収集不可能だったのですが、現在ではどんな製品も、ウェブで検索をかければなんらかの情報が得られます。多くの場合、そのソフトウェアの開発元のウェブサイトをヒットできますし、メーカーがわかればその製品の紹介ページもすぐにみつかります。一般 的に言って、クライアントから支給される情報よりもウェブを自分で調べて得られる情報のほうが、質量 ともにずっと充実していることが多いようです。

逆に言えば、「調べてもわかりませんでした」という、一昔前は一般的だった言い訳が現在ではほとんど通 用しませんから、ずぼらをして翻訳対象の製品やその開発元の情報をウェブサイトで調べもせずに翻訳する翻訳者は、ちゃんとそれらの情報を調べてから翻訳にかかる翻訳者にかなうわけがありません。

実機チェックの必要性

ソフトウェア マニュアルの翻訳の場合、そのマニュアルの記述通りにソフトウェアを操作して実際の応答を確認する作業のことを「実機チェック」と呼びます。「実機チェック」はソフトウェア マニュアルの翻訳ではどこかの段階でかならず行うことが望ましい、とても重要な工程です。通 常は翻訳者の後工程で得意先の社内などに実機チェックを集中的に行う担当者が存在しますが、翻訳者が翻訳中に可能な範囲で実機チェックを行うことは、とてもよい習慣です。

翻訳者が実機チェックを行う場合、対象となるソフトウェアは通常はまだ市販されていないわけですから、ベータ版やアルファ版のソフトウェアを得意先から貸与してもらい、実機チェック用のマシンにそれをインストールして、翻訳作業用のパソコンと並べて実機の応答を確認しながら翻訳をすすめる段取りになります。

なぜ実機チェック用のマシンが翻訳作業用のマシンとは別に必要かというと、実機チェックの時点で貸与されるソフトウェアのベータ版やアルファ版の動作が不安定で、致命的なバグが残っていることも多く、そのような不安定なソフトを翻訳作業用のパソコンにインストールして翻訳作業環境を破壊でもすると、えらいことになるからです。パソコン経験が長い人は、たいていは以前メインマシンとして使っていた一世代か二世代前の遅いマシンが手元にあるでしょうから、そのマシンを実機チェック用として使うというのがよくあるパターンです。

ただし、最近はサーバーアプリケーションやネットワークアプリケーションの仕事が多く、そういうアプリケーションの場合は、実機チェックの環境を SOHO 内に作ろうとしても著しく困難です。また、エラーメッセージのように、その状況を手元で再現するのが困難なケースもあります。このような場合は、できる範囲で実機チェックを行い、それ以上の実機チェックは得意先に任せるか、あるいは得意先でラボを借用して実機チェックする、というやり方になります。

クライアントの満足を得るための原則

どのような翻訳者であっても、顧客には勝てません。お客様は神様です。そして、翻訳という商品は読む人の主観的な好みで評価が左右されるために一概に翻訳品質を規定できません。あるクライアントは代行著述に近い理解の深い翻訳を高く評価しますが、別 のクライアントに持っていくと、同じ翻訳が危険な超訳としてとても低く評価されるということも現実に経験します。

前提として言えることは、まず翻訳品質の評価に先だって円満な人間関係が重要であるということです。人間関係が成立していない段階で翻訳の評価を下されると、辛い評価に傾きがちですので、得意先と円満な人間関係を結び保つよう翻訳者の側から努力することは意味があるでしょう。もっとも、いくら人間関係が良好でも肝心の翻訳が下手では話になりませんので、そのあたりは勘違いしないように注意しましょう。

仕事で行う翻訳の場合は必ず納期が設定されます。納期というものは、きちんと守っても評価は上がりませんが、みだりに破ると評価が落ちます。納期厳守は必要条件であっても十分条件ではないと心得るべきでしょう。納期に遅れることは待ち合わせに遅刻するのと同じです。一方、評価を上げるポイントは翻訳の品質です。

致命的なミス、許されるミス

すべての翻訳者は多かれ少なかれ誤訳します。人間である限り、これは避けられません(といって機械ならば誤訳がないかというと機械には翻訳すらできないわけですが...)。大切なのは、つまらない箇所で誤訳やミスを犯さないということです。誰が見ても一目瞭然のつまらぬ ミスや誤訳は致命的です。一方、難しい個所で誤訳してもほとんどの人はそれが誤訳だと気付きませんから、そういう誤訳は迷宮入りになります。

こういう理由から、誤字脱字や訳抜けのような基本的なミスは非常に評価を下げるわけです。トライアルでも、基本的なミスを犯している回答は即座に不合格にする翻訳会社が多くなるのも当然です。

これに関連して問題なのが、「地雷を埋める」という行為です。すなわち、一見すると流れるような日本語に訳してあるのですが、英文と照らし合わせてみると、内容をまるで理解しておらず、技術的には完全なる誤訳であるような訳文を生成する翻訳者を「地雷屋」と呼びます。なぜ地雷かというと、一見しただけでは日本語がきれいで、そこに地雷が埋まっていると気付かないからです。チェッカーや QA 担当者もともに地雷の存在に気付かず、そのまま得意先に納品して、そこで誤訳が判明すると (地雷が爆発すると) その後始末が大変です。

翻訳者はくれぐれも、「地雷を埋めないように」注意してください。言い換えれば、技術的内容を深く理解していないのに、中途半端な理解で日本語表現だけをとりつくろうようなことをしないでください。そのような場合は、理解が不十分であることが分かるように翻訳者コメントを付けてもらうほうがよほど親切です。たとえて言えば、地雷が埋めてある箇所には旗をちゃんと立てておいてください。旗がたててあれば、その地雷は納品前に撤去可能になりますから。

新規訳語とコメント

上に述べた理由により、翻訳者は納品時に翻訳者から査閲者へのコメントを用意することが望ましいわけです。あわせて、支給されたグロサリにない新規用語についてどのような訳語をあてたか示す、新規訳語(案) も得意先に提出するとさらによいでしょう。

本当は翻訳者が感じた疑問は翻訳中にだれか詳しい人にリアルタイムで質問できて疑問を解決して翻訳できれば一番いいのですが、現実にはそのようなフォロー体制が敷かれることはまずありませんから、翻訳者はコメントを埋めるなり洞察力を高めるなりして、疑問に対処しなければなりません。

(1999年12月14日執筆)

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