オフショア開発のよくある失敗事例と成功するためのコツとは?

2021.05.20
中垣圭嗣
がっかりするビジネスマン
目次

はじめに

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

ただ、オフショア経験者の意見を聞いたり、ネット記事を調べたりすると、「オフショア開発は失敗するからやめておいた方がいい…」という意見もちらほら見受けられるので、
初めてのオフショア開発に対して高いハードルを感じてしまうのではないでしょうか。

そこで今回は、Wakka Inc.のベトナム拠点マネージャーの中垣が
初めてのオフショア開発でよくある失敗事例とその対策について説明していきます。

▼忙しい方向けに、サクッとわかるガイドブックも配布中▼

10分でわかる_ガイドブック_DL

オフショア開発とは

word cloud - offshoring

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

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

※オフショア開発の詳しい説明はWakkaブログのこちらの記事にまとめています。

よくある失敗事例

①納期が遅れてプロジェクトが進まない

オフショア開発で失敗したことがある経験者は、まず「納期遅延の多さ」を指摘することが多いです。

具体例としては、日々のデイリーで進捗を確認しており、現地ブリッジSEからはいつも「大丈夫」という回答が返ってくるので安心していたところ、
ずるずると数日くらい納期が遅延してしまい、遅れて出てきた納品物も思っていたものと違うというケースです。

そして遅れを取り返せないまま、各タスクの遅延や手戻りが続きプロジェクト全体が遅延してしまうという結果に。

これは考え方の違いについて相互理解が不足している場合に発生します。例えば、日本のように数時間の遅れも許さないという考え方もあれば、海外のように多少の遅れであれば大勢に影響はないので気にしないという考え方もあるからです。

その場合、日本と現地の考える「大丈夫」の定義が違いますので、認識のズレを埋められないままプロジェクト全体が遅延してしまうのです。

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

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

②コーディング規約が守られない

Programming code on a monitor.

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

さらに、ベンダーもコーディングルールの手直しはあまり前向きに取り合ってくれないので、すぐに国内開発に戻してしまったという結果に…。

このような失敗は、日本と同じ感覚でコーディング規約を渡してしまったり、テスト項目にコーディングルールのチェックを設けたりしていないプロジェクトで発生します。日本の開発では目的やメリットが曖昧でもルールがあれば守ってくれるということが大半だと思います。

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

このような失敗を防ぐためにはコーディング規約の「目的・メリットの明示」と「品質テストでの項目設定」を行いましょう。

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

また、後者については品質に対する意識は伝えてすぐに変わるものではありませんので、品質テスト項目にコーディング規約チェックを加えることで仕組みでもカバーすることを心がけましょう。

③現地エンジニアの稼働率が低い


単価が安いことに魅力を感じてオフショア開発を導入したのに、稼働率が低く思ったよりコストパフォーマンスが悪いという意見をよく聞きます。
このような失敗意見では「感覚論」と「タスク分配ミス」の要因が入り混じって発生しているケースが多いです。

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

しかしながら、1年間トータルの祝日の数で見ると日本の方が多いケースがほとんどです。年初に稼働率が下がるという感覚を抱きがちですが、
事前に現地の休み期間を考慮して開発スケジュールを組んでおくことで、効率よく開発をすすめることができるようになります。

また、「タスク分配ミス」について説明すると、オフショア開発は事前にエンジニアの工数を確保しておく契約形態となっていますので、
日本からのタスクが少ない場合は現地エンジニアのやることがなくなり費用対効果が悪くなります。

この場合は、定例などで定量的に工数を確認しておき、工数があまりそうな際には他のタスクも依頼するなどをしながら調整するようにしましょう。

オフショア開発を成功させるための対策

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


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

日本から依頼する際には、「なぜやるのか、ゴールは何か、いつまでに必要なのか」を意識的に強調するようにしましょう。

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


これは国内でも言えることですが、その人しか分からないという俗人的な進め方では、継続的に高い品質のサービスを作ることは難しくなります。

コーディング規約や納品物で絶対に守ってもらいたいと感じることは、現地のブリッジSEと開発メンバーに背景含めて伝えるだけではなく、作業終了前のチェック項目に盛り込むなど仕組みでカバーするようにしましょう。

初めは効率が悪いと感じるかもしれませんが、続けていくうちに日本と海外の品質の目線が揃ってきて手戻りが少なくなりますので、結果的に数ヶ月後には以前よりも効率が良くなるはずです。

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


最後にオフショア開発に失敗したケースの多くで共通する原因は、「現地ベンダーやブリッジSEに丸投げしてしまった」ということです。
開発を成功させるためには、社内の人間か否かということは関係なく、同じプロジェクトの仲間であるという意識が大切です。
初めは面倒に感じるかもしれませんが、大切な開発の仲間であることを意識しながら、開発の目的や背景・全体スケジュール・ルールを丁寧に説明して共通言語を作っていくことで、徐々にスムーズなコミュニケーションを取ることができるようになります。

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

この記事ではオフショア開発の失敗の理由と対策について説明してきました。

しかし、時間をかけて現地のエンジニアチームを育成しても、メンバーが入れ替わるとまた同じことの繰り返しなのではないかと感じる方も多いと思います。

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

このサービスでは、事前にオフショア開発に参画するメンバーを決めてから開発するのでノウハウが蓄積しやすく、さらに信頼関係ができたタイミングで貴社の子会社としてチームを移管させることが可能です。

中長期的な成長を目指す企業の皆様におすすめのサービスですので、興味がある方はまずはお気軽にWakka Incにお声がけください。

▼ラボ型開発がサクッとわかる資料、無料配布中!▼

10分でわかる_ガイドブック_DL
この記事を書いた人
中垣圭嗣

WebメディアでPGから管理職まで幅広く経験し、Wakka Inc.に参画。Wakka Inc.のオフショア開発拠点でラボマネジャーを担当し、2013年よりベトナムホーチミンシティに駐在中。最近では自粛生活のなかでベトナム語の勉強にハマっています。

  • ホーム
  • ブログ
  • オフショア開発のよくある失敗事例と成功するためのコツとは?
Contacts

Wakkaについて詳しく知りたい方はこちら