IT業界の営業で商談を進めるには？｜SaaSと個別開発の確認事項

▼ この記事の内容

IT業界の営業では、商材に応じて技術要件・確認担当・検証条件を明確にします。SaaS・受託開発／SI・インフラの違いを踏まえ、聞き取るのは現行業務と接続・運用条件です。SEと回答範囲を分担し、検証結果と未解決事項をそろえて導入可否を判断します。

「今の基幹システムと接続できますか」と聞かれても、接続先の仕様や契約範囲が分からなければ、その場で可否を答えられません。IT業界の営業で商談を進めるには、顧客の要望を具体的な確認項目に分け、誰が回答するかを決める必要があります。

SaaSの標準機能、個別開発の対象範囲、インフラの運用条件では、確認する内容が異なります。営業マネージャーの役割は、営業が説明できる範囲と技術担当に判断を求める範囲を分け、未回答の項目と期限を管理することです。

商材別の確認表を出発点に、技術要件の聞き取り、SEとの役割分担、デモやPoCによる検証、導入判断までを順に整理します。表と架空の記入例を使い、担当案件で次に確認する条件と相手を具体化してください。

IT営業で確認すべき点を商材別に整理する

IT業界の営業では、顧客が実現したい業務と、商材ごとに異なる技術条件を対応させて商談を進めます。機能の有無だけで判断せず、提供範囲、確認担当、導入前に確かめる条件をそろえることが出発点です。

SaaS・受託開発・インフラの確認軸を比べる

IT営業では、SaaSは標準機能・連携・利用運用、受託開発は対象業務・開発範囲・検収、インフラは構成・性能・運用分担を確認します。商材名だけで可否を決めず、顧客の必須条件と技術担当の回答を見比べます。

「SaaS」は、提供事業者が運用するソフトウェアをネットワーク経由で利用するサービスです。標準機能で対応する業務と、設定変更や外部連携が必要な業務を分け、契約するプランやオプションの範囲も確認します。

受託開発で合意するのは、何を作るかと、完成をどう確認するかです。複数のシステムを組み合わせる「SI（システムインテグレーション）」では接続部分の分担も確認し、サーバーやネットワークなどのインフラでは、性能条件と稼働後の運用担当を具体化します。

商材別の確認項目

商材	顧客への質問	技術担当への確認	導入判断に必要な材料
SaaS	誰が、どの業務で使いますか。既存システムとの連携は必要ですか。	標準機能、設定、追加契約、連携で対応する範囲を確認します。	必要な材料は、利用条件と提供範囲を対応させた一覧です。
受託開発／SI	どこまでを開発対象とし、何をもって完成と判断しますか。	開発範囲、接続条件、検収方法、変更時の扱いを確認します。	必要な材料は、対象業務、成果物、検収条件、双方の作業です。
インフラ	想定する処理量、停止できる時間、運用体制はどうなっていますか。	構成、性能、稼働継続や復旧の条件、監視の分担を確認します。	必要な材料は、構成案、検証結果、運用担当、障害時の対応手順です。

この表は、案件の確認項目を選ぶための整理例です。各分類は重なるため、自社が販売する商材に該当する行を組み合わせ、契約に含まれる範囲ごとに確認を進めます。

複合商材は契約と担当範囲を分けて確認する

SaaSと個別開発を組み合わせる案件では、標準提供、追加開発、顧客作業、他社作業を分けて確認します。「全体として実現したいこと」と「各社が引き受けること」を分けないと、接続部分の確認担当が決まりません。

記入例（架空の案件）は、営業管理用のSaaSと既存の基幹システムを連携させる案件です。SaaS側のデータ出力、連携処理の開発、基幹システム側の受け入れ設定を別々の作業として記録し、誰が仕様を回答するかも添えます。

記入例（架空の案件）：SaaSと個別開発の担当範囲

