プリセールス・セールスエンジニアのフリーランス案件で求められるスキルと経験

プリセールス・セールスエンジニアのフリーランス案件で問われるスキルは、製品と周辺技術の知識、ヒアリングと課題の整理、提案書・RFP回答の文章力、デモの設計、PoCの計画と実行、営業担当との連携の6分野に分けられます。どの分野がどこまで求められるかは、任される支援の型で変わります。

業務委託では、正社員のように社内で育ててもらう前提がありません。参画した時点で、少なくとも一つの分野を任せきりにできることが求められます。この記事では、分野ごとに求められる中身と、経験の段階ごとの目安を整理します。

6つの分野と、支援の型との関係

募集文に「プリセールス経験」とだけ書かれている場合でも、面談ではこの表のどこを任せたいのかが具体的に話されます。自分の得意な分野と、まだ浅い分野を分けて把握しておきましょう。

分野ごとに問われること

製品と周辺技術の知識

製品の機能を説明できるだけでは足りず、顧客の既存のシステムとどうつながるかを説明できることが求められます。認証の方式、データの連携、ネットワークの構成、バックアップや障害時の動きなど、顧客の情報システム部門が気にする点に答えられるかが見られます。

クラウドの基盤やSaaSを扱う領域では、クラウドの基本的な構成の知識がほぼ前提になります。知識の裏付けとして、扱う製品の認定資格や、AWSの認定資格、Salesforceの認定資格などを持っていると説明の助けになりますが、案件で見られるのは資格より実際の商談での使い方です。

ヒアリングと課題の整理

顧客が最初に話す要望は、課題の一部であることが多くあります。「なぜその機能が必要か」「今は何で困っているか」「誰が導入を判断するか」を聞き取り、提案の論点に組み直す力が問われます。聞き取った内容を、その場で短くまとめて確かめる習慣があると、デモや提案書の方向がずれにくくなります。

提案書・RFP回答の文章力

提案書では、顧客の課題、解決の方法、導入の進め方、体制、リスクへの備えを、読み手が判断しやすい順に並べる力が求められます。RFPへの回答では、要件の一つひとつに対して「標準で対応」「設定で対応」「追加開発が必要」「対応しない」を正確に書き分けることが重要です。できないことをあいまいに書くと、受注後に問題になります。

セキュリティの質問票や、要件への適合を一覧にした表は、分量が多く締切も厳しくなりがちです。過去の回答を整理して使い回せる形にしておく工夫も、業務委託の現場では評価されます。

デモの設計

製品の画面を順に見せるのではなく、顧客の業務の流れに沿って、懸念が解消される場面を見せるのがデモの設計です。誰が出席するか（現場の担当者か、情報システム部門か、決裁者か）で、見せる場面と時間配分を変えます。デモ用のデータに実在の個人情報を使わないことも基本です。個人情報を扱う業務の注意点は個人情報を扱う業務委託の記事で解説しています。

PoCの計画と実行

PoCは、導入の前に技術的な実現性を確かめる検証です。プリセールスに求められるのは、環境を作る手の速さだけでなく、何を確かめれば成功とするかを、始める前に顧客と合意する力です。範囲と期間と成功基準を決めずに始めると、検証が長引き、結論が出ないまま終わることがあります。

結果の報告では、うまくいった点だけでなく、制約や追加の対応が必要な点も書きます。その誠実さが、受注後の導入をスムーズにします。

営業担当との連携

商談全体を任される案件では、営業担当と役割を分け、商談の進め方をすり合わせる力が求められます。価格や契約条件の話は営業担当が、技術の話はプリセールスが、という線引きを最初に確かめておくと、顧客の前で話が食い違いにくくなります。

経験の段階ごとの目安

入り口の段階では、正確さと速さが評価の中心になります。中堅の段階では、顧客ごとに見せ方を変えられるか、PoCで結論を出せるかが問われます。熟練の段階では、技術の説明だけでなく、商談の勝ち筋を営業担当と一緒に考えられるかが見られます。

段階をまたいで共通して見られること

• 締切を守る力：RFPや提案の締切は動かないことが多い
• 分からないことを持ち帰る判断：その場で推測で答えず、確かめてから回答する
• 情報の扱い：顧客の構成情報や見積の条件を、決められた範囲の外に出さない
• 製品の更新に追いつく力：SaaSやクラウドの製品は機能の追加や画面の変更が頻繁にあり、古い知識のまま説明すると信頼を失う

業務委託では、製品の研修を発注側が用意してくれるとは限りません。公式の更新情報や資料を自分で追い、デモの手順や回答の雛形を最新に保つ習慣が、どの段階でも評価の土台になります。

業界知識と語学

顧客の業界の業務や規制を知っていると、ヒアリングとデモの両方で説明の説得力が増します。金融、製造、医療、公共などは、業界特有の要件が多い分野です。

海外の製品を扱う案件では、製品の資料や問い合わせ先が英語のことがあります。開発元とのやり取りが英語で行われる案件もあるため、英語の資料を読めることが条件になる場合があります。英語を使う案件の進め方は英語を使う案件の記事で解説しています。

スキルを面談で伝えるには

スキルの一覧を並べるより、一つの商談を「顧客の状況→出てきた懸念→自分が用意したもの→結果」の順に話せるようにしておくと、どの分野の力があるかが伝わります。PoCであれば、成功基準をどう決め、どこまで確かめ、何を結論にしたかまで話します。

スキルシートへの書き方はプリセールスのスキルシートの記事、面談の流れは面談でよく聞かれる質問の記事で解説しています。

よくある質問

プログラミングの経験は必要ですか？

案件によります。PoCでAPIの連携を試したり、データの移行を検証したりする案件では、簡単なスクリプトを書ける力が求められることがあります。デモや提案書が中心の案件では、プログラミングより構成の理解と説明の力が重視されます。

営業の経験がなくてもプリセールスの案件に入れますか？

構築やPoCの経験があれば、技術検証の支援から入れる案件があります。顧客の前で話す経験が少ない場合は、社内向けの説明や、顧客との技術的な打ち合わせの経験を整理しておくと、面談での説明の材料になります。

ITコンサルタントとプリセールスで求められるスキルは違いますか？

重なる部分は多いものの、ITコンサルタントは発注側の立場で中立に選択肢を比べるのに対し、プリセールスは特定の製品の側に立って、その製品で顧客の課題をどう解くかを示します。比べる立場か、示す立場かで、求められる説明の仕方が違います。ITコンサル側のスキルはITコンサルタントのスキルの記事で解説しています。