翻訳者として開業する前はSEとしてシステムを開発・保守していたのだが、オフショア開発もやっていたため必然的に英語のドキュメントが必要になることもあった。
最初から英語でドキュメントを作成するプロジェクトもあるが、開発時は英語ができる人材がいたとしても、保守フェーズになると最低限の人数まで体制が縮小する。
必ずしも英語ができる要員が残り続けるわけではないので、だれでも保守できるように基本的に設計書は日本語で書かれることが多い。
他社の話だが、海外にプロジェクトオフィスがあるのに、外人含めてのコミュニケーションを日本語で統一している開発プロジェクトすら聞いたことがある。
基本は日本語の設計書だが、必要に応じて翻訳する場合、プロの翻訳者の翻訳とは根本的に異なると感じる。
プロの翻訳者は当然のことながら原文に忠実に翻訳する。だってそれが仕事だもん。
しかし、社内エンジニアが翻訳する場合、ある程度忠実に翻訳するが、読む人も開発のプロなので大体の意図は伝わるぐらいの翻訳である。
加えて、海外の開発者が間違いそうなところは、原文になくても注意事項を加えたりする。
なので、出来上った英文は原文の日本語とは厳密には一致していない。
あくまでも私がエンジニア時代にやっていた翻訳もどきの話だ。
エンジニアにとっての最終的な共通言語はプログラム言語なので、テスト含めてプログラムソースで正当性を担保するという考えになりやすい。
もちろん、仕様書もちゃんと書くのだけども。
基本的に社内の人間が、自分たちのプロジェクト内で使う資料を翻訳する場合で、自分で責任がとれるからやれる翻訳のやり方なのだ。
ちょっとつたない英語でも、「ちゃんと伝わるから問題ない。ネットの会議でも伝えておくから」ということも可能だ。
一度、翻訳会社に依頼して翻訳してもらったことがあるが、「確かに間違ってはいないのだが。。。」という印象だった。
しかし。。。
翻訳者になったいま振り返ると、その納品物はプロの翻訳者の仕事としては何も問題が無いと思う。
だって、依頼者と同じレベルのプロジェクト特有の知識を求めることは無理があるし、原文より素晴らしい英文は望むべくもない。
翻訳が”いまいち”と感じたのは、日本語の原文自体が翻訳用としては “いまさん” ぐらいのレベルだったのだろうと思う。
そう考えると、流行りのAI翻訳でも、質の悪い原文を入力にしてちゃんとした翻訳が出てくるはずがないのだ。
Garbage in, garbage out.
AI翻訳を活用したいなら、原文の質というか書き方を考えないといけないだろうね。
話を戻すと、翻訳もどきからプロの翻訳に変わるにはちょっとした壁を超えないといけないと思うわけです。おしまい。
コメント