区分	確認する作業	回答先・担当候補	契約前に確かめること
標準提供	SaaSから必要なデータを出力します。	確認先はSaaS提供側の担当者です。	契約範囲、出力項目、利用条件を確認します。
追加開発	データの変換・転送処理を作ります。	確認先は開発を受託する技術担当です。	開発対象、費用、検収条件を確認します。
顧客作業	社内で利用権限と接続申請を整えます。	確認先は顧客の情報システム担当です。	申請者、承認者、準備期限を確認します。
他社作業	基幹システムの受け入れ設定を変更します。	確認先は既存システムの保守会社です。	変更可否と作業範囲を確認します。

担当範囲を分けても、各社が自分の範囲だけを確認した段階では、全体の接続可否は未確認です。営業は、双方の技術担当が同じ接続条件を見て回答できるように調整し、接続試験を誰が取りまとめるかも決めます。

未確定の作業を、見積もりや契約の対象に含まれるものとして顧客へ説明してはいけません。まず担当範囲と未回答を記録し、その範囲を確定するために必要な業務条件を聞き取ります。

技術要件のヒアリングで業務・接続先・運用条件を確認する

技術要件のヒアリングでは、顧客の要望を、利用する人、実施する作業、接続するシステム、稼働後の担当に分けて確認します。分からない項目は推測で埋めず、回答する相手と確認期限を決めることが必要です。

業務の困りごとを利用場面と必須条件に分ける

「業務を効率化したい」という要望は、そのままでは技術担当が対応方法を判断できません。誰が、いつ、どの情報を使って何をするのかを聞き、困っている作業を利用場面まで具体化します。

聞き取りを進めるには、現在の作業を順にたどる方法が有効です。入力元、担当者の操作、確認する相手、出力先、締め時点を確かめ、実施頻度と、処理が間に合わない場合の業務への影響も記録します。

記入例（架空の案件）は、「集計を楽にしたい」という相談です。「営業担当が入力した案件情報を、管理担当が月末の締め後に集計し、会議用の表へ転記している」と書けば、自動化したい工程と、確認が必要なデータが明確になります。

そのうえで顧客と分けるのは、導入に欠かせない必須条件と、満たせれば望ましい希望条件です。「締め後の修正を集計へ反映することは必須」「表の配色を現在とそろえることは希望」のように整理し、優先度を決めた顧客側の担当者も記録します。

接続先・データ・運用担当を質問表に残す

業務の条件を聞いた後の確認対象は、接続先、扱うデータ、認証と権限、処理量、移行、運用です。すべての案件で同じ項目を聞くのではなく、実現したい業務に関係する質問を選んで表に残します。

顧客の窓口が技術条件を把握していない場合は、その場で回答を求め続ける必要はありません。業務担当が答える内容と、情報システム担当や保守会社へ確認する内容を分け、窓口と確認先を調整します。

記入例（架空の案件）：接続・データ・運用の質問表

質問	確認済みの内容	未確認の内容	回答担当	期限
どのシステムと、どの方法で接続しますか。	既存の基幹システムと接続します。	利用できる接続方式を確認します。	回答担当は、顧客の情報システム担当と保守会社です。	技術打ち合わせ前までに確認します。
どのデータを、どの形式で渡しますか。	渡すのは案件情報です。	項目、形式、更新タイミングを確認します。	顧客の業務担当と双方の技術担当が回答します。	確認期限は、連携仕様を検討する前までです。
接続時の認証と利用権限はどう管理しますか。	社内申請が必要です。	認証方法と権限の付与者を確認します。	回答担当は、顧客の情報システム担当です。	検証環境の準備前までに確認します。
通常時と繁忙時に、どの程度処理しますか。	月末に処理が集中します。	確認するのは、件数、データ量、処理の締め時刻です。	顧客の業務担当が回答します。	検証条件を合意する前までに確認します。
何を移行し、いつまで作業を止められますか。	過去の案件情報も利用対象です。	移行範囲と停止可能時間を確認します。	顧客の業務担当と情報システム担当が回答します。	確認期限は、移行計画を作る前までです。
稼働後の監視と問い合わせ対応は誰が担いますか。	顧客内に運用窓口があります。	監視範囲と障害時の連絡先を確認します。	回答担当は、顧客と提供側の運用担当です。	導入判断前までに確認します。

