案件情報は届くのに、自社エンジニアの技術や開始時期と合わない。いつもの協力会社以外に営業先を増やしたいが、発注企業の誰に何を伝えればよいか分からない。待機が見えてから動くため、新しい取引先との関係づくりが後回しになる。
この記事は、顧客の開発・運用にエンジニアの技術支援を提供するSES企業の経営者・営業責任者に向けたものです。実際に技術支援を使うエンド企業との接点を作り、紹介を一度きりの出会いで終わらせず、案件相談へ進める方法を説明します。
この記事の結論
SES企業のエンド開拓は、自社が担える技術・役割・参画時期を整理し、発注条件に合う企業へ直接営業や紹介で接点を作り、必要な仕事と参画条件の確認から紹介元への報告・継続相談までを運用します。
SESのエンド開拓は、発注企業との接点から案件化までを設計する
エンド開拓は、実際に技術支援を必要とする企業と新しい取引の接点を作る営業です。担当者と会うだけで終わらず、自社が担える仕事があるか、いつ・どの条件なら発注できるかまで確かめます。
エンド企業・元請け・BPの違いを押さえる
この記事では、技術支援を使う企業を「エンド企業」、その企業から直接仕事を受けて取りまとめる会社を「元請け」、案件や技術者を紹介し合う協力会社を「BP(ビジネスパートナー)」と呼びます。BPは相手との関係を表す呼び方なので、元請け企業がBPになる場合もあります。
「直請け」はエンド企業と直接取引することです。間に入る会社が少ないと顧客の課題を聞きやすくなる一方、取引開始の手続きや契約・稼働の管理を自社で担えるかも確認が必要です。元請けとの協業なら、自社の得意な技術や工程に集中して参加できる場合があります。
狙うのは、顧客の課題が分かり、自社の技術と体制に合う取引です。直請けという形だけで案件を選ばず、元請け経由も含めて、自社が責任を持って支援できる範囲を見ます。
待機を埋める営業と、次の取引先づくりを並行する
直近の稼働を確保するための案件照会と、まだ取引のない企業との関係づくりは、必要な時間が異なります。待機を埋めることが急務なら、条件の合う既存BPや過去の取引先への確認を進めます。同時に、次の取引先を開拓する担当と営業時間を決めます。
新しい接点を、具体的な案件相談へ進める基本の順番は次のとおりです。
- 自社が担える技術・役割と、参画できる時期・体制を整理する。
- その支援が必要になりそうな企業を調べ、話すべき部署と発注条件を確認する。
- 直接連絡するか、紹介元を介するか、元請けと協業するかを選んで接点を作る。
- 初回商談で必要な仕事と条件をそろえ、提案する範囲と次の確認事項を決める。
- 参画の可否を確認し、条件が合わない場合も理由と次回連絡日を残す。
既存BPとの取引を急に減らす必要はありません。紹介元の顧客へ連絡するときは、窓口や役割を事前にすり合わせ、すでにある取引関係を尊重します。
自社の技術と参画条件から、狙うエンド企業を決める
知名度や企業規模だけで営業リストを作ると、話せても提案できない相手が増えます。この記事では実務上、「担える仕事」「必要とされる時期」「取引を始められる条件」の重なりで候補を選びます。
技術名を、任せられる仕事と支援範囲に変える
「Javaのエンジニアがいます」だけでは、発注側はどの仕事を任せられるか判断しにくくなります。例えば「既存のJava業務システムで、仕様を確認しながら改修とテストを進める役割に対応できる」と、工程と役割を添えます。これは説明の例なので、実際の経験と現在の体制に合わせて使ってください。
個人のスキル一覧に加え、会社として提供できる支援をまとめます。担当できる工程、単独かチームか、顧客側に必要な体制、開始可能時期、勤務場所、支援期間、費用条件の考え方を整理します。候補者や採用予定の段階と、参画を約束できる段階は分けて伝えます。
営業と技術側で情報を共有し、開始時期や対応範囲が変わったら更新します。古い情報のまま営業すると、せっかく来た相談にも応えられません。
需要の兆しと、外部企業へ発注できる条件を確かめる
企業のサービス更新、開発職の採用、システム刷新の発表などは、技術支援が必要かを考える手掛かりになります。ただし、求人があるだけで外部企業を使うとは限りません。公開情報から立てた仮説を、会話で確かめます。
例えば、開発を増やしている企業には「新機能の開発に伴って、改修やテストをどの体制で進めていますか」と聞けます。そのうえで、自社が対応できる役割との重なりを確認します。
候補企業を次の営業先へ進める前に、分かっていることと未確認のことを分けます。
- 自社が支援できる仕事と、相手に需要がありそうな理由がある
- 技術や業務の課題を確認できる部署・担当者が分かる
- 外部企業の活用方針と、新しい取引先を受け入れる窓口を確認できる
- 必要な時期・体制・勤務条件が自社の条件と合う、または確認する予定がある
- 次に誰へ何を確認するかが決まっている
顧客側が指定の元請けを通じて発注している場合は、その元請けとの協業を検討します。技術需要があることと、直接契約できることは別に確認します。
直接営業・紹介・元請けとの協業を使い分ける
技術支援が必要な企業へ届く方法は一つではありません。相手を選んだ理由を説明できるなら直接営業、課題を知る相手との関係があるなら紹介、発注経路や提供体制を補う必要があるなら元請けとの協業を検討します。
入口 | 主に話す相手 | 向いている状況 | 最初に行うこと |
|---|---|---|---|
エンド企業への直接営業 | 開発部門、情報システム部門、外部取引の窓口 | 技術需要の仮説と自社の支援範囲が具体的 | 公開窓口の用途を確認し、連絡理由と確認したい課題を短く伝える |
紹介元を介した接点 | 顧客と取引するコンサルや支援会社、その先の担当者 | 課題を聞いている相手に自社の役割を理解してもらえる | 紹介してほしい相談場面と、初回に話す内容を共有する |
元請けとの協業 | 案件を取りまとめる会社の営業・技術責任者 | 得意技術で不足を補える、または顧客の発注経路に合う | 対応できる工程と体制、顧客対応の分担をすり合わせる |
直接営業では、企業名だけを変えた「案件はありませんか」という連絡から一歩進めます。調べた事業上の変化と、自社が担える仕事を結び付け、技術体制について話す機会を依頼します。関係のない窓口へ大量に送ると、話すべき相手へ届くかも判断できません。
紹介では、既存の信頼関係を通じて相談の背景を聞けることが利点です。ただし、紹介元と会えたことをエンド企業との商談に数えてしまうと、実態が見えなくなります。「紹介元との面談」「エンド企業との課題確認」「具体的な案件提案」を分けて記録してください。
紹介元が動けるよう、相談場面と役割を共有する
紹介を継続させるには、誰から紹介してもらうかだけでなく、相手が何を聞いたときに自社を思い出せるかを決めます。さらに、紹介することで相手と顧客にどんな利点があるかを共有します。
技術支援が必要になる場面から紹介元を選ぶ
次は、自社の技術と顧客層に合う候補を探すための例です。業種だけで決めず、実際にどの部署と接しているか、技術支援の相談を聞く機会があるかを確かめます。
紹介元候補 | 技術支援が必要になる場面の例 | SES企業が補える役割 |
|---|---|---|
DX・ITコンサル | 方針は決まったが、実行する開発・運用体制が足りない | 自社の経験に合う工程の技術支援 |
システム開発会社・元請け | 特定技術や工程を担うメンバーが不足する | 得意な役割を分担した体制の補完 |
業務ソフトの導入支援会社 | 導入に伴う連携・移行・運用の作業が増える | 対応可能な技術領域での作業支援 |
技術職の採用を支援する会社 | 採用までの体制をどう維持するか相談される | 顧客が外部支援を検討する場合の選択肢 |
接点は、既存BPとの面談、過去の共同案件、業界の勉強会、同じ顧客層を支援する会社への個別連絡から探せます。最初の面談では、相手の得意分野と対応しきれない相談を聞き、自社が補える場面を一つ確かめます。
例えば採用支援会社との連携なら、採用活動を置き換える話にせず、顧客が採用までの体制を相談している場合に、外部支援が選択肢になるかを話します。顧客が求めていない提案を紹介元に頼まないことも、関係を続けるために必要です。
紹介依頼と、相手に返せる価値を一緒に伝える
非技術者の紹介元には、専門用語を並べたスキル表より、相談場面が伝わる短い説明が役立ちます。技術面の詳細は、顧客の担当者と話す段階で確認します。次は、Webシステムの改修に対応できる会社を想定した依頼文です。
併せて、相手が取りまとめる案件で自社がどの工程を補えるか、相手の対応外の相談をどう引き受けられるかを話します。顧客を紹介してもらう依頼だけでなく、相手の支援を前へ進める協力にします。
顧客へ連絡する担当、最初の面談に同席する人、紹介元に報告する範囲を事前に決めます。顧客と共有を合意した情報から確認し、秘密情報や個人の詳細なスキル情報を必要以上に広げないようにします。
紹介結果と参画可能な条件を更新する
一度面談しただけでは、紹介元はいつ声をかければよいか分かりません。紹介後には、面談の実施状況、次に確認すること、条件が合わなかった理由を、合意した範囲で返します。仕事につながらなかった場合も、次の紹介が合うための情報を残します。
参画可能時期や対応できる役割が変わったら、紹介元へ更新を伝えます。案件がない期間も、相手が相談された技術体制の悩みを聞き、次回の連絡日を決めます。連絡のたびに案件を催促する形を避け、双方に役立つ情報交換を続けます。
このように他社との関係を通じて顧客接点を増やす方法を、パートナーセールスと呼びます。基本的な考え方を深めたい場合は、パートナーセールスの仕組みと始め方も参考になります。
初回商談から参画まで、止まった段階に合わせて改善する
新しい担当者と会えても、技術・時期・体制が合わなければ案件には進みません。紹介元の数と、顧客との相談の進み具合を分けて確認します。
初回は必要な仕事・時期・発注条件をそろえる
初回商談では、まず顧客が進めたい仕事と、今困っている箇所を聞きます。そのうえで、必要な工程や役割、技術環境、既存チームの体制、開始時期、勤務条件、予算・費用条件、取引先の選定手順を確認します。分からない項目は、誰にいつ確認するかを決めます。
自社側は、実際に対応できる体制と経験、対応外の範囲を伝えます。話が合えば、次に技術担当を交えた確認や具体的な提案へ進みます。スキル表を送ったままにせず、確認する人と返答の予定をそろえてください。
顧客が求めるのが技術支援ではなく、システム一式の開発であれば、社内で受けられる範囲を判断します。受託案件として開拓したい場合は、受託開発会社の新規開拓で扱う営業設計が参考になります。この記事では、契約形態や現場での指示に関する法的判断は扱いません。
参画しなかった理由と、次の確認日を残す
提案が進まない理由を「営業力が足りない」でまとめると、同じ条件で連絡を繰り返してしまいます。営業記録には「企業/必要な役割/希望時期/提案可能な体制/止まっている理由/次の行動と日付」を残します。
止まった段階 | 確認すること | 次に変えること |
|---|---|---|
担当者との会話が始まらない | 窓口と連絡理由が合っているか | 接触先や紹介経路を見直す |
会えたが技術支援の相談にならない | 相手に需要があるか、課題を知る担当者か | 対象企業・部署・聞く内容を修正する |
具体的な相談があるが提案できない | 技術、役割、時期、勤務条件のどれが合わないか | 対応条件を更新し、合う時期や案件を相談する |
提案後に決まらない | 発注条件、選定状況、確認待ちの情報は何か | 追加情報と次の判断日をそろえる |
参画後に次の相談が途切れる | 評価確認と今後の体制相談の機会があるか | 顧客と確認日を決め、追加需要や終了予定を把握する |
時期だけが合わなかった相手なら、次の計画が決まる頃に連絡する約束をします。技術領域や発注条件が根本的に合わない場合は、継続して追う対象から外します。
最初は、実績のある技術領域を一つ選び、候補企業と紹介元への接触を小さく始めます。週ごとに次の行動を確認し、月ごとに課題を聞けた企業、具体的な提案、参画、継続相談を振り返る進め方ができます。自社の営業量に合わせて頻度を決め、紹介元との面談数だけを成果にしないことが大切です。
エンド開拓の紹介元づくりをSparkLaboと進める
エンド企業との接点を増やしたいのに、既存案件の調整で手いっぱいになり、紹介元の探索や面談後のフォローが止まる。こうしたSES企業には、新しい紹介元を探し、継続して関係を動かす支援が役立ちます。
SparkLaboは、紹介営業や他社との協業を、継続的な案件獲得の仕組みにするサービスです。5,000社以上との直接接点を土台に、自社の人脈の外から紹介・協業候補を探索します。パートナー候補の紹介は毎月2〜5社、年間30〜60社が目安です。これは紹介元・協業先となり得る企業との接点数で、SES案件数や直請け商談数ではありません。
候補との接点づくりに加え、紹介などの施策の企画・運営、月次の振り返りと改善まで支援します。紹介元を探す方針が決まっていなくても、コンサルタントが現在の営業状況や強み、希望を聞き、課題整理と戦略づくりから一緒に進めます。
SparkLaboの業種を限定しない顧客事例では、営業をすべて担っていた社長が紹介ルートを作り、営業時間を大きく減らして、新規事業・戦略策定・事業改善へ時間を振り向けられるようになりました。候補探しや関係づくりを社長だけで抱えないことは、案件獲得に加えて経営に使う時間を取り戻す意味もあります。
SparkLaboを活用する場合も、自社は技術・参画条件の確認や顧客への提案を担います。直近の待機を埋める案件探しと並行して、その先も相談を受けられる紹介元を増やしたいときに相談できます。

