sales-engineer

セールスエンジニアのスキル

技術的な専門知識と営業活動をつなぐ、プリセールスエンジニアリング向けの本番環境対応スキルパッケージです。RFP/RFI への回答、競合ポジショニング、概念実証の計画を自動で分析します。

概要

役割： セールスエンジニア／ソリューションアーキテクト
分野： プリセールスエンジニアリング、ソリューション設計、技術デモ、概念実証
事業形態： SaaS／プリセールスエンジニアリング

このスキルでできること

• RFP/RFI 回答の分析 - 要件の網羅度を評価し、ギャップを特定して、入札可否の推奨事項を作成します
• 競合との技術的なポジショニング - 機能比較表を作成し、差別化要因と弱点を特定します
• POC の計画 - タイムライン、リソース計画、成功基準、評価スコアカードを作成します
• デモの準備 - 説明ポイントと反論への対応を含むデモスクリプトを構成します
• 技術提案書の作成 - ソリューションアーキテクチャと実装計画のためのフレームワークを提供します
• 勝敗分析 - ディール戦略に役立つ、データに基づく競合評価を行います

主要指標

指標	説明	目標
受注率	受注したディール数／全商談数	>30%
営業サイクルの期間	初回ヒアリングから成約までの平均日数	<90 days
POC 成約率	成約に至った POC の割合	>60%
顧客エンゲージメントスコア	評価における関係者の参加度	>75%
RFP 網羅度スコア	十分に対応した要件の割合	>80%

まず確認すること

成果物を作成する前に、以下の入力内容を確認してください。不明または曖昧な項目があれば、推測せずに質問してください。

• 成果物の種類 — RFP/RFI 網羅度分析、競合比較表、または POC 計画（使用するツールとフェーズが決まります）
• 顧客要件と優先順位 — 必須／推奨／あると望ましい項目の一覧（重み付けした網羅度評価と入札可否の判断に必要です）
• 商談における競合他社 — 機能比較表、差別化要因、バトルカードの作成に必要です
• POC の範囲と成功基準 — POC を計画する場合のユースケースと、測定可能な実施可否の基準（範囲が際限なく広がることを防ぎます）

質問は成果物に最も大きく影響する 2～3 項目に限定してください。ユーザーが「とりあえずドラフトを作成して」と言った場合は、作成を進め、成果物の冒頭に前提条件を記載してください。

5 フェーズのワークフロー

フェーズ 1：ヒアリングと調査

目的： 顧客の要件、技術環境、ビジネス上の動機を把握します。

活動：

1. 関係者と技術的なヒアリングを実施します
2. 顧客の現行アーキテクチャと課題を整理します
3. 統合要件と制約を特定します
4. セキュリティ要件とコンプライアンス要件を文書化します
5. この商談における競争環境を評価します

ツール： rfp_response_analyzer.py を使用して、初期段階の要件適合度を評価します。

成果物： 技術ヒアリング文書、要件マップ、初期網羅度評価。

フェーズ 2：ソリューション設計

目的： 顧客の要件に対応するソリューションアーキテクチャを設計します。

活動：

1. 製品の機能を顧客の要件に対応付けます
2. 統合アーキテクチャを設計します
3. カスタマイズの必要性と開発工数を特定します
4. 競合との差別化戦略を策定します
5. ソリューションアーキテクチャ図を作成します

ツール： competitive_matrix_builder.py を使用して、差別化要因と弱点を特定します。

成果物： ソリューションアーキテクチャ、競合ポジショニング、技術的な差別化戦略。

フェーズ 3：デモの準備と実施

目的： 関係者の優先事項に合わせた、説得力のある技術デモを実施します。

活動：

1. 顧客のユースケースに合ったデモ環境を構築します
2. 関係者の役割ごとに説明ポイントを含むデモスクリプトを作成します
3. 反論への対応を準備します
4. 失敗のシナリオと復旧手順をリハーサルします
5. フィードバックを収集し、進め方を調整します

テンプレート： demo_script_template.md を使用して、体系的にデモを準備します。

成果物： カスタマイズしたデモ、関係者ごとの説明ポイント、フィードバックの記録。

フェーズ 4：POC と評価

目的： ソリューションを検証するため、体系的な概念実証を実施します。

活動：

1. POC の範囲、成功基準、スケジュールを定義します
2. リソースを割り当て、環境をセットアップします
3. 段階的なテスト（コア、応用、エッジケース）を実施します
4. 成功基準に照らして進捗を追跡します
5. 評価スコアカードを作成します

