こんにちは！ デバイスソフトウエア開発部の米森です。
以前、「やさしい日本語」をテーマにグローバルメンバーとのコミュニケーションについての記事を公開いたしました。
こちらは口頭でのコミュニケーションを前提とした話でしたが、今回はテキストベースでのやり取りに主眼を当てます。
テキストの場合、口頭でのやり取りとは違って自動翻訳ツールの導入が容易です。Microsoft Teamsを使用していれば標準の翻訳機能を使用してメッセージを逐次翻訳することができますし、WEBブラウザであれば、Google翻訳でページ全体を簡単に翻訳することができます。
これらのツールはシームレスに翻訳をしてくれるので便利な一方、その翻訳過程はブラックボックスなので翻訳前後の意味が同じであることをどう保証するかが重要です。
「よろしくお願いします」を自動翻訳すると、「Thank you」のような英訳が返ってきますが、少し違和感があります。英語であればこのような直感が多少働きますが、他の言語への翻訳となると、最終的にどのようなニュアンスで翻訳されているかは一切把握できません。
報連相が重要であるビジネスコミュニケーションにおいて、自分自身の発言内容を把握していないのは危険です。かといって、ツールがアウトプットする外国語を理解できるようになるまで語学力を上げるのは現実的ではありませんし、本末転倒です。
なので、今回は自動翻訳のアウトプットではなくインプット側にフォーカスし、自動翻訳使用時に発生する翻訳ミスの事例とその解決策をご紹介いたします。
（準備）日英翻訳シートを作る
本記事では、日本語・英語間の翻訳を前提に話を進めます。
日英間の翻訳挙動を調べるため、今回はGoogle スプレッドシートのGOOGLETRANSLATE関数を使用します。
|
1 |
=GOOGLETRANSLATE(<翻訳対象テキスト>,<元の言語>,<翻訳先言語>) |
という構文なので、
|
1 |
=GOOGLETRANSLATE(A2,"ja","en") |
で、A2セルの日本語を英語に翻訳できるようになります。
この関数を使うと、翻訳前の元の文と訳文の両方をスプレッドシートに記録できるので、翻訳を通じて伝達ミスが起きた際にその原因を調査することができます。
事例1. 主語が変わってしまう
日本語において、主語は必須文法要素ではありませんので省略しても非文ではありませんが、英語は必ず主語が必要な言語です。
例えば、「明日の会議で確認する。」は、「I’ll check it out at tomorrow’s meeting.」と翻訳されるので、翻訳前の文にはない「I」を補完してくれていることが分かります。
しかし「次回の定例会で確認する。」と少し文言を変えると、主語が「We」になってしまいました。
なぜこのような変化が生じるのかは不明ですが、補完される主語が文によって変わってしまうのは紛らわしく、責任の所在が不明瞭になります。
他の例も見てみます。
個人の理解や見解を示す際に「認識」という言葉が使われることがあります。例えば、「本件は対応不要という認識です。」を翻訳すると、「It is understood that no action is required in this case.」となります。
この英訳は「本件は対応不要と（みんなに）理解されています」という意味です。主語が曖昧になり、「認識」という言葉が含意する「飽くまで個人の理解・見解である」という要素が抜けてしまいました。
このような不正確な翻訳を避けるため、日本語として不自然でも主語はなるべく明示するようにしましょう。
|
1 2 |
修正前：「次回の定例会で確認する。」 修正後：「私が次回の定例会で確認する。」 |
とすると、主が「We」ではなく「I」として翻訳されます。
|
1 2 |
修正前：「本件は対応不要という認識です。」 修正後：「本件は対応不要という私の認識です。」 |
とすれば、「my understanding」であることが翻訳後も残ります。
事例2. 用語の訳語にゆれが生じる
複数人で業務を進める上で、用語とそれが指し示すものの定義はとても重要で、ここに認識齟齬が生まれると業務効率の低下につながります。
しかし、翻訳ツールを使うと翻訳の前後で用語の一貫性が失われてしまうので注意が必要です。
「在庫」という用語がどのように英訳されるかを見てみましょう。単純に「在庫」とすると「stock」と訳されます。
しかし、「在庫を削除する。」だと、なぜか「Remove inventory.」と翻訳され、「在庫」という用語の訳が変わってしまいます。
「『在庫』を削除する」とかっこを添えると、「Delete “Inventory”」のように対応する語にクォーテーションマークを付けてくれるので、特別な用語であることを示せます。
しかし「stock」を想定しているのに「inventory」と翻訳されてしまっていることに変わりはありません。
この事象を解決するためのアプローチとして、明示的に訳語を提示するという方法があります。DeepLを使用する場合、ユーザー定義の用語集を追加することができます。
このように、「在庫=stock」と明示的に教えることで、こちらが意図した通りに翻訳してくれます。
＜ユーザー定義用語集無しの場合＞
＜ユーザー定義用語集有りの場合＞
明示的に訳語を提示するというアプローチは、用語集を定義する手間が増えてしまいますが、NotebookLMを始めとしたAIツールへの応用もできそうです。
事例3. 曖昧な修飾を正確に翻訳できない
「『致命的な』バグ」、「『仮で』対応しました。」のように、文中の言葉に対してより詳細な説明を付すことを修飾といいます。正確なコミュニケーションをする上で必須な文要素ですが、文が長くなると修飾の繋がりが見えにくくなり、意図が変わってしまうことがあります。
次の文を考えます。
|
1 |
「パラメータを検証する共通クラスのfooメソッドを確認してください。」 |
この文は、以下2つの解釈が考えられます。
- パラメータ検証を担うのは「共通クラス」
- パラメータ検証を担うのは「fooメソッド」
修飾の対象語は語順的に近い方が自然なので、1の解釈の方がより一般的でしょうか。
この文を英訳してみると「Check the foo method in the common class which validates the parameters.」となるので、1の解釈が採用されていることが分かります。
英語でも日本語同様解釈の余地がありますが、1の解釈が自然であると言えると思います。
この解釈の揺れは以下のように、意味的に近い要素を近づけ、必要に応じて読点で区切ることで解決できます。
|
1 2 3 |
修正前 ：「パラメータを検証する共通クラスのfooメソッドを確認してください。」 修正後①：「パラメータを検証する共通クラスに属する、fooメソッドを確認してください。」 修正後②：「共通クラスに属する、パラメータを検証するfooメソッドを確認してください。」 |
最後に
自動翻訳は便利である一方、アウトプットされたテキストが同じ意味を保っているかの保証が難しいです。今回ご紹介した工夫をすれば、意図せぬ翻訳結果になることは減らせると思いますので、ぜひ意識していただければ幸いです！
また、エコモットでは一緒にモノづくりをしていく仲間を随時募集しています。弊社に少しでも興味がある方はぜひ下記の採用ページをご覧ください！
