ベトナムオフショア開発

# はじめに
尊敬してやまない@kanoari パイセンの翌日を担当させていただき、胸いっぱいでございます。
ネタが誰かとかぶらないかヒヤヒヤしておりましたが、弊社の子会社のベトナムメンバー:flag_vn:とどのように開発をしているか簡単に紹介します。

# 1日の始まり
シンチャオ:thumbsup:
日本時間11時半（ベトナム時間9時半）から定例MTG

ベトナムとの時差は2時間。昼夜逆転しなくても問題なく一緒に仕事をすることが出来ます。
ちなみにベトナムの始業時間は8時から！この国は平日休日とわず朝が早い！！

この定例MTGには、ベトナムからは日本語が話せるコミュニケータとPM、PL、日本からは開発機能の担当者が参加しています。（1人のPMにつき、1人のPL、PGが3～4人という体制です。）

ここでは、コミュニケータにそれぞれのPMが進めている機能開発の進捗を報告してもらいます。
PMしか業務レベルの日本語でコミュニケーションがとれないので、PLとコミュニケーションを取るためにも定例MTGや仕様説明のときはコミュニケータを通して伝えるようにしています。
MTGの始まりは、

**「お疲れ様です」**

MTGから退出するときは

**「失礼します」**

と、とても丁寧です。

進捗が順調でMTGする必要が無い時もありますが、毎日お互いの声を聞いて関わりを持つことは非常に大事なことだと思います。
文字情報だけではわかりませんが、声を聞くと、音声という別の角度からの情報が入ってきます。
伝えることは、チャットやメールで事足りますが、風邪を引いて鼻声だったりすると、
「風邪ですか？大事にして下さいね」と声をかけてくれます。
離れているけれど何気ない会話は一緒に仕事をする上で大切だと思っています。

# コニュニケーションの取り方
＜ツール＞
**Google Hangout**を使用しています。

自分のPCの画面を相手に共有できるというのは非常に便利です。
コミュニケータがいても、それなりに日本語が話せるPMだったとしても、視覚情報は相手に伝える手段としては非常に有効です。
ベトナムメンバーから何か伝えたいことがあるときも、言葉で伝えにくいときも、実際の画面の動きで伝えることが出来るので、重宝しています。

＜話し方＞
**標準語を使い、ゆっくり話す**

ようにしていますが、、、、。理解してくれるので、つい早口になることも。


**和製英語は厳禁！！**

英語と異なる意味で使っている場合があるので、コミュニケータには悪質な言葉です。

**相手が話したことが理解できなかった時は、「わからなかったので、もう一度お願いします」という。**

言うべきことははっきり言う。大事なことなので、もう一度いいます。

**「言うべきことははっきり言う。」**

自分より、エンジニアとしての経験年数の長いPMに、色々と言わなければならないのは、未だに慣れません。
ただ、言わなくても伝わるなんていう考え方は捨てました。
お互いの曖昧な理解が認識の齟齬を生み、仕様が違うなど大事故につながりかねません。
アメリカが、英語が第一言語または第二言語として普及にしているインド:flag_in:やフィリピン:flag_sx:に対してはじめたオフショアリングを真似している我々には、

**「言葉の壁」**

が非常に大きく立ちはだかっています。
それでなくても物事をはっきり伝えない、行間を読み取るなど、はっきり言わなくても伝わることを習慣としている
日本人にとっては、注意すべき点です。

MTG以外にも、チャットでメンバーとやり取りをしています。
このあたりは、日本国内メンバーと大差ありません。PMから、Hangoutで呼び出しもあり、1対1で仕様の確認や、
相談にのったりしています。

# プロジェクト管理
＜スケジュール＞
ベトナムに開発を依頼している所までは、PMにWBSを作成してもらっています。
自分自身でたてたスケジュールであれば責任をもって守ろうとするだろうと、依頼しています。
また、誰が何を担当するかなど、ベトナムメンバーの采配はほとんどPMに一任しています。

＜タスクの管理＞
Redmineを使用しています。