ツール： poc_planner.py を使用して、完全な POC 計画を作成します。

テンプレート： 評価の追跡には poc_scorecard_template.md を使用します。

成果物： POC 計画、評価スコアカード、実施可否の推奨案。

フェーズ 5：提案とクロージング

目的： 商談の成約を支援する技術提案を提示します。

活動：

1. POC の結果と成功指標をまとめます
2. 導入計画を含む技術提案を作成します
3. 未解決の懸念に、根拠を示して対応します
4. 価格設定とパッケージに関する協議を支援します
5. 意思決定後に受注・失注分析を実施します

テンプレート： 提案書には technical_proposal_template.md を使用します。

成果物： 技術提案、導入スケジュール、リスク軽減計画。

Python 自動化ツール

1. RFP 回答アナライザー

スクリプト： scripts/rfp_response_analyzer.py

目的： RFP/RFI の要件を解析し、対応状況を評価して、ギャップを特定し、入札可否の推奨案を作成します。

対応状況のカテゴリ：

• 完全（100%） - 現行製品で要件を完全に満たします
• 部分的（50%） - 要件を部分的に満たしており、回避策または設定が必要です
• 予定（25%） - 製品ロードマップにはありますが、まだ利用できません
• ギャップ（0%） - 未対応で、現時点で対応予定もありません

優先度の重み付け：

• 必須：重み 3 倍
• 推奨：重み 2 倍
• あれば望ましい：重み 1 倍

入札可否の判定基準：

• 入札： 対応スコアが 70% 超、かつ必須要件のギャップが 3 件以下
• 条件付き入札： 対応スコアが 50～70%、または必須要件のギャップが 2～3 件
• 入札見送り： 対応スコアが 50% 未満、または必須要件のギャップが 3 件超

使用方法：

# Human-readable output
python scripts/rfp_response_analyzer.py assets/sample_rfp_data.json

# JSON output
python scripts/rfp_response_analyzer.py assets/sample_rfp_data.json --format json

# Help
python scripts/rfp_response_analyzer.py --help

入力形式： 完全なスキーマについては assets/sample_rfp_data.json を参照してください。

2. 競合比較マトリックス作成ツール

スクリプト： scripts/competitive_matrix_builder.py

目的： 機能比較マトリックスを作成し、競争力スコアを算出して、差別化要因と弱点を特定します。

機能の評価：

• 完全（3） - 機能を完全にサポート
• 部分的（2） - 機能を部分的または限定的にサポート
• 限定的（1） - 機能を最小限または基本的にサポート
• なし（0） - 機能を利用できません

使用方法：

# Human-readable output
python scripts/competitive_matrix_builder.py competitive_data.json

# JSON output
python scripts/competitive_matrix_builder.py competitive_data.json --format json

出力内容：

• スコア付き機能比較マトリックス
• 製品ごとの重み付け競争力スコア
• 差別化要因（自社製品が優位に立つ機能）
• 弱点（競合製品が優位に立つ機能）
• 差別化要因に基づく勝ち筋

3. POC プランナー

スクリプト： scripts/poc_planner.py

目的： スケジュール、リソース配分、成功基準、評価スコアカードを含む体系的な POC 計画を作成します。

デフォルトのフェーズ構成：

• 第 1 週： セットアップ — 環境のプロビジョニング、データ移行、設定
• 第 2～3 週： コアテスト — 主なユースケース、統合テスト
• 第 4 週： 応用テスト — エッジケース、パフォーマンス、セキュリティ
• 第 5 週： 評価 — スコアカードの完成、ステークホルダーによるレビュー、実施可否の判断

使用方法：

# Human-readable output
python scripts/poc_planner.py poc_data.json

# JSON output
python scripts/poc_planner.py poc_data.json --format json

出力内容：

• 段階的なスケジュールを含む POC 計画
• リソース配分（SE、エンジニアリング、顧客）
• 測定可能な指標を含む成功基準
• 評価スコアカード（機能性、パフォーマンス、統合、使いやすさ、サポート）
• 軽減策を含むリスク登録簿
• 実施可否の推奨フレームワーク

参照ナレッジベース

参照先	説明
references/rfp-response-guide.md	RFP/RFI 回答のベストプラクティス、コンプライアンスマトリックス、入札可否の判断フレームワーク
references/competitive-positioning-framework.md	競合分析の手法、バトルカードの作成、懸念への対応
references/poc-best-practices.md	POC 計画の手法、成功基準、評価フレームワーク

アセットテンプレート

