開発したいシステムやサービスはあるのに、エンジニアが足りない。多くの日本企業が、いまこの状況にあります。情報システム部門は採用に何か月もかかり、受託開発会社や制作会社は案件を断り、スタートアップは大手企業と同じ人材を取り合っています。その解決策の一つとして、オフショア開発を検討する企業が増えています。
一方で、オフショア開発には「仕様が伝わらない」「品質が期待に届かない」「やり取りに手間がかかり、かえって社内の負担が増えた」といった失敗談も少なくありません。ただ、こうした問題の多くはあらかじめ予測でき、委託先の選び方と始め方で防ぐことができます。この記事では、実際にオフショアで開発を担当している立場から、確認すべきポイントを具体的にご紹介します。
なぜ日本企業はオフショア開発を選ぶのか
最大の理由はエンジニア不足です。経済産業省が2019年に公表した「IT人材需給に関する調査」では、2030年にIT人材が最大で約79万人不足するという試算が示されました。また、同省のDXレポートでは、老朽化した既存システムが経営の足かせになる「2025年の崖」にも警鐘が鳴らされています。正確な数字はともかく、採用の現場で人材不足を実感している企業は多いはずです。
スピードとコストも理由の一つです。オフショアのチームは、採用に比べて数週間単位で立ち上げることができ、業務量に合わせて体制を増減できます。コストを抑えられる場合もありますが、それだけで選ぶのはおすすめしません。安くても手戻りや修正指示が多い委託先は、結果的に総コストが高くなりがちです。
委託先としては、ベトナム、フィリピン、中国、インドなどが一般的です。インドはエンジニアの人材層が非常に厚く、Web、モバイル、クラウドの開発経験も豊富です。さらに日本との時差は3時間30分しかありません。
委託先を選ぶときに何を確認すべきか
見積金額を比べる前に、各社が実際にどのように仕事を進めているかを比べましょう。口頭の説明ではなく、要件定義書のサンプル、週次報告のサンプル、過去案件のテスト計画など、実物を見せてもらうのが確実です。主な確認ポイントは次のとおりです。
- コミュニケーション：日々誰とやり取りするのか、言語は何か、質問への回答にどのくらいかかるか。
- 要件定義：要件をどのように文書化し、理解した内容をどう確認し、仕様変更をどう扱うか。
- ドキュメント：開発中と納品時に何を受け取れるか（仕様書、デザインデータ、API仕様書、環境構築手順など）。
- 品質管理（QA）：誰が、いつ、どの端末やブラウザでテストし、不具合をどう管理・報告するか。
- セキュリティとNDA：自社のNDAに署名できるか、ソースコードやサーバー、データへのアクセスをどう管理し、終了時にどう解除するか。
- ソースコードと知的財産の帰属：成果物の著作権や知的財産が発注側に帰属することを契約書に明記し、リポジトリも自社で保有すること。
- 時差：共通の業務時間が何時間あり、会議をいつ設定できるか。
- 体制の安定性：提案書に書かれたメンバーが、実際に開発を担当するか。
言語の壁を越えて、要件とコミュニケーションをどう進めるか
オフショア開発の失敗の多くは、要件定義の段階から始まっています。日本の組織では、文脈や「言わなくても伝わる」前提で情報が共有されることが多く、日本のチームには明確な仕様書でも、海外のチームには抜け漏れのある資料になることがあります。対策は、すべてを明文化することです。
良い委託先は、文書を中心に仕事を進めます。要件、決定事項、変更点は会議で話すだけでなく、必ず書面に残して確認します。受け取った要件を自分たちの言葉で書き直して確認し、例外ケースについて質問し、コードを書く前にプロトタイプや注釈付きの画面で動きを見せてくれます。視覚的な資料は、どれだけ言葉を尽くすよりも認識のずれを減らします。
言語については、現実的に判断しましょう。日本語を話すブリッジSEを置く委託先もあれば、英語をベースに、翻訳ツールやAIツールを使って文書の翻訳、会議のリアルタイム翻訳や議事録作成を行う少人数のチームもあります。どちらの形でもプロジェクトは進められます。自社にどちらが必要かを先に決め、トライアルの中で実際に試してみてください。
時差は有利に働きます。インド標準時は日本標準時より3時間30分遅れているため、インドの午前中と日本の午後が重なります。インドで9時30分ごろに始業するチームなら、日本時間の13時ごろからオンラインになり、毎日数時間を打ち合わせや質疑応答に使えます。
なぜ小さな有償トライアルから始めるべきなのか
最初から大きな契約を結ぶのは、最もリスクの高い始め方です。委託先の本当の仕事ぶりは、一緒に仕事をしてみて初めて分かるからです。2〜4週間程度の小さな有償フェーズなら、低いコストでそれを確かめられます。
最初のフェーズとしては、要件整理（業務フロー、画面遷移、技術方針、見積もり）、クリック操作できるプロトタイプ、既存システムへの小さな機能追加などが適しています。費用はきちんと支払いましょう。無償のトライアルでは、委託先の普段の仕事の進め方が見えにくくなります。
トライアルの終わりには、どのような質問をしてきたか、ドキュメントとコードの品質、フィードバックへの対応、次フェーズの見積もりの根拠が明確か、を評価します。トライアルの段階でうまくいかなければ、本番のプロジェクトはさらに難しくなると考えてください。
受託開発とラボ型開発、どちらが合っているか
日本企業がオフショア開発を依頼する場合、主に二つの形があります。受託開発（請負型）は、決められた範囲を、決められた納期までに納品する形です。新規アプリの開発や、特定システムのリプレイスなど、要件が明確で変わりにくい場合に向いています。
ラボ型開発は、一定期間（通常は月単位）専属のチームを確保し、発注側が優先順位を決めながら開発を進める形です。継続的なサービス開発、要件がまだ固まっていない案件、安定した開発リソースが必要な受託開発会社に向いています。その分、発注側の関与も必要です。社内に優先順位を決め、成果物を確認する担当者を置きましょう。
まず要件整理や小規模な案件から始め、信頼関係と共通理解ができてからラボ型に移行するのも、よくある進め方です。
よくある失敗とその防ぎ方
うまくいかないオフショア開発の原因は、ほぼ共通しています。それぞれにシンプルな対策があります。
- 暗黙の前提：業務ルール、例外ケース、受け入れ基準を文書にし、委託先にも書面で確認してもらう。
- 接点が少ない：週1回の定例会議と、日々の質問用の共有チャンネルを用意し、問題を早めに見つける。
- 最後にまとめてテストする：1〜2週間ごとに動くものを受け取り、自社でも確認する。
- 発注側の責任者が不明確：質問に答え、すぐに判断できる担当者を一人決めておく。
- 価格だけで選ぶ：社内の管理工数や手戻りも含めた総コストで比較する。
- 資産の管理を手放す：ソースコード、デザインデータ、クラウドのアカウント、ドメインは初日から自社名義で管理する。
Devnori は日本企業とどのように仕事をするか
Devnori は、インドを拠点とする少人数・シニア中心のプロダクトデザイン＆エンジニアリングスタジオです。リモートで世界中のお客様と仕事をしています。プロダクトデザイン、UX/UIデザイン、Web・モバイル（iOS/Android）開発、AI・自動化、クラウド・DevOps、QAを一つのチームで担当するため、デザイン会社と開発会社の間での引き継ぎは発生しません。これまでにWebプラットフォーム、モバイルアプリ、社内ツールなど60件以上のプロジェクトを手がけ、Opticdigit、TrainFoxx、Securelyze などの自社プロダクトも開発・運営しています。
契約形態は、上で紹介した二つの形に対応しています。「プロジェクト」は、範囲を決めて一貫して納品する形で、要件整理のワークショップ、専任のデザイナーとエンジニア、週1回の定例会議、定期的な進捗報告、ドキュメント付きの引き継ぎまでを含みます。「エクステンデッドチーム」は、月単位で柔軟に体制を確保し、お客様のツールや進め方に合わせて開発する形で、いわゆるラボ型開発に近いものです。受託開発会社や制作会社向けには、NDAのもと御社の名前で開発を行うホワイトラベルでの協業も可能で、お客様との関係は御社が保持します。
言語の違いには、文書中心の要件管理、リアルタイム翻訳と要約を活用したAI支援の会議、プロトタイプや画面フロー、注釈付きの画面による視覚的なコミュニケーションで対応しています。正直にお伝えすると、Devnori には日本語を話すスタッフはいません。委託先側に日本語対応のブリッジSEが必要な場合や、すべてのドキュメントを日本語ネイティブで作成する必要がある場合は、別の委託先の方が適しています。料金は公開しておらず、初回の打ち合わせの後に案件ごとにお見積もりします。合わないと判断した場合は早めにお伝えし、お問い合わせには平日24時間以内にご返信します。