セールスエンジニアの一日

この役割の実像

平均的なSEは常時4～6件のアクティブな案件を担当します。ミッドマーケットのB2B SaaSでは、そのうち2～3件がアクティブなPOCの状態にあります。

**ベストインクラスの技術的な受注率は70～80%**です。SEが関与したPOCのうち10件中7～8件が受注に転換します。Presales Leadership Collective で共有されたベンチマークによります。

デモ準備の比率：30分のライブデモに対し1.5～2時間の準備が、ディスカバリー主導でカスタマイズしたデモの目安です。「定型デモを立ち上げる」やり方は速いですが、転換率は半分です。

正式なSE機能を持つ企業では、受注したミッドマーケット案件の60～80%でSEが案件チームに入っています。Forrester のpresalesベンチマーキングによります。

知識への貢献は、効いてくる遅行指標です。デモは出すのに文書化しないSEは、いずれ単一障害点になる存在です。

SEの一日を一枚の図で

5つのブロックです。準備、デモ、同期、構築、文書化。まずAEが記録したものを読むところから始まります。コールを実施します。昼食をとりながらAEとパイプラインをトリアージします。見込み客が信じる必要があるもの、つまりサンドボックス、統合仕様、セキュリティ回答を何でも構築します。学んだことを書き留めて、次のSEが車輪を再発明しないようにします。最後のブロックを飛ばすと、チームの集合知は四半期ごとにリセットされます。

午前9時47分。カレンダーには4件のデモ、午後2時にはデータモデルについてすでに二度押し返してきた見込み客のアーキテクトとのPOCレビュー、そしてダニエル（AEの一人）が今週3度目の「Xと統合できる？」をSlackで送ってきたところです。3度目なのは、最初の2回の回答が「はい、ただしこういう注意点付きで」だったのに、誰もそれを書き留めなかったからです。

これがSEの一日です。採用説明資料のバージョンではなく、本物のバージョン。営業の焦りとプロダクトの現実のあいだで、あなたが衝撃を吸収する側に立つ日です。

SEを志す人、SEが一日中何をしているのか不思議に思っているAE、転身を考えているエンジニアのいずれであっても、このガイドはそのリズムを時間ごとにたどります。この仕事は、誰も口にしないある一点で生きるか死ぬかが決まります。SEは買い手の信頼のベクトルなのです。買い手はAEからは決して受け入れない「いいえ、それはお客様のスタックでは動きません」を、SEからなら信じます。その信頼性を守ることが、この技芸のすべてです。

なぜSEの役割は組織図が示す以上に重要なのか

たいていの組織図では、SEは営業の下に位置し、AEに付いた機能説明係のように見えます。その枠組みは、実際の仕事を取りこぼしています。

SEは案件の技術的良心です。買い手の技術評価者（多くはエンジニアリングのディレクター、セキュリティのリード、運用の責任者）は、過去に痛い目を見ています。彼らは洗練されたデモを見て、契約に署名し、6週間後に、自分たちのスタックが必要とする統合がroadmap上で静かに後ろにずれていたと知ったのです。その記憶は、あなたがZoomを開くたびに部屋の中にあります。

「これはXをどう処理するのか？」という問いの裏で、買い手が本当に尋ねているのはこうです。これは私たちの本番環境で動くのか、それとも、なぜ間違ったツールを選んだのかを半年かけてCTOに説明する羽目になるのか。

それに答えるのがSEです。SEなら「はい、その統合はサポートされていますが、お客様のボリュームだとレート制限に当たります。実際にはこう解決します」と言えるからです。その一文は、プロダクトのどの機能よりも価値があります。SEがそれを言う気をなくした瞬間、信頼は崩れます。だからこそ一日のリズムは、その信頼性を守るように組まなければなりません。

時間ごとのリズム

午前8:00～9:30：デモ準備

最初の90分は受信箱のトリアージのためではありません。9時30分のデモのためのものです。コーヒー片手に9時25分から準備を始めれば、定型の流れに頼ることになります。そしてその定型の流れは、見込み客がすでにあなたのウェブサイトで見たものです。

