昨今の人手不足の影響で国内の開発リソースが不足しつつあり、「最近オフショア開発を視野に入れ始めた」という経営者やCTOの声をよく耳にします。

ただ、オフショア経験者の意見を聞いたり、ネット記事を調べたりすると、「オフショア開発は失敗するからやめておいた方がいい…」という意見もちらほら見受けられるので、初めてのオフショア開発に対して高いハードルを感じてしまうのではないでしょうか。そこで今回は、Wakka Inc.のベトナム拠点マネージャーの中垣が、初めてのオフショア開発でよくある失敗事例とその対策について説明していきます。

オフショア開発のうち、Wakka Incではオフショアラボ型開発サービスを提供しています。
ラボ型開発に興味がある方は「【保存版】成長企業が導入するWakkaのラボ型開発」に詳しいサービス内容を掲載しているのでご覧ください。

オフショア開発とは

オフショア開発とは、自社の開発を海外の企業にアウトソーシングする手法です。一般的に現地のエンジニアのリソースを数ヶ月から半年程度確保する契約形態となっており、継続的な受託開発や自社サービス開発をしている企業には適しています。

オフショア開発のメリットとしては、国内に比べてエンジニアの確保がしやすく、コストが下がるので第二の開発拠点として利用しやすい点が挙げられるでしょう。

オフショア開発が注目される理由

理由1.国内でIT人材が不足している

DX化の推進やAIの活用など、IT投資にともなう人材の需要は今後ますます高まることが予想されます。
しかし現在、日本国内のIT人材不足は決して楽観できる状況ではありません。
オフショア開発が注目される背景には、国内の深刻なIT人材不足があるのです。

一方、東南アジアには若いIT人材が多く、IT人材の育成に力を入れている国も多いため、将来性が見込まれています。今後のIT投資に対応するためにも、IT人材不足を解消する対策としてオフショア開発を採り入れる企業は増えていくでしょう。

理由2.発注先の技術力が向上した

日本国内で高度なITエンジニアを採用するのは非常に困難な状況です。
これは、前述した人材不足の問題もありますが、優秀な人材には仕事が集まるため、確保するのが容易ではないという理由もあります。

しかし、ベトナムやフィリピンなど東南アジアの各国では優秀なITエンジニアが多く、オフショア開発では優秀なITエンジニアを確保しやすいのがメリットです。これは、前述したように東南アジア各国ではIT人材の育成に力を入れており、近年は各国ともITエンジニアの技術力が向上しているのが理由でしょう。

今後はIT投資の増加、オフショア開発の増加により、東南アジア各国でも日本のようにIT人材が不足することが予想されるため、長期的な視野でオフショア開発に投資する企業も増えているようです。

理由3.オフショア開発の環境が整った

今、優秀なIT人材が豊富なベトナムをはじめ、東南アジアの各国では日本に向けてオフショア開発を提供する企業が増えています。各受託企業はその中で差別化を図っており、非常に競争が激化しているようです。

例えば、特定の業務や技術に特化した企業、開発体制の柔軟性を特徴とする企業など、各社の得意とする領域を明確にして業績を伸ばしてきています。つまり、オフショア開発を発注する立場の日本企業にとっては選択肢が増え、自社に適合した発注先が見つかる可能性が高くなっていると言えるでしょう。

このように、日本企業にとってオフショア開発に取り組みやすい環境が整ってきていのも、注目される理由のひとつです。

●開発リソースの不足にお悩みなら●

＞＞＞Wakka.Inc独自の海外子会社設立サービスがおすすめ！
無料でサービス資料をダウンロードできますのでぜひご覧ください。

オフショア開発が失敗しやすい4つの要因とは

オフショア開発を採り入れるメリットはたくさんありますが、難しい点が多いのも事実です。
本章では、オフショア開発が失敗しやすい要因について解説します。

要因1.管理者の能力不足

オフショア開発では、発注側の管理不足が原因で失敗する例が多くみられます。例えば、進捗状況をきちんと管理せずに現地の開発チームに任せていると、後々大きな問題になることがあります。

また、オフショア開発では開発メンバーの入れ替わりがよくおこります。
開発メンバーが頻繁に入れ替わるとノウハウの蓄積が進まず、開発したソフトウェアの品質が期待通りに上がっていきません。

