投稿者「trivector staff」のアーカイブ

trivector staff について

トライベクトル株式会社スタッフです。 BtoB 向けを中心に翻訳や通訳、ローカライズ、英会話等についてお得な言語コミュニケーションサービスについての情報をお届けします。お気軽にご相談&お問い合わせください。

【徹底解説】Web サイト翻訳の見積もり依頼の方法

スタッフ N です。

昨年来、コロナ禍で Web からのリード獲得やコンバージョンに注力される企業様が増えており、弊社にもコロナ前と比べ 3 倍近くの Web サイト翻訳のご相談依頼が続いております。

様々なご相談をいただいておりますが、その中でも特に最近になって Web に力を入れ始めたお客様の場合、翻訳やローカライズのお見積りを作るにあたり、必要な情報が不足してしまい、やりとりにお手間をかけてしまう上、正確なお見積りをお伝えできなかったというケースもあります。

一方で、Web サイトの翻訳についての相談ポイントを正しく知っておかないと、発注後に齟齬が起きてトラブルになってしまう可能性があります。

そこで今回は、発注後のトラブルを防ぎ、お見積段階から納品まで、正しくスムーズにプロジェクトを実行していただくための方法をご紹介します。

翻訳の見積もりに必要な6つのポイント

外資系企業のための CMS を活用した Web サイトローカライズ

Webサイトの翻訳で最も多い見積依頼の4パターンとは

翻訳のお見積り依頼をいただく際に、ほとんどのお客様が以下の 4パターンのいずれかでご相談いただくことが多くなっています。

  • 翻訳対象の Web サイトの URL を送る(トップページの URL のみ)
  • 翻訳対象ページの URL だけを送る
  • 翻訳対象の Web サイトの URL と文字数を伝える
  • 翻訳対象となるテキストを Word か Excel で送る

上記のパターンにはメリットデメリットがあります。以下に解説します。

1. 翻訳対象の Web サイトの URL を送る(トップページ URL)

お見積り依頼時に翻訳対象の Webサイトのトップページの URLだけを送るパターンです。

問い合わせ例:

https://www.trivector.co.jp/

「上記サイトのお見積りをお願いします」

一番多いのがこのパターンでのお見積り依頼です。確かに、URL をコピペして、メールに張り付けて送信するだけなので非常にスピーディで楽です。しかしお見積もりの精度としては、これがもっとも精度が低くなってしまいます。

  • 翻訳対象となるページが正確ではないため、対象ページに見落としや抜けが出る可能性がある
  • 画像や動画などが含まれる場合の確認をしたり、その分、抜けや漏れが出る可能性がある
  • 基本的に Web サイト内のテキストをコピペして分量を算出するが、コピペ防止の Web サイトの場合は取得できない
  • 逆に翻訳対象外にもかかわらず、不要な個所を含めてしまい見積もり金額が上がってしまう
  • 見積もり前の確認作業が増えるため、見積もりを出すまでに時間がかかる(翻訳会社によっては対応不可、もしくは別途作業費がかかるケースも)
  • 翻訳対象に抜けがあった場合、追加費用が発生し、ローンチスケジュールに間に合わない
  • Web サイトを元に見積もりした時から内容が更新されることもあり、見積もりの精度が落ちる

2. 翻訳対象ページの URL だけを送る

問い合わせ例

https://www.trivector.co.jp/

https://www.trivector.co.jp/service/

https://www.trivector.co.jp/service/beforeorder/

https://www.trivector.co.jp/feature/

https://www.trivector.co.jp/brandoftranslation/

「上記のURLのお見積りをお願いします」

これは 1 番とほぼ同じですが、最初の「翻訳対象となるページが正確ではないため、対象ページに見落としや抜けが出る可能性がある」という点は防ぐことができます。しかし、それ以外については同様の理由により不明確な点が多くなります。

3. 翻訳対象のWebサイトのURLと文字数を伝える

問い合わせ例

https://www.trivector.co.jp/  (200文字)

https://www.trivector.co.jp/service/(300文字)

https://www.trivector.co.jp/service/beforeorder/(180文字)

https://www.trivector.co.jp/feature/ (2,000文字)

https://www.trivector.co.jp/brandoftranslation/  (780文字)

合計:3460 文字です。上記の URL のお見積りをお願いします。

あらかじめ分量と内容がわかるため、お見積りは比較的早く提出できますが、いくつか注意点があります。

  • お客様による分量の算出方法に誤りがないか、実際の原稿を Word か Excel でお借り次第、再度見積もり
  • 実際の作業時は Word か Excel で支給してもらう必要がある(これができなければ、1 および 2 と同じリスクが発生する)

