プリセールスは、商談の中で「その製品や仕組みで、顧客の課題を解決できるか」を技術面から確かめ、提案を支える仕事です。機能を説明するだけでなく、顧客の利用環境や制約を聞き、実現できることと確認が必要なことを分けます。
ただし、担当範囲は会社や商材によって異なります。求人を見るときは肩書きだけで判断せず、提案前の調査、デモ、検証、導入後の支援のどこまでを担当するかを確認しましょう。
プリセールスは商談の何を前に進めるのか
例として、GitLabのSolutions Architectの職務説明には、顧客に対する技術評価の支援、デモや概念実証、営業と顧客をつなぐ技術提案が含まれます。これは一社の職務定義ですが、技術知識を使って顧客の意思決定を助ける仕事を理解する参考になります。出典:GitLab
商談で「既存システムと連携できますか」と聞かれた場合、「APIがあるので可能です」だけでは判断材料が足りません。連携対象、認証方法、扱うデータ、処理頻度、エラー時の対応を確認して、標準機能で対応できる範囲と追加開発が必要な範囲を示す、という進め方が考えられます。
これは説明用の仮例です。プリセールス自身がすべてを実装するという意味ではありません。開発担当や製品担当に確認し、未検証の条件を約束に変えないことが提案の質に関わります。
営業・開発との違いは成果物で考える
営業にも技術理解が必要です。厚生労働省の職業情報では、ITコンサルティング営業がSEと顧客を訪問し、技術上の質問に対応しながら提案を進める仕事が紹介されています。営業と技術担当の境界は、完全に分離されているとは限りません。出典:job tag
役割分担を理解するための整理例を示します。実際には会社の定義を優先してください。
| 役割 | 主に判断を進める対象 | 成果物の例 |
|---|---|---|
| 営業 | 顧客課題、予算、契約条件、商談の進め方 | 提案全体、見積もり、契約調整事項 |
| プリセールス | 技術的な適合性、導入条件、未解決の技術課題 | 構成案、デモ、検証結果、技術回答 |
| 開発・構築担当 | 合意した要件を実際に動く形へ落とす方法 | 設計、実装、テスト、構築手順 |
同じ人が複数の役割を担うことも想定して、仕事の受け渡しを具体的に確認します。「誰が作業するか」に加えて、「誰が回答を確定できるか」が分かると、顧客への説明で迷いにくくなります。
デモと検証では、見せることと確かめることを分ける
デモでは、顧客の業務に沿って利用イメージを伝えます。検証では、採用判断に必要な条件を満たすか確かめます。本記事ではこの違いを、提案準備の整理として使います。
たとえば問い合わせ管理の提案なら、デモで受付から担当者への割り当てまでを示し、検証では実際に必要な権限や既存認証との接続を確かめる、と分けられます。画面が動いたことだけを、運用全体が成立する根拠にしないことが大切です。
検証前には、合格条件と対象外を短く書いておきましょう。「このアカウントでは接続できた」「本番相当の同時利用や障害時の動作は未確認」のように、結果の適用範囲まで残します。顧客が社内説明に使える資料は、成功した画面だけでなく、条件と残課題が分かる資料です。
求人を見るときに確認したい仕事内容
応募を検討するなら、担当製品の範囲、顧客との会話の比重、検証環境の準備、導入後の引き継ぎを読み取ります。技術調査が中心なのか、商談への同席が中心なのかで、日々の時間の使い方は変わります。
自分の経験を整理するときも、技術名だけを並べるより、「誰から何を聞き、どの条件を検証し、どんな判断材料を渡したか」を説明すると仕事との接点を示せます。未経験の製品について、扱った経験があるように書く必要はありません。確認方法や学習の進め方と、実務経験は区別しましょう。
プリセールスという職名の募集有無と、IT営業の募集は同じではありません。テクノヴァースの職種や募集内容は、採用情報で実際の記載を確認してください。技術を理解しながら顧客と仕事を進めたい方は、担当する業務の境界から比較してみてください。