IT技術者と英文ライティング　～AI時代のIT技術者の英語との付き合い方

 

text＝米田 謙　日本IBM

 

日本のIT技術者が英語を求められる場面

今から10年ほど前、一部の日本企業で英語を社内の公用語にするという取り組みが相次いで発表されました（＊1～3）。狙いとしては、海外事業の展開や、グローバルに活躍できる人材の獲得・育成がありました。このような取り組みが始められてから数年経った現在、その結果は賛否両論ありますが、英語を公用語にした企業に関わるITの現場でも成果物や報告書を英語で作成しなければいけないといった影響がありました。

私が所属している会社では、英語は公用語ではありませんが、外資系ということもあり、英語を必要とする場面がいくつかあります。特に以下に挙げた最後の3つは必ずしも日常的に英語を使う役割にない社員であっても、キャリアの途上で避けられないものになっています。

・英語を公用語にしているお客様への提案やプロジェクト
・お客様や社内のグローバルプロジェクト
・米国本社への報告
・日英併記の全社宛・事業部全体宛メール
・海外ボランティア（＊4）やテクニカルコンテスト（＊5）など、グローバルの各種プログラムへの応募
・技術系プロフェッション審査の申請書類（＊6）
・昇進条件のTOEICスコア
・英語と日本語のCV（職務経歴）登録

また、ここ数年の間に有償/無償で使える翻訳ツールの選択肢が増え、機械翻訳の精度が向上していることを実感している人も多いかと思います。さらに文書作成ソフトウェアやプレゼンテーション資料作成ソフトウェアなどのファイルをアップロードすると、翻訳された状態のファイルを作成してくれるような機能も提供されるようになりました。このような翻訳ツールの発展から、全体的に英語のアウトプットを作成する障壁が低くなり、これまであまり英語を求められてこなかったIT技術者であっても、以前より所属企業やプロジェクトなどで求められるようになっているかもしれません。

伝わりにくい英文

私は海外駐在を含めて10年近く複数の比較的大規模なグローバルプロジェクトに従事し、英語が得意な人、それほど得意でもない人の書いた英文を目にする機会がありました。その中には、日本語的な思考で書かれた文章をそのまま英語にしたり、本人または翻訳ツールや外部翻訳サービスなどの第三者が内容を踏まえずに直訳したりしてしまったために、英語圏の読み手にとって伝わりにくい英文になっているものもありました。

これまで見てきた伝わりにくい英文の代表例として、以下のようなものがあります。

・主語を省略するなど、英語の文型に沿っていない（＊7）。
・文頭が小文字で、文末のピリオドがなく、文章の切れ目が分かりにくい。
・受動態を多用している。
・否定文や二重否定文を多用している。
・日本語の体言止めをそのまま英語にしている。
・和製英語や、英語とは異なる意味で使われているカタカナ用語をそのまま英単語として使っている。
・単語と単語を連結していて、製品やサービスなどの固有名詞なのか、スペースを省略した一般用語なのか、区別がつかない。
・日本語でしか通用しない記号を使っている。

英語のアウトプットを作成する3つのパターン

英語ネイティブではない日本のIT技術者が英語のアウトプットを作成する際には、3つのパターンがあると考えています。

 

1つ目は、はじめから英語のアウトプットを作成するパターンで、英語が得意で、ある程度英語で思考し、英語で文章を組み立てられる人のやり方になります。

2つ目は、はじめに日本語のアウトプットを作成してから、本人が英語のアウトプットを作成する（翻訳する）パターンです。先に日本語で考えを整理してから英語の文章を書くので、このやり方を採用する人は多いかと思います。

3つ目は、日本語のアウトプットを作成した人とは別の第三者もしくは翻訳ツールなどが英語のアウトプットを作成するパターンです。ここでいう第三者とは、職場にいる英語が得意な帰国子女や留学経験者だったり、英語のネイティブスピーカーだったり、外部の翻訳サービス事業者だったりします。グローバルプロジェクトで英語のアウトプットが大量に求められる場合や、すでに日本語で作られた製品やアセットなどをグローバル展開するような場合は、このやり方を採用することが多いのではないかと思います。

日本語の原文を作成するにあたっての注意点

