システム開発では、契約した開発会社がすべての作業を自社内で行うとは限りません。一部の工程を別の会社に委託する「再委託」や、海外の拠点・パートナーと連携して開発する「オフショア開発」が用いられることがあります。これらは、コストや体制を最適化するための一般的な選択肢であり、それ自体が良し悪しを決めるものではありません。
本記事は連載第9回として、再委託・オフショア体制が含まれる場合の確認項目を整理します。重要なのは、どこで開発されるかという立地そのものよりも、体制・責任の所在・品質管理・コミュニケーション・情報管理が明確に設計されているかどうかです。本記事は、立地を問わず適用できる観点で整理します。
まず結論
- 再委託・オフショアは、それ自体が良い悪いを決める要素ではありません。見るべきなのは体制と管理の仕組みです。
- 発注前に確認するのは、体制図、責任分界、品質レビュー、コミュニケーション経路、情報管理の5点です。
- 契約上の窓口と責任者が元請けに明確に残っているかを確認すると、トラブル時の対応がぶれにくくなります。
| 見る項目 | 判断のしかた | 発注前の確認ポイント |
|---|---|---|
| 体制図 | 誰がどの工程を担うか | 元請け・再委託先・拠点を明示 |
| 責任分界 | 不具合や遅延の責任者 | 発注側の窓口を一本化 |
| 情報管理 | データの保管・アクセス・削除 | NDAと契約終了後の扱い |
OUTCOME BLUEPRINT
AI/DX投資の前に、成果KPIと発注条件を整理しませんか？
補助金、SaaS選定、開発見積、PoCの前に、業務要件・費用レンジ・RFP・合格条件を成果起点で整理します。
この連載での位置づけ
- 前に読む記事：連載第8回：クラウド・API費
- 次に読む記事：連載第10回：RFP
- 比較表で整理する：連載第11回：比較表
- 発注前の質問に落とし込む：連載第12回：開発会社への20問
再委託・オフショアが用いられる理由
再委託やオフショア開発が選ばれるのには、合理的な理由があります。
- 特定の技術領域に強いパートナーに任せられる
- 開発リソースを柔軟に確保できる
- コストを最適化できる場合がある
- 大規模・短納期の案件で、体制を拡張できる
一方で、複数の会社や拠点が関わることで、責任の所在やコミュニケーションの経路が複雑になる側面もあります。だからこそ、見積段階で体制を確認しておくことが重要になります。
確認すべき5つの観点
再委託・オフショアが含まれる場合に確認したいのは、次の5つの観点です。いずれも、立地ではなく仕組みに着目した観点です。
| 観点 | 確認したいこと |
|---|---|
| 体制図 | 誰が・どの会社が・どの工程を担うか |
| 責任分界 | 不具合や遅延が起きたとき、どこが責任を持つか |
| 品質管理 | 成果物の品質を、誰がどう確認するか |
| コミュニケーション | 言語・時差・窓口をどう設計するか |
| 情報管理 | データや資料の管理・取り扱いのルール |
体制図
まず、プロジェクトに関わる会社・拠点と、それぞれが担う工程を体制図で確認します。元請けの開発会社が窓口となり、再委託先やオフショア拠点をまとめる形が一般的です。発注側から見て、誰に何を言えばよいかが明確になっているかが大切です。
体制図では、工程ごとの担当だけでなく、各フェーズで誰が成果物をレビューし、誰が承認するかのフローも確認できると理想的です。「開発は再委託先」「レビューは元請けのシニアエンジニア」「発注側への報告は元請けPM」というように役割と接点が整理されていれば、進行中の課題発生時にどこに連絡すれば解決できるかが明確になります。
責任分界
複数の会社が関わる場合、「不具合が起きたとき、どこが対応するのか」「遅延が起きたとき、誰が責任を持つのか」を明確にしておく必要があります。契約上は元請けが一括して責任を負う形が多いですが、その認識を双方で共有しておくことが重要です。
責任分界を確認する際は、「成果物の検査・受入を行うのはどこか」「瑕疵担保（契約不適合責任）の範囲はどこまでか」という点も合わせて聞いておくと、後から揉めにくくなります。再委託先が関与している場合でも、発注側との契約上の相手は元請けですから、対応ウィンドウは一本化されているかを確認します。
品質管理
オフショアや再委託で作られた成果物の品質を、元請けがどう確認するかは重要な確認点です。レビュー体制やテストの工程が、体制全体で設計されているかを確認します。品質管理の考え方はシステム開発会社の選び方でも整理しています。
品質管理の仕組みとして具体的に確認したいのは、「コードレビューはいつ・誰がやるか」「単体テストの実施と確認の担当者は誰か」「結合テスト・総合テストで元請けが介在するタイミングはいつか」という三つのポイントです。再委託先が作ったものをそのまま納品するのか、元請けが必ず中間チェックを挟むのかでは、品質管理の実態が大きく変わります。
コミュニケーション
海外拠点が関わる場合、言語・時差・連絡経路の設計が、進行の円滑さを左右します。発注側が直接やり取りするのか、日本側の窓口を介するのか、仕様の伝達がどの言語で行われるかを確認します。これは特定の地域を避けるという話ではなく、意思疎通の仕組みを確認するという観点です。
確認しておくと特に有効なのは、「仕様や要件の変更を伝えるとき、どの言語でどの経路を通って開発担当者に届くか」という伝達フローです。元請けがきちんと翻訳・整理して伝えるのか、発注側の資料がそのまま渡されるのかによって、認識のずれの起きやすさが変わります。また、時差がある場合は「急な問い合わせに対して、その日のうちに回答をもらえるか」「定例会議の時間帯はどう設定されるか」も実務的な確認点です。
情報管理
自社の業務データや資料が、どこで・どのように管理されるかは、確認しておきたい点です。アクセスできる範囲、データの保管場所、契約終了後の取り扱い、秘密保持の取り決め（NDA）などを確認します。これも立地ではなく、管理ルールが明文化されているかが論点です。
情報管理については、特に個人情報や顧客データを扱う開発の場合、「開発環境で本番データを使うか、マスキング済みのデータを使うか」「再委託先との間にもNDAが締結されているか」「システムのソースコードや設計書の保管・閲覧の権限はどこまで及ぶか」を確認します。これらは要件定義や開発の進行中に判断するより、見積・提案の段階で確認しておくほうが、後の認識のずれを防げます。
元請けが一括して窓口になる体制が基本
再委託やオフショアが含まれる場合でも、発注側から見た窓口は、契約した元請けの開発会社に一本化されているのが基本です。発注側が再委託先と直接やり取りする形は、責任の所在があいまいになりやすく、避けるのが一般的です。元請けが全体を取りまとめ、進捗・品質・課題を一括して管理し、発注側はその元請けと向き合う、という形になっているかを確認します。窓口が明確であれば、複数の会社が関わっていても、発注側の負担は大きくなりません。
契約・情報管理で取り決めておく項目
再委託・オフショアを含む場合に、契約や取り決めで確認しておきたい項目を挙げます。
- 再委託の可否と、再委託先を事前に開示する取り決め
- 秘密保持契約（NDA）の対象範囲（再委託先も含むか）
- 業務データの保管場所と、アクセスできる範囲
- 契約終了後のデータの返却・削除の取り扱い
- 不具合・遅延が起きたときの責任の所在
これらが文書で取り決められていれば、立地にかかわらず、安心して任せられる体制かを判断する材料になります。
見落としやすい論点：体制の「深さ」を確認する
体制図の有無を確認するだけでなく、体制の「深さ」にも目を向けることをおすすめします。たとえば、体制図には元請けとオフショア拠点しか記載されていないが、実際にはオフショア拠点がさらに別のパートナーに一部作業を流している、というケースがあります。再委託のなかに再々委託が含まれる場合、品質管理と責任分界の実態が複雑になります。
「再委託先が、さらに別の会社に委託することはありますか」という一問を加えるだけで、体制の実態が見えやすくなります。これも排除の話ではなく、管理の連鎖がどこまで設計されているかを確認するための問いです。管理が及んでいる範囲と、その根拠を示してもらえれば、判断の材料になります。
体制の深さと合わせて、「発注側がいつ・何を承認するか」のタイミングを確認しておくことも重要です。中間成果物のレビュータイミング（要件定義完了後、設計完了後など）が明示されていれば、発注側が品質に関与できる接点が整理されます。これは追加費用の発生条件とも連動するため、システム開発の発注プロセス チェックリストの整理とセットで考えると分かりやすくなります。
発注前チェックリスト（再委託・オフショア）
- 再委託やオフショアが含まれるかどうか、見積・提案で開示されているか
- 関わる会社・拠点と、各工程の担当を示す体制図があるか
- 体制図に記載された再委託先が、さらに別の会社へ委託しているかどうか確認したか
- 不具合・遅延が起きたときの責任の所在が明確か
- 成果物の品質を、元請けがどう確認するかが分かるか
- 単体テスト・コードレビューの実施主体が体制図と一致しているか
- コミュニケーションの窓口・言語・連絡経路が設計されているか
- 仕様変更や急な問い合わせに対する回答タイムラインが共有されているか
- 業務データや資料の管理場所・アクセス範囲が分かるか
- 開発環境で本番データを使うか、マスキング処理を行うかが確認できているか
- 秘密保持の取り決め（NDA）と、契約終了後のデータの取り扱いが定められているか
- 再委託の可否や条件が、契約で取り決められているか
開発会社に確認する質問
- 「この開発に、再委託やオフショアは含まれますか。含まれる場合、体制図を見せてください」
- 「再委託先が、さらに別の会社に委託することはありますか」
- 「不具合や遅延が起きたとき、どこが責任を持って対応しますか」
- 「オフショアや再委託先の成果物は、誰がどのように品質を確認しますか」
- 「コードレビューと単体テストの実施は、元請けの担当者が行いますか、再委託先ですか」
- 「私たちとのやり取りは、どの窓口・どの言語で行われますか。急な確認が発生した場合、当日中に回答をいただけますか」
- 「私たちの業務データは、どこで管理され、契約終了後はどう扱われますか」
- 「秘密保持契約（NDA）は、再委託先も対象として含まれますか」
体制と情報管理を率直に開示できる相手は、複数拠点での開発を管理する仕組みを持っている傾向があります。
相談前に整理しておくとよい情報
- 取り扱うデータの機密度（個人情報・顧客情報の有無）
- 社内の情報管理・セキュリティに関する社内ルール
- コミュニケーションに求める頻度・スピード
- 想定している納期と、体制拡張の必要性
- すでに受け取っている提案で、体制がどう示されているか
これらを整理しておくと、再委託・オフショアを含む体制が自社の要件に合うかを、立地ではなく仕組みの観点で判断しやすくなります。
GXOの発注前レビューで見る実務メモ
GXOが再委託・オフショアを含む見積を確認するときは、国や地域ではなく、体制図、責任分界、情報管理、品質確認、窓口の5点を見ます。たとえば3社以上が関わる案件では、誰が要件を決め、誰が実装し、誰がレビューし、誰が検収前の不具合を直すのかを1枚の体制図にします。
見積段階で確認したいのは、単価差よりも管理の深さです。週1回の定例、課題管理表、コードレビュー、テスト結果、NDA、契約終了後のデータ削除、24時間以内の障害一次回答など、運用ルールが具体化されているかを確認します。これらが明確なら、国内外を問わず比較しやすくなります。
| 確認領域 | 見るポイント | 発注前の質問例 |
|---|---|---|
| 体制 | 元請け、再委託先、担当工程 | 体制図を見せてもらえますか |
| 品質 | レビュー、テスト、検収前確認 | 誰が成果物を確認しますか |
| 情報管理 | アクセス権、保管場所、削除 | 契約終了後のデータはどう扱いますか |
| 連絡 | 窓口、言語、時差、定例 | 緊急時は誰に連絡しますか |
| 契約 | 責任分界、NDA、再委託可否 | 不具合時の責任範囲はどこですか |
参考にすべき一次情報・確認観点
見積書を社内稟議やベンダー比較に使う場合は、一般論だけで判断せず、公式資料と自社データを照合してください。特に契約形態、責任分界、DX投資の目的、セキュリティ要件は、見積金額より前にそろえるべき前提です。
- IPA「情報システム・モデル取引・契約書」：請負、準委任、成果物、検収、責任分界を確認する際の参考になります。
- 経済産業省「DX推進指標」：経営課題、ITシステム、組織体制を分けて、DX投資の目的を確認する際の参考になります。
- 自社の見積比較では、3社比較、5年TCO、月額5万円・10万円・15万円、画面20件、帳票10件、API3本、移行データ1000件、受入テスト5日、操作研修2回、障害受付24時間、初期予算500万円・1000万円など、仮でも数字を置いて前提をそろえます。
- AI開発、セキュリティ要件、補助金活用を含む案件では、機能要件だけでなく、ログ保管、個人情報、権限管理、証跡、補助対象経費の切り分けも見積条件に入れてください。
よくある質問
Q. オフショア開発は品質が心配です。
A. 判断の軸は、どこで開発されるかという立地そのものではなく、体制・責任分界・品質管理の仕組みです。オフショアや再委託先の成果物を、元請けがどのようにレビューし品質を確認するかが設計されているかを確認すると、判断しやすくなります。
Q. 再委託されること自体は問題ですか。
A. 一般的な選択肢であり、それ自体が問題とは限りません。重要なのは、再委託の有無が開示され、責任の所在と窓口が明確かどうかです。発注側から見た窓口は、契約した元請けに一本化されている形が基本です。
Q. 自社のデータは安全に扱われますか。
A. データの保管場所、アクセスできる範囲、契約終了後の取り扱い、秘密保持の取り決め（NDA）を文書で確認します。これらが明文化されていれば、立地にかかわらず、管理の状態を判断する材料になります。
Q. 体制図を見せてもらえない場合はどう判断すればよいですか。
A. 体制図の提示を断る、あるいは「社内の情報なので開示できない」と言われる場合は、再委託の構造を発注側が把握できないことを意味します。体制を透明にできないことは、責任の所在も不明確になりやすいため、その点を理解したうえで判断することになります。体制の開示に率直に応じるかどうかそのものが、管理体制の成熟度を測る材料になります。
まとめ
再委託やオフショア開発は、コストや体制を最適化するための一般的な選択肢です。判断の軸は、どこで開発されるかという立地そのものではなく、体制図・責任分界・品質管理・コミュニケーション・情報管理という仕組みが明確に設計されているかどうかにあります。見積・提案の段階でこれらを開示してもらい、自社の要件に照らして確認することで、安心して任せられる体制かを判断できます。次回は、そもそも見積を取る前提となる「RFP」の有無が見積に与える影響を扱います。
関連記事
システム開発の見積・相見積もりを整理しませんか
GXOでは、システム開発の見積書、相見積もり、要件定義、開発会社選定について、発注前の整理をご支援します。総額だけでなく、工数、保守範囲、追加費用、体制、契約条件まで確認し、自社に合う進め方を一緒に整理します。
※ 初回相談では、営業資料の説明よりも見積内容と発注前の論点整理を優先します。
