ベトナムラボ型開発で起きた問題とそれに対しての解決策

# 概要
日本の業務のベトナムラボ型開発への移管を２年ほど経験した上で、考えをまとめます。

※エンジニア業務の一部のみベトナムに移管し、全て日本から日本数名、ベトナム数名の体制で運用していきます。
※企画は日本に居る中で、チャットツールを使い遠隔でベトナムのBSEやエンジニアに対して指示出しを行い、日本のエンジニアがそれをサポートしていきます。
※日本側と同じレベル感の仕事をしていくことをゴールに考えています。

# 日本人とベトナム人の違い
同じ日本人でも個人・グループ単位で全然違って一括りに出来ないように、ベトナム人もそれで一括りにできません。
たとえば「日本人はシャイ」と一括りし個人個人を見ずにマネジメントしたら失敗するのは目に見えているように、「ベトナム人は○○」と一括りの価値観でマネジメントすると失敗するのは明白かと思います。
つまり国柄的な平均値はあれど、個人個人の振れ幅を考えると対日本人と同じで個人・グループの性格にあわせたマネジメントになると考えます。
ただしベトナム運用と日本運用の絶対的な違いも存在するので、それに関してフォーカスして考えて行きます。

# 日本運用とベトナムラボ型運用の違い
## 1. 雇用形態の違い
### 考察
ラボ型開発とはいえ業務委託と依頼主の関係であり、同じ目的を共有した社員ではありません。あくまでお客様である依頼主に良い仕事を提供することが目的です。
つまりどうしても社員とは異なる価値観で行動選択をしてしまうことになりがちです。

たとえばオフショア開発をしている人たちの中で、失敗を隠そうとするという課題を聞くことが多々ありました。
あくまで依頼主が満足する仕事を提供するのが目的と考えると、自分の仕事の結果としてプロジェクトがどうなっても関係がありません。つまり仕事で失敗したときに失敗を報告するより隠し通せたほうが良くなってしまう可能性があります。

また仕事を求めるが自分から主体的に仕事を行っていかないという声も多々聞きます。
これもお客様から依頼された仕事をすることが目的の全てだと考えると、自分たちの判断で何かを進めていく必要性はありません。むしろ自分たちで勝手に何かを進めていくのは悪いという価値観になっているのが自然かと思われます。

### 対策
**日本人と目的・価値観を共有する**
障害件数、運用コスト、パフォーマンス、DB台数など、日本人が見ている情報を公開し、それらを目標・評価と紐づけることで寄せていきます。

**仕事を振る振られるの上下関係でなく、一緒に仕事をしている並列の存在（同じチームメンバー）としての関係を意識づける**
自分も同じレベル感の仕事をし、対等の関係として接する。つまり実装に一緒に入って一部の実装を請け負い、こちらのコードレビューもベトナム側に依頼します。

**大目標だけ与えて、そこからのアクションプランは自分たちで考える必要があるような仕事を与える**
「○○を修正する」ではなく「1日のエラー発生件数を○件以下にする」といったレベル感で仕事を与えて、自分たちでアクションとそれに対する反省を考えさせるようにします。そこから自分たちで考えドライブしていく文化を根付かせていきます。

## 2. 言葉の違い
### 考察
ネイティブ同士だと伝わるのが前提で、いかに相手を配慮するかといったところに目がいきます。
しかし、そもそものコミュニケーションの本質は相手に思考を伝えることです。オフショアに関しては非ネイティブとのコミュニケーションなので、そもそも意図が伝わらず誤った認識をしてしまうことは良くあります。
したがって非ネイティブとのコミュニケーションにおいては、意図が伝わることがまず何よりも優先されます。
これは日本人（自分）が英語で話しかけられたときどう話しかけられたら伝わりやすいか、という発想で考えてみるとわかりやすいかと思います。

### 対策
**1文を短くする**
1文が長いと文の構造が複雑になり、意味を読み取るのが難しくなります。

**主語を入れる**
日本語は主語を省きがちです。そして主語が何かであるかに論理性は薄くある種の経験をもとに推測します。
主語に関しては日本人同士でも認識違いが起き得る箇所であり、確実に認識を共通する上で主語は入れるにこしたことはありません。

**文法的に正しいかどうかより伝わるかどうかで言葉を選ぶ**
お互いに英語でコミュニケーションする際は、相手も非ネイティブであるという点を意識して会話するべきです。
たとえば英語ネイティブ的に正しい難しい表現や単語を使ったとしても、相手がそれを知っているとは限りません。
したがって文章を構築していくうえで、英語的に正しいか否かではなく伝わるかどうかを優先して考えるべきです。

