ベトナムオフショア開発の失敗事例

最初に代表的な失敗事例を挙げると以下のようなものがあります。

１．スケジュール遅延

２．バグの量が多く品質が悪い⇒作り直しとなりコスト高

３．発注先の旗色が悪くなると急に連絡が取れなくなった

このうち1と2は、コミュニケーションギャップや丸投げに起因することが多いです。先述したとおり、ベトナム人と日本人ではバックボーンとしている文化が違います。コミュニケーションをする上で、しっかりと期日や求める質を伝えたつもりでも、伝わっていないケースがあります。また３は、日本企業との取引に慣れていないところや価格面だけのポイントで選んでしまうと、こういうベンダーにあたってしまうリスクがあるでしょう。

日本でやっている働き方やコミュニケーション方法をそのままベトナムのオフショア会社に適用してもうまく行かず、上記のような失敗に繋がってしまうケースが多いです。仮に日本では丸投げでうまく行ったからと言っても、オフショアで丸投げしてうまく行ったケースは、ほぼ無いと考えられます。

そこでどうすればお互いに気持ちよく一緒に働けるのか、通じ合えるのかを発注元も意識し、地道に改善をしていくことが重要です。また、日本人の仕事の仕方やコミュニケーション方法、品質へのこだわりなどは、ある意味世界的に見て特殊でもあるため、日本人との仕事に慣れている開発パートナーを探すことが開発を円滑に進めるうえで非常に重要となります。

ベトナムオフショア開発会社には日本語でのコミュニケーションが可能なブリッジ人材が多いです。それがベトナムが選ばれる要因になっているものの、人によって日本語能力にはばらつきがあり、ネット回線状態などにも左右されるオンラインビデオMTGツール越しでの会話であることから、以下のような点について注意してコミュニケーションを取るだけで、失敗するリスクを減らせるでしょう。

（１） わかりやすい日本語で伝える

日本語で意思を伝える際に、できるだけ1つの文章を短くし、なるべく平易な言葉で直接的な表現で伝えるようにしましょう。これは日本人が外国人から英語で話しかけられた逆のパターンをイメージすると、どういう言葉で話しかけるのが良いか理解しやすいと思います。

（２） 伝える手法を工夫する

CHATツールやチケットなどを使って日本語でブリッジ人材へ指示をし、開発を進めていくケースが多いものの、あまり伝わっていない様子であるならビデオMTGでその部分を補足説明してどの程度まで理解しているのかを確認するようにしましょう。もしくはその逆にビデオMTGで説明をした後、CHATツール上でも補足説明をしておくことで、認識の不一致発生を防いでいくことに繋がります。

（３）コミュニケーション頻度を上げる

最低週1回は、オンラインビデオMTGを実施することで密なコミュニケーションを実施しましょう。また普段同じオフィス内の開発担当者となら実施していることをオンラインでも実施することで、開発チームとして1つであるという意識を共有できます。

具体的には、Chatツール上での挨拶、社内イベントの写真共有、KickOFFや新メンバー追加時の自己紹介、雑談などちょっとしたコミュニケーションを実施していくだけで、国境を越えた仲間意識が高まっていきます。

なお、現在コロナ禍で行き来が難しいものの状況が落ち着いたら、半年や1年に1度でも現地へ出張し実際に会って話す場所を設ける＆一緒に食事をすることで、より一層の仲間意識構築に繋げていくことが可能です。ベトナム人は、中国やインドといったオフショア開発国に比べ、より家族的であり、そのようなつながりを求めている傾向があります。

以下の様なポイントにも力を入れることで、成功の可能性を高めていけるでしょう。

（１）専任のPM人材をアサイン

・片手間で兼務だと別の業務が忙しくて開発現場へのレスが遅くなりがち

・「やはりこうしてくださいといった」仕様の手戻りが発生するのを避ける

・仕様の意思決定を迅速に実施できるようにしていく

（２）現地メンバーとのKickOffの実施

サービス立ち上げ時に可能であれば現地へ訪問し、直接開発メンバーとあって話をする機会を設けます。その際に「何」を作ってもらうのかだけではなく、「なぜ」開発するのかをとことん話して熱意を伝えると良いでしょう。

・なぜこのプロジェクトを始めるのか？

・なぜ（開発者の皆さんを）選んだのか？どこに期待しているのか？

・なぜこのプロダクトを作る必要があるのか？

もし行き来できない場合でもオンラインKickOffで同様の事を実施することで代用ができます。こうすることで、他人事ではない自分たちの開発であるという意識を持ってもらうことに繋がります。

（３） 品質について明確な基準を握る

相手は同じ社内の日本人ではないので、「普通ならこうやる」「普通はこう書かない」といった感覚での判断はNG。どの程度の品質であれば受け入れ可能か基準を明確にて提示していくべきです。もしくは相手に任せると判断したのであるなら、全て任せましょう。

（４）日本語ドキュメントは、必要性を判断したうえで作成量を調整する

日本語のドキュメント類を大量に作成して指示することは可能であるものの、比較的にコストが高いブリッジ人材の工数を活用することになるため、高コストになりがちです。

また分量が多いとスピードが出ないうえ、誤りや表記ゆれなども出やすくなります。

本当に日本語のその書類が必要なのか、API仕様書自動生成やテストコードを仕様書として代用する等ができないのかなど工夫することで費用を低減できる可能性があります。

（５）分担する場合は競合しないように設計をする

日本側の社内開発チームと、オフショア開発チームの双方が同時進行で開発を進める場合、ソースコードが競合しやすくなります。それを避けるため、フロントエンドとバックエンドで分担を分ける、機能モジュールで分担を分けるといった点を意識的に行うことで、こういった問題の発生を避けることに繋がるでしょう。

さらに品質の面では、以下の点を注意することでより品質を高めていくことに繋がります。

・プロジェクト開始時にお客様より「なぜ」をご説明いただく。

・機能要件だけでなく、非機能要件も定義する。

・求める品質レベルを定量的に定義し、合意形成を取る。

・こまめに連絡しあい、認識相違を極力防ぐ。

・モジュールごとにできたものから検証環境で確認する。

・テストコードを書く。

・テストケースを作成してE2Eテストをし、結果を報告する。

・コードレビューを取り入れる。

・ソースコードのフォーマッタの使用や静的解析を行う。

いかがでしたでしょうか？ ベトナムの代表的なオフショア開発における失敗事例を緒に、成功のためのノウハウを考察してみました。開発リソースが減少する今こそ、御社がグローバル市場で戦っていくための開発体制を構築していくために、是非ベトナムオフショア開発に挑戦してみてください。