＜目次＞

• 注目されるオフショア開発とその失敗の要因
• よくあるトラブルケース
  • 技術者の勝手な判断による問題解決
  • 要求内容の理解と想定の甘さ
  • 認識や定義理解の相違　
  • バグ修正時の詰めの甘さ
  • チーム内の情報共有の不足
  • お客様への報告に関する問題
  • 問い合わせ等への反応・返答の遅さ
  • コミュニケーターの語学力または専門知識の不足による問題
• 日本側ができる対策やトラブル防止方法
  • 積極的にコミュニケーションをとる
  • 報告のタイミングなど、開発側に徹底してほしいことを具体的に明確に文章で伝える
  • 忖度のないわかりやすい日本語で伝える
  • 会議の際は、端的に話し、通訳の時間を十分に設ける

注目されるオフショア開発とその失敗の要因

　日本の慢性的なIT人材不足にコロナ禍による社会影響が重なり、オフショア開発は大注目を集めています。オフショア開発のメリットと言えば、「コスト削減」を一番に頭に浮かべる人も多いでしょう。地理的条件や人件費の安さなど、様々な要因からアジアの国々をオフショア開発先として選ぶ企業・組織がほとんどです。その中でもここ数年、最も人気の高いオフショア開発先がベトナムです。オフショア新興国と称されて10年以上、ベトナムは技術力や経験を蓄え、オフショア開発市場のトップに立つまでになりました。

　人材不足、コロナの他にも、ベトナムオフショア開発に乗り出す企業が近年大幅に増えてきた理由に、開発企業の増加、品質やサービスの向上なども挙げられます。また、ベトナムオフショア開発企業が日本で事務所を構えるなど、日本への直接的な展開も進み、日本企業が更に“安心”して委託できる環境が整ってきました。

　今や、実際に私たち日本人が使っているあのアプリもオフショア開発でベトナム人プログラマーたちによって作られた…なんてことも珍しくありません。

　と、ここまではあくまでいい面を切り取っただけの話です。

　現在でもオフショア開発と聞くと顔をしかめる人も少なくないはずです。思ったようなものができなかった、納期に間に合わなかった、トラブルが続出したなど“失敗”という言葉が、オフショア開発のキーワードの検索候補の上位に顔を出します。

　やはり、オフショア開発には失敗やトラブルはつきものなのでしょうか。

　ベトナムオフショア開発全体において、商品やサービスの品質は向上を続けている一方で、未だ日本のお客様の基準に満たない、期待に応えられない場合があるのも事実です。 外国人エンジニアがどんなに日本人の文化、考え方、仕事のやり方、またオフショア開発のプロセスを身につけ、経験が豊富であろうとも、トラブルが発生しないとは言い切れません。また、ベトナムのIT業界は人気職であると同時に、人材の流動性が高く、人事の頻繁な入れ替わりがあります。そのため、知識や経験の引継ぎがうまくできない場合があります。

　オフショア開発が難しいと評価されるには様々な要因がありますが、その中の一番の要因は、コミュニケーションや文化の違いでしょう。この問題は、開発側と委託側双方の歩み寄りが必要になります。

　2NFソフトウェアの日本のお客様と歩んできた10年以上の経験を基に、ベトナム人の国民性や仕事のやり方傾向を踏まえた上で、ベトナムオフショア開発を行う際によくある問題やトラブルケースについてご紹介します。その他、弊社独自で行っている改善・対策方法ならびに、一般的なオフショア開発時のトラブル防止のため、日本企業側が行うべき工夫や対策についてもご紹介します。

よくあるトラブルケース

Case1.技術者の勝手な判断による問題解決

　開発時にITエンジニアが勝手な判断や思い込みで不明点や問題点を解決し、結果として顧客の要求した内容と異なる製品ができてしまう。この場合、再度修正が必要になるので、工数の増加と同時に、納期に間に合わない可能性がある。

＜弊社の対策＞
　小さな疑問点や不明点でも、お客様へ質問・相談を徹底するよう社員教育を行っています。弊社独自でQAの書き方をトレーニングしたり、整理してまとめてやり取りを行うことで、お客様にわかりやすく、かつ負担にならないようにしています。

Case2.要求内容の理解と想定の甘さ

ある機能の開発を行う際、その要求の解析、Q&A、発生する可能性があるケースなどに関する検討を重視せず、直ぐにコーディング工程に入る傾向がある。

＜弊社の対策＞
　コーディング工程に入る前に、どのような要求解析、設計書分析をするべきか研修し、規模を問わず、どのようなプロジェクトに対しても徹底的に検討を行います。その際、予めお客様にお伝えし、納得して開発に進んでいただけるようにしています。