テンプレート	用途
assets/technical_proposal_template.md	エグゼクティブサマリー、ソリューションアーキテクチャ、実装計画を含む技術提案書
assets/demo_script_template.md	アジェンダ、説明の要点、反論への対応を含むデモスクリプト
assets/poc_scorecard_template.md	重み付けスコアリングを用いたPOC評価スコアカード
assets/sample_rfp_data.json	アナライザーのテスト用サンプルRFPデータ
assets/expected_output.json	rfp_response_analyzer.pyの想定出力

コミュニケーションスタイル

• 技術的でありながら分かりやすい - 複雑な概念をビジネス関係者向けに説明します
• 自信に満ちたコンサルティング型 - ベンダーではなく、信頼できるアドバイザーとして位置づけます
• エビデンスに基づく - あらゆる主張をデータ、デモ、または導入事例で裏付けます
• ステークホルダーを意識する - 対象者（CTO、エンドユーザー、調達担当者）に合わせて説明の深さと重点を調整します

統合ポイント

• マーケティングスキル - ../../marketing/ の競合情報とメッセージングフレームワークを活用します
• 製品チーム - ../../product-team/ のRFP分析で「Planned」とされたロードマップ項目について連携します
• Cレベルアドバイザリー - 経営幹部の関与が必要な戦略的案件を ../../c-level-advisor/ にエスカレーションします
• カスタマーサクセス - POCの結果と成功基準をCSMに引き継ぎます（../customer-success-manager/）

---

ツールリファレンス

1. rfp_response_analyzer.py

RFP/RFIの要件を解析し、「完全」「部分的」「計画済み」「ギャップ」のカテゴリを使ってカバレッジを評価します。重み付けカバレッジスコア、ギャップ分析、工数見積もり、入札可否の推奨を生成します。

python scripts/rfp_response_analyzer.py rfp_data.json
python scripts/rfp_response_analyzer.py rfp_data.json --format json

フラグ	種類	説明
rfp_data.json	位置引数	RFP要件とカバレッジデータを含むJSONファイルへのパス
--format	任意	出力形式：text（デフォルト）または json

入札可否の判定ロジック：

• 入札： カバレッジスコアが70%超、かつ必須要件のギャップが3以下
• 条件付き入札： カバレッジスコアが50～70%、または必須要件のギャップが2～3
• 入札しない： カバレッジスコアが50%未満、または必須要件のギャップが3超

2. competitive_matrix_builder.py

機能比較マトリックスを生成し、重み付けされた競争力スコアを計算して、差別化要因と脆弱性を特定し、勝ち筋を提示します。

python scripts/competitive_matrix_builder.py competitive_data.json
python scripts/competitive_matrix_builder.py competitive_data.json --format json

フラグ	種類	説明
competitive_data.json	位置引数	機能比較データを含むJSONファイルへのパス
--format	任意	出力形式：text（デフォルト）または json

スコアリング： 完全（3）、部分的（2）、限定的（1）、なし（0）

3. poc_planner.py

フェーズごとのスケジュール、リソース配分、成功基準、評価スコアカード、リスク登録簿、実行可否の判断フレームワークを備えた、体系的なPOC計画を生成します。

python scripts/poc_planner.py poc_data.json
python scripts/poc_planner.py poc_data.json --format json

フラグ	種類	説明
poc_data.json	位置引数	POCの範囲と要件を含むJSONファイルへのパス
--format	任意	出力形式：text（デフォルト）または json

デフォルトのフェーズ構成： 第1週：セットアップ、第2～3週：コアテスト、第4週：高度なテスト、第5週：評価

---

トラブルシューティング

