開発パートナーの選び方|開発会社が外部パートナーに依頼するときの見極めポイント
受託開発の案件が重なったときや、自社にない技術が必要になったとき、開発会社が外部の開発パートナーに作業の一部を依頼する場面は珍しくありません。うまく組めれば受注できる案件の幅が広がりますが、パートナー選びを誤ると、品質の問題や納期の遅れが自社の顧客との関係に直接響きます。
顧客から見れば、作業を誰が担当したかに関係なく、責任を負うのは契約の相手である自社です。パートナーの成果物に不具合があっても、顧客に対しては自社の不具合として対応しなければなりません。だからこそ、技術力だけでなく、進め方や体制の安定性まで含めて見極める必要があります。
また、パートナーへの依頼には、顧客との契約の再委託条項、取引の適正化に関する法律、労働者派遣との線引きといった、法令や契約上の確認事項も伴います。ここを曖昧にしたまま進めると、品質とは別の問題を抱えることになります。
この記事では、開発会社が外部の開発パートナーに依頼するときに、事前に決めておくこと、見極めのポイント、契約と法令の確認事項、小さく試してから広げる進め方を、判断基準とともに解説します。
依頼する前に決めておくこと

パートナー探しを始める前に、「何を、どの形で任せるのか」を決めておく必要があります。任せ方によって、求める能力も、契約の形も、自社側に必要な体制も変わるためです。
| 任せ方 | 内容 | パートナーに求める能力 | 自社側に必要なこと |
|---|---|---|---|
| 工程単位 | 詳細設計以降の実装とテストなど、工程をまとめて任せる | 設計書を読み解き、品質を自ら管理できること | 工程の入口となる設計書と、受け入れの基準 |
| 機能単位 | 管理画面、外部連携など、機能のまとまりを任せる | その機能領域の経験と、他の機能との結合を意識した設計 | 機能間のインターフェースの定義と結合テストの計画 |
| チーム単位 | リーダーを含むチームで、一定期間の開発を任せる | チーム内の進行管理と、優先順位の変化への対応 | 優先順位を判断し、チームのリーダーと調整する担当者 |
| 専門技術のスポット支援 | 性能改善、インフラ構築、データ基盤など特定の課題を任せる | その技術の深い知識と、調査結果を説明できる力 | 課題の範囲と、完了の判断基準 |
自社側に必要なことが用意できない任せ方は、選ばない方が安全です。たとえば、設計書を十分に書く余裕がないのに工程単位で任せると、パートナーは推測で実装するしかなく、手戻りが増えます。その場合は、設計から一緒に進められるチーム単位の任せ方の方が合っています。
あわせて、顧客との契約上、再委託が認められているかも最初に確認してください。独立行政法人情報処理推進機構(IPA)と経済産業省の「情報システム・モデル取引・契約書」(第二版)では、再委託に顧客の事前承諾を必要とする案と、原則として受注者の裁量としつつ顧客が中止を求められる案の二つが示されています。どちらの場合も、受注者は再委託先に自社と同様の義務を負わせる契約を結び、再委託先の履行について自ら業務を遂行した場合と同様の責任を負う形になっています。
顧客との契約が準委任の場合は、民法第644条の2により、顧客の許諾を得たときか、やむを得ない事由があるときでなければ、作業を別の者に任せることができません。契約書に再委託の条項がない場合でも、確認を省かないようにしましょう。
参考:情報システム・モデル取引・契約書(第二版)/IPA(情報処理推進機構)
参考:民法/e-Gov法令検索
見極めのポイント

