こんにちは！

ベトナムでのシステム開発を提供する、mor asiaのヤマダです。

ここ数年ベトナムでのオフショア開発がトレンドになっていますが、

「実際どうなの？」「日本と比べて品質が劣るのでは？」

と考え、プロジェクトの失敗を懸念される方も多いのではないでしょうか？

確かに、オフショア開発では時に文化や言葉の壁を感じることがあるかもしれません。

しかしクライアント側と開発側が相互理解を重ねることで、失敗を防ぎ、プロジェクトの成功を導くことができます。

今回は、弊社が考える

• ベトナムのオフショア開発が失敗しそうになる事例
• ベトナムのオフショア開発を持ち直した方法と対策

を考察します。最後までお読みいただけたら幸いです。

1. あるプロジェクトのあらすじと失敗事例

A社はモアアジアと既に約2年、ラボ型開発の契約を継続しています。

当初ラボメンバー3名でスタートしましたが、現在は10名体制。順調に開発体制を拡大しています。

しかし最初から円滑に開発ができた訳ではありません。時にはプロジェクトが頓挫するかもしれない状況になったこともあります。その度に、A社のプロダクトマネージャー・北山さん(仮名)とモアアジアは工夫を重ね、困難を乗り越えてきました。

今回はA社がラボ型開発をスタートしてから、いくつかの困難で失敗しそうになったものの、今はモアアジアと素晴らしいチームになることができたストーリーを紹介します。

A社のプロフィール

• 担当者　 ：プロダクトマネージャーの北山さん(仮) 、受託開発の依頼はしたことがあるが、オフショアのラボ開発は初めて
• 案件　　 ：自社のWebサービスの開発
• 契約形態 ：ラボ型開発（ラボメンバー3名から徐々に増員し現在10名）
• やり取り ：Slack、Jira、週に1~2回定例会議（必要に応じてさらに開催）

失敗事例①：言葉の壁？ミスコミュニケーションで対応漏れ

（北山さん）

プロジェクトが始まってから、普段はチャットでやり取りして、週に１回の定例会議で進捗を確認していました。

定例会議では何なく会話ができていたのですが、BrSEに伝えたことが実は理解されていなかったことが多々あって、オフショア開発ってこんな感じなのかな?と感じていました。

そんな中早めに対応してほしかったことが開発されていなくて、ちょっとまずい状況になったんですね。

BrSEに聞いたら、少し工数がかかりそうだったら、調査をして後からやるつもりだったとのこと。早めにやってほしいと伝えたはずなのに…。

（mor ヤマダ）

期限はラボメンバーから質問すべきところ、申し訳ありませんでした。

しかしオフショア開発では必要以上に明確な指示出しが必要なのです。

日本人になら通じるような「こう言えば、やってほしいことが分かるだろう」といったニュアンスでは、ベトナム人には全く伝わりません。

例えば「（この問題は重要だと心の中で思いながら）できるだけ早くやってください」ではなく、「何日までにテストを含めて対応してください」と伝え、Jiraなどの管理ツールに明記し期限を設定する必要があります。

特にベトナム人は開発スピードは早いのですが、スケジュールや品質意識は日本人と比べて低いところがあります。「バグは早く対応して当然」「この位の品質は当然」と思うのではなく、優先度や品質レベルも、口頭・テキスト・プロトタイプなどのあらゆる手段を使い、明確に指示する必要があります。

クライアント担当者様は、スケジュールをしっかり伝える・管理する時間が必要ということになりますが、逆にそれさえやれば、真面目なベトナム人はスケジュール通りに、対応漏れがないよう開発に取り組んでくれるでしょう。

失敗事例②：仕様違いや不具合が散見された

（北山さん）

開発については任せておけば大丈夫だろうと思い、しばらくしてから開発経過を確認してみました。

すると、仕様違いや不具合など修正して欲しいところが結構な数がありまして…。

社内での報告直前に確認したから本当に困りましたし、修正に時間がかかるからスケジュールに不安を覚えました。

（mor ヤマダ）

この時は遅れを出さないために、不具合専門のメンバーを参加させ緊急対応させていただきましたね。

仕様違いや不具合が多かったのは、仕様が不明瞭な部分が多かったことに起因します。ベトナム人は日本人のように仕様を書いた人、またはエンドユーザーの意図を汲み取る“行間を読む”ということができません。

仕様書はある程度細かく作成いただくことで、仕様違いや不具合を減らすことができます。

そして作成した仕様書をBrSEに確認させ、疑問点を洗い出すことが大切です。

しかしそれよりも、ラボ開発は受託開発ではないため、まとめて成果物を確認するのではなく、開発ごとに細かくフィードバックをしていただく必要があります。

ラボメンバーに任せておくのではなく、クライアント側がプロジェクトにしっかり参加する、仕様違いや不具合は発生しうるものとして、「開発→フィードバック→修正→フィードバック→完了」のサイクルを繰り返す方が、アジャイル式・ラボ開発の利点を生かせます。

※上記を踏まえた上で、ラボチームには、テスターをメンバーに追加するのをおすすめしています。弊社は国際標準化機構の品質マネジメントシステム「ISO9001:2015」も取得しているので、最適な進め方をすれば、高品質な開発を提供することができます。

失敗事例③：最大のピンチ！納期に遅れてしまいそう・・・

（北山さん）

何とか開発が進んで、オフショア開発にも慣れてきたかな？エンジニアの技術力はさすがだな、と思っていた中の出来事でした。
納期が迫っている中、進捗に遅れがで始めたんですね。

BrSEに聞いたら、想定以上に作業量や難易度が高くつまずいているところがあるとのこと。 このままでは納期に間に合わず、本当に失敗するかも…と思いました。

