今回の問いはこれです。提案書が自社の提供するものを説明するとき、顧客はそれがなぜ自分にとって重要なのか、そしてなぜ御社にしかできないのかまで読み取れるでしょうか。
多くの提案書は前半にだけ答えて止まります。能力、製品、認証、業歴を並べ、その価値は評価者に考えてもらうままにしています。APMP Body of Knowledgeは解決策を三つの言葉で示します。機能（Feature）は自社が提供するもの、便益（Benefit）は顧客がそこから得るもの、差別化要因（Discriminator）は顧客にとって重要で、他の入札者には真似できない便益です。顧客は便益を買い、差別化要因が自社の便益を選ばせます。
このシリーズでは、APMP Foundation Study Guideに要約されたAPMP Body of Knowledgeを順に取り上げます。今回の能力はFocus on the Customerに属し、シリーズの他の回で扱うテーマ・ステートメント、バリュー・プロポジション、ウィンテーマの材料になります。
三つの言葉、三つの問い
Study Guideは三つを見分ける簡単な方法を示しています。そのまま推敲の道具になるので、覚えておく価値があります。
| 用語 | 答える問い | 誰の言葉か | 例 |
|---|---|---|---|
| 機能 | What? 自社は何を持ち、何をするのか | 自社の言葉：仕様、ツール、プロセス、人員 | 「24時間有人の監視センター」 |
| 便益 | So what? 顧客にとって何が良くなるのか | 顧客の言葉：コスト、時間、リスク、成果 | 「利用者が気づく前に問題を捉え、サービス停止が減る」 |
| 差別化要因 | Why us? なぜ自社だけなのか、顧客はなぜそれを気にすべきか | すべての競合と比べたときの顧客の言葉 | 「この顧客と同じ種類のネットワークをすでに監視している唯一の入札者なので、習熟期間なしに初日から監視が始まる」 |
簡単に言えば、機能は説明、便益は価値、差別化要因は選ぶ理由です。提案書には三つとも必要ですが、評価者が点を与えるのは主に後の二つです。
Body of Knowledgeがはっきりさせている点が一つあります。機能を書くなという意味ではありません。機能は便益を実現する手段であり、評価者は便益を信じるために機能を見る必要があります。問題は機能で止まってしまい、それを顧客の課題に結びつける作業を顧客に任せてしまうことです。多くの組織がまさにそうしています。
提案書が機能で止まってしまう理由
提案書の書き手は自然と売り手の視点から出発します。製品も方法論もチームもよく知っているので、まずそれが頭に浮かびます。評価者は反対側から読みます。頭の中では一つの問いがずっと回っています。それで、うちにとって何が良いのか？
売り手の視点（機能）
「当社は24時間監視システムを提供します。」
正しいけれど、まだ終わっていません。なぜ重要なのかは評価者が推測するしかありません。
顧客の視点（便益）
「24時間の監視により、貴機関は障害の兆候を早く見つけ、サービス停止時間を短くできます。」
同じ機能が、顧客の望む成果につながりました。
Body of Knowledgeによれば、この切り替えを特に難しく感じる人たちがいます。
- 技術担当者とSME（分野の専門家）。その機能がなぜすごいのかを正確に知っているので、本人には機能がそのまま便益に感じられます。評価者にとっては、まだ仕様にすぎません。
- 現行の受注者。何年も同じ契約を担当していると、顧客が「本当に」求めているものを知っていると思い込みがちです。今回顧客が求めたことと違っていてもです。
- 自社について書くすべての人。どのチームも自社の強みを過大評価します。人として当然のことで、だからこそ顧客の視点は推測ではなく確認する必要があります。
顧客ニーズから始める
便益とは、自社が考える自社の良いところではありません。顧客が自分の課題を解決してくれると認めた価値です。だからBody of Knowledgeはこのテーマを顧客理解から始めます。書き始めるずっと前、営業や案件管理のプロセスの中でです。
案件を追うということは、自社の能力が顧客ニーズに合っていると仮定することです。Study Guideは、その仮定を信じ込まずに確かめるよう勧めています。プロセスを簡単にまとめると次のとおりです。
- 書く前にニーズを知る。顧客に会い、何を直したいのか、何を実現したいのかを把握します。
- 自社の機能をニーズに対応させる。どの機能と、その機能が生む長所が、それぞれのニーズを解決できるかを検討します。
- 顧客とアイデアを検証する。考えられる解決策を共有し、顧客がどれに価値を感じるかを確かめます。
- 確認された長所を便益に変える。顧客が認めたものは、たとえば機能・便益表として、提案書に便益として盛り込みます。
- 競合と比べる。自社の便益を競合が提案しそうなものと並べ、どれが差別化要因かを見極めます。
要求事項がなぜ入っているのかを知る
Body of Knowledgeは見落としやすい点をもう一つ加えます。要求事項に何が書いてあるかを知るだけでは足りません。顧客がなぜその要求事項を入れたのかも知る必要があります。
たとえばRFPに「リアルタイム監視」とあるとしましょう。それはWhatです。Whyは、昨年障害の発見が遅れたからかもしれませんし、運用担当者が苦情を受けて初めて問題を知ったからかもしれませんし、繁忙期にサービスが二度止まったからかもしれません。理由ごとに便益は変わり、そのうちこの顧客が買おうとしている便益は一つだけです。監視機能はどの場合も同じですが、点を取る文は違います。
機能、長所、便益
3列の表を使うと翻訳の過程が目に見え、まだ機能の段階にとどまっている文もすぐに見つかります。文書処理ソリューションを例に、この記事のために作った表です。
| 機能（自社が持つもの） | 長所（その機能がすること） | 顧客の便益（顧客にとって良くなること） |
|---|---|---|
| 自動分類エンジン | 繰り返しの手作業による仕分けをなくす | 担当者の1件あたりの処理時間が減り、滞留が早く解消する |
| 標準テンプレート | すべての文書が同じ構成になる | 確認者が重要な情報をすばやく見つけ、差し戻しが減る |
| 各記述から出典へのリンク | 誰でも内容の出どころをたどれる | 監査リスクが下がり、修正にかかる時間が減る |
1列目は社内の言葉で、最後の列は顧客の言葉です。草案の文が1列目にしか当てはまらないなら、まだ完成していません。
差別化要因を見つける
機能を便益に変えるのは仕事の半分です。残りの半分は、どの便益が自社をより良い選択肢にするのかを見極めることで、これは自社だけを見ていてもできません。比べる必要があります。
顧客の側から、正直に比べる
差別化要因を見つけるには、顧客ニーズについての情報と、競合がそのニーズにどう応えそうかについての情報が必要です。キャプチャーチームや営業チームが集めることも、外部のコンサルタントが集めることもありますが、誰が集めたにせよ、Body of Knowledgeは丁寧に分析するよう求めています。役に立つ競合情報は、誰が入札しそうか、何をいくらで提案しそうか、そして何よりも顧客が彼らをどう見ているかに答えます。
続いて入札者比較マトリクスで、自社を含む主要な入札者を、各要求事項が求めることと、それが盛り込まれた理由に照らして評価します。このツールを役立てるルールは耳が痛いものです。自社がつけたい点ではなく、顧客がつけるであろう点を書くことです。自社に甘い点をつけるチームはすべての欄で満点を取り、本当に手を入れるべきところを見逃します。入札者ごとのSWOT分析は、経営陣の交代、法的な係争、合併の噂など、マトリクスが拾いきれない文脈を補ってくれます。競合の弱みは自社の機会になり、競合の強みは自社の脅威になります。（二つのツールは第5回顧客・競合インテリジェンスで詳しく扱いました。）
スイートスポット
Study Guideは差別化要因を、重なり合う領域として描いています。顧客ニーズ、競合の能力、自社の能力です。差別化要因があるのはただ一つの区画だけです。顧客が重視するものを自社が提供し、他の誰も提供していないところです。それ以外の組み合わせは、完全な差別化要因にはなりません。
残りの区画を読むことも、提案書を計画するときに役立ちます。次の表はこの考え方の当てはめ方として、この記事のために整理したものです。
| 顧客に必要か | 自社は提供するか | 競合は提供するか | それは何か | 提案書ですること |
|---|---|---|---|---|
| はい | はい | いいえ | 差別化要因 | 前面に出し、定量化し、証明する |
| はい | はい | はい | 前提条件 | 満たしていることを簡潔に示すか、その上に自社だけの便益を重ねる |
| はい | いいえ | はい | ギャップ | パートナーや解決策の変更で埋めるか、影響を抑える |
| いいえ | はい | どちらでも | 買い手のいない機能 | 削るか短くする。点にはならない |
2行目はもう少し詳しく見る価値があります。自社と競合が同じ機能を持っていても、その機能を自社だけが提供できる便益で包めば差別化要因に変えられる、とBody of Knowledgeは述べています。2社ともヘルプデスクを運営できるとします。しかし、この顧客のシステムをすでに知っているエンジニアを配置し、最初の電話で問題を解決できるのは1社だけかもしれません。
ブランド、規模、経験は自然に差別化要因にはならない
ここで最も多い失敗は、自社の名前を頼りにすることです。自社のロゴを付けられるのは自社だけですが、だからといってロゴが便益になるわけではありません。人員規模、拠点、確立したプロセス、製品、業歴も同じです。どれも便益として認められる前に検証が必要な機能であり、差別化要因かどうかはその先の話です。
過去の実績が正しい方向を示してくれます。類似案件の一覧は、主に自社の主張を裏づける役割を果たします。その便益は、そこから学んだことにあります。近道、今なら避けられるリスク、自ら作ったチェックリストなどです。その教訓によって、この顧客の要求をより速く、より良く、より安全に、より低コストで満たせると説明すれば、経験が便益として働き始めます。
価値を定量化し、証明できるようにする
測定された便益は形容詞に勝ります。施設保守の入札を例に、この記事のために作った二つの文を比べてみてください。
あいまい
「迅速なサポートを提供します。」
何と比べて迅速なのでしょうか。どの入札者も同じことを言います。
測定されている
「時間帯を問わず、2時間以内にエンジニアが現場に到着します。」
顧客が思い描け、比べられ、約束の履行を求められます。
Body of Knowledgeは、よくあるテーマ・ステートメント「安心して任せられる会社」についても同じことを述べています。リスクが低いと伝えたいのですが、測りようがありません。機能させるには、具体的な便益を示し、根拠と数字を付ける必要があります。たとえば、本当に打ち出したいのがスケジュール順守である入札者なら、次のように書けます（数字は説明のための架空のものです）。
「お約束した日に稼働することを信頼していただけます。同種の移行案件18件はすべて予定どおりに稼働し、その中で磨いてきた切り替え手順書により、週末の停止時間を3分の1短縮しました。」
この文には、具体的な便益、それを裏づける根拠、顧客が確認できる数字がそろっています。
定量化を誠実に保つための注意点が三つあります。
- 証明できる数字だけを使う。裏づけのない数字は、ないほうがましです。評価者が一つの主張を疑った瞬間、他の主張もすべて割り引いて読まれます。
- その数字で評価される覚悟をする。結ばれる契約が成果連動型なら、定量化した便益がそのまま自社を測る指標になることがあります。根拠とともに全体を通して定量化し、実行段階で守れることを確認してください。
- 測れないときは結びつける。すべての便益に数字があるわけではありません。その場合は顧客のミッションや公表された目標に結びつけ、顧客自身の言葉で説明してください。顧客の言葉を使うこと自体が、ニーズを理解しているというサインになります。
So what?テストを行う
このテーマで最も単純な道具が、最も役に立ちます。便益のつもりで書いた文のあとに、顧客になったつもりで「だから何？（So what?）」と問いかけてください。機能の文は答えられません。便益の文は、解決される顧客の課題や得られる成果を示して答えます。
顧客が関心を持つところに行き着くまで、鎖のように問い続けます。この記事のために作った例です。
- 「当社のプラットフォームには120の標準コネクターがあります。」だから何？
- 「貴機関の既存システムを、個別開発なしで接続できます。」だから何？
- 「連携が数か月ではなく数週間で終わり、年度内に新しいサービスを始められます。」
1行目は機能です。3行目はこの顧客がお金を払う価値のある便益で、そのスケジュールに競合が追いつけないなら差別化要因です。
誰がテストするかが重要です。機能を設計した本人は、その機能が便益として読まれるかを判断するのに最も不向きです。Body of Knowledgeは、技術の詳細は知らないが顧客の視点を理解している人に任せるよう勧めています。目指すのは、便益があまりに明らかで、顧客が自社の機能の価値を自分で推し量る必要がない状態です。
次の提案書のためのチェックリスト
- まず顧客ニーズを書き出す。主要な要求事項ごとに、RFPに入っている理由も含めます。
- 機能／長所／便益の表を作る。主なソリューション要素ごとに埋めます。
- 想定される便益を顧客と検証する。できればRFPの前に行い、顧客が認めたものを残します。
- すべての入札者を顧客の視点で評価する。比較マトリクスでは自社の弱点も正直に書きます。
- スイートスポットを示す。自社は満たせて競合は満たせないニーズを前面に出します。
- ブランド、規模、経験の主張を疑う。それぞれを、この顧客にとって何が変わるかで書き直します。
- 証明できるところは定量化する。残りは顧客のミッションに顧客の言葉で結びつけます。
- So what?テストを行う。技術よりも顧客をよく知るレビュアーと一緒に行います。
Contrlでは
今回の要点は、機能は顧客が認める便益と、自社にしかできない理由に変わって初めて点になる、ということです。Contrlでは、この翻訳がスライドを書く前に行われます。戦略インタビューで顧客、自社、競合について話すと、提案されるウィンテーマにはそれぞれ顧客ニーズ、競合に対する自社の強み、顧客が得る効果が書かれているため、話した機能は「だから何？」と「なぜ自社か？」への答えとして現れることになります。選んだテーマはセクションごとにキーセンテンスへ絞り込まれ、各ページの先頭に機能の一覧ではなく便益が立ちます。
次回予告
便益と差別化要因を打ち出すと、評価者は皆同じことを尋ねます。それが本当だとどうしてわかるのか。第10回はプルーフ・ポイント（Proof Points）を取り上げます。どのような証拠が主張を信じさせるのか、そして提案書のどこに置くべきかを見ていきます。
この記事は、APMP Body of Knowledgeを要約したAPMP Foundation Study Guide 第4.2版（© 2025 APMP）にもとづく独立した学習用の解説です。原典を言い換え、解説したもので、APMPの承認を受けたものではありません。監視とヘルプデスクの文、文書処理ソリューションの表、四つの区画の表、サポート時間の比較、スケジュール順守の文、コネクターの例と、その中のすべての数字は、この記事のために書いたものです。正式な本文と資格についてはapmp.orgをご覧ください。