はじめに
「いい内容のはずなのに、なぜか提案が通らない」
「営業に頼まれて作ったのに、“刺さってない”と言われる」
——こういった“提案書迷子”になっているSEは、実は少なくありません。
この記事では、なぜ提案書が通らないのか、その原因と解決策を3つの視点から解説します。
point：読み手は意思決定者。技術者の「わかりやすさ」では不十分です。
1. 提案書が通らないSEの“あるある”パターン
提案書が通らないSEには、いくつか共通のパターンがあります。
| パターン | 内容 | ありがちな結果 |
|---|---|---|
| 技術説明が中心 | スペックや仕組みの解説がメイン | お客様が「で、何が良いの？」と感じてしまう |
| 結論が見えない | ページが進んでも“何が言いたいか”が不明瞭 | 読み手の集中力が切れる |
| 課題とのつながりが弱い | 解決策が相手の現状と紐づいていない | 「それ本当に必要？」と疑問視される |
2. 通る提案書に共通する“3つのポイント”
ポイント①：読み手の“意思決定軸”に合わせて構成する
-
読み手が「コスト重視」なのか「リスク回避重視」なのかで、響くポイントは変わる
-
提案書の最初に**「読み手の関心ごと」→「課題」→「提案」**の順で構成する
| タイプ | 関心ポイント | 提案書で強調すべき項目 |
|---|---|---|
| コスト重視 | ROI・削減効果 | 定量的な数値・費用対効果 |
| 品質重視 | 安定性・導入実績 | ユースケース・信頼性 |
| スピード重視 | 導入期間・手離れの良さ | プロジェクトスケジュール・サポート体制 |
ポイント②：「だから何？」を常に先に書く
-
ページの冒頭に、一文で言いたいことを結論として書く
-
技術説明や詳細情報は、結論を支える根拠として位置づける
NG例：
「このソリューションは分散アーキテクチャを採用しており…」
→ で、何がいいの？ となる
OK例：
「高可用性を担保するために、分散アーキテクチャを採用」→理由として納得感が出る
ポイント③：課題と提案を“1対1”でつなげる
-
相手の「困っていること」と「提案内容」が直結していることが大事
-
課題→それに対する提案→効果、という“対応表”で考えるのが効果的
課題と提案の対応表（例）
| 相手の課題 | 提案内容 | 解決されること |
|---|---|---|
| 顧客対応が属人化している | ナレッジ共有システムの導入 | 誰でも情報にアクセスできる仕組み |
| 手作業でミスが多い | 業務フローの自動化 | ミス削減・担当者の負荷軽減 |
3. 提案書作成の「よくある誤解」を解いておこう
誤解①：「わかりやすく＝詳しく書く」
→違います。わかりやすさとは、“短くても伝わること”。
シンプルな構成と要点が何より大事。
誤解②：「情報は全部盛り込んだ方が安心」
→むしろ逆効果。情報過多で、伝えたい主張がぼやけてしまいます。
“読まれる前提”ではなく、“流し読みされる前提”で構成を。
4. 提案力を武器に変えるには？day0でできるサポート
提案書づくりは、一人でやると主観に偏りがち。
day0の1:1支援では、第三者視点を活かしながら提案書の壁打ちや改善を支援しています。
day0でできること
| サポート内容 | 説明 | 活用場面 |
|---|---|---|
| 提案書レビュー | 構成・論点・表現などをブラッシュアップ | 商談前の資料精査に |
| 読み手視点トレーニング | 意思決定軸に応じた資料設計の練習 | BtoB商談に多い |
| ロールプレイ | 説明の流れ・補足スキルの練習 | 本番前のリハーサルに |
まとめ：通る提案書は「論点」と「構造」が命
-
通らない提案書には、技術過多・構成不明・課題と提案のズレがある
-
まずは、「誰に」「何を」「なぜ」を構造化して書くことが第一歩
-
読み手の“決め手”を意識した構成を心がけよう
