オフショア開発拠点で直面する3つの問題と対策を解説します！

こんにちは、タテキです。

エンジニア不足の問題を抱えていませんか？ITエンジニアの有効求人倍率は2022年12月時点で15.8倍となっています。全体の有効求人倍率1.35倍と比較し、かなり高い数値です。

（参考：PR TIMES　ITエンジニア・クリエイターの求人倍率、15.8倍と高止まり続く）

人材不足を解決する手段としてオフショアに開発拠点を作る企業が増えています。オフショア開発のモンスターラボホールディングスが2023年3月に上場するなど、勢いのある業界だと言えるでしょう。
（参考：モンスターラボ　東京証券取引所グロース市場への上場承認に関するお知らせ）

オフショア拠点開発は2つのパターンに分けられます。

自社でオフショア拠点を立ち上げる
オフショア開発を得意とする外部企業に委託する

今回は「1.自社でオフショア拠点を立ち上げる」について、よくある問題と対応策を解説します。オフショア拠点での開発は日本国内でのエンジニア不足によって開発が進まない問題の解決が可能です。より安価にコストメリット良くシステム開発をできるようになるので、興味のある方はぜひ参考にしてみてください。

オフショア開発で発生する問題点

オフショア開発で発生する問題点について3つ解説します。

オフショア拠点が要件と異なる機能を作ってしまう
オフショア拠点で作られた機能はバグが発生しやすい
メンバーの頻繁な入れ替わりでオンボーディングにコストがかかる

それぞれ順番に解説します。

オフショア拠点が要件と異なる機能を作ってしまう

オフショア開発で発生する問題点のひとつは、オフショア拠点が要件と異なる機能を作ってしまうことです。品質の低下やコストの増加、スケジュールの遅延により、顧客の不満を招きます。要件と異なる機能を作ってしまう最大の理由は日本との文化の違いです。

とくに日本のビジネス様式の理解はオフショア拠点のメンバーには難しいことです。いわゆる「行間を読む」「良しなにやる」といった考えは通用せず、国内エンジニアであれば想像して対応してくれるだろう曖昧さは、オフショアメンバーには通じないと思って良いでしょう。

オフショア拠点との文化の違いは教育にも現れます。「言われたことを言われたとおりにやる」教育や、暗記や正誤回答が主流の国も多いです。オフショア拠点の教育水準によっては、想像をはたらかせた業務を期待するのは適切ではありません。

また、オフショア拠点には日本よりも転職が広く浸透している国もあります。多くの国では日本と比較してメンバーの入れ替わる頻度が高いです。急なメンバーの入れ替わりの際は、文章化されていない知識が次のメンバーに継承されません。重要な要件や作業進捗が明文化されていれば良いですが、情報が抜けたメンバーの頭の中にのみある場合はさまざまなトラブルが発生するでしょう。

オフショア拠点と日本では文化が異なります。そのため要件と異なる機能を作ってしまうことが、往々にして発生するのです。

オフショア拠点で作られた機能はバグが発生しやすい

オフショア拠点で作られた機能はバグが発生しやすい傾向があります。日本国内にいないオフショアのメンバーは、日本で使われるサービスの理解度が低い傾向にあります。バグによりサービスが止まった際の、ユーザインパクトをイメージできません。

たとえば日本に住む私たちはUberというサービスを知っています。しかし、GrabというUberと同規模のサービスについての認知度は低いです。Grabが東南アジアにあると聞いても、現地で実際に使ったり広告を見たりしないと実感しにくいからです。

たとえ売上やトラフィック数を見せて説明してもサービスのプレゼンスを実感することは難しく、一つのバグが及ぼす影響の大きさを自覚することも簡単ではありません。

メンバーの頻繁な入れ替わりでオンボーディングにコストがかかる

オフショア拠点のメンバーの頻繁な入れ替わりは、オンボーディングのコスト上昇に繋がります。新しいメンバーに対するトレーニングや教育をする必要性があるからです。海外の多くの国は日本と異なり、転職が広く浸透しているため、メンバーの頻繁な入れ替わりを想定しなければなりません。

チームメンバーが入れ替わると新しいメンバーの教育や、チームの信頼関係の構築に時間がかかり、生産性の低下を招きます。オフショア拠点ではオンボーディングのコストを織り込んで事業を考える必要があるでしょう。

海外では報酬の為に転職することが日本以上に一般的です。経済産業省の「IT人材に関する各国比較調査結果報告書」からも海外の国が給与や労働条件を重視していることが分かります。労働に対する考え方が違うので、文化の違いを前提とした仕組みを構築する必要があるでしょう。

オフショア開発での問題に対する対策

オフショア開発での問題点に対する対策をそれぞれ解説します。

