期待以上の「心に刺さる」翻訳は、正確さだけで測れない──SPEEDA Localization Team

2013年　翻訳チーム設立、英語版SPEEDAをローンチ
2016年 　英日ユニットも設立、海外アナリストのレポートを和訳開始
2018年　新機能「トレンド」を国内・海外チーム合同でローンチ
2020年　Translation TeamからLocalization Teamへ改名、新ビジョンを掲げる

・Viktor Makhnutin（ヴィクトル・マフヌーチン／Team Leader）：
フリーランス翻訳者 → ブリヂストン（タイヤメーカー）→ Uzabase（2017年～）

・Luke O’Donovan（ルーク・オドノヴァン）：
Facebook（コミュニティオペレーションズ）→ Pernod Ricard（酒類メーカー：ブランドアンバサダー）→ Uzabase （2018年～）

・Xiaoye Li（リ・シャオエ）：
TransPerfect（Life Sciences） → Uzabase（2019年～）

・Laura Wakefield（ローラ・ウェイクフィールド）：
リコー → freee → Uzabase （2019年～）

・Cody Branscum（コーディー・ブランスカム）：
フリーランス翻訳者 → アルティア・セントラル（英語指導助手）→ 株式会社インブルーミー（翻訳課）→ フリーランス翻訳者 → Uzabase（2021年～）

・Eliza Lim（イライザ・リム）：
Arc Communications （翻訳会社） → Welocalize Japan（翻訳会社） → Uzabase（2021年～）

・齋藤 茉菜（Mana）：
英国リーズ大学 Applied Translation Studies 修士号取得 → Uzabase（2018年～）

・石﨑 彩子（Ayako）：
セイコー → 翻訳会社（エネルギー専門）→ フリーランス翻訳者 → Uzabase（2021年～）

・後藤 央依（Terry）：
英会話講師 → 外資の自動車部品メーカー（セールスエンジニア） → 中川政七商店（小売業） → IT企業／フリーランス → 国際特許事務所（特許翻訳） → 外資の情報サービス企業 → Uzabase（2021年～）

Viktor Makhnutin（ヴィクトル・マフヌーチン／以下「Viktor」）：
SPEEDAでは、市場を分析した「業界レポート」や、自動運転などの市場変化を取り上げる「トレンドレポート」などのオリジナルコンテンツを多数提供しています。業界分析からコンテンツの企画制作までを一手に担うのがContent Divisionです

Viktor：
私たちの創業プロダクトである経済情報プラットフォーム「SPEEDA」では、自社のアナリストたちが「業界レポート」や「トレンドレポート」などを作成しています。SPEEDAは中国をはじめ海外でも展開しているので、それらをローカライズするのが主な業務で、通常業務の80〜90％を占めます。

業務の大まかな流れとしては、まず原文を翻訳者がローカライズしていきます。それを別のメンバーがクロスチェックして、フィードバックします。その後は元の翻訳者がフィードバックを確認・修正してSPEEDAにアップロードします。

原文のコンテンツを制作するチームと同じDivisionに所属しているので、ローカライゼーションやクロスチェックの段階で疑問があれば、原文の執筆者にすぐ確認できる環境です。原文であってもローカライズした文章であっても、「一緒にプロダクトをつくっている」感覚なので、書きながらブラッシュアップしていくことが多いですね。

Viktor：
業界レポートやトレンドは、ゼロからつくるものより更新するケースが多いんです。年1〜2回の頻度かな。この場合は更新箇所だけローカライズするので、量にもよるけど1〜2日で完成させています。ゼロから書かれたレポートは、本数としては少ないですね。

JtoE（Japanese to English／日本語→英語へのローカライゼーション）とEtoJ（English to Japanese／英語→日本語へのローカライゼーション）ではボリュームを計る基準が違って、JtoEは文字数、EtoJは単語単位で計算します。たとえば新規の業界レポートであれば、JtoEなら8,000字、EtoJなら3,000〜4,000語くらいが平均ボリュームです

齋藤 茉菜（以下「Mana」）：
新規で3,000〜4,000語くらいだと、ローカライゼーションからアップロードまで5日くらいでできますね。

Viktor：
グローバル市場のレポートだと追っている指標が多く、カバーする範囲も広いので、文字数が増えます。なので、これを翻訳するEtoJだとボリュームが多くなりがちですが、逆にJtoEの場合は特定の市場──主に日本・中国・台湾を分析しているので、そこまでボリュームは出なくて4,000〜5,000字程度です。

Mana：
ローカライゼーションには、まとまった時間と集中力が必要です。好みによりますが、私は午前中にガガッと翻訳するのが好きです。クロスチェックより翻訳の方が集中力が必要なので、頭がフレッシュな午前中にやるようにしています。EtoJユニットではほぼ毎日、昼会といって簡単な進捗共有の場をつくっていて、午後からはクロスチェックをやることが多いです。