要因2.コミュニケーションが不足している

オフショア開発では通常、現地のブリッジSEが発注元と委託先の開発チームの橋渡しをします。日本と委託先企業の国では言語が違うため、ブリッジSEの言語能力に問題があると、こちらの意図が思うように伝わりません。

日本人同士であれば、行間を読んで暗黙のうちに伝わることもあるでしょう。しかし、海外ではなかなか日本と同じようにいかないため、あいまいな指示では相手に真意が伝わらないこともあります。

要因3.発注先の商習慣・文化を考慮できていない

言葉によるコミュニケーションの問題だけでなく、文化や商習慣の違いにも要因があります。海外の人材は基本的に、日本の常識とは違った文化や商習慣の中で仕事をしているため、日本では常識とされていることが同じように通じるとは限りません。

代表的なところでは、例えば時間感覚の違いが挙げられます。オフショア開発を受け入れている国では、日本ほどシビアな時間感覚を持ったところはあまりないため、スケジュールや納期についてあいまいな感覚で指示していると、認識違いを起こすリスクが高いでしょう。

このように、日本では当然と思われていることが海外では感覚が違っているため、互いの認識違いが原因で失敗するケースが多いのです。

要因4.為替変動が計画に盛り込まれていない

オフショア開発のコストを考えるときは、為替変動を考慮しておくことが欠かせません。開発を委託する現地国の経済状況、あるいは日本国内の経済状況の変化によって為替が変動するため、経済動向も加味した収益計画を立てるのが重要です。

特に、安い人件費で発注できる発展途上国は、社会情勢や経済状況が不安定な国が多いので、注意すべきでしょう為替の変動を十分に考慮していないと、当初見込んでいた予算を超過するリスクが増大します。

オフショア開発でよくある失敗事例と対応策

オフショア開発に取り組むなら、

• 具体的にどのような失敗が多いのか
• 失敗しないためにはどのような対策が必要か

について事前に知っておくのは重要です。

本章では、オフショア開発でよくある失敗事例と対応策について見ていきましょう。

事例1.納期が遅れてプロジェクトが進まない

オフショア開発で失敗を経験した人は、納期遅延の多さを指摘することが多いです。具体例としては次のようなケースがあります。

日々の進捗状況は確認しているのですが、現地ブリッジSEからはいつも「大丈夫」と報告が返ってくるので安心していました。しかし、実態はブリッジSEの報告とは違い、決められた納期からずるずると数日ほど遅延してしまいました。しかも、遅れて出てきた納品物も思っていたものと違っていたのです。

結局、遅れを取り戻せないまま各タスクの遅延や手戻りが続き、プロジェクト全体が遅延してしまうという結果に…。このようなことは、考え方の違いについて相互理解が不足している場合に発生します。

例えば、日本のように数時間の遅れも許さないという考え方もあれば、海外のように多少の遅れであれば大勢に影響はないので気にしないという考え方もあるからです。その場合、「大丈夫」の定義が日本と現地では異なっているため、認識のズレを埋められないままプロジェクト全体が遅延してしまうのです。

このようなトラブルを避けるためには、明確で定量的なタスク管理を行うのが重要です。具体的には、適切に管理できる粒度で工程を細分化し、それぞれに定量的なゴールと納期を明示してタスク管理をすることを徹底することをおすすめします。

ゴールと納期が明確であれば、日々の進捗管理で双方の認識の大きなズレは防げます。

事例2.コーディング規約が守られない

大規模なプロジェクト開発では、品質や保守性を高めるためにコーディング規約を用意していることが多いと思います。しかし、コーディング規約を事前に説明して書面も渡しているのに、現地からの納品物を見るとコーディングのルールが守られていないという話を耳にします。

さらに、ベンダーもコーディングルールの手直しはあまり前向きに取り合ってくれないので、すぐに国内開発に戻してしまったという結果になりかねません。このような失敗は、日本と同じ感覚でコーディング規約を渡してしまったり、テスト項目にコーディングルールのチェックを設けていなかったりするプロジェクトでは発生しがちです。