パートナー候補を比較するときは、技術力だけを見て判断しがちです。しかし、実際の協業で問題になりやすいのは、技術そのものより、進め方、品質の管理、連絡の取り方、体制の継続性です。確認したい観点を表にまとめます。
| 観点 | 確認すること | 確認の方法 |
|---|---|---|
| 技術 | 必要な言語・フレームワーク・クラウドの実務経験があるか | 過去の担当範囲を具体的に聞く。可能なら過去のコードや設計書の抜粋を見せてもらう |
| 品質の管理 | コードレビュー、テストの書き方、不具合の記録方法が決まっているか | レビューの手順とテストの範囲を説明してもらう |
| 進め方 | 見積もりの根拠、進捗の報告方法、課題の上げ方 | 見積もりの内訳と、遅れが出たときの連絡の流れを聞く |
| コミュニケーション | 質問の質と速さ、仕様の不明点を自分から確認するか | 打ち合わせで出てくる質問の中身を見る |
| 体制の継続性 | 担当者が抜けたときの代替、特定の個人に依存していないか | チームの人数と、交代時の引き継ぎ方法を聞く |
| 情報管理 | ソースコードや顧客データの取り扱いルール、端末やアカウントの管理 | 社内規程や、取得している認証があればその範囲を確認する |
このうち、事前の面談で最も差が出やすいのが、質問の質です。仕様の説明をしたときに、例外ケース、既存データの扱い、性能の前提など、作る前に確認すべきことを自分から質問してくるパートナーは、実装の段階でも不明点を放置しにくい傾向があります。説明をそのまま受け取って質問がない場合は、理解しているのか、確認する習慣がないのかを見極める必要があります。
見積もりの比較では、金額だけでなく内訳の粒度を見てください。作業を細かく分解して見積もっているパートナーは、どこに不確実性があるかも把握していることが多く、開発中に問題が起きたときの説明も具体的です。「一式」の見積もりしか出せない場合は、作業の全体像を把握していない可能性があります。
過去の実績を確認するときは、案件名や顧客名よりも、そのパートナーが担当した範囲を具体的に聞くことが大切です。同じ「業務システムの開発」でも、要件定義から関わったのか、決まった設計に沿って一部の画面を実装しただけなのかで、任せられる範囲は大きく違います。自社が任せたい任せ方と、過去に担当した範囲が近いかどうかを確認しましょう。
契約と法令で確認すること

開発会社が外部パートナーに依頼する取引は、取引の適正化に関する法律の対象になることが多く、自社が発注者としての義務を負います。依頼する前に、次の法令との関係を確認しておきましょう。
中小受託取引適正化法(取適法)
2026年1月1日に改正法が施行され、通称が「取適法」になりました。顧客から受託したプログラムの作成を外部に委託することは、情報成果物作成委託にあたります。プログラム作成の委託では、委託する側が資本金3億円超で受ける側が3億円以下(個人を含む)、または委託する側が資本金1千万円超3億円以下で受ける側が1千万円以下(個人を含む)の場合に対象になります。改正により、委託する側の従業員が300人超で受ける側が300人以下という従業員基準も加わりました。
対象になる場合、委託する側には、発注内容(給付の内容、代金の額、支払期日、支払方法など)を書面または電子メールなどで明示する義務、取引の記録を作成して2年間保存する義務、受領した日から60日以内のできる限り短い期間で支払期日を定める義務、支払が遅れた場合の遅延利息を払う義務が課されます。あわせて、受け取った成果物の受領拒否、代金の減額、買いたたき、無償でのやり直しの要求、価格協議に応じない一方的な代金決定、手形払いなどが禁止されています。
実務で特に注意したいのは、顧客の検収を待ってからパートナーに支払うという運用です。支払期日はパートナーから成果物を受け取った日から起算するため、顧客の検収が遅れたことを理由にパートナーへの支払いを遅らせることはできません。顧客との支払条件とパートナーへの支払条件を、資金繰りも含めて先に設計しておく必要があります。
フリーランス・事業者間取引適正化等法
個人のフリーランスに依頼する場合は、2024年11月1日に施行された「特定受託事業者に係る取引の適正化等に関する法律」も関係します。業務を委託したときは、直ちに取引条件を書面または電磁的方法で明示する必要があり、従業員を使用する法人などの発注者には、受領した日から60日以内に支払期日を定める義務などが課されます。
労働者派遣との線引き
パートナーのエンジニアに、自社の社員が直接作業の割り振りや労働時間の指示を出すと、契約が請負や準委任であっても、実態として労働者派遣とみなされるおそれがあります。厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」とその疑義応答集は、準委任でも実態として指揮命令があれば労働者派遣にあたるとしています。
パートナーのエンジニアを顧客先に常駐させ、顧客の担当者が直接指示を出す形は、特にリスクが高くなります。作業の指示はパートナー側の責任者を通す、顧客との打ち合わせには自社の担当者が同席するなど、指示の経路を契約と運用の両方で決めておきましょう。
参考:製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律/e-Gov法令検索
参考:製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律第七条の書類等の作成及び保存に関する規則/e-Gov法令検索
参考:特定受託事業者に係る取引の適正化等に関する法律/e-Gov法令検索
小さく試してから広げる