本物の準備とはこういうものです。

AEのディスカバリーメモを全部読む。 見込み客が課題を表現するのに使った具体的な言葉に下線を引きます。「担当者の定着が本当にきつい」「リードの半分を24時間で失っている」「運用が報告に追いつけない」。こうしたフレーズがデモの骨格です。
3枚のカスタムイントロを作る。 1枚目：彼らの課題を、彼らの言葉で。2枚目：似た顧客でこれがどう展開してきたか。3枚目：これから20分で、彼らの優先順位の順に何を見せるか。「会社紹介」スライドは不要。14社のロゴの壁も不要です。
彼らのデータの形でデモ環境を整える。 実際のデータではなく、その形です。チーム規模、商談ステージの名称、テリトリーの分け方。もし相手がEMEAの12人チームなら、デモは200人規模の米国組織から始めてはいけません。
「Xについて聞かれたら」の分岐を2～3本、事前に仕込む。 ディスカバリーメモから、上位3つの質問はたいてい予測できます。ある統合、権限の質問、レガシーシステムの質問。答えを「後で確認します」ではなく、別タブで用意しておきます。

私が守っている比率は、30分のデモに対して90分の準備です。「定型デモを立ち上げてその場でしのぐ」やり方の成約率はおそらく30～35%。ディスカバリー主導で準備を重ねたやり方は60～70%超で成約します。計算は微妙ではありません。

午前9:30～11:30：ディスカバリー＋デモ

最初の15分はデモではありません。本物のディスカバリーです。AEが最初のコールですでにディスカバリーをしていても、見込み客が「とにかく見たいだけ」と言っていても、です。

質問はシンプルに聞こえますが、残りのコールを実りあるものにしてくれます。

「こういうものを買って90日後、素晴らしい成果とはどんな状態か、説明してもらえますか？」
「今使っている回避策は何で、その中で実際に壊れるのはどの部分ですか？」
「他に誰がこれを使いますか、そしてその人たちは何を見る必要があるでしょう？」

そのうえで、そのとき初めてデモをします。メニュー順ではなく、課題の順に。担当者の定着が一番の問題だと言われたなら、管理コンソールからではなく、担当者向けのモバイル体験から始めます。本当の適合を見つける技術的ディスカバリーが、その質問群をさらに深掘りしています。

実践的なルール：4～5分ごとに止まって「これはご覧になりたかったものですか？」と尋ねます。答えが「はい、でも本当に気になっているのはXです」なら、残りのデモをお膳立てしてもらったようなものです。機能ツアーではなく買い手の課題を中心に据えたデモ設計が、その深掘り版です。

午前11:30～午後12:30：AEとの案件戦略ランチ

これはSEの一日で最も過小評価されている1時間であり、最も犠牲にされやすい1時間でもあります。犠牲にしないでください。

AEとのランチ（あるいはコーヒー、30分のZoom）はパイプラインのトリアージです。どの案件が本当に現実的か。AEがどの案件で自分に都合のいい物語を語っているか。先週のどの技術的な反論が、AEが自然消滅を願っている案件キラーなのか。6週目に調達が止めてしまう前に、誰のために今セキュリティレビューの道筋を開く必要があるのか。

やり取りの一例です。

ダニエル（AE）： 「Acme は18万ドルのARR、championはVP Ops、案件は固い。あとはPOCだけ」 私（SE）： 「POCの成功基準は何？」 ダニエル： 「えっと…試してみたいって」私：「それはPOCじゃない、サンドボックスだよ。POCの成功に誰がサインオフして、具体的に何を見る必要がある？それが書面でないなら、立ち上げるべきじゃない。3週間を無駄にして、相手は音信不通になる」 ダニエル： 「…うん、その通りだ」

その会話を毎週繰り返すことは、あなたが今後出すどんな機能よりも、案件の進行速度にとって価値があります。

午後12:30～2:30：POC支援／RFP回答

