今、私はベトナムで海外開発チームを指揮しております。 毎日業務は刺激に溢れ、経済のダイナミックな成長を感じることが出来ます。
本題ですが、こちらではコードという世界共通の土台があるとはいえ、 やはり常識や感覚のファンダメンタルな所が違うため、日本人同士で働く以上に工夫が必要です。 今のところ働きながら心がけているTIPSがあるので、それを共有しようと思います。
1. とにかく具体的に指示を出すこと
口頭のコミュニケーションはとにかくミスが多発します。 これは日本人同士であっても同様かと思います。
口頭で仕事依頼してくる人の状況だとたいていエビデンスが残らないため、 仕事の依頼者側のいいように言われがちです。(私はそんなこと言わなかった・・など） だいたいメッセージツールで「本当にこれでいいのか？」と必ずメッセージでエビデンスを残すようにします。 責任の所在などを明確にしないと苦しむのは自分ですので、日々心がける必要があります。
本題からそれてしまいましたが、外国人同士で働くと、母国語以外の言語で業務の連絡をしなければいけません。 なので、基本的に難易度が高いことになります。 そんな所で双方に「ベトナムのクオリティは低い」「日本人の言っていることが意味が分からない」 といった相互に敵対関係のような状態になってしまいます。それはブリッジの人間としても避けなければなりません。 そこで簡単で有効なのが、「具体的な指示を出して方向性を決める」というポイントです。
コマンドレベルで手順の入り口を列挙
$ git checkout develop
$ git checkout -b feature/{your-new-feature}
$ git add .
$ git commit -m "add new feature"
$ git push -u origin featue/{your-new-branch}
エンジニアにとって、コードが万国共通で間違いのない手順です。 全ての手順を書き込むのは難しいですが、方向やベクトルを正しく出来るところまでナビゲートしてあげる責任はあります。
コマンドの具体例とは非常によくて、簡単に横展開が出来ます。 「やっておいてください！」でゼロから考えさせてしまうと、人それぞれ思い思いの方向に進んでしまいがちです。 ただ具体例があれば、その一部を変更するだけなので、差分は出にくいです。
スクリーンショット多用
Github、Hitchat、Redmine、Skypeなど様々な管理ツール、メッセージツールでは画像の添付が可能です。 なるだけスクリーンショットを多様して、赤い図形などで囲んで「ここ！」という感じに指定してあげるようにします。
言葉が通じないレストランで、メニューみて指を指すように、ビジュアルで伝えられることは、 言葉で伝えることより、より確実な伝達を提供します。
2. レビューやフィードバックを沢山いれる
背景として持っている基準がやはり日本チームとベトナムチームでは異なっていることを意識する必要あります。
昨今の開発環境では、Githubなどでもpushをするたびにslack/hipchatに通知が来るような仕組みになっていると思いますが、 その通知が来たときに是非一言でもGithub/Redmine上にコメントを残すように心がけます。
これはFacebookのイイねレベルでも良いです。「No problem」「Good」「Bad」。 必要あれば、適切なコメントを付与します。そうすることで「ちゃんと見ているのだな」という印象を与えられると同時に、 この認識のギャップを都度フィードバックで埋めることが出来きます。
日本人同士であっても最後の最後に「NGですので、全部やりなおしてくれ」などと言われると不信感が出るはずで、 なので、常に早い段階で細かいポイントでもフィードバックを繰り返して、 同じような価値基準を作っていく必要があります。
このコメントに対する有効性は書籍「Team Geek ―Googleのギークたちはいかにしてチームを作るのか」でも言及されています。 コードをコメントするカルチャーがあるだけで、変なものはPushしないという抑止力にもつながります。
3. ちゃんと教える
ベトナム例であれば基本的に学ぶ意欲が非常に高いエンジニアが多く、特に最新技術のキャッチアップはしたい人が多い傾向にあります。 逆に、テストや検証などそういった地味な所は軽視されやすいです。 「ベトナムだから高度なことは出来ないだろう」と考えてらっしゃる方が日本に居るかどうか定かではありませんが、 フルスタックに近いレイヤーをまたがるような開発もディレクションがしっかりすれば、十分に可能な印象です。 特にインフラ開発などは経験がないパターンが多いので、うまく業務を通じ経験してもらう必要があります。
個人的な考察ですが、ベトナム自体が物流インフラの不足、クレジットカードなどのWeb決済が普及しておらず、 まだまだ内需として中小規模のWebのシステム開発が進んでいないのが原因でないかと感じます。
重要なことは、 日本チームを教えるのと一緒に「WHY」の箇所をしっかりベトナムのチームにも伝え、その上で仕事を教えるように心がける点です。
ベトナム語の技術文献はあまりなく、英語でほとんどの人は学んでいるので、 最新情報などを学ぶ下地としては正直日本人以上にあると感じます。 Googleで検索しても、誰かが書いた日本語のブログが一番上に出てきてしまうのと、公式ドキュメントが一番上に出てくる差に起因しているのではないかと感じます。
またベトナムに限っていえば、「先生」と「生徒」というスタイルが一般で、 エキスパートに教えてもらうという考え方のマインドが強い傾向にあります。 そのため、「丸投げして勉強よろしく」というよりは、ある程度間違いのないガイドを最初にしてあげるほうが 学習の効率も高い感じが今のところします。
4. 案件について考える必要もある
当たり前ですが、基本的に新しい技術の案件などは好まれる傾向にあります。 地味な機能の拡張などばかりだと現場のモチベーションも下がることもあるので、 日本同様にうまく面白い開発案件と手堅い開発案件を交互に進めていく必要があります。
働きながらどんどん高度に成長できる環境を作るようになるのは同様です。
5. 文書が一番重要で唯一のエビデンス
なるだけ口頭で会話をしても、その後「こうです」というのをチャット等で改めて確認の意味をこめて送信します。
たとえばベトナムなどで働く場合では、コミュニケータと呼ばれる通訳の人を入れるケースが多いです。 ただ結局、技術などを完全に理解したプロフェッショナルの通訳という訳ではなく 我々と同様に一緒に学んでいる状態を意識するる必要があります。 (プロフェッショナルかつエンジニア出来る人はおりますが、それは上級のBSEです）
このように文書で書いておけば言った言わない理論は発生しなくなります。 日本人同士ですらトラブルになる口頭伝達は、こちらではもっとトラブルになる可能性があるので、特に注意です。
6. デザインパターンなどの共通言語を会得すること
デザインパターンやフレームワークなどを理解していれば、 たった一言のメッセージで、正確な大量の情報を相手に伝えることが出来ます。 （ここはストラテジーパターンで組み直してください、など）
現場のエンジニアは最初は知らないくて良いですが、ブリッジとなる人または マネージャとなる人は理解しておくべきです。
設計の時も「RESTfulの仕様にそってください」など伝えるだけで、認識の齟齬が発生しにくく、 誰が作っても安定したクオリティのソフトを作ることが出来る可能性が高いです。
意外と自分で開発していても全パターンを網羅して使っていないと思います。 (実際特にWebシステム開発では必要なケースが少なかったりはしますが） これを機会に学び直すのも良いです。
7. テストをしっかりすること
これはベトナム限定かもしれませんが、意外とこちらではテストの意識が低い印象があります。 作った即完成ということになり、テストがスッポ抜けてしまっていることも多いです。
これはレクチャー次第で改善する話でもありますが、 「テストのカバレッジを50%以上までお願いします」など仕組みでカバーするほうが良いかもしれないです。
