オフショアで齟齬をへらす日本語コミュニケーションの取り方

こんにちは、美容師を15年、演出家を3年やってきてコミュニケーションをとる仕事のキャリアがけっこう長いりゅうじです。

去年からオフショアでベトナムチームと仕事させてもらうようになってきて、日本語でのやりとりがメインになりつつだからこそ、齟齬が生まれやすい関わり方だなとスタート直後に勘づきました。

基本的にオフショア開発といってもピンキリあるという前提になりますが、関係のあるベトナムチーム数社に関してはレベル感として高い方だと思ってはいます。具体的な状況としては

• 日本語は流暢に話せる
• 学習意欲は高い方
• いい感じにやってくれることもある
• スケジュールは適切に守ってくれる
• 気になることは細かくてもちゃんと聞いてくれる

この辺りのことはしてくれていますので、よく言われているオフショアによしなには一切通じない。かと聞かれると1年経とうとする今でもそこまでは・・・という感想ですから恵まれている方だと思っています。

でもさすがにこれを前提に初見で組むオフショア開発チームとのやりとりを進めるのはあまりにも恐ろしいです。

そこで今回はオフショアチームとの日本語コミュニケーションの取りかたについて書いていこうと思います。

アジェンダとしてはこちらの4つになります。

• 二重否定を使わない
• 箇条書きで順番にリスト化
• 表現があいまいな言葉は英単語にする
• 意見を求めるときは自分の考えを先に伝える

上から順番にだんだん高度になっていく印象です。

二重否定を使わない

「間違いない」という表現は間違いあるのかどうなのか？考えて判断しているようなやりとりが多いです。「間違いない」「間違っている」の表記を両方使ってしまう人は特に気をつけた方が良さそうです。

脳内での反応としても先に否定的な言葉があると、否定評価されていると判断してしまいがちなので肯定したい時には肯定表現である「正しい」という内容で伝えるようにしていきます。

二重否定に質問系を被せた時ときは結構な頻度で「つまりどういうことですか？」と聞かれることも多いので、「間違いないのではないでしょうか？」とか返そうものなら「正しいですか？間違いですか？？？」と聞き返されることはきっと高確率で起こります。

コミュニケーション取りはじめた序盤では全然気にならないのですが、スケジュールがカツカツになってきたタイミングでこれをやられると双方かなりいらっとします。ミスも誘発することになるので意識して二重否定は避けた方が良さそうです。

箇条書きで順番にリスト化

日本語特有でやりがちなのが主語+述語がどこにあるのかわからない句読点の応酬な長文です。自分でもやりがちなので反省するところではあるのですが、長くても句読点1回で1文をまとめることが重要だと考えています。

間違ってもやってはいけないなと思うことに、文章の役割が違う内容を1文にまとめることです。長文を書くときに意識してやっていることは、話が切り替わる時には段落を変える（ここでは改行入れているところ）ことで1塊を見るようにします。違う話が入っていたなと感じたら改行いれて分割して整形し直すという具合いです。

作業の指示に関しては、誰が何をする。くらいの箇条書きでリストにすることが重要です。例えば

ログイン機能についてメールアドレスを忘れた時の再設定がうまくいかない場合

NGパターン

• ログインしようとした時にメールアドレスの再設定がうまくいかないので原因を調べてもらえますか？

これだとそもそも何が問題なのか文章自体を何度か読み返すことがオフショア側では起こっています。そしてログイン機能全体を見直す必要があると捉えられがちで、予想以上に時間がかかってしまいます。

OKパターン

• ログイン→メールアドレスで登録
• メールアドレスを忘れたので申請をクリック
• メールアドレスの再設定リンクを送るボタンクリック
• メールが届く、リンクURLをクリック
• リンクURLが404エラーで承認されない
• パスワードの再設定ができない
• リンクURLの発行、活性化あたりに問題があるかもしれないので調査して原因を報告してもらえますか？

ここまでがワンセットでやるとプロジェクトマネジージャー側も原因が特定できていることになりますし、オフショアメンバーにも伝わりやすい内容になります。

1から10まで伝えるのが面倒だと感じる人がこの辺りのやりとりでいるのだとしたら、きっと日本人ならよしなにやってくれるのに・・と思いやすいですよね。

ところが日本人側としても実際にこれらのパターンでそれぞれ依頼されると調査コストがどのくらい増えているか明確だと思います。

つまり仕事をしていないと開発チームから思われるマネージャーは自分で全容把握する業務をおざなりにして開発チームに任せっぱなしなステータスであることが多く、危険性が高いです。早急に改善した方がいいかもしれません。

マネージャーは開発チームの上司ではありません。協業パートナーとして一緒に取り組もうという行動ありきでコミュニケーションは取っていった方が良さそうです。

意見を求めるときは自分の考えを先に伝える

先ほどのNGパターンの内容と重複するのですが、問題がある箇所を明確にする前に調査を丸投げしてしまうとトラブルの原因になりやすいです。