3つのパターンの中でも、2と3のパターンで英語のアウトプットを作成する場合に、上に挙げたわかりにくい英文になりやすい傾向があるように思います。逆説的ではありますが、翻訳ツールが高度に発展している今こそ、正しい日本語を書けることが重要になっていると考えます。正しい日本語をインプットとして翻訳された英語は書き手の意図を的確に反映し、結果的に伝わる英文になります。そのためには、英語にすることが決まっている文書について、はじめに日本語を書く時から以下のような点に注意して書く必要があります。

・英語にした時に完全文になるように日本語の文章も書く。
・句点を省略しない。
・能動態で書く。
・肯定文で書く。
・体言止めは、用語やデータ項目の意味定義など、英語でも体言止めが自然な個所に留める。
・同音異義語、異音同義語をなるべくなくす。
・同じ言葉を英語、カタカナ、日本語（漢字）で表せる場合は、日本語（漢字）→カタカナ→英語の順で優先的に用いる。
・ダブルバイト記号は使用しない。

第三者や翻訳ツールに英訳を委ねる場合の書き手の責任

3つ目のパターンで英語のアウトプット作成を第三者や翻訳ツールに委ねる場合も、その結果をレビューする責任は書き手に残ります。その際、レビューをする人は、日本語の原文、英語の翻訳文、内容の3つを理解している必要があります。

以前あるシステムの仕様書で「貸方/借方」を「Borrower/Lender」と訳しているのを見たことがあります。借方/貸方は簿記会計の用語で、正しくは英語では「Debit/Credit」と言います。おそらく翻訳した人は簿記会計用語だということを知らずに、金銭などを「借りた人/貸した人」と解釈したものと想像します。このような誤訳を正しい状態にするためには、書き手は、借方/貸方が簿記会計の用語であること、Debit/Creditという対訳があることを理解している必要があります。日本語と英語が得意な人であっても、簿記会計の知識がなければ、この誤訳に気づくことができません。

 

本記事では、IT技術者が英語のアウトプットを求められる場面、意図せず伝わりにくい英文となってしまう代表例、英語のアウトプットする方法のパターン、日本語から英語を作成する場合に日本語の原文を作成するにあたっての注意点、第三者や翻訳ツールに英訳を委ねる場合の書き手の責任についての経験談をご紹介しました。

私の個人ブログでは、今回ご紹介したような注意点や英語圏の読み手に伝えるためのヒントを、テーマ毎にもう少し掘り下げて書いています。組織として、個人として英語のアウトプットを作成する際に参考になるものがあれば幸いです。

「IT技術者のためのEnglish Writing」
https://youneedaken.hatenablog.com/

 

◎参考

＊1　「ユニクロ　英語公用語化」毎日新聞、2010年6月24日朝刊
＊2　「楽天、社内共通語を英語に　海外取扱高7割をめざす」日本経済新聞、2010年6月30日電子版
https://www.nikkei.com/article/DGXNASDD300CZ_Q0A630C1000000/
＊3　「資生堂、英語を公用語に　18年に本社部門で」日本経済新聞、2017年2月20日電子版
https://www.nikkei.com/article/DGXLASDZ20IVU_Q7A220C1TJC000/
＊4　日本アイ・ビー・エム株式会社「コーポレート・サービス・コー」
https://www.ibm.com/ibm/history/ibm100/jp/ja/icons/corporateservicecorps/
＊5　IBM「Call for Code:Open source projects need you」
https://developer.ibm.com/callforcode/
＊6　データサイエンティストは課長級以上、アーキテクトは次長級以上、プロジェクトマネージャーとスペシャリストは部長級以上が英語で書類を揃えて審査を受ける。
＊7　SV (主語→動詞)、SVC (主語→動詞→補語)、SVO (主語→動詞→目的語)、SVOO (主語→動詞→目的語→目的語)、SVOC (主語→動詞→目的語→補語) の5文型。

著者｜
米田 謙 氏

日本アイ・ビー・エム株式会社　
IBM コンサルティング事業本部　アーキテクトCoC
シニア・アーキテクト
TEC-J Steering Committeeメンバー

大手金融機関の複数の大規模複雑なグローバルプロジェクトにアーキテクトとして従事してきた。途中IBM本社に出向し、お客様と共に日米横断アーキテクチャ推進体制のUSチームをリードした。現在は、複数のプロジェクトのアーキテクトを担当する傍ら、アーキテクト向け研修の講師やアーキテクトコミュニティの推進活動をしている。

。