Case3.認識や定義理解の相違

　タスクが完了したという認識、あるいは「完了」の定義の理解が統一されていない。『タスクの完了＝コーディング作業の終了もしくは基本的な流れの終了である』と考えているITエンジニアが少なくない。

＜弊社の対策＞
　　まず「完了」の定義はどのような意味であるか、どのように理解すべきかを説明し、社内で統一しています。

・開発者：コーディングを行った後、結合テスト、総合テストをする前に、チェックリストに沿ったソースレビュー、単体テスト項目の作成・実施などを厳重に行います。プロセス通りの厳正な実施を徹底しています。
・テスター：結合テストの際に、単体テスト工程にエラーを発見した場合、開発チームに報告・返却し、再度エラーがでなくなるまで開発者に厳正な修正を要求しています。
・総合テストを実施する際、エビデンスを取得します。

Case4.バグ修正時の詰めの甘さ

　お客様に指摘されたバグしか修正しない。もしくはシステムにそれと同様のバグがあるか、またはそのバグ修正によって他の機能に影響があるか、などのチェックを怠る。

＜弊社の対策＞
　弊社では同様のバグやディグレードバグの確認及び検出方法について研修を行っています。バグを修正すると同時に、それと同様のバグを修正（横展開）します。また、修正する前に、その影響（デグレード）を受ける他の箇所の有無の確認も徹底しています。もしある場合、バグ修正後にデグレード防止のため、その箇所に対してもテストを実施を義務付けています。

Case5.チーム内の情報共有の不足

　顧客が注意や指摘をしたにも関わらず、それが周知されずに、開発チーム内でそれぞれのメンバーが同じ間違いを何度も繰り返すことで、開発計画に影響がでる。

＜弊社の対策＞
　チーム内でお客様に指摘された事柄を始め、バグに関する全ての情報を共有します。共通のバグリストを作成し、それぞれのメンバーが念頭に置いてコーディング及びレビューを行います。

Case6.お客様への報告に関する問題

　プロジェクト開発を進める中で、顧客から依頼があった場合にのみ報告書を作成する。作成した報告書も内容が乏しく、不明な点が多いため、プロジェクトの進捗や現状などを掴みにくい。逐一再確認しなければならず、無駄な工数の増加に繋がる。

　また、問題が発生し、プロジェクトの納期や品質に影響を与える可能性があるにも関わらず、顧客へすぐに報告をしない。結果としてプロジェクトが完了できず、その時になって報告しても遅すぎるため、顧客の計画調整が不可能な状況になってしまう。

＜弊社の対策＞
　社員全員に対して、報・連・相という日本のビジネスマナーの意味、メリットの周知をし、やり方をトレーニングしています。毎日、チームメンバーが日報を作成し、PMに送ります。PMが調整・まとめを行い、報告書としてお客様に提出します。
　報告書には４項目（当日の計画、現状、問題（原因、対策）、翌日の計画）あり、プロジェクトの進捗を総合的、客観的に記します。問題が発生すれば、開発チーム全体とお客様の双方が状況を把握できるよう、お客様に即座に報告し、解決方法について話し合います。

Case7.問い合わせ等への反応・返答の遅さ

　顧客からの質問・依頼への返信が遅く、顧客を待たせたり、緊急の要望に応じられない。その原因として、完全に対応が終了してから返事をするというベトナム人の習慣や、オフィスワークの文化の違い（勤務時間中の私的な外出など）が挙げられる。

＜弊社の対策＞
・お客様から連絡を受け取った場合、できるだけすぐに返信するようにします。連絡に対してまだ回答ができない場合、その質問・依頼内容を理解したこと、対応が完了次第連絡する旨をお伝えします。
・勤務時間中に、無断で席を長時間離れることをが厳しく禁止しています。また、休みや遅刻の場合、早めに総務担当者に連絡することを徹底し、連絡がない場合は欠勤扱いにします。

Case8.コミュニケーターの語学力または専門知識の不足による問題

　プロジェクト開発の際、コミュニケーター（通訳・翻訳者）の能力・知識不足によって、技術的な問題について両者間で誤解が生じる。また、オンライン会議の際に、コミュニケーターが通訳内容を理解するための開発側の話し合いに時間がかかったり、即座に回答・問題解決ができない場合がある。

＜弊社の対策＞
　開発側内部での話し合いに時間がかかると判断した場合は、お客様に断りを入れるか、会議後に回答する旨を伝えます。技術問題を明らかにするため、BrSEを参加させます。コミュニケーターは主に資料翻訳を担当し、技術問題についてはBrSEがサポートします。時間がかかっても問題が解決できない場合、BrSEがその問題を調査し、解決方法を直接お客様に提案、協議を行います。