レビューのチケットまで細かく作っています。うっかりして、し忘れたとは言わせません:triumph:
1機能あたりのチケットの多さの良し悪しは別にしておいてください。
やらなければならないタスクの全体量が把握できますし、慣れると次にすることがわかるので、近頃は指示しなくても、終わってますと言われることもあります。
また、チケット名は日本語／英語で登録するようにしています。日本語だけだとPGがわからないので、英語を記載するようになりました。

# 機能開発
＜仕様書・仕様説明＞

仕様書は日本で、日本語で作成し、英語に翻訳してベトナムメンバーに渡しています。
仕様書のフォーマットは固定で、誰が書いてもも同じ粒度の内容になるようにしています。
また、仕様書を作成する時の規約というものがあります。その中の1つに「和製英語は禁止」という項目があり、和製英語を使っていた日には、仕様書レビューで突き返されます:no_good_tone1:
誤訳に繋がる芽ははじめから摘んでおきましょう。

仕様の説明は、英語翻訳した仕様書をPMに読んでもらうことが第一段階です。
第二段階は、仕様書を読んでわからない所を解消していく質問方式を取っています。
その後PMはメンバーに説明をして、PL、PGが仕様を理解していきます。日本側から一方的に、言葉だけで説明はしません。
仕様の複雑さもあり、あえて仕様書を作り込み、彼らのペースで理解してもらいます。第二段階での質問を聞けば、仕様を理解しているかどうかの判断はつきます。

機能開発が始まると、日々の機能に対する質問はQAリストに蓄積されていきます。QAリストは、機能開発中に生じた質問を書き込み、日本側で回答しています。このリストには、PGでも気軽に書き込めるようにしています。
仕様のやり取りはなるべく文字に残し、関係者が共有出来るようにしています。
言った言わない、認識の齟齬が1番怖いですからね。

＜詳細設計書・テスト項目書＞

詳細設計書の必要性の有無は機能理解したPMに一任しています。
ソースコードを含め、2重レビューを行っています。

**ベトナムにて作成→ベトナムにてレビュー→日本にてレビュー**

ベトナムからのドキュメント系の成果物は全て英語でなので、日本では英語のままレビューしています。

QAチームと呼ばれるテスト専門部隊(テスター)がいます。
テスターにテスト項目書の作成と単体テストの実施はお任せしています。
ベトナムではテスターがいるため、PGがテストするという習慣があまりありません。PGの単体テストは品質が悪いことが多々あります。

# ベトナムネタ

お昼休憩は12時から一斉にとります。食後のサトウキビジュースが個人的には好きです。

お値段、5000ドン:chart:

食事を済ませてオフィスに戻ると、電気が消えています。
お昼寝タイムです:zzz:


日本では「ありえへん！！」というようなことが起こります。

今夏、出張でベトナムに行きました。
その時、滞在先の受付のお姉さんとの出来事。

日本でも流行りましたよね、、そう、**ポケモンGO！**

ベトナムでも流行っていたんです:laughing:
受付のお姉さんは、ほとんど受付にはいませんでした。どこにいたかって？

**ポケスポット**

同時期に出張に行った同僚たちに、受付のお姉さんは名言を残していました。

**「Every time every night PokeSpot.」**
用があれば電話で呼んでねとのこと。自由な国、ベトナム:flag_vn:

真面目に業務での出来事

  **PGが誤って別のリモートbranchにpush**

  まぁ、過ちは誰にでもあります。戻せば問題ありません。次回から気をつけようね:ok_hand:

  **間違えたことを知ってて放置**

  :scream:

この時は日本側で気づき、結果的に大きな問題にはなりませんでした。
このように、日本では感覚的に「ありえない」であろうレベルのことが日常で起こります。
こんな時は、**ありえへん**:rage: と怒ってはなりません。

- 何がいけないことか
- 対処方法

を教えました。悪いことだと思っていなかったり、知らなかったということがほとんどだったりします。
こんな具合に、日々色々と起きます。

# 最後に
色々と紹介しましたが、はじめからこのような体制になっていたわけではありません。
ベトナムメンバーの要望を聞いてお互い歩み寄った結果、今の体制をとっています。
もちろん、今後変わっていくことは大いにあります。
言葉も、育った環境も文化も習慣も異なる人達と共に仕事をするということは、お互いに歩み寄ることが何よりも大事だと思います。

引き続き弊社のアドベントカレンダーをお楽しみください。