問題点	対策
オフショア拠点が要件と異なる機能を作ってしまう	オフショアに向けた要求整理とプロダクト要件は丁寧に作る
オフショア拠点で作られた機能はバグが発生しやすい	重要機能ではなく部分機能をオフショア拠点に切り出す
メンバーの頻繁な入れ替わりでオンボーディングにコストがかかる	オフショア拠点のオンボーディングを仕組み化する

オフショアに向けた要求整理とプロダクト要件は丁寧に作る

要件に沿った機能を作ってもらうためには、丁寧に要求整理とプロダクト要件を作る必要があります。オフショア拠点との言語の壁や文化の違いを乗り越えるためです。曖昧な要件ではオフショア拠点が要件と異なる機能を作ってしまう可能性が高いでしょう。

私もオフショア拠点で開発してもらう場合、日本側で作ってもらうよりも倍くらいの時間をかけます。曖昧な部分を減らすためです。とくに以下の3つはじっくり作ります。

ユーザフロー
機能要件
モック

要求整理とプロダクト要件を作る際は、なるべく曖昧な表現は避けましょう。想像の余地が入ると別の意味で捉えられる可能性があるからです。明確な指示のない部分は自由に作業されてしまい、適当に作られてバグに繋がる恐れもあります。

少人数でも安定継続して作業できるメンバーを見つけたら、時間をかけて教育するのがおすすめです。教育後はブリッジエンジニアとして、オフショア開発チームとの間にある文化や言語の壁を取り除き、円滑なコミュニケーションを促進する役割が期待できます。

重要機能ではなく部分機能をオフショア拠点に切り出す

オフショア開発では重要機能ではなく部分機能をオフショア拠点に切り出すのがおすすめです。バグによりサービスが止まったとしてもユーザに与える悪いインパクトを最小限にできます。バグを完全になくすよりも、バグが起こっても影響の少ない環境を作ると良いでしょう。

たとえばサービス全体に影響が出る重要機能はオフショア拠点に任せない方が賢明です。サービスの開始から終わりまでの基本的なユーザフローに関わる機能は、バグが発生するとサービス全体に大きな影響があるでしょう。具体的な機能はログイン → トップページ → 購入が該当します。

そのため止まってしまってもサービス自体は継続できる機能や、新しく立ち上がったばかりのサービスなど、一部ユーザしか使わない機能をオフショア拠点に切り出すべきです。既存顧客からの修正要望やLCMなど簡単な対応を任せるのもおすすめします。

オフショア拠点で作られた機能はバグが多くなりがちです。サービス全体に影響を及ぼす重要機能ではなく、一部ユーザのみが使う部分機能をオフショア拠点に切り出すと良いでしょう。

オフショア拠点のオンボーディングを仕組み化する

オフショア拠点のオンボーディングを仕組み化するとコストを削減できます。海外の多くの国は転職によりメンバーの入れ替わりが激しいからです。あらかじめメンバーの入れ替わりを折り込み、仕組み化しておけば余計な労力やコストを払うことなくオンボーディングが可能です。

オンボーディングを仕組み化すると、コスト削減以外にも以下のようなメリットがあります。

新メンバーの作業品質の向上
チームの効率化

オンボーディングの仕組み化によりスムーズかつ効率的にプロセスを行えれば、新メンバーの早期習熟が可能です。チームの効率化により、全体的な作業品質の向上が期待できるでしょう。

また良い関係を築いたオフショアメンバーであったとしても、辞めてしまうリスクがあります。常にメンバーの入れ替えに備え、オンボーディング資料をマニュアル化しましょう。オンボーディング資料は定期的に見直していくことも大切です。最新化されたオンボーディング資料があれば、新しいメンバーが短時間で必要な情報を理解できるでしょう。

まとめ

オフショア拠点での開発は日本国内でのエンジニア不足によって開発が進まない問題の解決が可能です。しかし自社でオフショア開発拠点を立ち上げる際は、日本国内の事業とは違った問題が発生します。オフショア開発拠点ならではの悩みがあり、適切なアプローチが必要です。またオフショア開発拠点を導入するため、日本側の開発体制を変える必要もあるでしょう。

オフショア開発拠点を導入すればコストを抑えたエンジニアの採用が可能です。やり方によっては初期コストを抑えてオフショア開発を試すこともできます。オフショア開発拠点を試しに導入し、メリットがあるかどうか、会社に合うかどうかを検討してみると良いでしょう。

オフショア開発拠点に関する解説はこちらの記事で詳細に行っています。

ぜひ参考にしてみてください。

オフショア開発拠点を作ろう！国際需要の高いインド周りの立ち上げをご紹介！