LoginSignup
85
80

More than 5 years have passed since last update.

ベトナムのエンジニアとの開発について

Last updated at Posted at 2016-06-04

オフショアに限った話ではありませんが、海外のエンジニアと仕事をする機会がどんどん増えていると思います。私もベトナムのラボ型開発会社さんと2年ほどプロダクトを開発しています。

最初はどうなることやらという感でしたが、やってみると案外問題なく回るものでした。ベトナムの方の気質やエンジニアという職種自体がリモートワーク向きなのもよかったと思います。

以下、プロジェクトを円滑にすすめるために気をつけていることやTIPSをまとめます。提携や関係づくりの参考にしていただければと思います

何はともあれ英語

ベトナム語⇔通訳⇔日本語でのコミュニケーションは通訳が入ったとしても難しいです。英語でコミュニケーションが取れるエンジニアしかいない提携先を選ぶのがよいと思います。TOEIC990点でペラペラ喋れる必要はありません。私も高校3年が英語力ピークだったと思います(典型的日本人)。

使う表現は中3レベルで全然通じます。たとえばこんな感じです

Could you read the following specification and design the table schema first?
(ざっくり仕様書いたからこれを基にまずはテーブル設計してくれますか?)
Please put a pulldown menu to show HOGEHOGE for now. Our designer will code later. :bow:
(プルダウンをとりま置いといてくれますか? うちのデザイナーが後ほどコーディングするんで)
For performance, I think adding a column to hogehoge is appropriate. What do you think?
(パフォーマンスのために正規化崩したほうが今回はいいかも。どう思います?)
Please avoid using xxxx method. I found that this line would cause an error in production. :sad:
(そのメソッドは開発環境と本番で挙動が違っててエラーになることがあるから使うのは避けてもらえますか?)

この英語が文法的に合ってるか私は分かりませんが、問題なく伝わるのでよいのです。

最後はコードで例示

エンジニアの場合、英語がダメでもコードで示せば伝わります。コードでの例示を多用しています。骨組みを実装してしまいPRを作り、このPRにコミットしていってください、というようにタスクを渡すこともあります。

レビュー負担が少ないFWを選ぶ

Railsは非常に向いています。ハイコンテキストなので、流儀と規約をアサイン前に勉強してもらえれば疎通違いが起きにくいです。オフショアの場合はJP側のレビュー工数が大きい(あなたが最後の砦です)ので、レビュー負担をなるべく少なくするのは大事だと思います。

フロントではたまたまAngularを使っていました。これもRailsと同じく縛りがきついFWなので向いていたと思います。特に問題なく実装してもらっています。

GIFアニとスクショ

国籍問わず、ビジュアルの威力は絶大です。新規機能の説明の際も、UIモックツールの成果物をシェアできれば想定通り(ときには想定以上の)のoutputをしてくれる確率がかなり上がります。粒度が小さくとも、よほど自明な時以外はスクショを貼ってコミュニケーションします。

問題は分割する

製品xxxと交換できるクーポン機能を実装依頼するとします。その際は、(1) テーブル設計 (2) クーポン生成管理画面 (3) クーポン適応ロジック (4) クーポン入力UI くらいにマイルストーンを切るのがいいです。こまめにチェックすることで予期せぬ方向に実装が勝手に進んでしまうのを防げます(苦い経験が何度も...)。これはオフショアに限った話ではないですよね。

VN側でレビューしてもらう & チェック項目を指定してしまう

提携先にアサインされるエンジニアのレベルはコントロール(=予期)しにくいです。出来るエンジニアもいれば、あまり出来ないエンジニアもいます。ひどい場合は、動作確認もしないでPRを送ってくる時もあります。こちらのローカルにpullして動作確認したら早速エラーで動かない→絶望的気分みたいな事も。そういう事態を避けるため、提携先でのレビューを経てからJPでチェックするフローにしています。具体的には、githubのラベル機能を使いステータスを管理しています

sc 2016-06-04 20.32.52.png

↑ こんな感じ

また、中・大規模な案件の場合は、githubのmarkdownでチェックを付ける機能があるので、それを利用して予めこちらからチェックして欲しい項目を簡易的に指定してしまいます。これを確認してからPRください、というメッセージです

sc 2016-06-04 20.38.12.png

↑ こんな感じ

なるべく仕組みで品質を一定に保ちたいものです。

根深い問題の調査が得意

根深い問題の調査依頼や、使うライブラリ候補のpros/consまとめなどが上手です。論理的に考えることが得意な国民性だと聞いていたのですがその通りだなあと思いました。こっちで調査してもいいけど機能開発優先したい〜〜という事は多々あるので助かります。

たまにKPIをシェアする

サービスが成長していくのは楽しいしモチベーションが上がるものです。適宜、KPIが節目に来たり、当月の調子が良かったりしたときはslackでシェアしています。

ex)
UU of xxxx is growing! UU/PV records highest score on this month! Thank you for contributing! :bow:

運用勘はないのでJPでフォロー

大規模サービスを運用したことのあるエンジニアはベトナムには少ないと思います。なので、テーブルの(ユニーク)インデックスの貼り忘れや、カジュアルにデカイテーブルへのalter tableをPRに含めてきたり、ところどころ雑なUI/UX作りなどは起こりがちです。ある程度はJPでフォローするのはやむなしと考えています。

まとめ

どうでしょうか。案外、日本の若手エンジニアと仕事をするときと大差ない気がしませんか?一度検討してみるのもよいとおもみます。
最後に、ベトナム料理は日本ではあまり見ませんが非常にうんまいです。現地で本場の味を楽しんで感動しました。こちらも一度ご賞味あれです。

85
80
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
85
80