**教科書っぽい文章を書く**
大半は教科書を使って日本語を勉強していたはずです。つまり教科書みたいな日本語が一番伝わりやすいです。
また口語は基本的に伝わりづらいため、あまり織り交ぜないほうが良いです。
ただし口語的表現を学べることは非ネイティブ日本語学習者にとって良い体験となるため、「伝わる」範囲内で口語的表現を織り交ぜ教えていくことは彼らのためになります。

**余計な情報を書かない**
ネイティブだと文章全体をパッと見てなんとなくどこに何が書いてあるのかがを理解することが出来ます。つまり文章全てを読まずに、必要な箇所のみ読んでいます。
ですが非ネイティブのかたは１文字１文字しっかり読んでいかないと内容が理解できないような方も多くいます。
したがって無駄な文章は１文でも削ってあげたほうが通訳者の時間の節約になります。

**丁寧な言葉を使うのが必ずしも正解ではない**
日本人は相手に直接依頼をするのではなく、状態を伝えて相手に行動を促すのを良しとしていることが多いです。
例えば「先日修正依頼したところ、１点直っていないところがありました。」のような文章は、「1点直っていないので修正してください」という意味が込められています。
しかしこういった書き方においては、そもそも依頼と受け取ってくれない例もあります。したがって直接的な言い方をすることが仕事をスムーズに回すことに繋がってくることがあります。

日本人が直接的な言い方をしない理由はその言い方が受け取り手にとって冷たい言い方であるように感じてしまうからです。
しかしこれはネイティブの感覚であり、非ネイティブが同じ感覚を覚えるとは限りません。
つまり非ネイティブに対して「言い方」に過敏になる必要はなく、伝わることを最優先したほうが良いでしょう。

また丁寧な表現は文章を長くしがちで、目的の文章を薄めてしまいます。
したがって余計な情報を書かないという意味合いでも、短くはっきりとした文章のほうが認識の齟齬が生まれにくいです。

もちろんこれらは相手が日本語に精通しておりネイティブに近い感覚を持っている場合に冷たい印象を与えてしまう可能性があります。
したがって相手の言語レベルに合わせて調整していきましょう。

**絵で伝える**
絵は人類共通のコミュニケーション手段です。
文章で長々と説明するより、絵やグラフ等用いて視覚的に説明したほうがスムーズに伝わります。
たとえば設計についてベトナム人に相談しに行ったとき、設計の絵を見せただけで言葉なく伝わったことも多々ありました。

**コードで伝える**
エンジニア共通のコミュニケーション手段です。
何より具体的で論理的な言語なため、下手に言葉でコミュニケーションを取るよりはコードで示したほうが早いケースもあります。

## 3. 物理的な距離
### 考察
当然ですが日本とベトナムには物理的な距離があります。つまりお互いに状況が見えづらいです。
たとえばベトナム側の状況はブラックボックスになりやすく、タスク状況が分からなかったり、メンバーの状況が分かりません。ベトナムから見たら予兆はあっても、日本から見たら突然退職と言われて困ってしまうケースも多々あります。
また居るのか居ないのかも分からず、タスク状況的に仕事をお願いして良いのかどうかもわかりません。したがってどうしても心情的に仕事をお願いしづらく、身近な人たち同士でタスクを回しあってしまうことが多々あります。
そしてこれらはベトナムから見た日本も同じです。

また日本だとそれこそ日常会話ベースから様々なインプットがあったうえで仕事が進んでいきます。
日々の生活の中で「こういう問題がある」という暗黙の共通意識があった中で、仕事が生まれてきます。
しかしベトナムだとほぼ資料ベースでしかインプットがありません。したがって資料に情報量が不足しているとすぐに認識違いが起きてしまいます。
これは別のオフィスに居る日本人のようなケースでも同様で、言語的な問題ではありません。

### 対策
**状況を細かく共有する、素早く反応をする**
対ベトナムに限らず大事な要素ではありますが、信頼性構築のうえでも特に大事になる印象です。

**設計書を作ってもらう**
実装に入ってもらう前に設計書を作ってもらうことで、相手が仕様に対してどう認識していてどう実装しようとしているのが分かります。
実装方針に対してレビュー出来るのはもちろん、認識違いを早い段階でキャッチすることができます。