LIGのくまこと久松です。
新規のお客様とお話ししていると「オフショア開発ってどうなんですか？」という話によくなります。
ふと自分自身の経験を振り返ってみると、過去6プロジェクトほど、オフショア開発会社へ依頼をしていたことに気づきました。依頼先の国も香港、フィリピン、ベトナムと多岐にわたっています。
もちろんオフショア開発が全てうまくいった訳ではなく、中には失敗してしまった例もあります。
そこで今回は、私が経験してきたオフショア開発の失敗事例や失敗した原因、成功に繋げるためのポイントについてお話をしたいと思います。
- 失敗を防ぐには会社選びが重要です
- オフショア開発で失敗をしないためには、実績のある会社を選ぶことが大前提。オフショア開発業界でも知名度が高く、安心して依頼できる会社を以下記事でまとめました！
>>オフショア開発におすすめの会社はこちら
※編集部注：2021年4月に公開された記事を再編集しました。
そもそもオフショア開発とは
そもそもオフショア開発とは、技術的な開発を海外の子会社や開発会社に委託することをいいます。
オフショア開発でプロジェクトを進めるときは、依頼側（日本）と開発先（海外）との間に、ブリッジSEと呼ばれるエンジニアが入るため、日本語で開発を進めることが可能です。開発先として選ばれる国は、主に日本との時差が少ない東南アジア諸国が多くなっています。
オフショア開発は文化や言語が違うメンバーと開発を進めることになるため、ミスコミュニケーションから生じるトラブルが起きやすいというデメリットがあります。
オフショア開発で実際にあった失敗事例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万円/月ほど跳ね上がり、何人もアサインするという判断が難しい状況でした。
同じ開発を進めるなら圧倒的にコストメリットのあるオフショア開発のほうが稟議が通りやすかったご時世だったのです。
まとめ
私自身のオフショア開発の失敗談と、そこから学んだ成功のポイントをご紹介いたしました。
とくに大切なのは以下の3つです。
- 現在進行系の実績を教えてもらう
- 自社の開発チームの一員に加わってもらう
- 体制を確認する
オフショア開発は、開発リソースを好きなタイミングで確保できるというメリットがある一方、認識の齟齬が生まれやすいというデメリットがあります。
オフショア開発のデメリットをカバーするために、今回紹介した失敗事例や成功のコツを参考にしてみてください。皆様のオフショア開発が成功に繋がる参考になれば幸いです。
以下の記事でオフショア開発の失敗事例・成功事例を紹介しています。あわせてご覧ください。
オフショア開発の成功事例・失敗事例｜進め方や開発のポイントを解説
Akemi
弊社LIGでは、新しいオフショア開発のかたちを提案しています
私たちは、ベトナムのホーチミンとフィリピンのセブ島にも拠点をもち、オフショア開発を推進する企業さまを支援しています。
すぐの実施を考えていない場合でも、オフショア開発に関するお悩みや課題を抱えられているなら、ぜひご相談してみませんか？
よくある質問
オフショア開発のメリット・デメリットを教えてください。
オフショア開発の最大のメリットは、開発リソースを好きなタイミングで確保できることです。IT人材が採用できない・教育できないといった課題があっても、すぐに必要な開発リソースが得られます。また、新規事業が転けた場合に生じる問題にも、対応できるというメリットがあります。
デメリットとしては、外注する分コストがかかることや、コミュニケーション齟齬が起きやすいという点です。結果的に品質が想定よりも悪いという事態に陥る可能性があります。
オフショア開発が失敗する理由は？
コミュニケーション齟齬の他にも、担当エンジニアが流動的であったり、ブリッジSEの日本語能力の問題などが失敗原因としてあります。しっかりと引き継ぎをおこなってくれるのか、日本語能力は問題ないかなど、事前に確認することで失敗を防ぎましょう。
オフショア開発を成功させるコツは？
まずは企業選定を慎重にすることです。実績を確認し、開発したいものが実現できそうなのか確認しましょう。いくら指示出しを注意を払っても、そもそも会社選びが間違っていれば失敗につながります。
また、オフショア開発先を下請け扱いせず、自社の開発チームの一員に加わってもらうというスタンスでいることも開発を成功させるポイントです。
「どの国にオフショア開発を委託すればいいのかわからない」「おすすめの国はどこか知りたい」という方は、以下よりオフショア開発で人気の５カ国とその特徴を無料でダウンロードいただけます。
関連記事
【2022年】オフショア開発の現状と開発先5カ国の特徴 いま「オフショア開発」に改めて目を向けてほしい理由 システム開発会社おすすめ18社｜大手・Web系など分野別で紹介 「オフショア開発、コミュニケーションが不安！」なあなたへ。新しい解決策を提案します。 オフショア開発の実情、実際にぶつかる課題とは。現地で働くディレクターが解説します！ フィリピンオフショア開発の実情と優良企業まとめ｜注意点も解説 オフショア開発の品質は低いって本当？現役ブリッジエンジニアが実体験をお話しします！
Koji Murata
Tomohiro Oyama
Michitoshi Kudo
キー坊
しげちゃん
しゅん
Natsuki
