📖 目次
はじめに
これまで発注される側（受注側）のエンジニアとして働いてきましたが、初めて発注側の立場になり、営業を受ける側を経験しました。
名刺を配った直後、様々な営業メールや会議依頼が来て、「あ、これ煩わしいな」と感じた瞬間がありました。
なぜそう感じたのか、トヨタ式の「なぜなぜ分析」で深掘りしたところ、エンジニアリングにも通じる本質的な気づきがあったので共有します。
煩わしいと感じた営業の実例
瞬間的に感じたこと：
今すぐ内容を確認できない（出勤直前）
他のメンバーを呼ぶべきか判断できない（内容不明）
もしかして焦らせて判断を急がせようとしてる？
なぜなぜ分析：煩わしさの正体
なぜ煩わしいと感じた？
→ 出勤直前で、会議依頼より資料が欲しかった
なぜ資料が欲しかった？
→ 今すぐ見られない、判断ができない、焦らされている気がした
なぜ判断ができないと困る？
→ ちゃんと判断したい、間違えたくない
なぜ間違えたくない？
→ 間違えると、他の人の時間を無駄にするから
なぜ時間を無駄にしたくない？
→ 自分が時間を無駄にされた経験が多く、他の人にそういう思いをさせたくないから
発見した3つの本質
- 売込みが煩わしいのは「相手の状況・価値観を無視しているから」
エンジニアは「文脈（コンテキスト）」を重視します。
今どういう状況なのか
何を判断すべきなのか
どんな情報が必要なのか
これらを無視した営業は、コードレビューで文脈を無視したPRを出すのと同じです。
- 良い営業とは「相手が判断しやすい情報提供」ができること
エンジニアが良いドキュメントを書くのと同じ原則：
悪い営業 良い営業
会議ありき まず資料・概要を提示
全て口頭で説明 文書で判断材料を提供
急かす 判断に必要な時間を尊重
売りたいものを押し付け 課題起点で提案
これってREADME駆動開発と同じ思想では？
- 人によって「時間の価値」や「判断基準」が異なる
ここで重要な気づきがありました：
「でも人によっては、無駄にされても会議を入れられれば良い人もいるかも」
つまり、相手のペルソナを理解する必要があるということです。
エンジニアが喜ぶ営業アプローチ（提案）
✅ DO：やって欲しいこと
件名：【資料送付】〇〇の課題解決案｜15分で判断可能な内容です
本文：
突然のご連絡失礼いたします。〇〇社の△△です。
■ 送付理由
貴社が××の課題を抱えていらっしゃると推測し、
当社の解決事例をまとめた資料をお送りします。
■ 資料内容（3ページ・読了3分）
- 類似企業での課題と解決策
- 料金体系（明朗会計）
- 導入フロー
■ 次のアクション（ご判断ください）
[ ] 興味なし→返信不要です
[ ] 詳細希望→15分のオンライン説明会
[ ] 本格検討→関係者含めた1時間MTG
ご不明点あればお気軽にご連絡ください。
この営業が良い理由：
相手の状況を尊重（読むタイミングを選べる）
判断材料が明示（資料・時間・内容）
次のアクションが選択可能（押し付けない）
無視してもOKという心理的安全性
❌ DON'T：やらないで欲しいこと
いきなり会議設定リンクを送る
内容不明のまま「お話しさせてください」
返信がないのにリマインド連打
「今だけ」「限定」で焦らせる
「他社も導入してます」と同調圧力
エンジニア視点で考える「営業の技術的負債」
実は営業にも「技術的負債」に似た概念があると気づきました。
技術的負債 営業的負債
雑なコード 雑な営業メール
ドキュメント不足 情報提供不足
後で問題化 信頼を失う
リファクタが必要 関係再構築が必要
「急いで成果を出そうとして、相手の時間を軽視する」
これは技術的負債を積むのと同じ構造です。
発注側になって学んだこと（まとめ）
受注側エンジニアとして
良い提案書は、相手が判断しやすいREADMEである
相手の状況（タイミング・役割・課題）を推測する
選択肢を提示し、押し付けない
発注側エンジニアとして
営業を受ける時は、判断基準を明示する
良い営業には、具体的なフィードバックを返す
自分の価値観（時間の使い方）を言語化しておく
どちらの立場でも共通
「相手の時間を尊重する」という原則は、エンジニアリングの根幹と同じ
おわりに
「売込みが煩わしい」という感情の裏には、
「自分が時間を無駄にされた経験から、他者の時間を尊重したい」
という価値観がありました。
これはエンジニアが「無駄な会議」「冗長なコード」「不明瞭な仕様」を嫌うのと同じ理由です。
良いコードを書くように、良いコミュニケーションをする。
それがエンジニアにとっての「喜ばれる営業」なのかもしれません。
皆さんは発注側・受注側、どちらの立場でどんな経験がありますか？
コメントで教えていただけると嬉しいです。