オフショア開発の相談を受けるなかで、よく耳にするのが、
「以前オフショア開発を依頼したが、想定どおりにプロジェクトが進まなかった」
という声です。
特に海外のオフショア開発では、価格や技術スタックだけで比較してしまい、実際に開発が始まってから「こんなはずではなかった」と感じるケースが少なくありません。
では、オフショア開発会社を選ぶ際に、どうすれば失敗や後悔を避けられるのでしょうか。
本記事では、オフショア開発会社を選定する際に確認すべき5つのポイントを、できるだけ実務目線で整理しました。
これからオフショア開発先を探す企業の方、あるいは今検討中の開発会社で本当によいのか不安がある担当者の方は、ぜひ参考にしてみてください。
1. オフショア開発会社は「技術力」だけでなく案件の進め方で見極める
海外のオフショア開発会社を調べると、多くの会社が技術力の高さを打ち出しています。
たとえば、
- 難易度の高い大規模開発の実績
- AWSやOracleなどの認定資格保有者数
- 対応可能な開発言語やフレームワークの多さ
などです。
もちろん、技術力そのものは重要です。
ただし、オフショア開発で起きる失敗の多くは、単純な技術不足というよりも、
- 発注側と開発側で認識がずれる
- いつまでに何を作るかが曖昧なまま進む
- プロジェクト管理が甘く、スケジュールやコストが膨らむ
といった、進め方や管理体制の問題によって起こります。
そのため重要なのは、「この会社は、開発開始後にどのようにプロジェクトを進め、ゴールまで持っていくのかを説明できるか」という点です。
以下で少し深掘りします。
1.1 開発手法
機能単位の小さなサイクルでの開発を短期間に繰り返して、迅速かつ柔軟に開発・リリース・改善を行うソフトウェア開発手法として、アジャイル開発を得意とする会社があったとします。
その手法で開発を行う場合、
- 設計・開発・テスト・レビューを一通り行う「スプリント」と呼ばれる期間はどのくらいか
- チームメンバーが毎日集まって短時間で進捗や計画の確認と調整をする「デイリースクラム」（これを実施しない場合も多いため実施する場合は）その実施方法、振り返りなどをどのように行っているか
について、ちゃんと説明できるかどうかという点です。
1.2 変更への対応姿勢
オフショア開発では、開発途中で変更が入ることも珍しくありません。
- 市場環境が変わった
- ビジネス要件が変わった
- 競合サービスの動きを見て優先順位を変えたくなった
こうした変化は、実際の開発ではよくあります。
一方で、開発側は追加工数や不具合リスクを嫌い、仕様変更をネガティブに捉えがちです。しかし、ビジネス環境が変わる以上、変更を前提に考えるべき場面もあります。
よって、まずオフショア開発チーム側が「仕様変更を積極的に受け入れる体制・姿勢になっているのかどうか」という点が重要です。
そして、そのうえで変更が必要になった場合、影響する範囲を特定し依頼者に報告や相談するプロセスがあるかという点です。
この開発会社と依頼主とのすり合わせができていないと、大きな品質問題やスケジュール遅延といったトラブルが発生する可能性があります。
1.3 品質管理
開発したソフトウェアが依頼者・発注元である顧客の要求や基準を満たしていることを体系的に保証する活動としてQA（Quality Assurance）と呼ばれる言葉があります。
このQAとして単なる納品前に行う検査の有無ではなく、不具合を未然に防ぐプロセス改善、品質基準の策定などがあるのかや、それを開発者だけで実施しているのか、それともQAチームなどがあって実施しているのかについて説明できるかという点です。
実際にオフショア開発会社選定の際に使える「質問」を用意しました。以下のような点を聞いてみましょう。
- 「過去の開発において、途中で仕様変更が発生した際の具体的な対応フローを教えてください。」
- 「プロジェクト進行中、定例ミーティングの頻度とアジェンダ（議題）、および進捗報告のフォーマットなどがあれば見せていただけますか？」
- 「QA（Quality Assurance）についてはどのように考えて活動されていますか？また、例えばテストはどのような基準で行われますか？」
2. オフショア開発の見積もりは「金額」より前提条件を確認する
オフショア開発では、準委任契約（ラボ型開発）と請負契約の両方がありますが、ここでは主に請負型のオフショア開発を想定します。
開発会社を選定するときに、開発したい内容を伝えて、見積書や見積金額などが含まれた提案書などを受け取り、発注すべきかどうかを検討することになります。
その際、計〇〇人月で計〇〇万円といった稼働工数だけを根拠にした見積だけが提示された場合、後々トラブルが生じる可能性があります。
なお要件が不明確な場合は、開発会社でも参考額としてざっくりとした金額で出さざるを得ないため、そういった場合は除きます。
見積もりの前提となる対象範囲（スコープ）が曖昧であった場合、依頼企業と開発会社とで認識が違い、「ここまでやってくれると金額だと考えていた」、「これは含まれていないと考えて見積もった金額だった」と、後から揉めることになります。
まず依頼企業の方で見積もりにあたり、ここまでやって欲しいと考えているという前提をはっきりと開発会社側へ伝え、それを元に見積もってもらうことが必要です。
そして送られてきた見積書において、前提条件や対応範囲などが明記されているかを確認しましょう。
2.1 前提条件の明記
「依頼企業から提示されたXXXXXの資料に基づく見積もりである」「デザインが〇月〇日までに顧客から提供される事を前提とした納期である」「使用するクラウド環境はXXXXである」など、見積条件が明確になっているか？
2.2 不明点へのアプローチ
開発会社が見積書を作る際、その前提となる依頼企業が用意する資料において漏れが無くかつ分かりやすい内容であれば別ですが、そうでない場合は開発会社と依頼者の間で「不明点についての質疑応答をしっかり行う」、
もしくは見積書において「この点が不明確･変動する可能性が高いと考えられる為、多めに見積もっている（予備工数バッファを積んでいる）」といった提示や説明があるはずです。
しかしそういうやり取りや説明が無く、不明点を質問してこない、安価な見積金額だけが提示される場合、認識の不一致が内包されている可能性があります。
この件で、選定時に使える「質問」は、以下の通りです。
- 「今回の見積もりの『前提条件』を教えてもらえますか。また、依頼者となる我々がいつまでに何を提供しないと、この見積もりが成り立ちませんか？」
- 「この見積もりにおいて、貴社として明確に『スコープ外（やらないこと、役務に含まれないこと）』としている作業は何ですか？」
- 「要件がまだ不明確な部分について、今回はどのように（どのくらい）バッファを見積もりに含めていますか？」
3. オフショア開発を成功させるには「役割分担」を明確にする
オフショア開発で特に失敗しやすいのが、「開発会社に丸投げすること」です。
依頼者にとって今後のビジネスに関係するソフトウェアを作る以上、開発会社へ「丸っとすべてやっておいて」ではなく、開発会社に対してどの部分やって欲しいのかを明確にしておく必要があります。
具体的には、以下の様なポイントです。
3.1 タスクや責任の境界
要件定義、基本設計、詳細設計、UI/UXデザイン、試験（テスト）といった各工程において開発会社が対応する範囲は、どこからどこまでか？
依頼者側において、デザインをこんな感じにしたいイメージや、画面設計図（ワイヤーフレーム）などを用意するのであれば、それを事前に開発会社へ話しておき明確にしておきましょう。
さらに1つの製品開発を複数のオフショア開発会社へ分割して依頼する場合は、どの会社の対応範囲がどこまでなのかを依頼者側で明確にしておかないと、責任の所在も曖昧となり、後々揉める元となります。
よって理由が無い限り、最初から複数の会社に分割して発注することは避けた方が良いです。（失敗する可能性が高くなってしまいます）
3.2 承認のプロセス
開発をしていく際は、フェーズと呼ばれる各工程ごとの期間･区切りを設けることも多いですが、その各フェーズにおける完了条件･何を持って次の工程へと進めていくのかや、依頼者側の確認が必要な場合、その期限なども設定されているか？
3.3 各種関連費用についての取り決め
オフショア開発では、実装費だけでなく周辺費用も発生します。
たとえば、
- AWSやAzureなどのクラウド費用
- 生成AIや外部APIの利用料
- 開発環境・検収環境のサーバー費用
- 代行契約時の手数料
などです。
これらを
- 発注側が直接契約するのか
- 開発会社が代行するのか
- 費用負担はどちらか
まで含めて、事前に決めておく必要があります。
この件で、選定時に使える「質問」は、以下の通りです。
- 要件定義からリリースまで、各フェーズで御社が主導する作業と、当社が対応すべき作業の分担表はありますか。
- 次のフェーズへ進むための確認・承認プロセスはどのようになっていますか。
- 当社側のフィードバックや確認には、通常どの程度のリードタイムを見込んでいますか。
4. オフショア開発会社は「トラブル時の対応フロー」まで確認する
システムの開発を進めている際に、何らかのトラブルが発生する可能性はあります。
例えば、バグであったり、処理はできるけど時間がかかるといった性能上の問題、（様々な理由による）納期の遅延、リリース後の障害発生、担当している開発エンジニアの急な長期病欠や退職などです。
これらは、開発会社側で注意していても発生し得るものである為、重要なのは、トラブルが起きた時にいかに迅速にリカバリーできるのかや、それを実現する開発会社としての体制、報告の際の流れ（フロー）などが事前に整備されているのかという点になります。
4.1 問題発生時の報告&対応フロー
障害などの問題が発生した際に依頼者側から開発会社の誰にどのような方法で連絡をするのか。それが休日や深夜などであった場合は、どうするのか。開発会社としては、どういう方針で対応することになるのか？
また障害の様な突発的な出来事だけでなく、普段から対応している日本語が話せるブリッジ人材やエンジニアに問題･不満があった場合、誰にどのように相談すればよいのか？
4.2 担当エンジニアが退職･離脱した場合の対応
会社やその時のビジネス環境によっても異なりますが、一般的には日本よりもベトナムの方が人材の流動性が高いとも言われており、プロジェクトのアサインされているエンジニアや日本語が話せるブリッジ人材の退職の可能性はあります。
また退職では無かったとしても、病気や交通事故などによって、プロジェクトから離れざるをえなくなる可能性もあります。
こういった時、どのように影響を最小化するのか、引継ぎ方法、会社としてのバックアップ体制なども確認しておくべきです。
この件で、実際の選定の際に使える「質問」は、以下の通りです。
- 「当社プロジェクトにアサインされたブリッジ人材やエンジニアに問題があると感じた場合、御社のどなたに相談すればよいですか？」
- 「開発途中でブリッジ人材やエンジニアが退職したり、病気等でアサインできなくなった場合、どのようなプロセスで引き継ぎや人員補充が行われますか？」
- 「本番リリース後に何らかの障害が発覚した場合、どのように対応されますか？またそれが御社の営業時間外であった場合は、どのような対応を想定されていますか？」
5. オフショア開発会社が「長期運用を見据えた体制」かを確認する
開発するシステムの目的や内容によっても違いはありますが、システムは出来上がってしまえばそれで全て終わりではなく、そこから保守・運用、さらには利用者の声･フィードバックを元にした継続的な改善が必要になる事が多いです。
その場合、開発をしたオフショア会社に継続して対応してもらうという方法もありますし、場合によっては、自社のチーム、または他社のチームに移管するというケースも考えられるでしょう。
そして仮に他社などへ引継ぎが発生するケースにおいては、問題なく引き継ぐことができる形で開発されているのかを確認をしておかないと、最初に開発を依頼した会社以外では対応できなくなってしまいます。
よって引き継ぐ可能性があるのであれば以下の点についても確認が必要ですが、費用やスケジュールなどに応じては、リスクを踏まえたうえであえてドキュメント類の整備を省く場合もありますのでご注意ください。
5.1 ドキュメント類の整備
API仕様書や設計書といったドキュメントが作成されているのか？
それらは、何語で作成されているのか？（少なくとも英語では書かれているのかなど）
5.2 ソースコードの品質
Github等を用いた相互のコードレビュー体制などがあり、またソースコードへのコメント記載ルールなどが徹底されているのか？
これによりコードの可読性や保守性を維持する仕組みが担保されているか。
5.3 リリース後の体制
請負型やラボ型で開発した後、リリース後の改修や保守運用フェーズにおいてはどのような体制･契約形態での対応が可能か？
この件で、実際の選定の際に使える「質問」は、以下の通りです。
- 「開発終了後、別のチームがソースコードを引き継ぐことを想定した場合、どのようなドキュメント類（設計書、API仕様書、環境構築手順など）を納品いただけますか？」
- 「属人化を防ぎ、コードの品質を一定に保つために、社内でどのようなコードレビュー体制やツールを導入していますか？」
- 「リリース後の運用フェーズに入った場合、どのような契約形態（ラボ型、チケット制の保守体制など）や、チーム体制を貴社では推奨されますか？」
これからオフショア開発を検討する方は、ぜひ本記事で説明してきたの5つの視点を、開発会社選びのチェックポイントとして活用してみてください。
