海外事業部長の岩田です。
お客様とお話ししていると「オフショア開発ってどうなんですか？」とよく聞かれます。オフショア開発は文化や言語が違うメンバーと開発を進めるため、ミスコミュニケーションから生じるトラブルが起きやすく、失敗しないか不安に感じる人も多いのだと思います。
ふと自分自身の経験を振り返ってみても、オフショア開発会社で失敗してしまったことがありました。
そこで今回は、私が経験してきたオフショア開発の失敗事例やその原因、成功に繋げるためのポイントを紹介したいと思います。依頼先の国も香港、フィリピン、ベトナムと多岐にわたっていますので、不安を感じている方の手助けになれば幸いです。
オフショア開発ができるパートナー企業を探しているけれど、現地の動向を含め信頼できる情報が欲しいですよね。はじめての相談相手として、2015年からオフショア開発をおこなっている弊社「LIG」はいかがですか？
- 100名以上の海外人材による開発体制
- 業界歴10年以上のベテラン国内PMが伴走
- ノーコード開発に対応し、低単価・高品質を実現
貴社のご要望やコスト・機能面の具体的な話など、お気軽にご相談ください。
※編集部注：2021年4月に公開された記事を再編集しました。
オフショア開発で実際にあった失敗事例5選
私自身これまでオフショア開発において複数のプロジェクトを発注しており、いろいろな失敗を経験してきました。その一例をお話しします。
失敗事例①品質がよくない
想定通り動かないプログラム、可読性の低いソースコード……。よくあるオフショア開発の失敗談ですが私も遭遇しました。
品質がよくないと納品後や内製化したときにも引きずります。単に受け入れが大変というだけではありません。オフショアという「遠くの顔も知らない誰かが作った出来の良くないソースコード」を見たとき、ほとんどの内製化担当エンジニアは他責の姿勢になります。
バグが出れば「オフショア開発先が悪い」、作業が遅くなれば「オフショア開発先が悪い」、複雑な仕様を投げれば「オフショア開発先のせいでできない」と主張します。
経験上、リプレイスなどで完全にソースコードが入れ替わるまで他責の傾向は続きます。反対に顔が見える古株社員が書いたソースコードだとそこまでボロクソには言いません。
また、品質の中でソースコード以上に苦悩していたものがあります。それは日本語管理画面です。画面イメージを提供しても意味が通じないので、細かく指示をする必要があります。
こんなとき、個人的には「日本語というのはマイノリティ言語なのだな」としんみりとした気持ちになっていました。
失敗事例②ブリッジSEの当たり外れが大きい
オフショア開発拠点と顧客の橋渡しであるブリッジSEですが、日本人が担当するケースと、オフショア開発先の国籍の人が担当するケースとがあります。
このブリッジSEについても2パターンの失敗がありました。
1つ目はブリッジSEの日本語能力の失敗。細かなニュアンスが伝わっていなくて違うものができたりしていました。
オフショア開発先として選ばれる国は、多くの場合ベトナムやフィリピンなどの東南諸国です。これらの国は、日本語を流暢に話せる人材は少なく、言語の壁はどうしても付き纏います。
2つ目はオフショア拠点の技術力不足をブリッジSEが被っているケース。こちらはかなり根深く、顧客としては「安くて品質が高い」と思って満足していても、台所事情は問題大アリなことも。1人の優秀なエンジニアが依頼された人月分のフリをしながらアウトプットを出していたりするとかなり悲惨な構図となります。
とあるオフショア企業様ではHTML/CSSのみ書ける人材が集まっていて、他はすべて1人の担当ブリッジSEが書いていたというところもありました。
この方のアサイン割合が先方都合で変わり、品質がみるみる落ちていったので渋々別の拠点を探したことがありました。
失敗事例③「よしなに」が通じず、違うものができる
「ここはよしなに」「いい感じにしておいて」「いつもみたいな感じで」
そこまで優先順位が高くない機能の場合、このように伝えてしまうことはあるのではないでしょうか。ただこれはあくまでも温度感が共有できている場合のみです。細かいところまで詰めておかないと、「どうしてこうなった」というものができあがります。
失敗事例④メンバーが流動的で知見が残らない
ある時点まで問題のなかったアウトプットについて、急に可読性が落ちたり、納品が遅くなったりするケースがありました。よくよくヒアリングをすると、実装を担当するメンバーがオフショア会社の都合や急な退職でしれっと変わっていたというものでした。
ある程度ボリュームのある実装物の場合、どうしても慣れが必要です。また、ソースコードにしてもそのプロジェクトのお作法が多かれ少なかれ存在します。
失敗事例⑤人件費の高騰、為替の変動
発展国の場合、急に経済が発展して人件費が上昇するケースがあります。また、急な円安など為替の影響も馬鹿にはできません。「品質への満足度がそれなりで日本で自社で手直しすることを加味しても安い」くらいの温度感で発注していたプロジェクトがあったのですが、数年前にこの両方が起きたことがあります。
「それなら採用コストを割いてでも自社でやろう」という判断をし、オフショア開発から撤退しました。
ここまでが私が経験した、オフショア開発の失敗事例です。さまざまな失敗を経験しましたが、とはいえリソース不足解消や社外に専属のチームを構築できるなど、オフショア開発には数多くのメリットがあります。このような失敗を踏まえ、しっかりと対策をとればより有益にオフショア開発ができるようになるはずです。
オフショア開発を成功させるための6つのポイント
ここまで紹介した失敗事例や成功したプロジェクトの事例から、オフショア開発で失敗しないポイントやコツをまとめています。
企業選定時に実績を確認する
オフショア開発を依頼する企業の選定方法も成功に繋がるポイントです。私の場合、選定時には見せても問題のないソースコードを提出してもらい、選定の参考にしていました。また、現在進行系の実績について具体的にどの工程から、どの部分を、どのくらいの期間で担当したのか教えてもらうようにしましょう。自ずと任せられそうなスキル感が見えてきます。
下請け扱いせず、自社の開発チームの一員に加わってもらう
オフショア開発に失敗するプロジェクトは、開発難易度の低い末端の作業をちょろっと投げるという下請け扱いをしている傾向にあります。
軽作業の下請けではなく、開発チームの輪の中に入ってもらいましょう。ここを線引してくるオフショア企業は体制に難があるのかもしれません。アジャイル開発を採用している場合は尚更です。
パートナーシップを結ぶ、同じ開発チームだと思ってオフショア開発の輪に巻き込むのが重要です。コーディング規約を提供する、ブリッジSEとともにコードレビューをして品質に共通認識を持つ。投げっぱなしにしないことが第一歩だと考えています。
ドキュメント化と共有を徹底する
プロジェクト管理ツール、ドキュメント管理ツールの類はオフショア開発先に共有しましょう。社内にある知見も共有し、そのうえでツールを共有し随時確認できるような環境にすることをおすすめします。
失敗するプロジェクトは（オフショア開発に限ったものではありませんが）納品前の確認スパンが短く、後戻りできないほど時間が経ったときにレビューしたら違うものができていた、という「あるある」があります。
詳細設計まで日本で実施する
「よしなに」の言語化は必須です。「よしなに」が通じる状態、概ねプロジェクト開始から1年くらい経過し円滑にコミュニケーションが取れるまでは、日本で詳細設計まで詰めてからブリッジSEに依頼するという方法の方が失敗を防げるでしょう。
これは何も言語や文化に関係するものばかりとも限りません。たとえば開発者と利用者でディスプレイサイズが違う場合、同じ管理画面を見ている場合であっても片方には十分に見えても、もう片方には小さすぎたり大きすぎたり使いにくく感じるケースがあります。
対象ブラウザ、ディスプレイ解像度の指定、スマートフォンのバージョン、iPadの画面の大きさなど、非機能要件も序盤に調整しましょう。
担当メンバーを固定してもらう
体制や人員はできる限り固定、やむを得ない場合は事前告知の上でしっかりと引き継ぎをしてくれる、こうした企業をパートナーとして選びたいものです。直接話すことはなくてもビデオ会議などで挨拶をするだけでも「この人が担当してくれるのか」と安心感に繋がります。
プロジェクトに関する知識の蓄積は財産です。半年以上継続していくと開発者も慣れてきてスピードアップに繋がり、コストメリットを感じられます。
コスト計算を継続して実施する
昨今流行している「DX」の中には「内製化」というキーワードがあります。しかし少子化や、転職し放題のエンジニア経験者市場を鑑みるとなんでもかんでも内製化するというのは無理があります。何を内製し、何を外に出すかを踏まえ、内製をする場合と外注をする場合のコストを絶えずモニタリングする必要があります。
会社選びもかなり重要
わざわざ書くまでもないことですが、やはり開発先のスキルがプロジェクトの成功に直結します。特に前述に述べたように、ブリッジSEのスキルはかなり重要です。
こちらで紹介しているオフショア開発会社であれば、スキルの高いメンバーをアサインしてくれると思いますが、それ以外の会社に依頼する際は、メンバーのスキルを必ず確認してください。営業担当だけでなく、実際にプロジェクトを進めるメンバーを事前にコミュニケーションをとることをおすすめします。
失敗しても、オフショア開発を選ぶべき理由
さまざまな失敗もあったオフショア開発ですが、それをもってしてもメリットが大きいと感じていました。なぜ私がオフショア開発を選んだのか、その理由についてお話しておきます。
私がこれまでオフショアに依頼していたシステムは、広告システム、基幹システム、営業管理システム、勤怠システムといったBtoBシステムから、リワードのようなBtoC向けサービスまで多岐に渡っています。
当時の所属組織では正社員エンジニアによる内製化も進めていましたが、以下の理由でオフショアへの発注を行っていました。
IT人材の採用難
私が所属していたある企業は営業職中心の会社だったので、エンジニア職が少なく開発リソースが限定的でした。エンジニアが少ないということはエンジニア組織をスケールするノウハウもないということです。
採用ノウハウもなければ教育ノウハウもない。これらのノウハウを貯めている途中であっても事業は進み続けます。
限られたエンジニア正社員を、主力事業にも新規事業にも割り当てるというのは現実的ではありません。
当座の開発を実施するためにも、外部のリソースを頼る選択肢としてオフショア開発がありました。
正社員採用ではなく投資として位置づけられる
新規事業に正社員エンジニアを配属すると、当の本人たちは0-1ができると喜ぶのですが、事業が転けた場合に2つの問題に当たります。1つ目は再配属をどうするかということ。
再配属先が存在しない場合、あるいは技術セットが再配属先に合致しないような場合は悲劇的です。
2つ目は新規事業に集中した正社員に事業継続断念を申し入れた場合、かなりの割合で退職してしまうという傾向です。
これらを鑑みると、当たるかどうかわからない新規事業に対し、最初から正社員エンジニアをアサインせずに外注するという選択肢には合理性があります。経理上も投資として扱えますしね。
フリーランスの単価高騰
オフショア開発が注目され始めた2010年代前半は日本はソーシャルバブル真っ只中。LAMPエンジニアの採用も一筋縄ではいきませんでした。LAMPフリーランスの単価が1～2年程度の間に相場が20万円/月ほど跳ね上がり、何人もアサインするという判断が難しい状況でした。
同じ開発を進めるなら圧倒的にコストメリットのあるオフショア開発のほうが稟議が通りやすかったご時世だったのです。
このような理由から、私はオフショア開発を選んでいました。特にIT人材の採用難については、2024年現在でも問題視されており、今後ますますその傾向が強まると予想されています。
また、東南諸国へオフショア開発拠点をもつのは日系企業だけではありません。つまり、現地のエンジニアが日系企業に魅力を感じなくなれば、今後、現在の日本と同じようにエンジニア不足に陥る可能性もあります。
今のうちに海外に自社の開発チームを作るという意味でも、オフショア開発はおすすめです。
まとめ
私自身のオフショア開発の失敗談と、そこから学んだ成功のポイントをご紹介いたしました。
とくに大切なのは以下の3つです。
- 現在進行系の実績を教えてもらう
- 自社の開発チームの一員に加わってもらう
- 体制を確認する
オフショア開発は、開発リソースを好きなタイミングで確保できるというメリットがある一方、認識の齟齬が生まれやすいというデメリットがあります。
オフショア開発のデメリットをカバーするために、今回紹介した失敗事例や成功のコツを参考にしてみてください。皆様のオフショア開発が成功に繋がる参考になれば幸いです。
以下の記事でオフショア開発の失敗事例・成功事例を紹介しています。あわせてご覧ください。
オフショア開発の成功事例-失敗例や進め方のポイントも解説
Noriaki Iwata
- コミュニケーションは英語じゃないとダメ？
- コストが低いというけど品質は大丈夫？
オフショア開発について、こんな悩みをお持ちの方は弊社「LIG」にご相談ください。
- 国内のベテランPMが窓口となるため日本語でOK
- ノーコード開発を活用して低単価×高品質を実現
上記のような強みを活かし、貴社に最適なご提案をさせていただきます。見積もりのご相談など、お気軽にご連絡ください。
よくある質問
オフショア開発のメリット・デメリットを教えてください。
オフショア開発の最大のメリットは、開発リソースを好きなタイミングで確保できることです。IT人材が採用できない・教育できないといった課題があっても、すぐに必要な開発リソースが得られます。また、新規事業が転けた場合に生じる問題にも、対応できるというメリットがあります。
デメリットとしては、外注する分コストがかかることや、コミュニケーション齟齬が起きやすいという点です。結果的に品質が想定よりも悪いという事態に陥る可能性があります。
オフショア開発が失敗する理由は？
コミュニケーション齟齬の他にも、担当エンジニアが流動的であったり、ブリッジSEの日本語能力の問題などが失敗原因としてあります。しっかりと引き継ぎをおこなってくれるのか、日本語能力は問題ないかなど、事前に確認することで失敗を防ぎましょう。
オフショア開発を成功させるコツは？
まずは企業選定を慎重にすることです。実績を確認し、開発したいものが実現できそうなのか確認しましょう。いくら指示出しを注意を払っても、そもそも会社選びが間違っていれば失敗につながります。
また、オフショア開発先を下請け扱いせず、自社の開発チームの一員に加わってもらうというスタンスでいることも開発を成功させるポイントです。
関連記事
【2024年】オフショア開発の現状と開発先5カ国の最新動向 いま「オフショア開発」に改めて目を向けてほしい理由 システム開発会社おすすめ20社を目的別で比較【2025最新】 オフショア開発はコミュニケーションが不安！プロが解決策を提案 オフショア開発の実情、実際にぶつかる課題とは。現地で働くディレクターが解説します！ 【2025】フィリピンオフショア開発の実情とおすすめ開発会社 オフショア開発の品質は低いって本当？現役ブリッジエンジニアが実体験をお話しします！
Koji Murata
Tomohiro Oyama
Michitoshi Kudo
キー坊
しげちゃん
Noriaki Iwata
山口 菜月
