オフショア開発会社の選び方を調べると、「実績は豊富か」「日本語は通じるか」といった観点が並びます。ただ、商談でそのまま尋ねても、返ってくるのは「はい、対応できます」という答えだけです。選ぶ材料になるのは、答えの中身で良し悪しを見分けられる質問です。
この記事では、発注担当者が商談で確認しておきたい10点を、公的な資料と調査データに沿って整理しました。それぞれについて、確認する理由と、安心できる回答の目安を示します。あわせて、MOHAに同じ質問をした場合の答えも、公開している情報の範囲で書きました。
オフショア開発会社の選び方が商談での確認で決まる理由
国内のIT人材不足は、当面解消しそうにありません。経済産業省は、需要が年平均2.7%程度伸び、労働生産性が年0.7%上昇する前提で、2030年に45万人の需給ギャップが生じると試算しています（経済産業省「IT人材需給に関する調査（概要）」）。採用だけでは埋めにくいこの不足が、海外の開発チームへ委託する企業を増やしています。
一方で、発注した企業の不満もはっきりしています。オフショア開発.comの『オフショア開発白書（2025年版）』によると、発注企業がオフショア開発企業に感じた課題は、「コミュニケーション力」と「品質管理」が引き続き上位でした。選定時に重視された点には「日本語対応力」「開発実績」「日本企業との取引経験」が挙がっています。選定の段階で感じた課題は「自社要件とのマッチング」と「初期コミュニケーション」でした（オフショア開発.com「オフショア開発白書（2025年版）」）。
この結果を見ると、失敗の芽は契約前のやり取りにすでに表れています。会社案内に並ぶ数字よりも、自社の案件について質問したときの答え方のほうが、判断の材料として確かです。
商談で確認する10点の一覧
先に全体を表で示します。右の列は、回答の妥当性を確かめる手がかりになる資料です。
| 確認点 | 商談での質問 | 手がかりになる資料 |
|---|---|---|
| 1. 契約主体と準拠法 | 契約書に署名するのはどの法人ですか。準拠法と裁判管轄はどうなりますか | 会社概要、契約書 |
| 2. 契約形態 | この案件は請負と準委任のどちらで結びますか。理由は何ですか | IPAのモデル契約書 |
| 3. 知的財産権の帰属 | ソースコードと設計書の著作権は、いつ発注側に移りますか | 契約書 |
| 4. 体制と役割 | エンジニアへの作業指示は誰が出しますか | 厚生労働省の疑義応答集 |
| 5. 日本語でのやり取り | 定例、日々の報告、仕様の質問は、誰とどの手段で行いますか | オフショア開発白書 |
| 6. 要件定義と仕様変更 | 仕様が変わったとき、費用と納期はどの手順で決め直しますか | IPAのモデル契約書 |
| 7. 品質管理とテスト | テストの範囲と完了の基準は、いつ誰が決めますか | オフショア開発白書 |
| 8. セキュリティと個人情報 | 本番の個人データを海外の拠点で扱いますか | 個人情報保護法のガイドライン |
| 9. 類似案件の実績 | 当社に近い案件は、どんな体制と期間で進めましたか | 公開されている事例 |
| 10. 保守・運用の継続性 | リリース後は誰が保守を担当しますか | 提案書、見積書 |
契約に関する確認点
1. 契約主体と準拠法
最初に確かめるのは、契約書に署名する相手です。海外の法人と直接契約する場合は、どの国の法律に従うか（準拠法）と、紛争をどこの裁判所で扱うか（裁判管轄）を個別に決めます。請求の通貨や送金の方法も、経理の手続きを左右します。
安心できるのは、契約主体、準拠法、裁判管轄、請求通貨の4つを、契約書の条項に沿って説明できる会社です。「日本に窓口があります」という説明を受けたら、その窓口と契約主体が同じ法人かどうかまで確かめてください。
MOHAの場合、契約の窓口は日本法人の合同会社MOHAジャパンです。2025年1月に設立し、横浜市西区みなとみらいに所在しています。開発はハノイの開発センターが担当します。準拠法、裁判管轄、請求通貨などの契約条件は、商談の際はMOHAにご質問ください。海外ベンダーとの契約で起きやすい問題は、日本企業が海外ベンダーと契約する際の落とし穴と対策でも取り上げています。
2. 契約形態（請負・準委任）
請負は成果物の完成を約束する契約で、準委任は業務の遂行を約束する契約です。どちらが合うかは、案件の性質で分かれます。
判断の物差しになるのが、IPAの「情報システム・モデル取引・契約書（第二版）」です。ユーザー企業とITベンダーのどちらかにメリットが偏らないことを目指してつくられています。2020年4月施行の改正民法に合わせて、請負の契約不適合責任や、成果報酬型の準委任の位置づけも見直されました。
商談では、「この案件ならどちらを勧めますか」と理由を添えて尋ねます。よい回答は、要件がどこまで固まっているかを聞き返したうえで、工程ごとに契約を分ける案まで示すものです。
MOHAのオフショア開発センターでは、専属チームモデル、スタッフ補強モデル、プロジェクト単位型モデルの3つを用意しています。成果物を決めて進めたい案件か、体制を続けて確保したい案件かに応じて選べます。契約書に入れる項目は、オフショア開発サービス契約の基本構成と注意点にまとめています。
3. 知的財産権の帰属
開発を委託しても、ソースコードの著作権が自動的に発注側へ移るわけではありません。著作権は原則としてつくった側に生じるため、発注側が権利を持つには契約書で譲渡を定める必要があります。
確認するのは3点です。1つ目は、著作権が移る時期（検収時か、支払いの完了時か）です。2つ目は、ベンダーが以前から持っている汎用の部品と、オープンソースソフトウェアの扱いです。3つ目は、納品後に発注側が自由に改修できるかどうかです。該当する条項を示して説明できる会社なら、後から解釈の割れる心配が減ります。
知的財産権の扱いは、契約書で決める事項です。MOHAとの契約でどう定めるかは、商談の際はMOHAにご質問ください。条項を読むときの着眼点は、オフショア開発契約で失敗しないための7つのチェックリストも参考になります。
体制とコミュニケーションの確認点
4. 体制とPM・ブリッジSEの役割
前述の白書は、成功のポイントとして「コミュニケーション」と「ブリッジSEの能力」を挙げています。ただし、ブリッジSEが1人いれば足りるという話ではありません。確かめたいのは、発注側の要望を誰が受け、タスクを誰が割り振り、進捗の遅れを誰が立て直すのかという役割分担です。
役割分担は、法令の面でも意味を持ちます。請負や準委任の契約であっても、発注側が受注側のエンジニアに業務の進め方や労働時間を直接指示すると、実態は労働者派遣だと判断されます。いわゆる偽装請負です。厚生労働省は、契約の形式ではなく実態に即して判断すると明記しています（厚生労働省「37号告示関係疑義応答集」）。令和8年5月に追加された第3集のQ8では、アジャイル型以外のシステム開発を請負で行う場合も、同じ考え方が当てはまるとされました。
よい回答は、体制図の上で「要望を伝える相手」と「作業を指示する人」を分けて示すものです。担当者が不在のときの代わりの窓口も、あわせて聞いておきます。
MOHAの場合、エンジニアへの指揮命令はMOHA側のPM／ブリッジSEを通じて行います。お客様に決めていただくのは、つくりたいものと優先順位です。作業の割り振りと進め方は、MOHA側で決めます。
5. 日本語でのコミュニケーション設計
白書では、選定時に重視された点として「日本語対応力」が挙がっていました。とはいえ、日本語を話せる人がいることと、やり取りが滞らないことは別の話です。商談では、やり取りの設計を確かめます。
具体的には、定例会議の頻度、日々の報告の形式、仕様に関する質問の経路を尋ねます。議事録を誰が書き、どちらが内容を確定させるのかも聞いてください。会議体と報告の流れを1枚の表で説明できる会社なら、開始後の手戻りを抑えやすくなります。
MOHAは日本法人が窓口となり、日本語でご相談いただけます。日本とベトナムの時差は2時間で、日本時間の10時はベトナム時間の8時です。双方の業務時間が長く重なるので、定例の時間を決めやすくなります。オフショア開発センターのページでは、専任のプロジェクトマネージャーが連携を支える体制を案内しています。日本語で対応するメンバーの人数や日本語のレベルは、商談の際はMOHAにご質問ください。
品質に関わる確認点
6. 要件定義と仕様変更の扱い
白書が選定時の課題に挙げた「自社要件とのマッチング」は、要件の伝え方と受け止め方の問題です。IPAのモデル契約書（第二版）も、見直しの論点に「プロジェクトマネジメント義務及び協力義務」を入れています。仕様を固める作業は、発注側の協力があって初めて進みます。
商談では、仕様が固まっていない部分をどう進めるかを尋ねます。変更が出たときに、影響の調査、費用と納期の再提示、合意までをどの手順で進めるのかも確認します。よい回答は、この流れを書面で示すものです。「柔軟に対応します」だけの答えには、費用の決め方を重ねて聞いてください。
MOHAはオフショア開発センターのページで、仕様が変わる場合は価格の見直しをお願いすることがあると明記しています。そのうえで、開発の初期にプロトタイプをつくり、ご要望と仕様が確定してから本格的な開発に入ります。変更の発生そのものを減らすための進め方です。
要件の読み違いを減らす道具として、MOHAは「SpecLens」を自社で開発しました。要件定義書や仕様書を整理し、矛盾や欠落、曖昧な表現を検出するAIアシスタントです。
7. 品質管理とテスト
白書で課題の上位に挙がったもう1つの項目が「品質管理」です。品質への不満の多くは、完成の基準を決めないまま開発を始めたことから生じます。
確認するのは、テストの種類と範囲、レビューの手順、不具合の報告の形式、検収の条件です。請負であれば、契約不適合責任を問える期間も尋ねます。準委任であれば、何をもって作業の完了とするかを聞いてください。安心できるのは、開発の前にテスト計画と完了の基準を合意する会社です。要件とテストケースの対応を、後から追える形で残しているかも確かめます。
MOHAのオフショア開発センターは、開発に加えてテスト・QA・QCまでを対象としています。導入の流れにも、進捗、品質、マイルストーンを追跡する段階を設けています。さらに、要件書からテスト観点とテストケースを生成する「Design Checklist」を自社で開発しました。要件とテストの対応関係を明示したレポートを出力でき、社内の開発プロジェクトで使っています。
セキュリティと個人情報の確認点
8. セキュリティと個人情報
この項目には2つの層があります。1つは、暗号化やアクセス制御といった技術面と運用面の対策です。もう1つは、個人データが国境を越えるときの法的な整理です。
見落としやすいのは後者です。個人情報保護法について国が公表しているガイドラインによると、外国にある第三者へ個人データを提供するには、原則としてあらかじめ本人の同意が必要です。同意が不要になるのは、提供先が日本と同等の水準にあると認められた国（EUと英国）にある場合や、提供先が基準に適合する体制を整備している場合などに限られます。同じガイドラインは、外資系企業の日本法人が外国の親会社に個人データを提供する事例を挙げています。この場合、親会社は「外国にある第三者」に該当します（「個人情報の保護に関する法律についてのガイドライン（外国にある第三者への提供編）」）。
そのため、窓口が日本法人であっても、海外の開発拠点が本番の個人データに触れるなら整理が必要です。商談では、開発とテストをダミーデータだけで進められるかを最初に尋ねてください。本番データを扱う場合は、その根拠と管理の方法を聞きます。
MOHAはオフショア開発センターのページで、データの暗号化、アクセス制御、VPNの使用、セキュリティトレーニングを対策として挙げています。個人データの取り扱い方や、貴社のセキュリティチェックシートへの回答は、商談の際はMOHAにご質問ください。秘密保持契約の基本は、NDAの解説記事で確認できます。
実績と継続性の確認点
9. 類似案件の実績（公開事例の読み方）
実績は、件数の多さよりも、自社の案件に近い事例がどこまで具体的に書かれているかで判断します。読むときは、規模、期間、チーム構成、技術、成果の5項目を拾ってください。MOHAが公開している語学学習プラットフォームの事例を例にすると、次のように読めます。
| 読む項目 | 事例の記載 | 自社の案件に引き直す問い |
|---|---|---|
| 規模 | 27.49人月 | 自社の案件は、これより大きいか小さいか |
| 期間 | 約5〜6か月 | 希望する公開時期に間に合う進め方か |
| チーム構成 | PM1名、バックエンド2名、フロントエンド1名、QA1名、UI/UXデザイナー1名 | QAとデザイナーが体制に入っているか |
| 技術 | Laravel、MySQL、jQuery、Bootstrap | 自社の既存システムと合う技術か |
| 成果 | 指導員と教室への依存を最大40%削減 | 成果が業務の指標で書かれているか |
5項目がそろっている事例なら、「当社の案件ではどこが変わりますか」と一歩踏み込んだ質問ができます。その答えから、見積もりの前提も読み取れます。MOHAの事例は導入事例の一覧で公開しています。業種や技術の近い事例が見当たらない場合は、商談の際はMOHAにご質問ください。
10. 保守・運用までの継続性
システムは、リリースした後のほうが長く使われます。開発が終わった時点で担当者が離れ、仕様を知る人がいなくなると、小さな改修にも時間がかかります。
確認するのは、リリース後の保守を誰が担当するか、開発時のメンバーがどの程度残るかの2点です。設計書やテストケースがどの形で引き渡されるかも聞いてください。契約を終えるときの引き継ぎの手順まで説明できる会社なら、将来の選択肢を狭めずに済みます。
MOHAのオフショア開発センターは、メンテナンスまでをサービスの対象としています。保守の体制や対応する時間帯は案件ごとに異なるため、商談の際はMOHAにご質問ください。
オフショア開発で発注側が引き受けること
ここまでの10点は、開発会社に確かめる項目でした。ただ、オフショア開発には、発注側が引き受ける負担もあります。
まず、要件を決める時間です。優先順位と受け入れの基準を決める担当者を、発注側に置く必要があります。次に、言葉にしない前提は伝わりにくくなります。口頭で察してもらうやり方は通用しないため、決めたことを文書に残す手間が増えます。時差もあります。ベトナムとの時差は2時間と小さいものの、日本の夕方以降に出した依頼は、翌営業日の対応になることがあります。
こうした負担を商談の段階で率直に話せる会社のほうが、開始後の食い違いは少なくなります。
よくある質問
商談の前に何を用意すればよいですか？
開発の目的、現行システムの概要、希望する時期の3つがあれば、話を進められます。決まっていることと、まだ決まっていないことを分けて書いておくと、質問への回答も具体的になります。
日本法人が窓口なら、個人情報の扱いは国内への委託と同じですか？
同じとは限りません。海外の拠点が個人データを取り扱う場合は、外国にある第三者への提供に関するルールが関係します。本番の個人データを使わずに開発できるかどうかを、最初に確認してください。
10点すべてに、その場で答えられない会社は避けるべきですか？
その場で答えられない項目があること自体は、問題ではありません。持ち帰った質問に、後日きちんと回答があるかどうかを見てください。この記事でも、MOHAが公開していない項目は「ご質問ください」としています。
お問い合わせ・ご相談
この10点は、そのままMOHAへの質問としてお使いいただけます。契約条件や体制、個人データの扱いについて、貴社の案件に沿ってお答えします。お問い合わせ・ご相談からご連絡ください。
参考文献
- 経済産業省「IT人材需給に関する調査（概要）」（平成31年4月）https://www.meti.go.jp/policy/it_policy/jinzai/gaiyou.pdf
- オフショア開発.com「オフショア開発白書（2025年版）」https://www.offshore-kaihatsu.com/news/articles/wp_2025/
- IPA「情報システム・モデル取引・契約書（第二版）」https://www.ipa.go.jp/digital/model/model20201222.html
- 厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」https://www.mhlw.go.jp/bunya/koyou/gigi_outou01.html
- 「個人情報の保護に関する法律についてのガイドライン（外国にある第三者への提供編）」（令和7年12月一部改正）https://www.ppc.go.jp/personalinfo/legal/guidelines_offshore/