「確認済み」には、回答の内容だけでなく、参照した仕様書や回答日も添えます。記入例の期限が示すのは工程です。実案件では関係者と具体的な日付を合意し、予定が変われば更新します。

質問表は、すべて埋めてから技術担当へ渡す必要はありません。業務目的と既知の条件を先に共有し、未回答のうち、誰の判断が必要な項目かを営業と技術担当で振り分けます。

営業とSE・プリセールスの回答範囲と確認担当を決める

営業は顧客の目的と商談条件を整理し、個別の技術判断は権限を持つ担当者へ確認します。顧客への回答窓口を決めたうえで共有するのは、誰が内容を確認し、いつまでに回答するかです。

営業が答える範囲と技術判断を分ける

営業が技術質問のすべてに即答する必要はありません。確認済みの提供範囲は営業が説明し、顧客固有の構成や接続条件に左右される可否は、技術担当の確認を経て回答します。

「SE（システムエンジニア）」は、システムの要件整理や設計などを担う技術職です。「プリセールス」は、受注前の提案や技術確認を支援する役割を指しますが、担当範囲は会社によって異なるため、役職名だけで回答責任を決めないことが大切です。

営業・技術担当・顧客の回答分担の整理例

確認する内容	営業の役割	技術担当の役割	顧客側に確認すること
業務目的・優先順位	利用場面と必須条件を聞き取ります。	示すのは、技術検討に足りない条件です。	業務担当が必要性と優先順位を確認します。
標準の提供範囲	確認済みの資料と契約条件に沿って説明します。	確認するのは、資料で判断できない適用条件です。	希望する使い方との一致を確認します。
個別の接続・性能	質問と前提条件を整理して引き継ぎます。	判断するのは、対応可否と検証の必要性です。	接続先の仕様と実際の利用条件を提示します。
セキュリティ・運用	審査の窓口と日程を調整します。	回答内容の確認先は、提供側の専門担当です。	社内の審査基準と運用の引受先を確認します。

営業マネージャーのレビューでは、「標準機能として存在する」と「顧客の環境で使える」の区別が必要です。過去に似た連携を実施した経験があっても、接続先の版や認証方法、契約範囲が異なるなら、その案件の可否を改めて確認します。

技術担当の回答を顧客へ伝える際は、回答の前提条件も説明の対象です。「この接続方式であれば対応可能」という条件を省かず、追加の確認が必要な場合は担当と期限を添えて説明します。

SEの同席条件と持ち帰る回答期限を決める

SEの同席を検討するのは、非標準の連携、具体的な性能条件、移行方法、顧客の技術担当との協議が必要な場合です。資料で回答できる質問だけなら事前確認で済ませ、同席によって何を決めたいかを先に明確にします。

SEへの依頼時には、次の情報をまとめます。

• 顧客の業務目的
• 現行システムの資料
• 確認済みの条件
• 未回答の質問
• 回答希望日
• 顧客側の参加者

これらの情報に加え、「接続方式を決める」「検証要否を判断する」のように打ち合わせの目的を指定します。「技術説明をお願いします」だけでは準備する範囲が広いためです。

記入例（架空の案件）では、顧客から「今の基幹システムと接続できますか」と質問された際、営業は「接続先の仕様を確認して技術担当と判断します。必要な資料を本日共有し、金曜日までに可否、または追加で確認する条件をご連絡します」と回答します。回答期限までに判断材料がそろわない場合も想定し、次に何を回答するかを顧客と合意します。

持ち帰った質問は、営業が一覧で管理し、技術担当の回答と顧客への連絡を対応させます。仕様の説明で解消した項目と、実際に試す必要がある項目を分けます。後者の次の段階は、検証条件の相談です。

デモ・PoCとセキュリティ審査で導入条件を確かめる

仕様の説明だけで判断できない条件が残った場合は、何を試せば判断できるかを決めます。操作の確認、個別条件の検証、顧客のセキュリティ審査は別々に扱い、それぞれの確認担当と完了条件をそろえることが必要です。

デモで分かることとPoCで確かめる条件を分ける

