オフショアを3年ちょいやってきて、自分なりにベトナムとのコミュニケーション方法というものが見えてきたので、共有します。

東京、沖縄、ベトナムの3拠点で一つのチーム。東京1人、沖縄1人、ベトナム8人程度。やり取りは全て英語で、基本はLyncを使ってのチャット、通話、画面共有となります。

大前提

同じ人間はこの世に存在しない
人が二人以上いれば、そこには必ず「差」がある。その「差」を埋めていくことが重要（基本的に日本とベトナムだから、とかではなく、日本人同士でも同じだと考えている）。

ベトナムと日本の差

※あくまで自分の印象、かつ全体的な印象。例えば若手と家庭持ちで残業に対する態度が変わったり、経験値の高いベトナムメンバーが居たりと、個別の事情に合わせてコミュニケーションは変える必要があるとは思っている。

どうやって差を埋めるか

雇用形態

ジョブ型なので、開発者とテスターはもちろん、開発者もフロントエンドとバックエンドでもさらに分かれる（さらに言えば言語でも）。そもそもバックエンド開発者にフロントエンドをやらせるのも筋違いなので、できれば分けるようにする（強い部分に集中させる）。

自分の場合は状況的に日本側がパンクしそうだったので、状況をきちんと説明した上で、VN側と話し合ってテストも引き受けて貰うようにした。その場合は、どういう理由で、どこまでを期待しているか、を明確に伝えて、納得して貰う必要がある（責任の範囲を明確にする）。

仕事の意識

基本はVN側の意識を尊重した（家族の用事やプライベートを優先してOK）。その上で、極力仕事の優先度を上げて貰う工夫をした。そもそも仕事が楽しい、あるいはやりがいを感じれば勝手に優先度上げてやってくれる。

・仕様説明の際に、目的や背景を明確に伝える（なぜ作るのか、どう使われるのか、それを作ることでお客様はどう嬉しいのか、など）

・（サービスだったので）KPIの達成度やユーザーからの声を定期的に共有する

・お客様の喜びの声を聞かせる（隣にいたので、VNとカメラで繋いだ状態でデモをおこない、歓声を届けた）

・細かくフィードバックする（良かった点、改善した方が良い点）
逆に、マイクロマネジメントは絶対に避けるように意識していた

品質の意識

そもそもの生まれ育った環境の差によるものが大きいので、一朝一夕で埋めるのは無理。VN側に90%までやって貰って、最後の仕上げは日本側でおこなう、など（あるいは許されるのであれば多少のバグには目をつぶるとか･･･ここは必要とされる品質による）。

出来ることがあるとすれば、コードレビュー。最低限、不経済なコード（n+1問題、再発明など）を弾くだけでも結構違う。後、コードレビューをおこなうことで日本側でも中身を把握できるので、休日等にトラブルが起きても最悪対応できる。

言語

日本語、ベトナム語、共にハイコンテキストな言語。ならば言わなくても通じるか、というとそれはない。

省略を実現するためには共通の背景知識が必要となるが、そこがお互いに異なるのでハイコンテキストなやり取りは不可能。ローコンテキストなコミュニケーションが必須となる（全て細かく書き出す、省略せずに明文化する。幸い、英語はローコンテキストな言語）。

英語力はそこそこあればいい（無論、高いに越したことはない）。最低限文法は正しくすることを意識する（単数、複数、過去、未来、主語を省略しないなど）。

後は言い方がダイレクトすぎないように気をつける（you made a bug, ではなく、we have a problem…など）。ざっくり言うと、「てめーのせいでバグってんだよ、ふざけんな、さっさと直せ」と「私たちはこういう問題を抱えているので、解決に力を貸してくれませんか」くらいの印象の差がある。

そもそもバグだと開発者を責めている感じになるが、実際は仕様の伝達ミスかも知れないので、バグという言葉を安易に使うこと自体が危険。特に開発初期はお互いのことを知らないので、そこでミスると最悪の印象を最後まで引きずることになる（まあ、普通にお互いを尊重しあって開発しましょう、という話）。

経験値

VNは全体的に若いので、経験の浅い人が多い。視野が狭くなりがちなので、日本側が広い視野でチェックする必要がある（コードレビュー、設計のレビューなど）。

VN側にリーダーを立てるときも、メンバーとリーダーでは求められる役割が異なるのでサポートが必要。ちなみに、VN側にリーダーを立てるのは主義に反するという意見もあるが、個人的には立てた方がいいと感じている。現地にいないと見えないことが多い（日本側のリーダーがVNに行って指揮を取るのであれば別。詰まってる、悩んでる、タスクがその人に合っていないなど）。

お客様との距離

これは東京と沖縄も同じかもしれないが、距離が遠いので温度感などが伝わりにくい。既に上で書いたが、ビデオチャットで共有する、各種KPIなどを共有するなどして、他人事から自分事に意識を変えていく必要がある。何のためにこの作業をやっているのかがわからないと、どうしても他人事になりがち（言われたとおりにやっただけ、みたいな）。自主的に動いて欲しいのであれば、当たり前だが目的や背景などを説明する必要がある。

最後に

当たり前ですが、開発者も人であり、感情があるということを忘れずに、という話。後は根本的にマネジメントスタイルが適切じゃない場合があると思うので、そもそも日本人に対しても不適切なマネジメントをしていないか、を考えた方が良い。

マネジメントというと指揮統制法を思い浮かべる人が多いが、曰く「言い換えると、軍隊が指揮統制を使うのは、それが18歳の若者に地雷原の中を突撃させるための唯一の方法だからであって、あらゆる状況で最善のマネジメント法だからではない。」。エンジニアに対して指揮統制法を適用しても、エンジニアが外へ流出するだけの結果になる

じゃあどうしたらいいか、は以下のリンクを参照（あるいはTeemGeek、ピープルウェア、デッドラインなどを読んで貰えれば）。

マネジメント法3種(イントロダクション)