1 番や 2番よりはリスクは減りますが、最も安全とまでは言えません。最後にお勧めする方法がもっとも安全で正確な見積もりを作ることができます。

4. 翻訳対象となるテキストを Word か Excel で送る

問い合わせ例

添付のエクセルに、翻訳対象のテキストを URL ごとに記載してあります。こちらのファイルを元に、お見積りをお願いいたします。

この方法が一番安全かつ、正確にお見積り作ることができますし、以下のメリットを享受することができます。

  • 見積もりをすぐに作ることができる
  • 対象箇所に誤りが出にくい
  • ファイルに上書き、または併記にして納品できるためお客様側で最終確認をしやすい
  • 多くの翻訳会社の見積もりの基本算出方法である「分量×単価」の「分量」を正確に出しやすい
  • 明らかな不要箇所(重複しているヘッダー、フッターのメニュー、URL・電話番号など)を特定できるため、コストを抑えられる

それぞれの特徴(まとめ)

上記の内容を表にまとめるとこのようになります。

それでもスピーディで楽な方法が良い?

前述のように実際に多いお見積り依頼はスピーディで楽な 1 番のパターンです。パッと URL をコピーしてメール送るだけですから、急いでいるときは特にそうしたくなると思います。

ただこれまでお伝えしてきた通り、結局、その後、翻訳会社から翻訳対象箇所の確認の連絡があったり、どこまで作業するかといった条件の確認があるので、それらのやり取りの時間を考慮しトータルで考えると、むしろこちらのほうが時間がかかってしまったというケースもあります。

つまり、1 番~3番目までの方法は実際には「楽」ではなく、「楽」に見えるだけで、最終的にはお客様側のご負担が大きくなってしまいます。

ましてや、もし貴社が、その先のお客様から Web の翻訳相談を受けていれば、貴社だけではなく貴社のお客様にもやり取りのご負担がかかってしまう可能性があります。

そういったことを防ぐために、ぜひ 4 番目の方法をご検討いただきたいのですが、そうは言っても「実際にやるかどうかわからないのにそこまでは準備できない」というご意見もあるでしょう。その場合には以下の条件で、概算お見積りをお渡しすることが可能です。

概算見積もりについて

お問い合わせいただく際に、よくあるのは以下のようなご意見です。

「まだやるかどうかもわからないから、Word や Excel の準備はできない」

とりあえずどのくらいの金額と作業期間がかかるのか目安が知りたいだけ

確かにこのような場合には、Word や Excel をわざわざ見積もり時点で準備するのは難しいと思いますし、弊社でもそのような場合は、「何が何でも Word や Excel で支給してください」とは申し上げません。

ここまでにお伝えした URL 等でのお見積りの精度のご説明を差し上げ、あくまで概算見積であり、正式なお見積りは諸条件がはっきりした時点で作り直すという前提で概算見積もりを準備しますのでご安心ください。

翻訳会社にはこの順番で問い合わせよう

上記の優先度に応じて翻訳会社に問い合わせると概算見積もりとはいえ、それなりの精度の高いお見積りを取ることができます。

TRADOS などの翻訳支援ツールではだめなのか

また Web サイトの翻訳を行う上で、翻訳支援ツールを使用してお見積りを作るというケースもあります。

※Web サイトコンテンツのようなマーケティングマテリアルについて、TRADOS を代表とする翻訳支援ツールを使用すること自体の信頼性がどうなのか、という点は今回は割愛します。

あくまでお見積りを作成するという点において考えると、結局のところこれも同じことです。

お見積金額や納期に関わってくるのは、ツール使用の有無でなく、「翻訳対象箇所を具体的に指定できるかどうか」だからです。

「なんとなくこのあたりを見積もって」ということであれば、TRADOS を使っても正確にはカウントできません。そのため、こちらも概算お見積りとして使用することはできても、対象範囲をはっきりさせることがより重要だと言えます。

まとめ

いかがでしたでしょうか。翻訳の見積もりをとるに限らないのですが、結局のところ、「最初に手間をかけるか、後で手間をかけるか」という点が重要だということです。

確認作業を減らし、正確で安全なお見積りを翻訳会社からとることを目的にしますと、「仕事は準備が7割」と言うくらいですから、やはり事前にファイルを整理していたただくのが最も効率が良いと言えます。

