オフショア開発から既存プロダクトを巻き取る方法
「オフショアの単価は魅力的だったが、リリース後の品質・コミュニケーションの速度に限界を感じている」——時差のあるやり取りで確認に1日以上かかる、コメントが現地語のまま残っている、担当者が変わるたびに設計思想が変わっている。そんな状態で「国内チームに巻き取ってもらいたい」という相談は年々増えています。オフショアの実装力自体は決して低くありません。ただし巻き取りには、国内の開発会社変更とは違う固有の論点があります。この記事ではその論点と、つまずかずに移管するための進め方を整理します。
オフショア巻き取りが「開発会社変更」と違う理由
開発会社を国内の別会社に変更する場合と比べ、オフショアからの巻き取りには次の4つの固有の壁があります。
- 時差とコミュニケーション速度: 移管期間中の質問・確認が翌営業日以降になりやすく、棚卸しに想定より時間がかかる
- ドキュメント言語: 設計メモやコードコメントが現地語(英語以外のことも多い)で書かれており、そのままでは国内エンジニアが読めない
- 設計思想・コーディング規約のばらつき: 案件単位・担当者単位でチームが変わることが多く、同じプロダクト内でも書き方の一貫性が低いケースがある
- 引き継ぎ協力を得にくい: 契約終了後は連絡が取りづらくなりやすく、国内企業のように「解約後も数週間は質問に応じる」という商習慣が期待しにくい場合がある
これらは能力の差ではなく、契約形態と商習慣の違いから来るものです。まずこの前提を踏まえて準備することが、巻き取りの成否を分けます。なお国内の開発会社間での移管手順は開発会社変更の引き継ぎチェックリストにまとめているので、共通する部分はそちらも参照してください。この記事ではオフショア特有の論点に絞ります。
移管前に確保すべきもの(オフショア版)
契約がまだ生きている、連絡が取れるうちに次を確保してください。時差の影響で1往復に1〜2日かかることを前提にスケジュールを組む必要があります。
コード・インフラの所有権
- [ ] リポジトリの Owner 権限が自社アカウントになっているか(オフショア側の Organization 配下に残っていないか)
- [ ] サーバー・ドメイン・SaaS の契約名義が自社か、オフショア側の管理画面経由でしかアクセスできない状態になっていないか
- [ ] CI/CD・デプロイ鍵・環境変数が「担当エンジニアのローカル環境にしかない」状態になっていないか
ドキュメントと言語
- [ ] 設計ドキュメント・API仕様が存在するか、存在する場合どの言語か
- [ ] コード内コメントの言語(英語か、現地語か)を事前に把握しておく。現地語コメントが多い場合、巻き取り後の翻訳・読解コストを見積もりに織り込む
- [ ] 用語集(業務用語とコード上の命名の対応)があるか。無ければ主要な画面・機能だけでも対応表を作ってもらう
引き継ぎの実働時間
- [ ] 契約終了後、質問対応にどれだけ応じてもらえるか(期間・稼働時間帯)を契約書または合意事項で明文化する
- [ ] オンラインでの引き継ぎミーティングを最低1〜2回、時差を考慮した時間帯で設定できるか
- [ ] 主要な設計判断(なぜこの構成にしたか)を、担当者が離れる前に文章かミーティング録画で残してもらう
これらは「不満をぶつけて契約を切ってから」では確保が難しくなります。関係が悪化する前、まだ協力を得られるうちに静かに進めるのが実務的です。
コードの現状診断で見るべきポイント
引き継ぎ資料が揃っていても、実際のコードがドキュメント通りに動いているとは限りません。巻き取り後すぐに手を動かす前に、次を確認する診断フェーズを挟むことを推奨します。
- ローカル環境が README だけで再現できるか: 手順が現地語や暗黙知に依存していないか実際に試す
- 依存ライブラリのバージョンと脆弱性: オフショア案件では速度優先でライブラリのバージョン固定・更新が後回しになっているケースが見られる
- テストの有無とカバー範囲: テストが無い、または現地語のテストケース名で意図が読み取れない場合、改修時の安全網が弱い
- コーディング規約の一貫性: 担当者交代の履歴が長いプロダクトほど、ファイルごとに書き方が違うことがある。まず「今どう書かれているか」を可視化する
こうした現状把握の観点は、オフショアに限らず既存プロダクト改善全般に共通します。詳しくは既存プロダクト改善で最初に見る観点で解説しているので、巻き取り前後どちらのタイミングでも参考にしてください。
段階的に巻き取る進め方
オフショアからの巻き取りは、初日から全面的に手を入れるのではなく、段階を踏むことでリスクを抑えられます。
- 現状把握フェーズ(1〜2週間): コード・インフラ・ドキュメントの棚卸しと、上記の診断を行う。この段階では機能追加や大きな改修は行わない
- 並走・確認フェーズ: 可能であればオフショアチームと国内チームが短期間でも重なり、質問できる窓口を残す。難しい場合は、契約終了前に集中的な質疑応答セッションを設ける
- 小さな改修から着手: いきなり大規模なリファクタリングをせず、影響範囲の小さい修正から始めてコードベースの挙動を実地で確認する
- 設計思想の統一: 複数の担当者・複数のフェーズで書かれたコードは、規約を一度に揃えようとせず、触った箇所から段階的に統一していく方が現実的
特に2の並走フェーズは、時差のある相手ほど早めに調整しないと確保できません。移管の意思決定と同時に、並走期間の交渉を始めることをおすすめします。
オフショアを一方的に否定する必要はない
ここまでオフショア固有のつまずきを整理しましたが、これはオフショア開発そのものを否定する話ではありません。仕様が固まった大量実装や、コストを抑えたい量産フェーズでは、オフショアの単価と実装力は引き続き有効な選択肢です。今回のプロダクトで起きた課題が「オフショアだから」なのか、「体制・引き継ぎ設計の問題」だったのかを切り分けて考えると、次にプロダクトを任せる相手を選ぶ際の判断材料にもなります。
まとめ
- オフショアからの巻き取りは、時差・ドキュメント言語・設計思想のばらつき・引き継ぎ協力の得にくさという固有の壁がある。これは能力差ではなく契約形態・商習慣の差
- 契約が生きているうちに、所有権・ドキュメント・引き継ぎの実働時間を確保する。関係が悪化してからでは協力を得にくい
- 巻き取り後はいきなり手を入れず、現状把握フェーズを設けてコードとインフラを診断し、段階的に統一・改善していくのが安全
torcheeesでは、オフショアからの巻き取りを含む既存プロダクトの改善・モダナイゼーション支援を行っています。現状のコード・インフラを確認する診断、継続的な改善支援もご提案します。「オフショアからの巻き取り方が分からない」という段階からでも、お問い合わせフォームからご相談ください。