日本の開発では、目的やメリットが曖昧でもルールがあれば守ってくれるということが大半でしょう。しかし、海外からすると目的のないルールは努力義務程度の内容と認識されてしまい、開発のゴールである「仕様書通りに動くシステム」を納品すれば問題ないと判断されてしまうことがあります。

このような失敗を防ぐためには、コーディング規約の

• 目的・メリットの明示
• 品質テストでの項目設定

を行うようにしましょう。

目的・メリットの明示

例えば、「可読性や将来の保守性を高めるためにルールを作っており、ルールが守られることで後工程の工数が30%削減できる」というような明確な説明をしておくことが挙げられます。

品質テストでの項目設定

目的・メリットをしっかり伝えていても、品質に対する意識はすぐに変わるものではありません。開発メンバーの品質意識だけに頼るのではなく、品質テスト項目にコーディング規約チェックを加えるなどの仕組みでカバーすることを心がけましょう。

事例3.現地エンジニアの稼働率が低い

単価が安いことに魅力を感じてオフショア開発を導入したのに、稼働率が低く思ったよりコストパフォーマンスが悪いという意見をよく聞きます。
このような失敗意見では、

• 感覚論
• タスク分配ミス

の要因が混在して発生するケースが多いようです。

感覚論

アジアの国では旧暦の正月を祝う旧正月という文化があり、旧暦の正月の少し前にあたる1月下旬ごろから1週間程の休暇が発生します。日本人の感覚からすると、正月休みが明けたあとすぐに現地の長期休暇があるため、思っていたより稼働が少ないという感覚論になりがちです。

しかし、1年間の祝日をトータルで見ると、実は日本の方が多かったというケースが多いのです。年初に稼働率が下がるという感覚を抱きがちですが、事前に現地の休み期間を考慮し、休暇の多い時期に開発のピークを重ねないなどスケジュールを工夫すれば、効率よく開発を進めることができるでしょう。

タスク分配ミス

オフショア開発は事前にエンジニアの工数を確保しておく契約形態が多く、その場合は日本から依頼するタスクが少ないと、現地エンジニアはやることがなくなり費用対効果が悪くなります。この場合は、定例会議などの場で定量的に開発メンバーの状況を確認しておき、工数が余りそうなら他のタスクも依頼するなど調整しながら進めましょう。

事例4.開発コストが予算を超える

開発を計画していた当初は、オフショア開発の委託先企業から取得した見積もりが予算内に収まっていたが、実際に開発を進めてみると予算オーバーしてしまうケースが多く見られます。

主な原因として考えられるのは次の２点です。

• 仕様が正確に伝わっていなかったため想定以上の工数がかかった
• 為替変動を加味した計画になっていなかった

委託先企業から出てきた見積もりが安かった場合は、こちらの要件がきちんと伝わっているか確認する必要があります。会社の実績やエンジニアの体制なども見積もり段階で細かくチェックしておき、見積もりの信頼性を確認しておくべきでしょう。

また、オフショア開発を委託する国の社会情勢や経済状況を把握しておき、為替変動によって人件費が高額になるリスクも計画段階で考慮しておくことが重要です。

オフショア開発を成功させるためのポイント

オフショア開発を成功させるためには、下記のポイントが重要です。

• 開発企業を慎重に選定する
• 詳細設計を日本で行う
• コミニュケーションを増やす
• 明確な意思表示を心がける
• 人に頼らず、仕組みに頼るという意識を持つ
• 大切な開発の仲間というマインドセット

開発企業を慎重に選定する

オフショア開発を成功させるためには、信頼できる発注先企業を選定するのが重要です。前述の失敗事例では、主に言語や文化・商習慣による影響を取り上げましたが、発注先が信頼できる企業であるかも影響していると思われます。

発注先の開発企業を選定する際には、次のことに注意してしっかりチェックしておきましょう。

• 開発見積もりが妥当か
• 会社の開発実績が豊富か
• エンジニアのレベルが期待通りか

それぞれ簡単に見ておきましょう。

開発見積もりが妥当か

開発見積もりについては、発注側で想定する工数や相場をあらかじめ押さえておいて、出てきた見積もりと比較しておきましょう。また、見積もりの根拠がしっかり検討されているかを見て、こちらの要件が正確に伝わっているかを確認しておきます。