（mor ヤマダ）

このときは度重なる仕様変更でスケジュールが切迫していることを事前に伝えていて、ご了承いただいた中での状況でした。

日本人なら行間を読んで理解する仕様変更の内容を、ラボメンバーが理解しておらず工数の算出を低く見積もってしまったんですね。

そしてベトナム人はスケジュールへの問題意識が日本人と比べ低いこともあり、緊急性を持っての対応（例えば、スケジュールや難易度が高い開発について上司に早めに相談する）に遅れが出てしまいました。

仕様書を明確に記載すること、そして「何とかしてくれるだろう」ではなく、 「本当に大丈夫？」という気持ちで進捗管理とチームマネジメントをBrSEと一緒に行うと、大きな失敗の防止になります。

少しでもスケジュールや進行に不安を感じたら、早い段階で、BrSEに対して上司に相談するよう指示いただけると助かります。

2. 改善策

（mor ヤマダ）

失敗が続く原因は、ラボメンバーがA社の要望を深く理解できていないことでした。

そこで、北山さんには

• ラボ型開発は受託ではなく伴走するものであること
• コミュニケーションのコツを掴んでもらうこと

を理解いただきご協力いただくことが必要だと感じました。

（北山さん）

モアアジアの営業担当と話し合い、まずはラボメンバーと毎朝打ち合わせをすることにしました。進捗報告を行う中で認識のズレがあれば早い段階で確認することができ、毎朝話すことで相互理解が深まったと思います。そして、改善策を実施しました。

A社の改善策

• コミュニケーションの数を増やし、曖昧な表現は使わないようにする
• 時には敬語を避け「日本人には少しきつく聞こえるかな？」位の言葉を使う
• TODOを口頭で説明後必ずテキストやツールで残す
• 仕様書の行間を減らす努力をする
• 開発背景を説明する（「なぜこの仕様なのか？」「〇〇業界ではこのような仕組みになっている」「日本の法律は〜〜になっている」など）
• BrSEの上司をチャットに追加する。上司が問題を早めにキャッチアップしやすく、緊急時には最適な策を相談できるようにしておく
• ラボメンバーのマネジメント、教育をするつもりで付き合う
• ラボメンバーの素晴らしい成果についてはしっかり褒める

モアアジアの改善策

• ラボメンバー全員で週に１回振り返りをし、プロジェクトをうまく進めるための改善案を出しあう
• 認識に相違が生まれないよう、BrSEは何ごとも議事録や口頭でお客さんに再確認をするようにする
• 上司や日本人メンバーが会議に参加し、BrSEへ特にコミュニケーションについてフィードバックをするようにする

（mor ヤマダ）

その他、開発に出てくる単語の意味についてなど、日本人なら簡単に分かることをラボメンバーから質問する場合もありますが、北山さんはしっかり回答してくれたので助かりました。

（北山さん）

改善策から、ラボメンバーにどのような伝え方をすべきか分かってきました。

マネジメントを意識して、何かあるごとに「こうしてほしい」「こうしてほしくない」をハッキリ伝えていくことで、ラボメンバーも私の気にする点を理解し、先立って問題提起や提案をしてくれるようになったと思います。（日本人なら）やってくれるだろうと思い込まないことが大切です。

（mor ヤマダ）

改善策を実施しコミュニケーションを改善した結果、エンジニアは持ち前の技術力で結果を出せるようになりました。北山さんとモアアジアから、「失敗するかもしれない」という不安は無くなり、週に１〜２回の定例会議で楽しく会話ができるほどになっています。

社内でも定期的な振り返りを行い、A社の満足度の向上に努めています。

3. 補足：ブリッジSE(BrSE）について

（北山さん）

約2年でBrSEはプロジェクトへの理解を深めてくれたので、安定してプロジェクトを進めることができています。長い付き合いなので信頼関係もあり、私が指定した資格も取得してくれました。

（mor ヤマダ）

プロジェクトが成功するか失敗するかはBrSEの存在が大きく関わっています。

BrSEとやり取りしてみて、相性がわるいと感じることがあれば、モアアジアの営業担当までお申し付けください。背景をヒアリングさせていただいた後に、BrSEの上司と直接相談し対策をとるようにしています。それでも相性のわるさが改善しなければBrSEの交代を行います。

また、失敗する原因となりうるのは優秀なBrSEが退職しプロジェクトから脱退してしまうことです。モアでは社内で退職率を下げる取り組みを多く行っています。

4. まとめ

日本とベトナムの小さな意識・文化の違いが、時にはオフショア開発の大きな失敗に繋がってしまうことがあります。このためオフショア開発を始めたら、

マネジメント・教育を意識した、分かりやすいコミュニケーションが大切です。

また可能であれば担当者がベトナム現地に入り、ラボチームメンバーと交流することもおすすめです。現地の開発拠点に入ることで、ベトナム文化やどうやって仕事をしているのかが理解できるので、日本に戻ってからもリモートでのコミュニケーションが取りやすくなります。（もちろんベトナム人も担当者に出会うことで、心の距離を縮めることができます。）

ラボメンバーとの付き合っていくコツを会得してしまえば、真面目で向学心が高いベトナム人は、2週間〜1ヶ月後には結果を出してくれるでしょう。

モアアジアのオフショア開発について 

モアアジアでは、安定してオフショア開発をご活用いただけるよう様々な取り組みを行っております。通常のオフショア開発に限らず、

• 日本人PMとやり取りし、要件定義から進めていきたい
• UI・UXデザインの改善を行うためにデザインからお願いしたい
• 開発チームだけでなく、QAチームを独立して立ち上げたい

などの対応もしております。

詳しい話が聞きたいなどご興味ございましたら、ぜひお気軽にお問い合わせください。