SHIP TECHBlOG

ベトナムのオフショア開発のマネジメントを始めて早6ヶ月が経ちました。先日、大規模な開発のリリースが無事完了し、ほっと一息ついたところで、オフショア開発を通じて感じたことや改善した点をまとめてみようと思います。

1. 現在の開発体制について

今の私のPJでは以下のような開発体制で運営しています。一般的にテスターを別途配置するケースもありますが、ベトナム開発メンバーが積極的にテストも実施する形を採用しています。

日本人

開発リード：3名

ベトナム人

コミュニケーター：1.5名
フロントエンドエンジニア：2名
バックエンドエンジニア：7名

2. 実際に経験してみて感じたベトナム人エンジニアの特徴

初めての海外メンバーとの仕事でしたが、開発スキルが高く、陽気で活気のあるチームと働くことができ、刺激的な日々を過ごしました。特に以下が印象的でした。

a. 成長意欲が高い
技術習得への意欲が強く、新しいプログラミング言語やフレームワークを学ぶのに積極的でした。
定期的にパワポを用いてテクニカルな発表を各個人で実施するような勉強会を開催しています。
最近ではAI周りの発表が多いのも印象的でした。

b. 英語力の高さ
多くのエンジニアが積極的に英語でコミュニケーションを取ろうとすることに驚きました。TOEICで一定以上のスコアを取得することが大学卒業要件になっている場合もあるようです。
コミュニケーターにおいては日本語と英語を使いこなすケースが多く、日本のエンジニアよりも高い語学力を持つ印象です。

c. IT教育の質が高まっている
ホーチミン工科大学やハノイ工科大学などのトップ大学のIT教育水準が高まっています。
当社と協業している企業でもホーチミン工科大学出身者が多く、若手社員が多いながらも高い技術力を持っています。ニッチなフレームワークを扱うプロジェクトでもキャッチアップが早い点が印象的でした。

d. 文化・働き方の違い
チームワークを重視する傾向はありますが、自発的に意見を言うことが苦手なのもあり、報連相についてはしっかりと指導が必要だなと感じました。
リモートワークの文化も進んでいますが、オフィスでの対面コミュニケーションの方が国民性からも合っているように見え、社内イベントやお祝い事を大切にする点が日本とは対照的でした。

e. スピード感はあるが、細かい部分はラフ
開発のスピードは速いものの、細かい部分の詰めが甘くなることがあります。
仕様のすり合わせや成果物の確認を慎重に行わないと、認識齟齬が発生しやすいと感じました。
特に、テストの重要性が十分に浸透していない点は課題です。

3. マネジメントの課題と工夫

オフショア開発でよくある課題の一つですが、「期待していたものと違うものが納品される」ことはよく話で上がってくることだと思います。
そのためにやるべきことは仕様として明確にし、ドキュメントをしっかり整備することが重要ですが、それだけでは不十分だと感じています。
コミュニケーターやベトナム開発陣に任せて終わりではなく、いかに日本人管理者が開発メンバーと開発プロセスの中に入ることが重要であるかを多く実感することができました。

- 改善策 -

a. タスクの細分化と見積もりのフィードバック
実装着手前にエンジニアに要件全体を把握してもらい、不明点を事前にヒアリングすることで認識のずれを防ぐことが大事です。

b. モックアップをしっかりと用意して、視覚的に理解しやすくする
母国語とは違う言語の開発なので当然と言えば当然ですが、大きい開発ほどしっかりとした成果物のイメージを展開する必要があります。
管理者や要件策定者間でも完成のイメージを共有できていないような場合、海外メンバーの完成イメージがかけ離れるのも当然と言えば当然です。

c. デイリーでの進捗確認（30分以内）
開発体制の中では完全に日本人開発チームとベトナム開発チームでコミュニケーションを分けることもあるかと思いますが、1日1回は状況を確認した方が良いと感じました。
進捗確認はもちろんですが、メンバーにただタスクをこなしてもらうだけでなく、PJの全体像・背景を共有し、課題をヒアリングすることは特に重要です。
日本人開発メンバーやベトナム開発メンバーが相互に理解しながら開発をやっていくことが双方にとってメリットがあるなと強く感じています。
ただ、デイリーが長すぎると各自のワークが短くなるので端的に30分以内を目指すことがベストです。

d. 週1回の仕様（成果物）レビューを実施
成果物の軌道修正を行うため週に1回のレビューを行うことが大事です。
オフショア開発では思っていた方向に進んでいないことが多く手戻りが発生しやすので、発見のタイミングをいかにPJ進行の前段に持ってくるかが成功の鍵となります。

e. ベトナムメンバー内でKPTを実施
ベトナム国内で複数企業が同一PJに参画しているため、各自意見出しや振り返りを実施してもらいたく週次で実施しました。
ここから出た改善案についても多く採用したことがあります。
ただ、意見が出しにくい国民性から、社内のマネージャーレベルのベトナム人に会の進行や意見出しについてサポートしてもらうことも大事です。

4. コミュニケーションコストの軽減

オフショア開発においてボトルネックになるのが、やはりコミュニケーションコストだと思います。
ブリッジSE・コミュニケータを利用して開発する場合、この中間レイヤーでやることが増えすぎてボトルネックになることが多いため、いかに低コストでコミュニケーションを行い、認識齟齬を発生させないように回せるかが重要だと感じます。

- 主な対策 -

a. チケット・テスト仕様書等の各ドキュメントの英語化
英語をなるべく利用することをOKとし、エンジニア主体でできることは極力エンジニアに任せ、コミュニケータを介さずにコミュニケーションを完結できるようにした方がコストを抑えることができます。
最近は翻訳ツールが発達していますが、ベトナム語・日本語の変換については弱いことも多く、英語を利用した方が低コストで認識齟齬が発生しにくいケースもよくあります。
ただし、大事なところについてはコミュニケーターを挟んでしっかりと対応・会話することが大事です。

b. 1方向の伝達を避け、三者間ミーティングを増やす
重要な機能説明やヒアリングについては「管理者 → コミュニケーター → エンジニア」の流れではなく、3者が参画し直接話す場を小まめに開いた方がスピード感を持って対応することができるケースも多いです。
言語は違えど、相手の理解度を声や表情から汲み取ることも重要と感じます。

c. 仕様書の作成・更新プロセスの明確化
仕様変更後の翻訳受け渡しの漏れは認識齟齬の原因となるため、こちらについてはコストをかけた方が良いです。
変更管理の仕組みを用意し、仕様変更から翻訳作業のプロセスを徹底的に行うことが大事です。
変更後の翻訳漏れに気づきやすいよう、可能ならドキュメントについては日本語版と翻訳版と別で作らず、日本語とベトナム語を併記したドキュメントを活用することも視野に入れた方が良いです。