面談や見積もりだけでは、実際の協業でどれだけ噛み合うかは分かりません。初めてのパートナーには、範囲の小さい作業から依頼し、結果を見てから任せる範囲を広げる方法が安全です。
試しに依頼する作業は、次の条件を満たすものを選ぶと、評価がしやすくなります。
- 数週間程度で完了し、失敗しても顧客の納期に影響しない
- 完了の基準が明確で、成果物を自社でレビューできる
- 仕様の確認や質問が発生する程度の複雑さがある
- 本番の案件で任せたい技術や工程に近い
評価するときは、成果物の品質だけでなく、作業の途中の振る舞いを見てください。不明点をいつ、どのように質問してきたか、遅れの兆候を早めに伝えてきたか、レビューでの指摘をどう反映したかといった点は、規模の大きい案件を任せたときの進み方をよく表します。
| 試行の結果 | 次の判断 |
|---|---|
| 品質も進め方も期待どおり | 工程単位や機能単位など、任せる範囲を広げる |
| 品質は良いが、連絡や報告に課題がある | 報告の形式と頻度を決め直したうえで、もう一度同規模の作業で確認する |
| 連絡は良いが、品質にばらつきがある | 自社のレビューを厚くできる範囲に限定して依頼する |
| 品質も進め方も課題が大きい | 依頼を見送り、別の候補を探す |
試行の作業にも、もちろん正当な対価を払う必要があります。評価のためだからといって無償で作業を求めることは、前述の法律で禁止されている不当な経済上の利益の提供要請にあたるおそれがあり、信頼関係の面でも逆効果です。
長く組むための運用

良いパートナーと長く組めると、業務知識や自社の開発ルールの説明が不要になり、立ち上がりが速くなります。そのためには、選んだ後の運用も大切です。
第一に、受け入れの基準を文書にしておくことです。コーディング規約、テストの範囲、レビューの観点、ドキュメントの形式を決めておけば、パートナーが変わっても品質のぶれを小さくできます。基準が自社の担当者の頭の中にしかないと、レビューのたびに指摘が増え、双方の負担になります。
第二に、技術的な判断をパートナーに丸投げしないことです。設計の重要な判断や、顧客の業務に関わる仕様の解釈は、自社が責任を持って決める必要があります。顧客に説明できない技術選定や設計が入り込むと、保守の段階で自社が対応できなくなります。
第三に、情報とノウハウの流れを片方向にしないことです。パートナーが作業の中で得た知見や、顧客の業務に関する情報を、設計書や議事録として自社にも残してもらう取り決めをしておきましょう。特定のパートナーの特定の担当者しか分からない部分が増えると、パートナーとの関係が終わったときに引き継げなくなります。
支払と条件の見直しも、関係を続けるうえで欠かせません。支払期日を守ること、作業範囲が増えたときに追加の対価を協議することは、法令上の義務であると同時に、優秀なパートナーに選ばれ続けるための条件です。良いパートナーほど他社からも依頼を受けているため、条件が見合わなければ離れていきます。
まとめ

開発パートナー選びは、任せ方を決めることから始まります。工程単位、機能単位、チーム単位、専門技術のスポット支援のどれで任せるかによって、パートナーに求める能力と、自社側に必要な準備が変わります。顧客との契約で再委託が認められているかも、最初に確認すべき事項です。
見極めでは、技術だけでなく、品質の管理、進め方、質問の質、体制の継続性、情報管理を確認してください。契約面では、取適法やフリーランス・事業者間取引適正化等法による発注内容の明示や60日以内の支払期日、労働者派遣との線引きを押さえる必要があります。
新しいパートナーと組むときは、まず数週間で完了する小さな作業を正当な対価で依頼し、成果物と途中の振る舞いの両方を評価してから範囲を広げましょう。受け入れの基準を文書にし、設計の重要な判断は自社で持つという運用を整えておけば、パートナーとの協業を自社の開発力として積み上げていけます。
