自己紹介＆どんな話？

グローバル開発部のYuki.Tです。グローバル向けプロダクトの運用や保守を担当しています。

グローバル開発部のメンバーの国籍は様々で、話す言葉も様々です。なかでも私のチームには「日本語が話せないメンバー」と「英語が話せないメンバー」が混在しています。そのためチーム内でのコミュニケーションを成立させるために、色々な工夫（苦労？）をしてきました。今回はその工夫の内容と、その過程で得られた気づきを紹介したいと思います。

結論

  - 「英語無理だったら、日本語でおｋ。」
  - 「喋れないんだったら、せめて書こう。但し正確に。」
  - 「大変だけど、頑張るだけの価値はあるよ。」

はじめに（どんなチーム？）

グローバル開発部内の私のチーム（運用保守チーム）でのお話です。約8名。
そのメンバー構成と仕事の進め方は、下記の様になっています。

メンバーの語学力は様々ですが、日本語メインの人が大勢を占めます（6人中8人）。

ちなみに私（日本国籍）は上記の"C"です。TOEIC 800くらい。
話すだけなら多少はいけますが、込み入った議論になると、途端に語彙不足が露呈します。あとリスニングが結構苦手…。

つぎに（YWT）

チームができた当初は、上記の分類でいうと"C"や"D"の人（以下「日本語メンバー」）ばかりで、コミュニケーション手段も基本的には日本語オンリー^[1]でした。その様なチームに、英語メインの"A"や"B"の人（以下「英語メンバー」）にジョインしてもらうため、色々な事を試してみました。

ここではその結果を、ふりかえりの手法のYWT^[2]（やった、わかった、つぎやる事）っぽくまとめてみます。シチュエーション毎に、「1.連絡手段(Slack)」「2.ミーティング(Teams)」「3.ドキュメント(Confluence, Jira)」の3つに分けて、紹介していきます。

1. 連絡手段（Slack）

やった	「日本語分からなくても、翻訳ツールにコピペで訳せば読めるよね？」
分かった	「訳して読んでくれるのは、最初のうちだけ。」 いちいちコピペで訳すのは、結構面倒なんですよね（自分でやってみると分かる）。 自分がメンションされていても、実際はあまり自分に関係しないケースも意外と多いため、「手間かけて訳してみても徒労に終わる」という経験が積み重なり、だんだんコピペ翻訳する気力が削がれていく様子。 またSlackは、単体のメッセージだけでなく、スレッド全体を読まないと意味が掴めないケースも多いです。それもまた翻訳のしにくさに繋がっている様です。
次にやった	「日本語と英語を併記しよう」 本当に伝えたいメッセージの場合は、英語でも書く様にしました。 コツは「日本語全部を訳そうとしない」という事。公開できる良い例が無かったのですが、例えばこんな風に。何の用件かは英語で分かる様にし、詳細が気になる用件なら、残りは自分で翻訳してもらうなり、個別で訊いてもらう様にしています。全部訳そうとすると、送り手側も大変ですしね。

2. ミーティング（Teams）