午後はたいてい集中作業です。SEの大変で地味な仕事です。見込み客のサンドボックスでのデバッグ、184問のセキュリティ質問票への回答、明日アーキテクトがレビューする統合仕様の執筆。

POC作業は、規律がなければSEの時間が死んでいく場所です。どんなPOCも始まる前に、SEは5つの質問をします。AEがそれを迂回することは許されません。

championが特定されている：見込み客の社内で、これのために戦ってくれるのは誰か。誰もいなければ、POCなし。
成功基準が書面化されている：何を証明するのか、それぞれ一文で、測定可能な条件とともに。
意思決定のタイムライン：POCはいつ終わり、購買の意思決定はいつ起こるのか。「Q3のどこかで」はタイムラインではありません。
統合の制約：これはどのシステムに触れる必要があり、アクセスは確認済みか。
セキュリティの道筋：セキュリティは巻き込まれているか、それとも5週目に不意打ちをしてくるのか。

5つのうち3つが欠けているなら、そのPOCは本物ではありません。立ち上げれば、実際に成約しつつある案件に回すべき40時間を失います。POCはSEがする中で最も高価なことです。すべての案件がそれに値するわけではありません。

午後2:30～4:00：技術的な反論の深掘り

今日の午後2時のコールは見込み客のアーキテクトで、データモデルが既存のウェアハウスに合わないと指摘してきました。彼は間違っていません。私たちのモデルがアカウントの下にイベントをネストさせるやり方は、標準的ではありません。

まずい動き：守りに入ること。彼のチームの前で押し返すこと。実在しないroadmap上の修正を約束すること。

正しい動き：彼の土俵で、彼と一緒にデータフローをホワイトボードに書くこと。「おっしゃる通り、これはお客様のウェアハウスが期待する形とは違います。なぜそう設計したのか、そしてお客様の状況のチームが使う3つの選択肢はこうです」。24時間以内に書面でフォローアップすることを約束します。ギャップが本物なら、プロダクトを巻き込みます。

アーキテクトは、あなたに議論で勝ってほしいわけではありません。あなたが質問を理解し、正直に答えてくれると知りたいのです。それが信頼のベクトルです。たじろがず技術的な反論に対応するが、その手筋を詳しく扱っています。

午後4:00～5:30：ナレッジベースへの貢献

最後の90分は、ほぼすべてのSEが飛ばす部分であり、チームを良くするSEとボトルネックになるSEを分ける部分です。

この1時間はこういうものです。

「Azure AD で条件付きアクセスを使ったSAMLをどう扱うか」の文書を書く。今四半期、3人のSEが同じ質問を受けました。誰も書き留めませんでした。今日、私が書きます。
デモ環境を更新する。先週プロダクトチームが出した新しいdashboardを追加して、次のSEが古いバージョンをデモしないようにします。
今朝の準備中に見つけたギャップについて、プロダクトとループを閉じる。3社連続で、ある特定のwebhookイベントについて尋ねられました。

デモを出すだけで文書化しないSEは、単一障害点です。書くSEは、チームの技術的な受注率が四半期ごとに積み上がっていく人です。一度答えた反論は、チームメイトが30分ではなく30秒で対応できるものになるからです。

よくある落とし穴

ディスカバリーなしの過剰デモ。 重要な3つではなく、すべての機能をクリックして回ること。デモは長くなり、買い手の注意は縮み、すべてを見せて何も証明しないままコールを終えます。メニューを削り、課題を追ってください。

AEのリサーチ部門になること。 あらゆる「Xはできる？」に、非同期の文書なしで即座にSlackで返信していると、一度に5つの案件のボトルネックになります。書面で、次のAEが見つけられる場所に答えてください。チームのwikiに置いた10分のLoom一本が、同じ質問を12回受けずに済ませてくれます。

非同期文書がないこと。 あらゆる答えがDMで死に、チームは翌四半期にそれを学び直します。ナレッジベースを案件の一部として扱ってください。

あらゆるカスタムPOC依頼にイエスと言うこと。 POCは高価です。すべての案件がそれに値するわけではありません。