これを踏まえてのケーススタディですが、修正指示ではない場合。実装計画を立てている最中などでエンジニア側の意見を聞きたい場合などがよくあると思います。

設計を国内で対応し、問題がないかどうかを聞く場合に「今の所このように設計しようと考えているので問題がありそうでしたら教えてください」という依頼の仕方をすると高確率で事後に事故が発覚します。これはどういうことでしょうか？

作業を始める前にプロジェクトマネージャーとオフショア（このばあいブリッジSE）とのやりとりで問題についての合意が取れていなまま作業を進めてしまったことでトラブルが起こっています。

実際にあったこととしては一般的にデフォルトでパッケージされているので導入するものと思っていたメモリキャッシュが設定されていなかった事件がありました。

内容を紐解いていくと、メモリキャッシュを設定すべき場所を別のインスタンスと勘違いしていた。という簡単なコミュニケーションミスだったのです。

基本方針として指示のあったことを忠実に再現することを受託の定義と徹底されていることが多いらしく、コミュニケーションのやりとりの中で具体的な指示、調査依頼などが明記されていないものはスルーされる前提になる。ということがわかりました（このチームだけなのかもしれませんが）。

改善策としては設計者であるプロジェクトマネージャーが自身で100%把握していないことについてはリストにするなどきちんと明記して相談をしてから設計を確定させる。その合意をテキスト上で得て指示を出すというフローが徹底されるとトラブルの起こる確率は飛躍的に抑えることができました。

表現があいまいな言葉は英単語にする

日本人だと無意識につかっている言葉でも、複数の意味をもつ内容だったということがよくあります。

例えば「待機ステータス」が承認待ち（=pending approval）なのか、廃止案の検討待ち（=waiting list）なのかで優先指示なのか判断しやすさが変わったりします。

カタカナ用語も気をつけた方がよくて、変換の手間はあるかもですけど重要な単語などは英単語で表記するようにすると相手にとっても目に留まりやすいですし効率も上がっていきます。

最近あったこととして、Git運用においてテスト環境でのdevelopブランチでエラー起こさないようにしてほしいという趣旨を理解してもらう時に苦労しました。

結局はdevelopブランチはクライアント様が見るmasterブランチです、進捗報告をするのに開発中のタスク状態を入れるとクライアント様に見せられなくなるのでエラーを出さないようにしてください。というやりとりがありました。

ここでのオフショア開発チームの考えとして「developなのだから開発中でエラーが起こるのでは当然ではないのか」ということでした。もちろん先ほどのクライアント様が見るmasterという説明はしているのですがdevelopと名がついている以上は一般的な認識で進めている。ということが話し込むまでうまく伝わっていませんでした。

あいまい表現になりがちでリスクの高いこととしてプログラミングの関係することも挙げられます。これはGitのcommit内容だったりとかわかりやすい点で、無理に日本語でやってもらおうとするとオフショア開発チームの内エンジニアさんは困ります。日本語がブリッジSEさんより格段に苦手というケースばかりなので作業効率の低下にも直結することが多いです。

プロジェクトマネージャーがどこまで介入するかにもよりますが、コードレビューなど兼務しないといけないとしてもプログラミングに関する部分はせめて英語でいけるようにはしておきたいものです。

対策としては日常的な調べ物でプログラミングに関するものは英語原文のものを単語単位でGoogle翻訳するようにして英単語を覚える工夫をしていました。

まとめ：グローバルな仕事は表現を明確にする

ですます調の言い切り型にするのはもちろんのこと、日本語ができると言ってもN1（日本語検定1級）でさえも日本人特有の文化理解をしてもらうのは困難だと思います。

オフショアチームの文化も知ることは重要ですが、友好な関係を作るためには同様にテキストのコミュニケーションに気を遣うことを優先した方が関係構築のスピードは驚くほど上がっていくことが段々とわかってきました。

つい最近もちょっとしたことがきっかけで1プロジェクトで2チームのオフショアチーム（1チームは初見）を割り当てられたことがあります。

その時はチームに合わせてやりとりも変えたり、初見チームに1から説明することも多々ありましたので危うく炎上させかけたのですが今回書いてきたことをコミュニケーションに活かしてなんとか火種は消し止められました。

弊社の請けているプロジェクトでオフショアと協業するときのスタンスとしてはテキストでのやりとりのみでビデオ会議などは入れていないのですが、これまでモバイルアプリの開発や業務システムなど大小様々なプロジェクトに対応できてきています。

それはテキストのコミュニケーションを丁寧に心がけてやってきたからということで、リアクション機能にも頼りすぎず言葉で対話することの重要さを噛みしめているところです。

ここまでストイック気味なコミュニケーションを書いてきましたが、国は違えど同じ人なのでコミュニケーションの根っこの部分は変わりないですし、ぜひ臆せずにオフショア開発に挑戦してみてください。