今後もコロナウイルスの影響はまだまだ続きそうですので、Webサイトに注力される企業様は増えていくでしょう。そういったお客様のために、弊社で少しでもお役に立つことができれば何よりです。今回の記事には書いていないようなケースもあるかと思いますので、こういう場合は?これはどうなるの?これもできる?などなど、ご質問等ありましたら、遠慮なくお気軽にお問い合わせください。


そのフィードバックは大間違い?訳文の品質を向上させるためのフィードバックとは

スタッフSです。

翻訳の仕事では、お客様とのやり取りが複数回にわたることもありますが、それは訳文をお客様のご希望の形に合わせていくためであり、「お客様がご希望の訳文品質」を作ることにほかなりません。

翻訳の目的は、お客様のチェック作業が楽になり、最終的には翻訳業務をアウトソースするコストパフォーマンスが向上することでしょう。

翻訳は「手段」であって「目的」ではない

そのためにはこの一連の「フィードバック」をしっかり定義しておく必要があります。

今回は、納品後の「フィードバック」について、翻訳会社の視点とお客様の視点の両方から見ていきたいと思います。

そもそもフィードバックとは

フィードバック(FeedBack)とは、もともと制御工学で使われていた用語で、出力された結果を入力側に戻し、出力を調整することを指します。

派生して、あらゆる分野でフィードバックという言葉を使うようになりました。翻訳やローカライズにおいても、同様の意味でお客様からのご指摘やご指示というニュアンスで使用しています。

フィードバックは非常に重要なプロセスです。なぜなら、これは品質改善に直接影響するプロセスだからです。

一方、「アンケート」や「お客様の声」などがあります。作り手にとって第三者による使用感、感想といったものは製品やサービスの改善のヒントとなることが多く、あらゆる業界で「現場の声」「使用者の声」や「アンケート」などを重要視しているのは言うまでもありません。

お客様からの反応はどちらも大切なのですが、フィードバックの場合には、納品後に訳文を戻していただく時から活用することができます。

特に初めてのお取引となる場合にはとりわけフィードバックは不可欠な要素であり、フィードバックをもとにした品質改善を行うことで、次回以降の翻訳やローカライズの品質やサービスの向上に役立てることが可能になります。

つまり、「ここが悪かった」、「ここをこうした方が良いのではないか?」という点において、お客様から具体的な指示をいただければ、それらをすべて検証し、次回以降に生かすことができます。

間違ったフィードバックの方法

まずはじめに、間違ったフィードバックの具体的な例をあげてみましょう。

間違った形でフィードバックをしてしまうと、その内容によっては、かえってミスが発生する、混乱を招くなど、結果的にお客様にご迷惑をおかけしてしまうことも少なくありません。

もちろん、そういったことのないように翻訳会社側も努力していますが、どうしても確認事項が増えてしまったり、ご希望の形になるまでに時間がかかったり、またあまりご満足いただけないこともあります。

その典型的なフィードバックをご紹介します。

例1:手書きで原稿に赤入れする

翻訳会社から納品された原稿をプリントアウトし、赤ペンで修正箇所を記入した。それを翻訳会社へPDFで送った。

頻度としてはそれほど多くはないのですが、しかし未だゼロにならないのが手書きによるフィードバックです。紙の原稿のお仕事の場合、どうしても手書きになってしまいがちです。たしかに、校正やチェック作業というのは、印刷してから行う方が間違いを見つけやすかったりするのは事実ですし、修正箇所を手書きですぐに書き込めることは便利だと言えます。

しかし、実はこれをそのままPDF化してお送りいただくと、修正ミスや抜け漏れが発生しやすくなってしまうのです。

理由は3つあります。

ファイル内検索ができない

手書きの場合、ファイル内検索ができないため、似たような文章が多くあるときには、該当箇所の特定に時間がかかります。

手書きが読めない

これはなかなか申し上げにくい点ですが、修正指示が走り書きのような文字だったり、省略形で記入されていたり、修正範囲が曖昧な場合など、どこをどう直せばいいのかがハッキリしないものもあります。その場合、読めなかった箇所については再度お問い合わせすることになり、結果的にお客様にご迷惑をおかけすることも少なくありません。

修正指示をコピペではなく入力しないといけない

これもよくありますが、修正指示がデータであれば、いったんそれをコピペして確認することもできますが、入力しなければならない時にはタイプミスの可能性を発生させてしまいます。

これらは純粋に修正作業ということではなく、余計な時間がかかってしまうため、手書き原稿よりは、PDF等にコメント機能を使用してフィードバックしていただくほうがより効率的です。

例2:修正意図がわからず、充分な確認が取れない

