プリセールス・セールスエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

プリセールスのスキルシートは、関わった商談やプロジェクトごとに「製品領域」「顧客の規模と業界」「支援の型」「自分の担当範囲」をそろえ、顧客のどんな懸念に何を示したかまで書くと伝わります。読み手は、発注側が任せたい支援の型と、あなたの経験が合っているかをまず確かめるからです。

この記事では、プリセールスならではの書き方のポイントを、架空の記入例とあわせて紹介します。全体の構成はスキルシートの書き方の基本、求められるスキルの中身はプリセールスのスキルの記事で解説しています。

「プリセールス◯年」だけでは伝わらない

プリセールスの経験者のシートで多いのが、職務経歴を会社単位で書き、「◯◯製品のプリセールスを担当」とだけ記した形です。これでは、デモを見せる担当だったのか、PoCで環境を組んでいたのか、RFPの回答をまとめていたのかが分かりません。

読み手が知りたいのは、次の4つです。

• 製品領域：どの領域の製品を扱ったか（クラウド基盤、セキュリティ、業務SaaS、データ活用など）
• 顧客：どの業界の、どの規模の顧客か
• 支援の型：提案書、デモ、PoC、RFP回答、商談全体のどれか
• 担当範囲：主担当か、補助か、同席か

スキル一覧は、この組み合わせが一目で分かる表にすると読みやすくなります。

件数は、正確な数が出せない場合でも「数件」「十数件」「数十件」のように桁が分かる書き方にすると、経験の厚みが伝わります。

支援の型ごとに書くこと

特にPoCは、成功基準をどう決めたかと結論が何だったかを書くと評価されやすくなります。「PoCを実施」だけでは、環境を作っただけなのか、検証の設計から報告までを担ったのかが伝わりません。

受注の結果は慎重に書く

プリセールスのシートで迷いやすいのが、受注の結果をどう書くかです。

受注は、価格、競合、顧客の予算や社内の事情など、技術の支援の外で決まる要素に大きく左右されます。そのため、受注の件数や率を大きく書くと、かえって自分の関与が見えにくくなることがあります。また、受注の金額や率は、前職や顧客にとって社外に出せない情報にあたることが多く、検証もできません。

書くとよいのは、自分の支援で商談がどう進んだかです。

• 技術の懸念が解消され、次の段階（PoCや最終提案）に進んだ
• PoCの結果をもとに、導入の範囲が決まった
• RFPの技術評価の段階を通過した

このように、商談の段階が進んだ事実を、自分が担った工程と結びつけて書くと、受注の数字に頼らずに貢献が伝わります。

記入例（架空）

記入例1：PoCが中心の場合

期間：約1年（業務SaaSの販売パートナー企業でのプリセールス）
製品領域：データ連携・ワークフローのSaaS
顧客：製造業・流通業の中堅〜大企業
役割：プリセールス（チーム3名のうち、PoCの主担当）
担当内容：既存の基幹システムとの連携を確かめるPoCの計画と実施。検証の範囲、期間、成功基準を顧客の情報システム部門と合意し、検証用の環境を構築。結果を報告書にまとめ、制約と追加の対応が必要な点を明記
判断した点：当初、全業務の連携を検証する案が出ていたが、データ量の多い受注の連携に範囲を絞り、期間内に結論が出せる計画にした
結果：検証の結論をもとに、導入の範囲と段階が決まり、導入の担当チームに引き継いだ

記入例2：RFP回答と提案書が中心の場合

期間：約2年（ITサービス企業での提案支援）
製品領域：セキュリティ製品とその運用サービス
顧客：金融・公共の大企業や団体
役割：提案チームの技術担当（RFPの技術の章の取りまとめ）
担当内容：RFPの要件を分野ごとに分け、対応可否（標準・設定・追加開発・対応しない）の判断と回答の執筆。セキュリティの質問票への回答。過去の回答を分野ごとに整理し、チームで使える形にした
結果：回答の作成にかかる手戻りが減り、締切前の確認に時間を回せるようになった

これは書き方を示すための架空の例です。製品、業界、規模、判断の内容は、ご自身の経験に置き換えてください。

守秘の線引き

プリセールスのシートには、顧客名、提案した価格、値引きの条件、競合の名前、PoCで扱ったデータの中身を書かないのが基本です。顧客は「製造業の大企業」のように業界と規模で、製品はメーカー名を出してよいかを前職との約束で確かめたうえで書きます。どこまで書いてよいかの考え方はスキルシートに書いてよいこと・いけないこと、秘密保持の約束の読み方はNDAの記事をご覧ください。

職務要約は「領域×型×顧客」で3行にまとめる

シートの冒頭に置く職務要約は、読み手が最初の数秒で合う案件かどうかを判断する欄です。プリセールスの場合は、次の3つを1行ずつ書くとまとまります。

1. 主な製品領域と年数の目安：例「業務SaaSとクラウド基盤のプリセールスを中心に経験」
2. 得意な支援の型：例「PoCの計画から報告までと、RFPの技術の章の取りまとめを主担当で経験」
3. 主な顧客層：例「製造業・流通業の中堅〜大企業、公共団体」

構築や開発、営業など、プリセールスの前の経歴がある方は、その経験がどの支援の型に生きているかを一言添えます。たとえば「インフラ構築の経験を生かし、移行の実現性の検証を担当」のように書くと、経歴のつながりが読み手に伝わります。

製品の認定資格と語学の書き方

扱った製品の認定資格や、クラウドの認定資格は、正式な名称と取得年月を書きます。有効期限や更新の扱いがある資格は、公式の案内で必ずご確認のうえ、現在も有効かを正確に書きます。

英語の資料を読んだり、海外の開発元とやり取りしたりした経験があれば、「英語の製品資料を読んで回答を作成」「開発元への技術的な問い合わせを英語で実施」のように、使った場面で書くと伝わります。

よくある質問

受注率を書かないと、実績が弱く見えませんか？

受注率は、商談の数や製品の価格帯、競合の状況によって意味が大きく変わり、読み手が比べにくい数字です。支援した商談の数の桁と、支援の型ごとに商談がどの段階まで進んだかを書くほうが、任せられる範囲が伝わります。面談で聞かれた場合は、前職との約束の範囲で、自分の関与と合わせて口頭で説明します。

同席が中心だった商談も書いてよいですか？

書いてかまいません。ただし、主担当だった商談と分けて、「同席・補助」と明記します。同席の経験でも、どの場面で何を説明したかを一行添えると、次に任せられる範囲の見立てに役立ちます。

製品の名前を出してよいか分かりません。

製品の名前そのものは公開されている情報ですが、どの顧客にどの製品を提案したかの組み合わせは、社外に出せない情報にあたることがあります。前職との約束を確かめ、迷う場合は「業務SaaS（経費精算の領域）」のように領域で書く方法があります。