やった	①「日本語で話すから、Teamsの翻訳機能で字幕を読んどいて」 ②「英語が苦手な人も、頑張って英語でしゃべるんだ！」 ③「よし、じゃあ私が全部通訳してやるぜ！」
分かった	①「読んでも意味が分からない」 「口語の日本語⇒英語の機械翻訳精度は、まだまだ低い」というのが結論です。 特に少人数でのカジュアルなミーティングでの日本語は、言い淀んだり、主語や目的語が曖昧だったり、複数人が同時に話したりと、機械翻訳にとって色々悪条件が重なるのも一因なのでしょう。 ②「誰も幸せになれない」 喋ってる本人も「…これでいいのかな？（不安）」と思いながら、途切れ途切れに話す拙い英語は、日本語メンバーにも英語メンバーにも伝わらず…。あとは「英語で何て言うか分からない事は、そもそも喋らなくなる」ので、日本語で話す場合と比べて、みんな寡黙になりました…。ミーティング自体は早く終わるけど、得られる情報が少ない…。 ③「終わらないミーティング」 日本語メンバーが話した後に、私が英語で話す事になるので、単純計算で2倍の時間が掛かります。さらに日常会話＋α程度の私の英語力だと、"how can I say..."と、どう訳せば良いか、つまづいてしまう事もしばしばで、時間はさらに延びる…。 そして英語で話してる間は、日本語メンバーはただぼんやり待ってるだけになります。そのため、だらけたミーティングになりがちでした。
次にやった	「英語が苦手な人は、日本語でOK」 英語が苦手な人には、無理せず日本語で話してもらう様にしました。そして英語メンバーが関係する内容に絞って、私が通訳する事にしました。これによって、ミーティング時間が極力伸びない様にしました。 「話すのが無理なら、せめて書こう」 これだけだと、英語メンバーに伝わる情報が減ってしまいます。なのでミーティングメモを、なるべく詳しく書く事にしました。そうする事で、その場では分からなくても、後でブラウザの翻訳機能で読んで貰う事ができます。ちなみに聴いた言葉をそのままメモするため、メモは日本語と英語が混在する事もあります。 「それでもやっぱり、努力は必要」 それでもSprint Retrospectiveの様に、事後では無くリアルタイムで意味を伝えないといけない場面もあります。そんな時は時間が掛かってしまっても、その場で訳を書き加えています。例えばこんな風に（青字）。 Sprint Retrospectiveの場合は、みんながKeepやProblemのアイデアを口頭で説明してる隙に、私がコソコソと訳を書き加える等、うまく隙間時間を活用しています。

3. ドキュメント（Jira, Confluence）

得られたもの

これらの「次にやった」の取り組みのお陰で、現在ではチーム内のコミュニケーションがある程度機能してきました。またその他にも、以下の様な効果がある事が分かってきました。

情報が記録される
些細なミーティングでも、ちゃんとメモを取る習慣ができてきました。その結果、「あの時どういう結論になったんだっけ？」と振り返りたい時に、困る事が減りました。

暗黙の了解が減る
適切な英語に訳すには、日本語の状態では隠れている主語や目的語を、明確にする必要があります。そのため「誰が」これをやるのか、「何を」対象にその変更を加えるのか、を確認する機会が増えました。
やってみると分かるのですが、「誰が」や「何を」がハッキリしていない事は、意外と多いです。そういう場面で「これは〇〇さんが担当してくれるんでしたっけ？」と確認する機会が増えるので、タスクの取りこぼしを減らす事もできます。
あと、「（〇〇さんがやってくれないかな、でも訊きづらいな…）」と遠慮して訊けなかった事も、「英訳するため」という目的があると訊きやすい、という側面もありました。

多様な意見が出せる・得られる
暗黙の了解が減って明確なコミュニケーションが取れる事は、「言いたい事が言える・多様な意見が出せる」に繋がってきた様にも感じます。また英語メンバーからの意見もより多く取り込める様になり、日本語メンバーだけでは気付きにくい視点も得られる様になりました。例えば下記の Try のアイデアです。これは「チケットに、タスクの背景や目的をきっちり書けなかった」という Problem に対する Try だったのですが、1つめのアイデアは、日本でありがちな真面目な内容（失礼）です。それと比べると、2つめの英語メンバーの「まぁちょっと落ち着こう」的な意見は、全く異なる視点からの意見で、私は「なるほどなぁ～」と思わされました。

まとめ

多言語でコミュニケーションを取るには、なかなかの労力が伴います。しかしその苦労は、目先の意思疎通だけでなく、新しい気付きや活発な意見の創出にも繋がっていくのだな、と感じています。
「多様性の実現は、義務やコストではなく、利益でありメリット」。そう思って、これからも取り組んでいこうと思います。