技術的なナラティブをAEに握らせること。 AEは価格、緊急性、購買プロセスを所有します。SEは「これは本番で本当に動くのか」を所有します。その配線が交差した瞬間、両方の役割が弱くなります。

SEの日次リズムのテンプレート

これをガードレールとして使ってください。すべての日が当てはまるわけではありませんが、逸脱は意図的であるべきです。

8:00～9:30：デモ準備ブロック（受信箱なし、Slackなし）
9:30～11:30：デモ／ディスカバリー
11:30～12:30：AEとの同期／パイプラインのトリアージ
12:30～2:30：POC／RFP／サンドボックス作業
2:30～4:00：技術的な反論またはアーキテクトとのコール
4:00～5:30：知識への貢献＋デモ環境の保守

真っ先に犠牲になるブロックは、いつも最後のものです。それを守ってください。

デモ準備チェックリスト

すべてのデモの前に使ってください。

AEのディスカバリーメモを全部読み、見込み客の正確な課題の言葉を拾った
3枚のカスタムイントロを作った（彼らの課題、自分が見てきたパターン、見せる内容）
デモの流れをプロダクトのメニューではなく彼らの優先順位で並べた
デモ環境が彼らのチーム規模、セールスサイクル、テリトリーの形に合っている
予想される反論3つに、用意した回答とタブの事前読み込みがある
クロージング用に「お客様のチームにとって、何があればイエスになりますか？」という質問を一つ用意した
相手側から誰がコールに参加し、各役割が何を気にするかを確認した
ライブ環境が不調なときのバックアッププラン

成果を測る

SEにとって本当に重要な指標です。

案件への影響：SEが案件チームに入っていた受注案件の割合。ミッドマーケットで50%未満なら、SE機能が本来配置されるべき場所に配置されていません。
技術的な受注率：受注に転換したPOCの割合。SEがPOCをきちんとqualifyし、うまく運営しているかどうかの最も明確なシグナルです。
POC成功率：表明した成功基準を満たしたPOCの割合。POCは成功しても成約しないことがありますが、自らの基準を満たせなかったPOCはほぼ成約しません。
デモでの価値到達までの時間：ベストインクラスは「始めましょう」から「ああ、まさにこれが欲しかった」まで8分未満です。
知識への貢献：四半期あたりに追加した文書や反論対応集の数。良いSEとチームを掛け算するSEを分ける遅行指標です。

本当に重要なSEの指標が、これらそれぞれを企業ステージ別の目標値とともに分解しています。

Rework が SE の一日をどう支えるか

SEの一日は3つの面（AEのパイプラインビュー、POC環境、チームのナレッジベース）にまたがり、ほとんどのSEは互いに連携しない3つの異なるツールに行き着きます。Rework CRM は、AEとSEに一つのパイプラインビューを与え、技術的適合のフィールド、POCのステージゲート、商談ごとに追跡されるSEの関与を提供します。Rework Work Ops はSE自身の仕事を扱います。担当者と期日付きのPOCタスク、反論対応集が実際に格納されるナレッジベース、そしてデモ環境の変更履歴です。CRM は1ユーザーあたり月額12ドルから、Work Ops は1ユーザーあたり月額6ドルからで、両者は奪い合うのではなくデータを共有します。SEの役割の全体像は、セールスエンジニアの職務記述書（Companion JD）にあります。

この次に来るもの

一日の流れは、4つのサブクラフトを深掘りして初めて意味を成します。適合を見つけるディスカバリー、買い手の課題を追うデモ設計、信頼を保ったまま行う技術的な反論対応、そしてそのどれが効いているかを教えてくれる指標。それぞれがこのコレクションの中の独立したplaybookです。

これは正直な仕事です。あなたはコールで最も声の大きい人にはなりません。最も信頼される人になります。一度それが案件で効くのを感じれば（懐疑的なアーキテクトが椅子に深くもたれて「なるほど、これは私たちに合うと思う」と言うあの瞬間）、なぜこの役割が存在するのかが分かるはずです。

セールスエンジニア Playbook