オフショア開発は、今や日本のIT業界になくてはならない開発手法となりました。
多くのシステム開発が、このオフショア開発によって作られていますが、一方で
「失敗しているプロジェクトもある」
ということを知っておくべきでしょう。
コスト面をはじめとして、非常に多くのメリットがあるオフショア開発ですが、それでも失敗や問題点がないわけではありません。
これからオフショア開発を検討する企業様に関しては、こういった過去の失敗実績や問題点をしっかりと理解した上で、オフショア開発を選んで頂きたいと思っています。
オフショア開発では失敗・問題点が多い？
オフショア開発は、実はプロジェクトとして失敗している事も多い開発手法です。
原因はいくつかありますが、やはり国内の企業と海外の企業では、様々な違いがあり、ビジネスとして成立させることが非常に難しい事が大きな要因となっています。
例えば、日本の市場や労働環境、法律を知っていなければ、その会社に取ってベストなシステムを作ることはできません。
また、働いている人同士のコミュニケーションの難しさや、スキルのミスマッチなども影響し、プロジェクトに失敗する可能性があるのがオフショア開発なのです。
オフショア開発における問題点・失敗10選
では、具体的にオフショア開発における問題点・失敗の例を挙げていきたいと思います。
現地とのコミュニケーションが取りにくい
失敗・問題点の1つ目は、「現地のエンジニアとのコミュニケーションが取りにくい」という点です。
これは、物理的に会うことが難しい点と、言語の壁の2つの意味があります。
どちらも、コミュニケーションを取る上では大きな障害となります。
どんなプロジェクトでも、コミュニケーション無しに成功することはできません。
そのため、このコミュニケーションが上手くいかないことは、失敗の原因となるのです。
期待した品質が得られなかった
次の失敗・問題点は、「期待した品質のシステムにならなかった」という問題です。
システム開発において、品質の問題は国内でもあります。
しかし、オフショア開発では国内以上に、スキルレベルが把握しにくく、開発難度とスキルが合わない事もあります。
全体の金額は安いものの、結果修正などで損をするというプロジェクトも存在します。
文化の違いを理解できない
次に、「文化の違い」による失敗です。
例えば、日本では納期に対して
「残業してでも完成させる」
というのが一般的な考え方です。
しかし、個人のパフォーマンスが下がることや、深夜手当などの経費面を考えると、本来は
「納期を伸ばす」
という選択の方が正しい場面もあるでしょう。
このような「一般的な考え方」は、国や文化によって異なります。
他にも、仕事を第一優先する日本に対して、海外では
「軽度の病気でもしっかりと有給をとって体調管理を優先する」
という所もあります。
こういった文化の違いで、思ったよりも進捗が進まなかったり、現地の人とトラブルになる事もあるようです。
間接的なコストがかかりすぎて赤字
続いての失敗・問題点は、「間接的なコスト」の影響です。
オフショア開発において、多くの失敗を経験している企業ほど、
・ブリッジSE
・QAエンジニア
・日本人ITコンサルタント
などの職種をプロジェクトに参加させる事が多いです。
前述した品質の担保や、現地とのコミュニケーションの問題を回避するために、適切な職種や役割を置くことがあるのです。
しかし、そうすることで失敗は避けられる反面、コストが上がります。
結果として、
「思っていたほど安くない」
という失敗もあります。
通常は見積もりの段階でそういった費用も記載されていますが、仕様が固まらないままに契約をして、その後要望が増えて追加見積もり・・・というケースもあり、そういった場合に失敗するケースが多いようです。
モチベーションを保てない
次に、「モチベーションが保てない」という失敗です。
これは、過度な要望が続くなどで起こる可能性があります。
例えば、月に40万円で海外のエンジニアを雇っていたとします。
それが、昨今の円安で月の支払いが60万円になった場合。
多くの人は、
「金額が上がるのは仕方ないけど、その分多くのことをしてもらう」
という意識が働くでしょう。
しかし、為替による影響の場合には、現地の人からすると給料は変わりません。
ということは、同じ給料なのに、求められる量や質だけが上がることになります。
この状態が続けば、モチベーションが続かないのも納得でしょう。
特に長期のプロジェクトほど、外的要因の影響を受けやすく、またモチベーションの維持そのものが難しくなります。
契約内容が明確ではない
会社やプロジェクトによっては、契約内容がしっかりと明記されていない場合があります。
この場合も、後々トラブルになってプロジェクトが失敗する可能性があります。
特に、前述した品質の面に関しても、
「どのくらいの期間は、致命的なバグの修正を保証するか」
など、しっかりと契約内容に含める必要があります。
ドキュメント類の言語の問題
続いての失敗・問題点は「ドキュメント」に関してです。
オフショア開発では、開発を依頼する側と、開発する側で言語が異なります。
そのため、国内の開発では問題にならない「ドキュメントの言語の問題」が生じる可能性があります。
例えば、難しい日本語で書かれた設計書を、現地のエンジニアがきちんと理解できなかった場合。
仕様と違ったものが上がってくる可能性は十分にあります。
他にも、議事録なども言語が違えば誤解の可能性が増えますし、理解に時間もかかります。
かといって、複数の言語でドキュメントを作成していくのは時間がかかります。
このように、ドキュメントにおける言語の問題は、失敗の大きな要因になります。
インフラの問題
次にインフラによる失敗です。
日本では、常に電気が通っていて、常にネットが繋がっている環境で仕事をするのが当たり前です。
しかし、それは日本のインフラ企業の努力の結果でもあります。
国や地域によっては、これらのインフラが不安定で、思うように仕事が進まない事もあります。
同じ国でも、地方と都会の格差が日本よりも大きい所はいくらでもあります。
そのため、ネット回線が遅くて、資料のアップロード・ダウンロードだけでも時間がかかる・・・というような問題も起こり得ます。
それはそのまま作業効率にも影響を及ぼし、失敗の可能性が出てきてしまうのです。
時差などの物理的な差
次の失敗は「時差」などの物理的な差による影響です。
例えば時差が4時間あれば、業務時間が同じ日中の9〜18時だったとしても、連絡が取れる時間帯が4時間しか無い事になります。
また、物理的に距離が離れているから
「ちょっと現地でトラブルになったから、知見のある人が現場に行ってすぐ解決する」
などの方法を取ることができません。
このような物理的な距離の影響は少なからずあります。
依頼先の国の急激な経済成長
次に、依頼先の国の急激な経済成長による失敗です。
依頼先の国が急激に成長すると、当然現地のエンジニアの給料も上げざるを得ません。
ということは、単価を上げなければ、技術力のないエンジニアに替えられてしまう危険性があります。
例えばアメリカでは直近10年の平均昇給率は3％程度と言われています。
仮に40万円のエンジニアが3年のプロジェクトをこなす際に、年3％昇給していくと、3年後には4万円ほど単価が高くなる計算になります。
場合によっては、年間10％上がる年もあるでしょう。
特にオフショアでメインになる国は、まだまだ発展途上国ですから、急激な変化が起こりやすいとも言えます。
一方で、日本は給料が上がらない時期が続いており、会社の利益額が上がらない企業も多いでしょう。
その中で、外注費用だけが急激に増えてしまうことは、プロジェクトそのものの失敗にも繋がります。
オフショア開発成功のポイント
さて、ここまでオフショア開発で起こりうる失敗を10個挙げてきましたが、オフショア開発を成功させるには、どのようなものが必要になるのでしょうか。
ヒアリング力
1つ目は、依頼をする企業そのもののヒアリング力です。
前述したような失敗の多くは
「しっかりとしたヒアリング」
で、事前に情報を整理することで解決する事が多いです。
例えば設計書なども、細かくヒアリングして詳細な部分を記載しておけば、誤解は生まれにくいです。
ヒアリング力が高ければ、後から要望が出てきたり、仕様の変更も少なくなるため、追加費用もかかりにくくなります。
このように、高いヒアリング力を持つ企業に依頼することで、失敗の可能性は小さくなります。
プロジェクトマネジメント力
次に、依頼する会社のプロジェクトマネジメント力です。
オフショア開発は、国内での開発に比べて、いろいろな職種の人を入れることが多いことは前述しました。
そのため、プロジェクトの人数自体が国内開発よりも増えるケースが多いです。
人数が多いほど、プロジェクトマネジメント力が必要となります。
高速のPDCAサイクル
次に、高速でPDCAを回せる企業に依頼することです。
特にプロジェクトが長期のものほど、
「最初のうちに認識のズレを修正しておく」
というのが非常に重要です。
何度もPDCAを行う事で、お互いに納得の行く形でのプロジェクト進行が可能になるため、そういった進行をしてくれる企業を選ぶことで失敗を防ぐことが出来るでしょう。
修正と妥協の線引き
オフショア開発で失敗しないための大きなポイントとして
「修正と妥協の線引き」
を考えることが重要です。
システム開発に明確な答えはありません。
作り込もうと思ったら、どこまでも細かいエラーチェックなどを付け加えること自体は可能でしょう。
しかし、そういった作り込みも、全て行うとすると膨大な工数がかかります。
これは、国内での開発でも、オフショアでの開発でもどちらにも当てはまります。
そのため、どの程度の品質で妥協するのかということは、しっかりと考えておきたいものです。
例えば、
・多少のエラーメッセージのわかりにくさは無視する
・よほどありえない操作は運用でカバーする（マニュアルを徹底するなど）
・画面サイズの問題は各ユーザーのブラウザの拡大／縮小で対応する
など、修正に工数を使わない方向性でプロジェクトを進める事ができます。
もちろん、システムが動かなくなるなど、クリティカルなエラーは修正してもらう必要がありますが、システムを運用に持っていくためにも、ある程度の妥協をすることも、失敗しないオフショア開発には重要なポイントです。
失敗しないオフショア開発はAMELAに
今回は、オフショア開発でありがちな失敗を解説してきました。
多額の費用を支払ってシステム開発をしたのに、それが失敗してしまうのは、企業としても避けたいものでしょう。
オフショア開発は、しっかりとした企業に依頼すれば、多くのメリットが有る一方で、実績のない企業に依頼するのは、大きなリスクもあります。
AMELAでは、ベトナムでのオフショア開発を中心に、日本でも多くの実績を残しています。
是非、現在のビジネスの問題点などご相談いただければと思います。
