さくら さん、こんにちは。

私もほぼ同じような仕事をしています。FM ファイルの STF ファイルへの変換、
Word での翻訳、STF の FM への再変換、そして最終的な PDF の出力までを、
一通り行っています。どのようにアドバイスしていいのか分からないのですが、
とりあえず私の場合について書かせていただきます。

通常は、「旧バージョンからの流用部分はバッチ翻訳して、更新部分だけを翻訳し
て終わり」では済みません。100% マッチ部分でも、いろいろと手を入れる部分は
ありますので。現に、外注先の翻訳会社などは、100% マッチ部分に対しても、新
規部分の数パーセントの料金を加算してきます。

私達も例に漏れず、常にタイトな納期に追われていますので、基本的に 100% マッ
チ部分に手は入れないという前提がありますが、「こりゃちょっとひでぇだろ」
という目に余る部分は、なんだかんだ言って直してます。また 100% マッチ部分
でも、フォント指定タグの内容が微妙に違っている（たとえば、<cs: code1>
が <cs: code2> に変わっているなど）場合や、前後の文脈から見て言い回しが
おかしい場合は、やはり修正しておく必要があります。

ただ、「過去の訳文についても品質を向上させる」という崇高な目標を立てると、
納期に到底間に合わなくなりますし、TRADOS を使用する意義が薄れてしまいま
すので、誤訳以外の修正に対する欲求（「てにをは」や言い回しの修正など）か
らは、あえて目を背ける勇気？も必要です。私も本来は、ちょっとでも気になる
部分は片っ端から直したいタチなので、あえて見逃す時には非常に狂おしい気分
になるのですが・・・

上司の方に理解がなくて辛いとのことですが、お気持ちは痛いほどわかります。
とりあえず、翻訳の全工程をこまか〜〜〜くリストアップして、それを提出し
てみてはいかがでしょうか。「ほら、全体の作業負荷に対して、翻訳はそれほど
大きい部分を占めていないんだよ？」みたいな（実は占めてるんですが）。

それに加えて、バッチ翻訳した 100% マッチ部分に手を入れずに PDF 化してし
まい、「ほら、100% マッチ部分でも前後の文脈やタグによっては、こんなに
変になるんですよ？ それでもいいの？」と見せつけてやるとか。

なんか、やはりぜんぜんアドバイスになっていませんね。すいません。誰か、も
っと頭のいい文章を書ける方のレスが付けばいいのですが・・・

さくらさま、皆様こんにちは。

お一人で管理から翻訳までこなしておられるとは、ご苦労お察しいたします。

私が係わっているのはソフトウェア関連の日英なので、お役に立つかどうかわかり
ませんが、バージョンアップに伴うの翻訳会社への発注は差分のみです。
すでに訳されている部分を全面的に見直すとか、既存部分と新規翻訳部分のつなが
りが悪くならないように考慮する、といったことすら行われません。
既存の問題点も発見・修正されないまま、版を重ねているのが現状です。

>「単なるアップデートなんだから、差分だけを翻訳すればいいのに、何でこんな時
>間がかかるんだ」と言われました。

上司の方のご指摘は、TRADOS使用の有無とは別の点にもあるのかもしれないです
ね。ローカライズサイクルは製品によっても違うのでしょうが、基本的に本国で製
品がリリースされたら、一日も早く日本語版をリリースしたいというのがメーカー
の本音でしょうね。マニュアル翻訳の品質を確保するために長い工数をとったとし
ても、良いものが出来上がったころには顧客は競合製品に流れてしまっているかも
しれない、それでは困る、とお考えなのではないでしょうか。
私が係わっている製品の場合ですと、日本語版のバージョンアップがほぼ半年お
き、ローカライズ版はそこから約1ヵ月程度の遅れでリリースされます。競合製品も
大体同じようなサイクルだと思いますので、マニュアル翻訳にかかる期間を長くと
ってしまうと、競合製品が先にバージョンアップを行い、新技術にいち早く対応し
てしまうかも知れません。その時点で、いくらマニュアルの翻訳品質が良くても技
術的には「一世代古い製品」になってしまいます。

また、周囲の開発者の方々が良く使う言葉で「スクラップアンドビルド」というの
をよく耳にします。せっかく途中まで出来上がっているものを何かの都合でつくり
なおさなければならないとき、「スクラップアンドビルド」せずに、使える部分は
使って、やり直しの負担を最小限に食い止める、というのがソフトウェアの発想、
と言いますか、美徳なのだろうと思います。

