オフショア開発事業のアカウントプランナーをしてる宮本です。
近年、日本のIT人材不足などの課題を解決する手段として「オフショア開発」が注目を集めています。
オフショア開発とは海外の子会社やサプライヤーに委託開発をする手法ですが、課題も多く失敗する企業が多いのも事実です。
今回はオフショア開発が抱える課題とその解決策について、私自身の経験をもとに解説します。
これから導入を検討している、またはオフショア開発がうまくいかないと悩んでいる開発ご担当者様は、ぜひご一読ください。
- オフショア開発を成功させるには…
- オフショア開発の成功には、実績のある依頼先を選ぶことが大前提です。オフショア開発の実績豊富な会社はこちらの記事でまとめています。
目次
※編集部注：2021年7月に公開された記事を再編集しました。
オフショア開発が抱える課題とは
オフショア開発が抱える課題を集約すると、主に以下のものになるかと思います。
- オフショア開発先との商習慣や文化に違いがある
- 要件や仕様の認識の違いがある
- 開発がブラックボックス化している
- 人材が定着しない
それぞれ詳しく解説します。
オフショア開発先との商習慣や文化に違いがある
一つ目の課題は、国間での商習慣や文化の違いです。
オフショア開発先には、ベトナムやフィリピンといった東南アジア諸国が多く選ばれます。
国が違えば日本では当たり前のことがそうではない、ということが往々にしてあります。
例えば、日本では日常的に残業が行われていますが、海外では普通ではありません。また、サービス残業も基本的には許容されません。
発注元から依頼を受けた内容を細かく確認せず、自らの判断で作業手順や仕様変更を変更してしまうことも多々ありますし、国によっては時間にルーズで会議が時間通りに進まないこともあります。
このような文化や考え方の違いを理解せずに進めてしまうことで、失敗につながります。
- 国による文化違いの例
-
- ベトナム：意向を汲み取ることや、暗黙の了解は存在しない。はっきり言わないと伝わらない。
- フィリピン：時間にルーズ。わからないことを嫌うため知ってるふりをする傾向がある。
- インド：時間にルーズ。他宗教の国であり、礼拝義務などで仕事ができない時間がある。
例えば「判断は任せるよ」といった場合、日本では周りの状況を踏まえて最良の方法を判断しますが、海外では好き勝手に行っていいと捉えられてしまう可能性があります。
要件や仕様の認識のずれが生じやすい
二つ目の課題は、要件や仕様の認識にずれが生じやすいことです。多くの場合、要件や仕様調整は基本的に英語です。英語ができなければ、当然認識のずれがおき、結果としてオフショア開発の失敗に繋がります。
また、母国語であれば細かなニュアンスを伝えることができますが、お互いに母国語ではない言語の場合はそれができません。
そのためどうしても、要件や使用に認識のずれが生じやすいという課題があります。
開発がブラックボックス化している
三つ目の課題は、開発がブラックボックス化していることです。オフショア開発では、基本的にテレワークで開発を進めていくことになるため、開発状況を目で見て把握することはできず、開発先からの報告レポートや会議での発言を信じるしかありません。
また、コミュニケーションは英語でとることが多く、母国でないことによるコミュニケーションロスが生じます。
このような状況下では、進捗管理やリスク管理がしづらく、確認できたときには、システム修正に大幅な時間やコストがかかるような状態になっていた、などの問題が発生してしまいます。
人材が定着しない
オフショア開発を進める上でよくある課題が、エンジニアの定着率の課題です。
オフショア開発先としてよく選ばれるベトナムやフィリピンでは、日本と比較して転職への抵抗が薄く、「スキルアップのために転職をする」「いい条件を求めて転職をする」という考え方が一般的です。
事実、経済産業省「IT人材に関する各国比較調査結果報告書によると、日本人は転職回数0回の人が約50%なのに対し、ベトナムでは20%程度。一方2回以上転職している人の割合は、日本が15%なのに対しベトナムでは33%と倍以上の差があります。
そのため、プロジェクト進行中でも人材の入れ替わりがおき、納品スピードが遅くなる、可読性が落ちるといった問題が生じることがあるのです。
オフショア開発における課題の解決策
ここまで上げてきたような課題を克服するためには、どのようなことに気を付けるべきなのでしょうか。
日本の文化を押し付けない・理解する姿勢が大切
まずは、相手の文化を重んじて日本の文化を押し付けない姿勢が大切です。こちらの文化を無理に押し付けてしまったり、相手の考えを変えようとしてしまえば、オフショア開発会社との関係が悪化する可能性もあります。
なお、元々の文化が違うのでこちらが正しいと思って説明しても相手からすれば理解できないこともあります。このことを理解し、時には妥協することも必要です。
また、プロジェクトのキックオフ時には、進捗報告やトラブル時のルール確認（報告フォーマットや報告手段、頻度など）をし、共通認識を持っておくようにしましょう。
- 例えば
-
- 進捗定例は週1、テレビ通話で行う
- 報告フォーマットはこちらが指定したもの、入力は定例日の前日までとする
- トラブル時は、○○に連絡、報告フォーマットに沿って報告する
依頼をする時には、「これ」「それ」などの指示語を使ったり、「こんな感じで」「よしなによろしく」といったような曖昧な表現や説明は避けます。
何をもって完了なのか定義をはっきりさせるなど、齟齬なく伝わる文章を心がけましょう。
オフショア開発先とのコミュニケーションの頻度や精度を高くする
課題としてあげた要件や仕様の認識の違いや、開発のブラックボックス化を防ぐためには、やはりコミュニケーションの頻度や精度を高くするしかありません。
特に要件定義や仕様書作成は、記載内容の漏れや表現の仕方によっては、後のテスト工程における仕様確認にも影響してきます。高品質な成果物を低コストで開発するためには、要件・仕様をいかに正確に理解してもらうかがポイントです。
抜け漏れがないように、日本人がドキュメントの作成やチェックなどをするようにしましょう。
また、基本的に進捗内容はレポートやテレビ会議となりますが、このときは定型フォーマットでの報告を行うことをおすすめします。さらにはドキュメントやソースコードを事前に見せてもらい、会議で細かい点を確認できるようにするといった工夫も必要です。
この時、お互いに共有して同時に書き込みできるITツールを活用するなどすると、スムーズなコミュニケーションがとれます。とにかく密なコミュニケーションがとれるように、さまざまな工夫をしてみてください。
また、何か依頼をするときは相互の理解にずれが生じない様に可能な限り図解(見える化)することをおすすめします。
ブリッジSEの能力を確認する
ここまで紹介してきたような課題を解決するには、ブリッジSEの能力も大切になります。ブリッジSEとは、日本側とオフショア開発側との間に立ち、意思伝達や全体のプロジェクト管理を行うエンジニアのことです。つまり、ブリッジSEのスキルは、プロジェクト成果に大きく左右しやすいのです。
オフショア開発を依頼するときは、発注前に面談などを実施し、ブリッジSEのコミュニケーションや技量、マネジメントスキルに問題がないか確認することをおすすめします。
懸念点はオフショア開発先にしっかりと共有しておく
オフショア開発の課題として挙げたものでもっとも対策しづらいのが、「人材の離職」です。海外は日本よりも、転職に対する抵抗がうすく、キャリアアップのために転職をしたいと考える人が多くいるため、離職が少ない開発先を見つけることはかなり難しいのが現実です。
とはいえ、エンジニアの勤続年数が長いオフショア開発先もあります。離職などで納品スピードの低下を懸念していることは、商談時に正直に相談するといいでしょう。また、急な人材の入れ替わりを認めないことを条件として、オフショア開発先を探すのも手です。
ただし、条件が高すぎると、その分費用が高くなる可能性があるため、バランスをみることが大切です。
開発したい内容にあわせた契約方法を選ぶ
これは課題に対する解決策というよりも、そもそもの話ですが、開発したい内容にあった契約方法なのかも留意するべき点です。オフショア開発での契約方法は主に以下の２種類があり、それぞれ進め方が異なります。
- 請負契約：成果物単位で契約をする方法。システムの完成を成果物とする
- ラボ契約：契約期間を定め、その間に必要な人員を確保する方法。社外に専属チームをつくるイメージ
請負契約は、システムの完成を成果物とするため、一定品質の成果物が受け取れる可能性が高いです。デメリットとしては、発注後の仕様変更が難しいということが挙げられます。
一方ラボ型契約は期間内にエンジニアのリソースを確保する、という契約になります。契約期間内であれば違うプロジェクトにアサインすることも可能ですし、追加修正や仕様変更がしやすいです。開発が長期にわたる場合や、仕様に変更が生じやすいシステムを開発する場合に有効な契約方法といえます。
ラボ契約（ラボ型開発）とは？メリット・デメリットや契約時の注意点
しゅん
オフショア開発の失敗事例
ここまで紹介してきたようなオフショア開発の課題に対処しなかった場合、どのようなことが起きるのでしょうか。失敗事例を元にみていきましょう。
失敗事例①成果物の品質低下
課題を解決しないままプロジェクトを進めた場合、第一に成果物の品質低下が起こりやすくなります。プログラムが想定通りに動かない、ソースコードの可読性が低いといったことはよく遭遇する問題です。
これはオフショア開発の課題2で挙げた、「要件や仕様の認識の違い」からくるものが大きいです。
日本では「ここはよしなに」「いい感じにしておいて」といった曖昧な表現をすることがよくあると思いすが、オフショア開発でこれをやるのは失敗原因になります。長く開発を共にしているのであればそれでも伝わるかもしれませんが、海外の場合は特に、異なった解釈をされて想定と違うものが納品される可能性が高いです。
曖昧な依頼はせず、細かすぎると思うくらいしっかりと依頼をするようにしましょう。
また、これはそもそも開発先の企業選びを慎重に行うことが大前提ですが、これ以外にもオフショア開発先を下請け企業として扱ってしまっていることも失敗要因として挙げられます。
オフショア開発先をパートナーとして捉え、自社の開発チームの一員に加わってもらう意識をもっていれば、このような失敗を防ぐことができます。コーディング規約を提供したり、ブリッジSEとともにコードレビューをして品質に共通認識を持つなど、こちら側から巻き込んでいくようにしましょう。
失敗事例②納期の遅れ
続いてよくある失敗事例が納期の遅れです。これは開発がブラックボックス化していることで、スケジュール管理がうまくいかないことにより生じる問題であり、多くの場合ブリッジSEが状況の把握ができていない・そもそも個人がスケジュール管理をする習慣が身についていない、といったことが要因として挙げられます。
このような失敗を防ぐためには、進捗報告やトラブル時のルール確認（報告フォーマットや報告手段、頻度など）をし、共通認識を持っておくことが大切です。
まとめ
オフィショア開発の課題は、経営やマネジメントの課題でもあります。ルール作りや手段・手順に関しての課題をクリアにしながらオフショア開発開発の失敗を防ぎましょう。
ポイントが多すぎてやっぱり不安だなぁという方もいらっしゃるかと思います。弊社ではベトナム、フィリピンを開発拠点として、オフショアでのシステム開発を支援しています。ラボ型、請負、アジャイルなど柔軟に対応可能ですので、お気軽にお声がけください！
オフショア開発について改めてしっかりと理解したい！という方はこちらの記事もおすすめです。
オフショア開発とは？注目される理由やメリット・デメリットを解説 いま「オフショア開発」に改めて目を向けてほしい理由 オフショア開発の品質は低いって本当？現役ブリッジエンジニアが実体験をお話しします！
しゅん
Tomohiro Oyama
山口 菜月
