受託開発の新規開拓：紹介以外で法人案件との接点を作る
2026/09/16｜内容確認・更新：2026/09/17
「紹介に頼らず、受託開発の法人商談を増やしたい」
「問い合わせはあるが、予算・決裁者・開発範囲が合わない商談が多い」
受託開発の新規開拓では、最初に「どの開発案件なら受けられるか」と「初回商談に進める条件」を決めることが重要です。発注したい企業を広く集めるだけでは、要件確認や見積もりの前段階で工数が膨らみます。
この記事では、システム開発会社が紹介以外で法人案件との接点を作るときに整理したい、対応領域、対象企業、初回接触、商談条件、ハウスリストや失注リストのフォローを解説します。
目次
受託開発の新規開拓で最初に決めること
受託開発の営業は、単価や技術領域だけでなく、相手企業の検討段階によって難しさが変わります。要件が固まっていない企業、既存システムの刷新を検討している企業、開発会社の比較を始めた企業では、必要な会話が異なります。
まず決めたいのは、次の3点です。
- 対応できる開発領域：業務システム、Webサービス、アプリ、保守運用、既存システム改修など
- 商談に進めたい企業条件：業種、従業員規模、利用中システム、決裁構造、予算感、開発時期
- 初回商談の成立条件：決裁者または担当部門が参加するか、課題と検討時期が確認できているか
この条件が曖昧なまま新規開拓を始めると、商談数は増えても、要件整理に進まない面談や相見積もりだけの相談が増えます。
得意案件から商談条件までの整理表
受託開発会社の新規開拓では、営業先リストを作る前に、得意案件と初回商談の条件を1枚にまとめます。営業担当や外部パートナーへ依頼するときも、この表があると対象外の商談を減らしやすくなります。
| 整理項目 | 確認する内容 | 商談前に決める基準 |
|---|---|---|
| 得意案件 | 新規開発、既存改修、業務システム、SaaS連携、保守運用など | 売上規模だけでなく、自社が要件定義・設計・実装・運用のどこまで担えるかを明確にする |
| 営業先 | 業種、部署、既存システム、開発体制、内製/外注の状況 | 発注可能性がある部署と、検討開始のきっかけを仮説化する |
| 初回接触 | 課題、検討時期、関係者、既存ベンダー、資料送付の可否 | いきなり見積もりへ進めず、課題と検討体制を確認する |
| 商談条件 | 決裁者同席、予算感、開発時期、依頼範囲、競合比較の有無 | 商談として受ける条件と、情報収集段階として扱う条件を分ける |
| 引継ぎ | ヒアリング内容、NG条件、次回確認事項、提案資料の要否 | 営業からPM・プリセールスへ渡す情報を定型化する |
案件タイプ別に営業先と接触きっかけを決める
営業先は「受託開発を発注しそうな会社」と広く置くより、得意な案件タイプごとに、相手部署、接触のきっかけ、初回で確認することを分けると選びやすくなります。下表は説明用の仮定例であり、実際の顧客事例や成果実績ではありません。
| 得意案件 | 狙う企業・部署 | 接触きっかけの例 | 初回で確認すること | 避けたい打診 |
|---|---|---|---|---|
| 業務システム開発 | 紙、Excel、既存パッケージで受発注・在庫・帳票を運用している中堅企業の業務部門、情報システム部門 | 拠点追加、担当者交代、入力ミス増加、既存ツールの限界、基幹システム刷新前の周辺業務整理 | 対象業務、現行フロー、利用中システム、関係部署、要件整理に参加できる担当者 | 業種名だけで一斉に「DXできます」と送る |
| Webサービス・アプリ開発 | 新規事業、会員サービス、予約・申込・ECなどの顧客接点を持つ事業部、マーケティング部門、プロダクト担当 | 新サービスの告知、既存サイトの会員化、スマホ対応、外部SaaS連携、PoC後の本開発検討 | 想定ユーザー、既存サイト/アプリ、必要な連携、初期リリース範囲、運用担当 | 企画が未定の段階で開発単価や納期だけを提示する |
| 保守・改修・引継ぎ | 既存ベンダーの対応遅延、担当者退職、古いフレームワークやサーバーの保守期限に悩む情報システム部門、管理部門 | 障害対応の長期化、機能追加が止まっている、仕様書不足、サーバー更新、セキュリティ対応 | ソースコード・環境へのアクセス可否、現行ベンダー契約、改修希望、緊急度、調査フェーズの必要性 | 現状調査なしに「すぐ安く引き継げる」と約束する |
得意案件から引継ぎまでの記入済み例
営業担当や外部パートナーへ依頼する前に、1案件タイプだけでも記入済みの形にしておくと、初回接触の質をそろえやすくなります。以下は説明用の仮定例です。実際の顧客事例、受注率、開発単価を示すものではありません。
| 得意案件 | 狙う企業 | 初回打診 | 確認質問 | 商談後の引継ぎ |
|---|---|---|---|---|
| 受発注・在庫まわりの業務システム改修 | 複数拠点で受注表、在庫表、基幹システムへの入力が分かれている可能性がある卸売・製造系企業 | 公開情報で拠点追加や取扱商品拡大が確認できる場合に、受発注や在庫確認の手作業が増えていないかを聞く。困りごとの断定はしない。 | 現行の入力元、二重入力の有無、既存システム名、関係部署、刷新か部分改修か、検討時期 | 課題仮説、確認済み情報、未確認事項、NG条件、次回同席してほしい職種をPM・プリセールスへ渡す |
| 会員サイト・予約機能のWeb開発 | 既存サイトで資料請求、予約、申込を受けているが、顧客管理や決済・通知が分断していそうなサービス企業 | 新規集客や既存顧客向け施策の文脈で、Web側と業務側の連携に検討余地があるかを聞く。 | 既存CMS/CRM、会員登録の有無、決済・通知・予約の連携先、初期リリースで必要な範囲、運用担当 | 想定ユーザー、必須機能、連携候補、運用制約、提案前に顧客側で整理が必要な論点を渡す |
| 既存システムの保守引継ぎ・小規模改修 | 長く使う社内システムがあり、改修依頼の滞留や担当者退職で保守体制を見直したい企業 | 障害や不満を決めつけず、現行システムの調査、保守体制、軽微な改修相談の余地を確認する。 | 契約中ベンダーの有無、ソースコード・設計書・環境情報の保有、直近の困りごと、緊急対応の要否 | 調査可否、契約上の制約、アクセス権限、優先改修、見積前に必要な資料を技術担当へ渡す |
営業先を決めるときの確認項目
受託開発の営業先は、業種名だけで決めない方が安全です。同じ業種でも、既存システムの老朽化、紙・Excel業務の多さ、外部サービス連携の必要性、内製エンジニアの有無によって提案内容が変わります。
営業先を選ぶときは、企業属性と課題仮説を分けて整理します。たとえば「中堅製造業」だけではなく、「受発注・在庫・帳票処理が複数システムに分かれている可能性がある企業」のように、接点を作る理由まで言語化します。
また、既存顧客と似た企業へ広げる場合でも、顧客名や実績を許可なく使わないようにします。公開できる実績がない場合は、対応範囲や進め方、確認項目を説明し、誇張した成果数値で補わないことが大切です。
初回接触で聞き出すべき情報
初回接触では、開発内容を細かく聞き切るよりも、商談に進めるための前提を確認します。電話、メール、問い合わせフォーム送信など、接触方法ごとに聞ける情報量は違うため、すべてのチャネルで同じ深さのヒアリングを求めない方が現実的です。
- 現在困っている業務やシステムは何か
- 新規開発、既存改修、保守引継ぎのどれに近いか
- 検討時期はいつか、急ぎの理由はあるか
- 社内の関係者や決裁者は誰か
- 予算感や見積もり取得状況を話せる段階か
- 既存ベンダーや内製チームとの関係に制約はあるか
この情報が揃うと、初回商談で「何を提案するか」ではなく「何を確認すべきか」が明確になります。営業担当から技術担当へ引き継ぐ場合も、会話の再確認が減ります。
ハウスリストと失注リストのフォロー
紹介以外の新規開拓というと、まったく新しいリスト作成から考えがちです。しかし受託開発では、過去に問い合わせがあった企業、提案後に止まった企業、予算や時期が合わなかった企業のフォローも有効な接点になります。
ハウスリストを使う場合は、過去の接点を確認し、同じ提案を繰り返さないようにします。失注リストでは、失注理由が価格、時期、体制、仕様未確定、既存ベンダー継続のどれだったのかを分けます。
| 対象リスト | 再接触の切り口 | 注意点 |
|---|---|---|
| 過去問い合わせ | 検討状況、要件の変化、社内体制の変化を確認する | 問い合わせ直後の温度感を前提にせず、現在の課題を聞き直す |
| 提案後に停止 | 予算化、優先順位、関係者の変更を確認する | 前回提案の押し直しではなく、止まった理由を確認する |
| 失注先 | 導入後の課題、追加開発、保守体制の不満を確認する | 競合批判ではなく、自社が支援できる範囲を聞く |
| 既存顧客周辺 | 別部門、追加機能、連携システムの課題を確認する | 既存契約の範囲と営業許可を確認する |
内製・紹介・外部商談獲得の使い分け
受託開発の新規開拓では、内製営業、紹介、外部の商談獲得支援を同じ役割で比べないことが重要です。受注可否、要件定義、見積、提案、契約条件の判断は顧客側と自社の商談で詰める領域であり、外部支援だけで元請案件やエンド案件の獲得を保証するものではありません。
| 方法 | 向いている条件 | 担う役割 | 社内に残す判断 | 併用時の注意点 |
|---|---|---|---|---|
| 内製営業 | 技術担当や代表が強い案件を説明でき、既存顧客・過去商談・業界知見を持っている | 商談条件の定義、既存接点の深掘り、技術的な見立て、提案前の優先順位づけ | 対応可否、見積方針、体制、契約条件、受けない案件の線引き | 代表やPMだけに依存すると、開発繁忙期に新規開拓が止まりやすい |
| 紹介・協業 | 既存顧客、士業、コンサル、制作会社、SaaS導入支援会社などが発注前の課題を聞きやすい | 信頼関係のある相手から課題文脈をつなぐ、対象外の相談を早めに見分ける | 紹介元への説明範囲、顧客情報の扱い、紹介後の責任分担、利益相反の確認 | 紹介数を増やすだけではなく、紹介しやすい案件条件と対象外条件を共有する |
| 外部商談獲得 | 対象企業と初回商談条件を定義でき、電話・メール・フォーム送信などの接点量を増やしたい | リスト作成、初回接触、商談日程調整、断り理由・ヒアリング情報の記録 | 要件定義、見積、提案、契約、受注判断、技術調査の実施可否 | アポイント数だけを成果にせず、確認質問と引継ぎ項目を事前に決める |
営業代行へ相談する前に決める条件
受託開発の新規開拓を外部へ相談する場合は、アポイント数だけでなく、商談として受け取る条件を先に決めます。開発案件は要件が曖昧なまま進むことも多いため、初回商談の条件を厳しくしすぎると接点が減り、緩すぎると技術担当の工数が増えます。
Sales Engineでは、BtoBの商談獲得を対象に、商材・対象・商談条件・対応内容を確認して個別見積します。初期費用、月額固定費、最低期間、最低利用金額はありません。合意した支援に必要なリスト、スクリプト、システム、電話、メール、フォーム送信、SMS、MAなどは商談単価に含みますが、すべてのチャネルを全案件で無条件に実施するものではありません。
商談条件は相談でき、NGリストの指定も可能です。未実施商談には費用が発生せず、管理画面からの申請をもとに再アポイント調整を行います。一方で、受注、元請・エンド案件の獲得、商談件数、検索順位などの保証はありません。通話履歴、文字起こし、AI分析を使い、トークと追客を改善していく前提で検討します。
まとめ
受託開発の新規開拓は、紹介以外の接点を増やす前に、得意案件、営業先、初回接触、商談条件、引継ぎ情報を整理することが出発点です。開発を発注したい企業をただ集めるのではなく、自社が対応できる案件と商談前に確認すべき条件を分けておきましょう。
ハウスリストや失注リストも、過去の接点を現在の検討状況へつなぎ直せば、新規開拓の対象になります。外部支援を使う場合は、商談単価だけでなく、対象企業、NG条件、ヒアリング項目、引継ぎ形式まで確認してから始めることが大切です。