私たちも英語を仕事にする上で、その裏にある事情や考え方を把握しておかないと
ストレスが溜まってしまいますよね。

それにしても、「A・I」や「猿の惑星」など、日米同時公開なんて考えただけでも
すごいですね。しかも同時公開でなかったらあんなに話題になったかどうか...見に
行かなかったお客さんも多いのではないでしょうか(たぶん私もです)。

Injunjoeさん、nicoさん、
アドバイスどうもありがとうございました。

同じ業界の方からご意見を頂けるのは、本当に心強いです。

nicoさんのおっしゃる通り、競争の厳しいソフト業界ですから、
確かにいくら良いものをつくっても世間はいつまでも待ってはくれないですよね。
納期と品質のトレードオフが必要になるのだと思います。
納期のために品質を妥協する、という意味ではありませんが、
両者のバランスをとっていくことが課題かな、と思いました。

今回は上司と話して、10冊ほどあるマニュアルのうち主要なものを日本語版製品リリースまで
に、残りはその後1ヶ月以内に、という妥協案でとりあえず決まりました。

「過去の訳文の品質向上」は私にとって一番頭の痛い問題です。
自分の過去の訳文を読むと直したいところがどうしても目についてしまいます。
Injunjoeさんのおっしゃる通り「あえて背を向ける」ことも確かに必要ですね。
もちろん、今後直す必要のない優れた翻訳をするに越したことはないのですが・・
それを目指して頑張ります。

ただ、nicoさんの会社の「既存の部分は見直さない」というのも驚きでした。
アプリケーションの性質にもよるのだと思いますが・・
いろいろ考えさせられ勉強になります。
どうもありがとうございました。

さくらさま、みなさま、こんばんは。経験も乏しく、しかも文系（？）なのにずーずーしくも書
き込みをさせていただくご無礼をお許しください。社内翻訳のはしくれからの拙文です。

これまであちこちにおりましたが、同シリーズの文書のアップデートの対応は、
（１）差分のみ。
（２）全体的に。
というのは、訳者によって、またはその企業（部署）の方針によって、まちまちでした。

（１）の言い分としては、「前バージョンとの継続性の重視」「前回、既に最終版となったもの
を勝手な一存でかえていいものか（結局は、個人的な好みに左右されるところも大きい）」「時
間的効率性の重視」等です。
（２）の言い分としては、「誤訳を使いまわしてしまう危険性」等ですが、これがきっとさくら
さんの主張されるところだと思います。

私は、どちらかといえば（１）の方です。よほど時間的に余裕があれば（２）が理想なのです
が。ただ、（１）としても、必ずざっとは原文と訳文の全体をを読み合わせます。そして、明ら
かな誤訳、訳脱は、直します。でも、「見つけられた範囲で」というだけで、逐語的には見ませ
ん（見るだけの時間がありません）。私が訳したのでもない個所に、クレームがついたりする場
合があるので（社内からですが）、それだけは回避する、というのが目的です。また、その
TRADOSのデータベースを作成した訳者の力量によっても「あらさがし度」は変わるようです
（これは一般論です）。

少しでもご参考になればよいのですが。　

ちょびさん、

コメントありがとうございました。大変参考になりました。
お礼が遅くなってすみません。

>（１）の言い分としては、「前バージョンとの継続性の重視」「前回、既に最終版となったもの
>を勝手な一存でかえていいものか（結局は、個人的な好みに左右されるところも大きい）」「時
>間的効率性の重視」等です。
>（２）の言い分としては、「誤訳を使いまわしてしまう危険性」等ですが、これがきっとさくら
>さんの主張されるところだと思います。

そうですね。私の場合「誤訳」もそうなのですが、自分の未熟な翻訳が目に付いてしまい・・ということ
も大きいです。ただ(1)の言い分にあるとおり「一度は最終版として世の中に出た」ものですから、本来
直す必要がない、という状態であるべきなんだと思います。

さくらさん、私も自分のやっつけ翻訳に再会してしまったときや、そうでなくとも「今ならこうは訳さないの
に！」という過去の翻訳に泣きたくなるときは多いです(できることなら封印してしまいたいくらいです)。そし
て、時間的なことを言い訳にしてはいけないと思いながらも、新しい翻訳に対して未熟ながらもその時々のベスト
を尽くす、ということでしか対応できません。さくらさんの真摯なご姿勢には、学ぶところが多いです。ありがと
うございました。