Viktor：
僕も同じで、基本的に午前中に翻訳を終わらせて、午後からクロスチェックをやっています。

Viktor：
SPEEDA以外のいろいろな事業からくる依頼に対応しています。業界レポートやトレンドレポートと違っていつ来るか分からないことが多いので、それに対応するために、常に少し余裕ができるようなオペレーションを組んでいます。

具体的には、特定のメンバーをこのようなアドホック（臨時の）タスクのアサイン担当にしています。その人が全員の業務量を見て、「この人ならコレをこの期間でできそう」と判断して、本人に確認してアサインします。その部分は結構アジャイルですね。

時には1日に3〜4件一気にアドホックな案件が来ることもあるので、その時はチーム内で優先順位を話し合い、納期を依頼者と調整・相談します

Viktor：
一番の違いは「編集するかどうか」。ローカライゼーションには編集が求められます。もちろん原文を尊重しないといけないですが、届ける先は原文の執筆者ではなくユーザーです。ユーザーにとって分かりやすい文章に編集するのがローカライゼーションだと思います。

ローカライズのニュアンスを伝えるのにちょうどいい例が、ディズニー映画「インサイド・ヘッド」です。アメリカだと子どもが嫌いな野菜の代表例はブロッコリーなんですが、日本ではピーマンですよね。そこで日本版「インサイド・ヘッド」では、あるシーンで登場するブロッコリーが、ピーマンに差し替えられているんです。このように、単に翻訳するだけでなく、意図や文化を理解して、国や地域ごとに分かりやすい情報にしていくことが、ローカライゼーションの役割です。

Viktor：
私たちはローカライゼーションのスキルを「翻訳」と「編集」の2つに分け、さらにそれぞれベース、アップサイドのスキルを定義しています。

ベースのスキルは、翻訳であればファクトと意図を伝えること。編集は読みやすさ──どれだけ自然な文章にできるか、ということです。読みやすくないと「翻訳っぽいな」と思われてしまうので、かなり気をつけています。

アップサイドのスキルは、翻訳であれば文脈の把握。プロダクトとしての位置づけ、業界内での位置づけなど、いろいろな文脈を考慮しながら翻訳できるスキルですね。編集のアップサイドは、表現力の強さ。どれだけわかりやすく、面白く書けるかということです。全てに適用できるかというと、ジャンルによってどれくらい面白さが必要なのか異なるので、なんとも言えないですが。

難しいのは、それをいかに客観的に評価していくか。今、チームとしてまさに課題としていて、OKR（Objectives and Key Results：目標管理手法のひとつ）にも設定しています。

Mana：
一般的な専門用語を使うように注意することです。その業界で一般的に使われている用語なのか、読んだユーザーがその用語を次にリサーチするときも活用できるか、という観点で表現するのは難しいですね。翻訳は機械翻訳にかけてから読むので難しくないんですが、一般的に使われている専門用語にたどりつくまでのリサーチには時間がかかります。

Viktor：
そもそも「一般的な専門用語」の定義がすごく難しいんですよ。その業界でしか使われていない専門用語がある一方、業界にいなくてもだいたい意味のわかる専門用語もあります。その業界に詳しくない人を想定読者としているので、どちらかというと後者を選ぶことが多いかな。

Mana：
EtoJの場合、たとえばソフトウェア系の翻訳だとカタカナだらけになってしまうのも難しいところです。カタカナでもそれが一般的であれば使うけど、判断できない場合は使わない。こうした細かい意思決定を、一文、一節ごとにやっていきます。

Viktor：
最近は特にNewsPicksとの連携を強化していて、EtoJユニットでも案件が増えています。

たとえば最近ローンチされた「NewsPicks トピックス」というサービスだと、英語記事のサマリーを日本語訳して、記事の冒頭に提供するようにしました。サマリーは執筆者に英語で書いてもらうんだけど、がっつりローカライズして、読者に刺さる内容にしようとしています。

また、JtoEユニットではNewsPicksのブランドデザイン記事の英訳を、サービスとしてユーザーに提供しています。ブランドデザインの広告主である日本企業からの「この記事を日本語が読めない海外メンバーにも読んでほしい」というニーズに合わせてローカライズ。海外の読者にも「面白い」と思ってもらえるように試行錯誤しています。

あと、INITIALの国内スタートアップの資金調達レポートも英訳しています。そもそも日本のスタートアップ市場は海外から見るとブラックボックスなので、そのギャップを少しでも埋められるよう意識しています。先日ブルームバーグの英語版で僕らのレポートが引用されたときは、誇らしかったですね。

Viktor：
同じコンテンツDivisionに所属しているアナリストチームとは毎日やり取りしています。