デモは画面操作や基本的な業務の流れを確かめるために使い、顧客固有の接続や性能に未確認の条件が残る場合は「PoC（概念実証）」を検討します。PoCは、実現可能性を確かめるために対象と条件を限定して試すもので、全案件で必須とは限りません。

まず具体的な質問に変えるのは、導入判断を止めている疑問です。「使いやすいか」なら顧客の利用者が操作を確認し、「月末のデータを締め時刻までに処理できるか」なら対象データ量と処理条件を定めて検証します。

AWSのAmazon OpenSearch Service移行ガイドでは、PoCの開始条件と終了条件を定義し、終了条件に機能・性能要件やセキュリティ実装を含めるよう案内しています。^[1]これは同サービスへの移行を対象とした案内であり、すべてのIT商材で同じ検証を必須とする根拠にはなりません。

記入例（架空の案件）：個別連携の検証計画

項目	合意する内容
検証する問い	合意した条件で、SaaSの案件情報を基幹システムへ渡せるかを確かめます。
開始条件	双方の接続仕様、検証環境、使用を認められたテストデータをそろえます。
終了条件	終了条件は、対象項目の受け渡しとエラー時の処理を、事前に合意した基準で確認することです。
対象外	本番への移行作業と、合意した範囲を超える負荷試験は含めません。
担当	提供側の技術担当が接続を確認し、顧客の業務担当が受け渡された内容を確認します。
期間	開始日、結果確認日、延長する場合の判断日を着手前に決めます。
結果の記録	記録するのは、試した環境、データ、結果、未確認の条件です。

検証の追加費用と双方の準備作業も、開始前に合意します。未確認の条件が仕様確認やデモで解消するならPoCを増やさず、試験が必要な場合は対象を絞り、結果を適用できる範囲と残るセキュリティ確認を区別します。

参考：Stage 2 – Proof of concept｜AWS

データの扱いと顧客の審査項目を確認する

動作が確認できても、データの取り扱いや運用条件の確認が完了したとは限りません。営業は顧客の審査項目と提出期限を早めに受け取り、情報システム担当、セキュリティ担当、提供側の回答者をつなぎます。

確認する内容は、扱うデータの種類、アクセスできる人、保存先、保存・削除の方法、障害発生時の対応などです。検証で使うデータについても、本番データをそのまま持ち込まず、利用を認められた範囲と受け渡し方法を関係者で確認します。

セキュリティ確認の整理例

確認項目	確認する内容	回答・判断する担当
扱うデータ	入力する情報と、検証・本番で使用を認める範囲を確かめます。	確認先は、顧客の業務担当とセキュリティ担当です。
アクセス権	利用者、管理者、提供側のアクセス範囲を確かめます。	顧客の情報システム担当と提供側担当に確認します。
保存・削除	確認するのは、保存先、保持期間、終了時の返却・削除の扱いです。	提供側の専門担当が回答し、顧客側が要件との一致を確認します。
障害対応	検知、連絡、復旧作業、顧客側の対応を確かめます。	確認先は、双方の運用担当です。
審査資料	必要な資料、未回答項目、追加説明の期限を確かめます。	顧客の審査窓口と提供側の回答窓口が調整します。

認証や認定の名称だけを理由に、顧客の要件を満たすと判断してはいけません。対象となるサービスや適用範囲、提出資料の内容を顧客の審査項目と見比べ、営業が確認できない項目は専門担当の回答を待ちます。

未回答は、審査項目、回答担当、確認期限、導入判断への影響をセットで残します。検証に合格した項目と審査が終わっていない項目を分けておけば、導入判断に進める条件と、追加確認が必要な条件が明確です。

検証結果と未解決事項を整理して導入判断につなげる

導入判断に渡す資料では、要件と検証結果を対応させ、未解決事項、追加作業、判断する担当者をそろえます。検証が終わったという報告だけでなく、確認が必要なのは必須条件と運用の引き受けです。

要件・検証結果・残課題を判断表で見比べる

判断表は、要件ごとに必須か希望かを示し、試した条件、結果、残課題を同じ行に記録します。「動いた」「問題なし」といった総評だけでは、どの条件が確認済みなのか判断する相手へ伝わりません。