問題	考えられる原因	解決策
RFP カバレッジスコアが 50% を下回り、No-Bid の判定になる	必須要件における製品の不足、またはカバレッジ評価の誤り	ギャップ項目を確認し、実際の不足と、設定、連携、ロードマップの確約によって対応可能な項目を区別します。辞退を決定する前に再評価します
競合マトリクスで 3 つ以上のカテゴリーに脆弱性が示される	特定の競合に対する製品の不足、または実際の競争状況がスコアに反映されていない	このベンダーと競合した経験のあるフィールド SE とスコアを検証します。劣勢の分野ではなく、優位に立てる差別化要因を中心にバトルカードを作成します
POC から成約への転換率が 60% を下回る	POC の範囲が広すぎる、成功基準が購入者の優先事項と一致していない、または関係者の選定が適切でない	POC を、購入者が明示した課題に結びつく 3～5 件のユースケースに絞ります。開始前に成功基準について書面で合意し、評価にエグゼクティブスポンサーが参加するようにします
受注率が 30% を下回る	技術面では勝っていても商談で敗れている、商談への参加が遅い、またはディスカバリーの質が低くデモ内容がニーズとずれている	営業サイクルの早い段階から参加します。MEDDIC フレームワークを活用してディスカバリーの質を高めます。デモのストーリーを製品の機能ではなく、購入者の言葉に合わせます
デモから POC への転換率が 40% を下回る	デモが購入者固有のユースケースに対応していない、または内容が一般的すぎる	すべてのデモを購入者が明示した要件に合わせてカスタマイズします。購入者のデータや業界固有のシナリオを使用し、最後に質疑応答と次のステップの提案を含めます
RFP の回答に 2 週間以上かかる	テンプレートや事前作成済みコンテンツライブラリを使わない手動の回答プロセス	要件カテゴリー別に索引付けした回答ライブラリを構築します。rfp_response_analyzer.py を使用して、必須項目への対応を優先します
ステークホルダーの関与スコアが 75% を下回る	技術評価に主要な意思決定者が参加していない	早い段階でステークホルダーの役割を整理します。技術的な詳細説明と合わせてエグゼクティブ向け説明会を実施し、各ステークホルダーに個別のフォローアップを送ります

---

成功基準

• すべての競合案件で受注率が 30% を超える
• ディスカバリーから成約までの営業サイクルが 90 日未満に収まる
• POC から成約への転換率が 60% を超える
• 受注対象案件の RFP カバレッジスコアの平均が 80% を超える（入札判断が適切に機能している）
• 競合マトリクスで競合ごとに明確な差別化要因を最低 3 つ特定できる
• 顧客エンゲージメントスコアが 75% を超える（評価の節目におけるステークホルダーの参加状況で測定）
• 構造化された回答ライブラリにより、RFP の平均回答時間が 5 営業日未満になる

---

対象範囲と制限事項

対象範囲： RFP／RFI の回答分析とスコアリング、競合機能マトリクスの作成、概念実証の計画と評価、デモ準備のフレームワーク、技術提案書の構成、受注／失注分析の方法論、およびプリセールスの 5 段階ワークフロー（ディスカバリー、ソリューション設計、デモ、POC、提案）全体でのステークホルダー関与の追跡。

対象外： 営業戦略とテリトリー計画（アカウントエグゼクティブの職務）、価格設定と商業条件の交渉（pricing-strategy を使用）、販売後の導入とカスタマーサクセス（customer-success-manager を使用）、マーケティングコンテンツと競合メッセージ（marketing skills を使用）、RFP のギャップに基づく製品ロードマップの判断（product-team を使用）。ツールが分析するのは静的なデータエクスポートのみです。CRM システム（Salesforce、HubSpot）や RFP プラットフォーム（Loopio、Arphie）との連携はありません。

制限事項： 入札可否のしきい値は設定可能ですが、デフォルトでは受注率 30% 以上を目標とする B2B SaaS を想定しています。競合マトリクスのスコアの精度は入力データに左右されるため、特定の競合との現場経験に基づいてスコアを検証してください。POC の期間は標準的な 5 週間の取り組みを想定しています。規制の厳しい業界（医療、政府）では 2～3 倍の期間が必要になる場合があります。2025～2026 年に登場している AI 支援型 RFP ツールを使えば、回答時間を 60～80% 短縮できますが、ここでは連携されていません。

統合ポイント

• revenue-operations -- 技術検証が必要なパイプライン案件は SE ワークフローを通じて進められ、SE の成約・失注データはパイプライン分析に活用されます
• customer-success-manager -- POC の結果と成功基準は、契約後の導入状況を追跡するため CSM に引き継がれます
• pricing-strategy -- マトリックスビルダーで作成した競合価格データは、価格設定のポジショニング判断に活用されます
• product-team -- 「Planned」または「Gap」として記録された RFP の不足項目は、製品ロードマップの優先順位付けに活用されます
• c-level-advisor -- 経営幹部の関与が必要な戦略的案件は、経営幹部向けアドバイザリーワークフローを通じてエスカレーションされます
• marketing -- マーケティングからの競合インテリジェンスは、バトルカードの作成とポジショニングに活用されます

---

最終更新日： 2026年3月 ステータス： 本番運用可能 ツール： Python 自動化スクリプト 3 個 参照資料： ナレッジベース文書 3 件 テンプレート： アセットファイル 5 個