翻訳者が原文の執筆者と直接連携が取れる、そのこと自体にやりがいを感じますね。翻訳者がプロダクトに最初から最後まで関わり、責任を持ってお客様に届ける経験は、翻訳会社にいるとなかなかできません。仲間とお互いにフィードバックを送り合い、知見を共有しながら翻訳していて、学びが多い環境でもあります。

また、役員と直接話しながらIR資料をつくる業務にもやりがいを感じます。ユーザベースは全体的にフラットなんですが、気持ちとしては業務上でつながりがあったほうが、より話しやすいですね。

Mana：
週1回の定例ミーティングでは、OKRの進捗や個人的な感情のシェアをしています。たとえば、「働き方の多様性ってどういうことなんだろう？」 とか、「今後は給与が上がることを前提にしない働き方を選ぶ人も増えてくるけどどう思う？ 」とか。感情以外にも、日常の些細なことにも興味を持つメンバーから「ヨーグルトのフタの裏はなめますか？」って唐突に質問が来たり（笑）。

Viktor：
あとはNewJoiner（以下「NJ」：新しく入社したメンバー）が増えたとき、NJは全員必須参加、他のメンバーも任意で参加できるコーヒーブレイクを定例MTG以外に週1回設定して、私も必ず参加するようにしています。最初はNJならではのいろいろな疑問が出てきますが、内容は「ローカライズする上でのエラーの定義」や「ユーザベースでの働き方」など、だいたい似通っています。なので、みんなで集まって話し合い、些細な疑問もそのままにしないようにしています。

Mana：
ちなみに、UB DAY（四半期に一度行われる、全社横断の事業共有会）とTHM（Town Hall Meeting：全社員を対象に毎週行われる、パーパス・バリュー浸透の場）が近づくと、大量の資料をローカライズするJtoEのメンバーがピリピリしているので、EtoJからは応援の気持ちを送っています（笑）。

Viktor：
EtoJメンバーに「ここの日本語がわからないんだけど」と相談することもありますが、各個人が一番得意な言語のローカライズを担当しているので、日本語から英語のローカライゼーションは基本的にJtoEユニットだけで対応していますね。

Mana：
日本企業だから、JtoEの翻訳依頼が圧倒的に多いんです。しかもイレギュラーや急ぎの案件が。なので同じチームのメンバーとしてせめて、「がんばれ」とか「おつかれ」みたいな応援と労いの声がけ（笑）を忘れないようにしています。

Viktor：
今はとにかく、フレームワーク化ですね。読みやすさと編集スキルの客観的評価はとても難しい。基準を明確に統一したほうがいいのか──原文に忠実にローカライゼーションするほうがいいのか、原文の意図を守りながらも自由度を高く書くのがいいのか。そして、その判断力をどういう風に磨いていくか。評価者によってバラつきが出ないフレームワークを作ろうとしています。

Mana：
あとは、フレームワークにも関わってきますが「脱・数値化」ですね。こんなに自由で何でもできる会社なのに、自分の翻訳スキルを「エラーの少なさ」でしか説明できないのはもったいないなって思って。

もちろん数値化も大事だけど、それが良いコンテンツをつくるうえで目的化しないようにしなければと思います。UBではOKRに基づいた目標設定を行うため、各部署ごとに「Competency Criteria」と呼ばれる評価基準を設けているんですが、今後は読みやすさの観点も基準に加えていきたいです。

Mana：
公平な評価をするためには、何を目指すか大枠を決めるのが大事です。そこで、2021年末のフレームワーク策定と同時期に、Localisation Teamが目指す大枠の方向性をまとめた「虎の巻」をEtoJユニットで作成しました。それに基づいて、クロスチェック基準も決めている最中です。

現行のCompetency Criteriaでは、「正確性」以外はあまり評価できていないんです。クリティカルなミスの個数はデータで細かく見ているけど、それだけで全体の品質は評価できないですよね。数値改善が目的化すると、読者の視点がごっそり抜けちゃう。EtoJ版の「虎の巻」はほぼ完成したので、JtoE版もつくるつもりです。

タイトルが上がるとミスも減って、翻訳スピードも速くなるはず、というのは現実的ではありません。読みやすさの工夫にもっと時間を割けるCompetency Criteriaをつくりたいです。

Viktor：
正確性だけを求めると、「読みやすさ」や「わかりやすさ」が置き去りになってしまいます。でも、ミスのない文章が読みやすいかっていうと、そうじゃない。もちろん、読みやすくてもミスが多いのはダメ。そのバランスですよね。

今まではミスばかりに着目していたけれど、フレームワークやコンピテンシーの策定で、今後はよりユーザーへの提供価値に目を向けていきます。ユーザーにとっても、脱字が全くない文章より、読みやすい文章の方が価値が高いはず。いま私たちはフレームワークを通じて、翻訳とローカライゼーションの違いを体現しようとしているんだと思います。決して簡単なことではありませんが、その挑戦にチームみんなワクワクしています！