記入例（架空の案件）は、SaaSと基幹システムの連携検証です。通常データでの受け渡しが成功しても、繁忙時の処理やエラー対応を試していなければ、該当する要件の結果は未確認として残します。

記入例（架空の案件）：導入判断の確認表

要件・優先度	試した条件と結果	残課題・担当・期限	追加費用・作業	判断者
対象項目の受け渡しは必須です。	合意したテスト項目の受け渡しを確認しました。	顧客の業務担当が本番で必要な項目との一致を、結果確認日までに確認します。	項目追加がある場合の再確認対象は、作業と費用です。	顧客の業務責任者が判断します。
締め時刻までの処理完了は必須です。	通常時の条件で実施し、繁忙時の条件は試していません。	双方の技術担当が追加検証日までに対象データ量を合意します。	確認対象は、再検証の準備と費用の有無です。	顧客の業務責任者と技術責任者が確認します。
連携失敗時の対応担当の決定は必須です。	エラーの通知先を確認しました。	顧客と提供側の運用担当が導入判断前までに復旧作業の分担を決めます。	確認対象は、運用手順の作成と契約範囲です。	双方の運用責任者が引き受けを確認します。
帳票の配色変更は希望です。	変更の可否は確認していません。	顧客の業務担当が導入判断前までに、変更なしで利用するかを判断します。	別途確認するのは、変更する場合の費用です。	顧客の業務責任者が判断します。

顧客の業務担当による確認と、技術担当による確認は別々のものです。データが届くことを技術担当が確認していても、必要な項目が業務で使えるかは業務担当に確かめてもらい、それぞれの回答日と根拠を残します。

技術検証の合格を、予算や契約を含む決裁承認と同一視しないことも必要です。判断表を顧客の承認手順に合わせて渡し、残課題を誰が解消し、誰が最終判断するかを確認します。

導入・再検証・見送りを条件で分ける

導入判断へ進む条件は、必須条件を満たし、運用の引き受けと必要な承認を確認できることです。必須条件が未確認なら再検証の条件を決め、満たせず代替策も合意できない場合は見送りを検討します。

記入例（架空の案件）のSaaS連携で、繁忙時の処理が未確認なら、通常時の成功だけで導入可能とは回答しません。検証担当、実施日、判定基準を決められるなら再検証とし、日程が決まらない場合は、導入日も確定せずに保留理由を共有します。

必須条件を満たせない場合に顧客と検討するのは、代替手順や対象範囲の変更です。追加作業や費用を含めて受け入れられるかを確認し、営業側の都合で必須条件を希望条件へ変更したり、運用負荷を顧客へ引き渡したりしないようにします。

まず手元の案件で、判断を止めている未回答の項目と次の確認担当を決めてください。技術面以外も含めて商談全体を点検する場合は、法人営業の段階ごとに次へ進む条件を決める方法を確認してください。

商談・営業スキル 法人営業のコツは段階ごとに次へ進める条件を決めること｜止まった段階の直し方

まとめ：商材ごとの確認担当と導入条件をそろえる

IT業界の営業では、商材と契約範囲に合わせて確認項目を選び、顧客の業務上の要望を技術要件へ具体化します。営業・技術担当・顧客側の担当者で回答範囲を分け、未回答の項目には確認先と期限を添えて共有しましょう。

デモや仕様確認で解消できない個別条件が残る場合は、対象と終了条件を決めてPoCを検討します。検証結果は試した環境や条件とともに残し、セキュリティ審査の状況、運用を引き受ける担当者、顧客の承認手順も確認します。必須条件が未確認なら再検証や保留の条件を決め、満たせず代替策も合意できない場合は見送りを検討してください。

まず手元の案件を選び、導入判断を止めている未回答項目と、次に確認する担当者・期限を決めましょう。確認済みの内容と残課題を同じ表にまとめ、関係者が判断に使う材料をそろえてください。

技術面の確認に加え、提案後の商談で何を確かめるかも整理したい方は、以下の『止まった商談を動かす提案受注率改善ガイド』をご確認ください。