会社の開発実績が豊富か

発注先として検討している企業の開発実績についても確認しておきたいところです。これまでの開発プロジェクトの内容や規模、業種、技術分野などを確認しておきましょう。

エンジニアのレベルが期待通りか

もし可能であれば、差支えのない範囲で過去に開発したプロジェクトのソースコードをサンプルで入手しておくと良いでしょう。または、簡単な仕様を提示してプロトタイプを構築してもらう手もあります。
エンジニアの実践力を評価できる情報を取得して、期待通りの成果を出してくれそうか確認しておきましょう。

また、ブリッジSEの能力の高さはオフショア開発の成否を左右する重要なポイントです。
ブリッジSEと面談するなどして、コミュニケーション能力と技術レベルもしっかり確認しておきましょう。

詳細設計を日本で行う

オフショア開発では前述したように、言語や文化・商習慣の違いがコミュニケーションに影響します。こちらから提示した仕様は、現地のブリッジSEや開発エンジニアに思ったより伝わっていないと考えた方が良いでしょう。

したがって、円滑なコミュニケーションが取れるまでは、日本国内で詳細設計まで実施するのが無難です。コミュニケーションが円滑になり、詳細設計の勘所もつかめるようになってきたら、様子を見て徐々に詳細設計も現地に任せるようにしていくと良いでしょう。

明確な意思表示を心がける

海外と日本では仕事の進め方も異なります。日本では事細かく伝えなくても、察してくれるコミュニケーション文化ですが、海外では明確に意思表示をしなければ伝わらないコミュニケーション文化が多いです。

日本から依頼する際には、

• なぜやるのか
• ゴールはどこか
• いつまでに必要なのか

を意識的に強調するようにしましょう。常に明確な意思を伝えることで、認識のずれを減らせるでしょう。

人に頼らず、仕組みに頼るという意識を持つ

これは国内でも言えることですが、その人でないと分からない俗人的な進め方では、継続的に高い品質のサービスを提供することは難しくなります。コーディング規約など、納品物で必ず守ってもらいたいことは、現地のブリッジSEと開発メンバーに背景を含めて伝えるとともに、作業終了前のチェック項目に盛り込むなど仕組みでカバーしましょう。

初めは効率が悪いと感じるかもしれませんが、数か月続けていくうちに以前よりも開発効率が改善されていくのが実感できるでしょう。仕組みづくりを進めていくことで日本と海外で共通の認識が醸成され、品質の目線がそろってきて手戻りが減るためです。

 大切な開発の仲間というマインドセットを持つ

最後に、オフショア開発に失敗したケースの多くで共通する原因は、「現地ベンダーやブリッジSEに丸投げしてしまった」ということです。開発を成功させるためには、社内の人間か否かということは関係なく、同じプロジェクトの仲間であるという意識が大切です。

初めは面倒に感じるかもしれませんが、大切な開発の仲間であることを意識しながら、開発の目的や背景・全体スケジュール・ルールを丁寧に説明して共通認識を育てていきましょう。そうすることで、徐々にスムーズなコミュニケーションを取ることができるようになります。

まとめ｜オフショア開発には「子会社化できるラボ型オフショア開発サービス」がおすすめ

この記事ではオフショア開発の失敗の理由と対策について説明してきました。
時間をかけて現地のエンジニアチームを育成しても、メンバーが入れ替わるとまた同じことの繰り返しなのではないかと感じる方も多いと思います。

そこで弊社では、オフショア開発のノウハウを蓄積し、中長期的なお客様のメリットも実現できるよう「子会社化できるラボ型オフショア開発サービス」をご用意しています。

ラボ型開発のご相談はWakka.incまで

伴走型システム開発・開発リソース強化ならオフショアラボ型開発。
Wakka Inc.はラボ型開発・海外法人支援で選ばれて10年。経験豊富なコンサルタントが、初めての海外進出でも手厚くサポートします。
日本国内と海外拠点の幅広い当社グループメンバーがあなたのチームの一員に。DevOpsを前提としたチーム編成でサービスグロースを強力に後押しします。まずはサービス資料からという方はこちらから。