・この記事でわかること
・オフショア開発が失敗する主要原因は何か（委託開発の場合）
オフショア開発が始まって、既に30年近くが経ちますが、いまだに失敗事例が後を絶ちません。
もちろん、オフショア開発が当たり前のSI’erもたくさんあり、そこでは大きな失敗はほぼなくなっているのも事実です。
失敗事例が多いのは、最近はオフショア開発を行う企業のすそ野が広がったことがひとつの要因ではないでしょうか。
たとえばITベンチャー企業では、要員不足からオフショアを使う場合も多くなっています。オフショア開発に不慣れな企業では失敗するのも当り前です。
そこで今でも多発する、オフショア開発の主要な失敗原因を考えてみました。
いろいろな状況の案件があるので一概に議論することは難しいのですが、今後のオフショア開発をする上での参考になれば幸いです。
オフショア開発の概要をお知りになりたい方は、こちらの記事を参考にしてください。
オフショア開発の成功要因については以下の記事を参考にしてください。
検討の前提を確認する
前提が不明確な議論は不毛
最近、「オフショア開発がなぜ失敗するのか？」という記事がWeb上で散見されますが、ほとんどうわべだけの失敗要因しか見てないように感じます。たとえば以下のようなこと。
・文化・国民性の違いを考慮してない、など
こんなことはオフショアを使うときには当たり前に考慮すべき前提事項なので、これが原因なんて素人すぎて論外でしょう。このような反省をしている会社はオフショアを使ってはいけません。
また、ちょっと気になるのは、どのような立場・契約でオフショアを使っているのか、前提の記載がないのでよくわからない記事が多い、というのが実情です。契約形態により責任も違うので、前提を明らかにすべきです。
これではあまり参考にならないと思うのですが。。。
そこで、当記事では、オフショア開発のパターン（含む契約）を明確にして、具体的に失敗要因を検討していきたいと思います。
前提とするオフショア開発方式のパターン
当記事では最も多いパターンである、日本の企業が現地のオフショア開発企業へ業務委託（請負契約）する場合を考えます。
一般的にオフショア開発をする場合のパターンは以下の３種類と言われています。
②オフショア開発企業への業務委託
※日系、非日系があるが通常は日系を利用する
③ラボ型開発（要員確保型）
今回は「②オフショア開発企業への業務委託」で考えるということです。
また、委託する開発業務はWeb制作（ホームページ制作）ではなく、本格的なプログラム開発を想定します。（数十人月程度以上の規模）
※参考の図：オフショア開発パターン
開発の失敗とは何か？
オフショア開発が失敗した、とは何をもって「失敗」というかも最初に明確にすべきです。
ここでは「業務委託開発（請負）」を想定しますので、以下の状態を失敗と定義します。
追加費用を請求された（追加費用で揉めた）
受託企業で赤字案件になった
（コンティンジェンシー費用以上に費用が増大）
当初予定期日までに開発が終わらなかった
（結果としての分割リリース対応も含む）
当初決めた品質基準を満たせなかった
（機能が未充足なども含む）
リリース後、バグだらけで業務が回らない
委託企業側の負荷が想定より大きくて不満大
何でも仕様変更（有料）と言われて揉めた
オフショア開発が失敗する主要な原因
業務委託開発の場合、オフショア開発が失敗する原因は多々ありますが、大きく分けて以下の４つが主要な原因だと考えられます。
・オフショア企業のマネジメント力の問題
・オフショア企業の開発力の問題
・委託側（顧客）の問題（オフショアに限らないが）
以下、具体的に見ていきます。
契約自体がバグっている（契約の失敗）
オフショア開発が失敗する最大の要因は、「契約問題」と言って過言ではないと思います。
しかし、自社で確実にできる案件だけを獲得していただけでは、利益がでないし、社員のスキル育成にもならないため、無理して案件獲得する場合があります。
また、委託側もオフショア開発の理解が不十分で、受託側に無理を押し付けるなどが見受けられます。
代表的な失敗要因は以下となるでしょう。
・仕様が不明確なまま契約する
仕様が不明確なまま契約してしまう、ということはよくあることです。
契約を取るためにはある程度仕方のないことなのですが、作業スコープが明確でないのに請負契約になるので、開発時に顧客が想定外のことを言い出しても、元々の仕様なのか仕様変更なのか分かりません。通常は元々の仕様と言うことで作業スコープが増大します。
これにより、工数・期間が増えることになります。
・見積りミス（契約金額、開発期間過少）
新規案件では見積りミスをすることは良くあります。
仕様の確定度合いにより工数や開発期間のバッファは見込みますが、契約獲得のプレッシャーや顧客側の条件提示（顧客の協力体制構築など）により、見積工数を少なく見積もることもでてきます。見積もる人のスキル不足で、単純な見積りミスもあります（特に現地エンジニアの見積り）。
契約時の大きな見積りミスは致命的です。
・開発要員・スキルが揃わない
オフショア開発企業ではよくあることですが、要員や開発スキルが不十分でも契約を獲得することがあります。
これは、「契約がとれてから必要な人を採用すればよい」ということで、IT人材の流動市場があることが前提になっています。
ただ、特殊なスキルだったり、必要スキル要員への応募が少なかったりして、必要な時期までに要員が揃わないこともでてきます。
場合によっては、高額なスポット人材に頼らざるを得ず割高になることもあります。
・そもそも無理な契約である
そもそも開発が無理な契約というのもあります。
例えば、開発量に比べて開発期間が短すぎる、という場合。300人月の新規開発案件(CD/UT）を3ヵ月というのは、仕様書が完璧でも相当タフですし、完璧な準備をしても想定外のトラブルが発生するものです。
そのほかにも、特殊なスキル要員が大量に必要とか、開発が他社に大きく依存する、など最初から大きなリスクがある場合が考えられます。
これらのリスクは、受託側の企業でリスクが分かっている場合と分かっていない場合の両方があります。
分かっている場合は、経営判断でGOサインを出すものが多いです。わかっていないのは、受託会社としての力量がないということですね。
オフショア企業のマネジメント力の問題
次に、契約自体は問題ないが、オフショア企業のマネジメント力に問題がって、開発が失敗することも良くある話です。
※このようなオフショア企業もあるという話です。全部がそうだと言っていませんので、ご理解いただきたく。
・コミュニケーション力の不足（ステークホルダー管理不足）
オフショア開発の場合、一般的に日本語のできるブリッジSEを日本側と現地の間においてコミュニケーションのハブにすることが多いです。
このブリッジSEによる各種調整ができずに問題が大きくなることはよくある話です。確かにブリッジSEにITスキルがなくてうまく伝わらないなど、本人に問題がある場合が多いのは事実。
しかし、本当の問題は仕様があいまいである、開発エンジニアが不足して問題を振る人がいない、などのことも多々あり根本原因を追究すべき場合も少なくありません。
・仕様が膨らむ（スコープマネジメントができない）
開発を進めるうちに仕様が膨らむということはよくある話です。
この問題をブリッジSEの調整能力や顧客側担当者の問題だと指摘する場合もありますが、これは変更管理の仕組みとして契約時に取り決めておく性質のものでしょう。
本来の仕様であるのか、仕様変更であるかはの判断が難しい場合はよくあります。
・キーメンバーが退職する
開発のキーメンバーが突然退職する、というのはオフショア特有の良くある話です。
これは防ぐことは非常に難しく、オフショア企業のマネジメントしては、想定しておくしかありません。
開発委託側としても、オフショア開発はそういうものであると、リスクとして見込んでおくことが必要でしょう。
※金銭的な問題ではなく、開発が遅れることによる機会損失を見込んでおく、ということです。
・正確な管理ができていない（進捗、品質）
組織として未熟なオフショア開発企業によくあることです。
週次進捗会議で「先週オンスケだったのに、いきなり1ヵ月の遅れ」になる報告が当たり前にされたりします。
オフショア開発会社の現地人のPMやマネージャーが現物確認をせず、開発担当者のヒヤリングだけで報告資料を作るとこのような事象が発生します。
また、進捗や品質について計数管理でなく感覚で報告してくることも多く非常に危険です。
このような報告がおかしいと思わないマネージャーもいたりするので困ったものです。
・レビューができていない（仕様、コード、テスト）
前項と同じく、組織として未熟なオフショア開発企業によくあることです。
開発会社内で担当者に丸投げをし、担当者が完了したというのでそのまま顧客宛てに成果物を提出する、というのもたまに見かけます。
もちろん、結果はボロボロで委託企業は大激怒、というパターン。
社内規定でレビュープロセスを定義しているが、PMやマネージャーがレビューをしない、指示していない、という場合が多いです。
オフショア企業の開発力の問題
３番目の問題として、開発力そのものの問題があります。
組織として開発スキルが備わっている会社なら良いのですが、多くの場合スキルは個々のエンジニアに依存しているのが実情です。
※開発力のあるオフショア企業もたくさんあります。（為念）
・開発スキルがない・低い
まともな開発スキルがない、低い、という根本的な問題を抱える会社も中には存在します。
人の入れ替わりが激しい場合、組織としてスキル蓄積ができないので、万年低スキルの状態になるようです。
結果として、営業ベースでは「何でもできます！」とは言うもものの、フタをあければ全く成果物が出てこない、出てきたらボロボロ、というのは良くある話です。
たまに”できる”エンジニアが担当して”あたり”を引く場合もあります。
スキルは必要な時に揃えれば（募集すれば）良い、という考えかたが主流なので、ある意味仕方のないことかもしれません。
・レビュースキルがない・低い
現地のエンジニアは何も言わなければ、成果物に対するレビューなどしません。作りっぱなしです。テストも自己流で実施して終わりです。
エンジニアの個人の考えとして「レビューはするもの」という考えは基本的にありません。まあ、日本のベンチャー企業でもそういうところは少なくないと聞きますが。
レビューも大事な開発スキルですが、まず物ができることが評価の物差しなので当然のことといえます。
もちろんレビューのための工数など見積りに入っていることは少ないです。安かろう、悪かろうの典型になります。
・開発方法論・標準化がない
成果物の品質が安定しないという根本原因は、「組織としての開発方法論・標準化がない」ということに尽きると思います。
いわゆる、担当者（エンジニア任せ）ということです。中小のオフショア企業ではよくあることだと思います。
このような状況が改善されないのは、最近の開発フレームワークなどを使えばそれほど変なものは出来ないこと、案件そのものが比較的易しいものが多くなっていることで、致命的な問題にならないだけのような気がします。
こういうところが複雑な案件を担当したら、一発でアウト、ということになりかねません。
委託側（顧客）の問題（オフショアに限らないが）
オフショア開発が失敗する大きな要因として、委託（顧客）側の問題も大きいと思います。
以前は委託側もシステム開発のプロが発注の中心でしたが、最近はユーザー部門などの人が発注の中心になる場合も多くなっています。（クラウドソーシングの案件などはその典型でしょう。規模は違いますが）
丸投げの請負開発として委託する場合がほとんどなので、安易に考えている場合が多いように思います。
・オフショア会社の選定ミス
まず、委託側の問題として、オフショア会社の選定を間違っている場合があります。
スキルの評価を十分せず、価格だけで選定してしまうことはよくある話です。また、会社により得意・不得意の分野は当然存在します。
請負契約だからと安易に考えず、会社としてのスキルをキチンと評価しないと、安物買いの銭失いになりかねません。
・日本人技術者と同じように対応してくれると思っている
オフショア会社側の売り方も問題なのですが、日本のエンジニアと同じようにオフショア側も対応してくれると考えてしまうことは間違いです。
海外のエンジニアは言ったことしかやりません。日本のエンジニアのように、常識を働かすことはありえません。発注者側の人が良く言う言葉に「こんなの常識だろう！」というのがありますが、もちろん通用しません。
日本人のブリッジSEも常識は持ち合わせていないと思ったほうが良いです。
まあ、一回痛い目に合えばすぐに分かることですが、懲りずに何回もごり押ししてくるところもあるようなので困ったものです。
・仕様を確定しない（できない）
仕様を確定しない（できない）ことは、オフショア開発以外でも良くある話です。
一般的には、仕様確定の期限を切るとか、仕様確定のための工数を別にいただくとかの対応を取りますが、委託側（顧客）と揉める原因になることが多いです。
一番困るのは、「よしなに」と言っておきながら、いざ出来上がるとこんなのは嫌だ、とか言い出すことでしょう。
このような顧客にあうと、工数は膨らみ開発期間は伸びます。
・開発を丸投げ、あとは無責任な態度
「仕様を確定しない」というのと似ていますが、これもよくあるパターンです。
請負契約なので、発注すればあとは自動的に出来てくる、と思っているようです。
忙しいということで、仕様の調整・確認にも非協力的で、合意がとれぬまま開発が進み、後でクレームがついて手戻り発生というのがパターンです。
契約書や提案書に協力して欲しいことを入れて、きちんと面前で説明することが重要でしょう。
まとめ
さて皆さん、いかがでしたか？
「【なるほど！】なぜオフショア開発は失敗するのか？（委託開発の場合）」をご紹介しました。オフショア開発を理解する上での参考になりましたでしょうか。
今回は「オフショア開発の失敗」に焦点を当てたため、オフショア開発に対して非常にネガティブなことばかりになりました。
しかし、失敗事例もあれば、当たり前のようにオフショアを利用して成果を上げているところもたくさんあるのも事実です。
近年のシステム開発では、価格や要員調達面でオフショア開発の利用は必須要件となっています。
つまり、これからのシステム開発では、オフショア開発利用にかかる先達の失敗事例を正しく学び、うまく活用していくことが当たり前に求められるということでしょう。
オフショア開発の成功要因についてはこちらの記事を参考にしてください。
なお最後に、オフショア企業にも開発力があり、しっかりしているところも多いことを申し添えておきます（為念）。
この記事がオフショア開発に携わる方々の少しでもお役に立てれば幸いです。
※セブでのオフショア関連のご相談はいつでもお受けいたしておりますので、当ブログのお問合せよりご連絡いただきたく。
また、、以下のような新しいオフショア開発サービスも始めました。ピンポイントでオフショア技術者を採用するという新し考え方です。一考に値するかと考えます。
では、明るく、楽しく、前向きに、毎日をお過ごしください。
コメント