納品された訳文(英語)を読んでいたら変更したい単語があったので、訳文を消して(上書きして)入力しなおしたファイルを翻訳会社へ送った。

お客様の社内で、英語の堪能な方やネイティブの方にチェックして頂くこともあります。当たり前の話ですが、ネイティブがチェックを行う方が精度は格段に上がりますし、修正したい単語があれば、単語を直接修正したほうが効率的です。

しかし、納品原稿を上書きしてしまうことはお勧めしておりません。

その理由は、弊社側では「なぜこの単語の方が良かったのか」、「どういう意図があって修正されているのか」が読み取れないためです。そうなると私たちが出来ることと言えば、「英語としておかしくないか」という観点でのチェックになってしまい、内容への理解は及ばないことになります。

以下の例をご覧ください。

正しい修正指示の入れ方の場合、「どんな意図をもって修正しようとしているのか」が明確なため、翻訳会社側にもその修正の妥当性が判断しやすくなります。

そうでない場合には、翻訳者は原稿から読み取れる情報や調査を行い、内容理解を深めた状態で翻訳作業を行いますが、お客様側で修正した箇所が、どのような意図で修正されたのか、どんな基準で修正されたのかが分からないと、どうしても「英語として不自然でないかどうか」という表面的な確認になりがちです。

例3:ファイルを上書きする

お客様側で上書きされたファイルをお戻しいただくと、「どの部分が修正されたのか」が分からないため、まずは場所の特定から進めなければなりません。これは非常に非効率で、例えば 100ページにわたるマニュアルの場合、100ページ分を納品時のファイルと比較しなければならないからです。

「どこを変更したのか」がはっきり分かる状態でお戻しいただく必要があります。

例4:仕様が変更になってしまう

原稿作成者とチェッカーが別で、仕様の共有が行われておらず、修正箇所が全文に及んでしまい、翻訳しなおすことになった。

チェッカーがプロジェクトの概要を理解せず(または知らずに)訳文をチェックする場合、どうしても主観性が大きく入り込んでしまいます。

仮にチェッカーから「納品された訳文が全く使えない」というコメントが入っても、実はそれには理由があったりすることも少なくありません。コスト削減のため過去の訳文を流用するような指示があったとか、また、産業翻訳の大前提である、「原文に忠実に」という作業許可を頂いていたのに、原文から大きく乖離した訳文に修正してしまったり、といったケースは枚挙にいとまがありません。

こういった事態の場合、最初の仕様の共有をするところから始まり、その上で、訳文をどう修正するのかの方針を改めてお客様と決めなくてはなりません。

プロジェクト中の仕様の変更は、品質だけでなく金額や納期に大きな影響を与えるため、極力避けるべきですが、チェッカーの方のご意向などが強い場合には修正箇所が全文に渡り、使う単語や表現などを大きく方向転換しなくてはならないため再度翻訳作業を行わざるを得なくなります。

これでは、作業時間もコストも大きく無駄になってしまいます。

翻訳では、使用用途や完成イメージを共有するということはとても重要なポイントです。例えば、日本語だけで考えてみても「見出し」と「本文」では役割が違います。

「見出し」は一目見て内容がわかる事を「本文」は情報を正確に伝える事を目的としています。

目的が違えば、言葉選びや表現が変わってくるのは当然ですが、こういった(ある種細かいことですが)仕様の変更は、訳文全体に大きな影響を与えることになりますので注意が必要です。また、これはどの言語でも共通の注意点です。

スムーズなフィードバックのための3つのポイント

ではどうすればスムーズなフィードバックができるのでしょうか。ポイントは 3つあります。

ポイント1:コメント機能を使用する

Word、Excel、PDFなどの納品したファイルには「コメント機能」または「変更履歴機能」を使い修正箇所を指摘する

正しい修正指示の方法

 

ポイント2:修正意図を記載する

修正意図(なぜ修正したいのか等)が明確にわかるように元の言語で記載いただき、その上で使いたい単語がすでにある場合は「元の言語+修正したい単語」とセットで記載する

ポイント3:仕様を共有する

複数名による作業(執筆者:日本人、チェック担当者:ネイティブスピーカーなど)になる場合は、完成イメージや目的を必ず社内でも共有する(同じ方針でチェックする)

あらかじめ決められるものはしっかりと決めておく(特にプロジェクトの根幹にかかわるもの)ことが重要です。

フィードバックはその重要要素のひとつでもありますので、以下の記事等もご覧いただき、フィードバックを送っていただく際の参考にしていただければと思います。

翻訳、ローカライズのフィードバックの重要性