日本側ができる対策やトラブル防止方法

　ベトナムでオフショア開発する際に起こりやすいトラブルケースについてご紹介しました。上でも述べた通り、技術面を除き、文化や言語の面では、開発側の努力だけでは解決や再発防止が難しい場合が多いです。委託側が、コミュニケーション方法・頻度や使用する日本語など、改善したり、留意することでスムーズに開発が進められるようになりますし、製品への満足度も高まるでしょう。日本企業ができる上記やその他様々なトラブルにも共通して言える対策や注意点を紹介します。

〇積極的にコミュニケーションをとる

　事前に指示している報告頻度に限らず、少しでも疑問点や不安点がある場合は自分から連絡します。特に、納期の厳守が求められる場合や、一つの作業自体に時間がかかる場合、こまめに進捗状況を尋ね、優先順位や作業内容を事前に変更することで、納期に間に合わせ、無駄な工数の増加を抑える効果があります。頻繁にやり取りしたり、過去のやり取りを見返すためにも、両者間のコミュニケーションツールにはチャットツールが便利です。チャットツールを選ぶ際、こちら側も頻繁にチェックできるものがよいでしょう。グループには一人だけでなく、開発者・委託側ともに複数人アサインすることで、情報の抜け落ちを防ぎ、早めの対応ができるようになるでしょう。また、文字でのコミュニケーションだけでは難しいと感じた場合、オンライン会議を行い、その場でスムーズに問題を解決することで、時間や経費の削減にもつながります。

〇報告のタイミングなど、開発側に徹底してほしいことを具体的に明確に文章で伝える

上記のよくあるトラブルでもご紹介した通り、開発側がトラブルに対して勝手に判断をしてしまう傾向があります。特に、経験が浅い会社やエンジニアによることが多く、このような状況を防ぐためにも、できるだけ自社側の方針や希望に沿って、定期報告や緊急報告、ミーティングについて詳細な指示書を作成します。会議で口頭で伝えるだけでは効果が低いため、開発側で正確な翻訳・共有をしてもらうために文章にすることがよいでしょう。また、開発段階で報告内容や頻度についてなど改善・変更してほしい場合は、すぐに伝えます。その際、どのように変更するのか具体的に明確にしましょう。開発側の過失で重大なミスが起こった場合、もしくはプロジェクトに大きな影響を与えうる場合は、原因の説明や再発防止策の策定を求めましょう。

〇忖度のないわかりやすい日本語で伝える

　オフショア開発企業、特に現地人によって設立された会社では日本人が対応できる会社は少なく、外国人コミュニケーターやBrSEが対応するのが一般的です。日本人の文化であり、欠点でもある忖度は文化が異なる外国人には基本通じません。遠回しの言い方も理解を難しくさせます。要件定義などの開発に必要な書類から、日頃のチャットでも、具体的で明確な日本語で伝えるよう意識しましょう。特に日本語では主語を抜くことが多いですが、ベトナム語では主語が必須なため、通訳者が混乱し、誤解が生まれることがあります。その他、『私は○○と言ったのですが…。』『いい感じに修正してください』など不明瞭で言い切らない表現も混乱を招きやすので、注意が必要です。

〇会議の際は、端的に話し、通訳の時間を十分に設ける

　オンライン、オフラインを問わず、開発側と会議を行う場合は、一気にダラダラと話し続けるのでなく、要点をまとめて端的に話すようにしましょう。会議中はコミュニケーターによる通訳が必要になるので、通訳者に配慮した話し方や声のボリューム、内容量が求められます。また、その後通訳する時間を十分に設けることも大切です。こちら側の質問などに対し、エンジニアとコミュニケーター間で話し合いが行われることがあり、日本人側としては待たされているという感覚になりますが、コミュニケーターが技術的な問題を理解し、正確に通訳するために必要な時間です。伝えたいことが言葉だけで説明が難しい場合、絵を描いて見せるなど、工夫も必要です。

　オフショア開発は通常国内で開発を委託するより、文化や価値観の違いから思いもよらない問題が起こりがちです。しかし、開発側と委託側両方の改善や意識の向上によって解決される問題がほとんどです。ベトナムでは日本企業によるオフショア開発が今最も盛んであり、日本人ITエンジニアに引けを取らない技術や経験を持つエンジニアも多くいます。オフショア市場でも唯一技術力とコストメリットを併せ持つベトナム。今後人件費が上昇していくと考えられるため、開発に乗り出すのは今が絶好のタイミングでしょう。

ぜひ、オフショア開発をされる際は弊社２NFを選択肢の一つにご検討ください！