執筆者：宮崎 祥一
Honeywell、Experian、Teradata、Avanade、SAS Instituteなどで、アナリティクス領域の事業開発に従事。製造業を中心に、医薬や金融など多様な業界において、導入事例が乏しい新領域の提案も含め、案件創出から受注までを主導してきました。2023年にHoneywellのAccount Management Directorを退任。現在は株式会社アルファブランディングを通じて、DXや新領域のソリューションにおける初期提案の設計支援を行っています。
はじめに｜評価基準が後から決まると、提案は価格で終わります
RFPが出て、ベンダーが出揃って、いざ比較という段階になったとき、「結局、価格で決まった」という経験はないでしょうか。
提案の出来が悪かったわけではない。むしろ丁寧に作った。それでも最後は価格と条件の話になった——そういうケースの多くは、提案書の内容より前の段階に原因があります。「何を基準に比較するか」が、RFPが出る前に設計されていなかったことです。
このコラムでは、IT・DX提案でそのまま使えるように、価格以外で評価される比較軸の設計手順と評価表テンプレを整理します。評価基準を先に作るとはどういうことか、具体的な項目と配点の考え方まで見ていきます。
- はじめに｜評価基準が後から決まると、提案は価格で終わります
- 1. 課題と背景｜提案が価格比較へ流れる構造
- 1-1. ヒアリングが丁寧なほど、提案は似通いやすい
- 1-2. 現場課題を丁寧に解いても、経営層には届かない
- 1-3. 調達・購買に渡ると、評価は価格と条件に戻る
- 2. 課題の構造｜なぜ提案は「経営の言葉」に届かないのか
- 2-1. 業務課題と経営課題をつなぐ橋がない
- 2-2. 「経営層の言語」に変換されていない提案は、上位会議で止まる
- 3. 解決策｜評価基準を先に設計し、価格以外の比較軸を固定する
- 3-1. 提案の起点を「経営課題」に置く
- 3-2. 「いつ、何が変わるか」を時間軸で見せる
- 3-3. 評価基準を「価値×根拠×リスク」で先に固定する
- 3-4. 評価表テンプレ｜購買に渡せる比較軸の1枚
- まとめ｜「何を基準に比較するか」を先に設計することから始めてみてください
- 【参考】CaseScenario™なら
1. 課題と背景｜提案が価格比較へ流れる構造
1-1. ヒアリングが丁寧なほど、提案は似通いやすい
DX提案では、「顧客の課題を丁寧にヒアリングし、その解決策を提示する」という進め方が標準になっています。姿勢としては正しい。しかしこの正しさが、提案の同質化を生むことがあります。
複数のベンダーが同じ顧客を訪問し、同じように「いま何に困っていますか」と尋ねると、顧客は同じ説明を繰り返します。各社の製品やサービスは違っていても、提案の出発点がほぼ同じになる。その結果、「現状分析→課題抽出→解決策→効果」という構成が揃い、使う言葉まで近づいていきます。
顧客から見れば、どの提案も「理解しやすいが、似ている」ものになる。差が見えなければ、比べやすい尺度である価格に話が寄っていくのは自然な流れです。
問題はヒアリングの姿勢ではありません。同じ課題を聞き、同じ言葉で整理する構造のままでは、どれだけ誠実に作っても提案は横並びになりやすいということです。
1-2. 現場課題を丁寧に解いても、経営層には届かない
提案が似通いやすいもう一つの理由は、多くのDX提案が現場最適の延長で止まりやすいことにあります。
RPAやAIによる自動化は、現場の業務効率化や負荷軽減には有効です。「作業時間の削減」「人手不足の解消」「データ活用の効率化」——これらは現場担当者には響きます。しかし経営層が見ているのは、それが「成長への貢献」や「利益構造の改善」にどうつながるかです。そこまで見えなければ、投資判断の対象としては浮かび上がってきません。
提案は「有効そうな業務改善策」として受け取られ、技術の優劣や導入コストの比較へ近づいていく。ここまで来ると、価格競争への入口はすでに開いています。
1-3. 調達・購買に渡ると、評価は価格と条件に戻る
提案が同質化し、なおかつ経営課題との接続が弱いまま進むと、最終判断は購買・調達部門の評価へ移りやすくなります。
調達の役割は「公平な条件で、比較可能な形で、最適な契約を結ぶこと」です。そのため評価の中心は、価格、契約条件、リスク、責任分界といった比較しやすい項目になります。この段階に入ると、提案は「経営の意思決定材料」ではなく「購買手続き上の比較対象」として扱われます。
誠実に作られた提案であっても、評価は価格と条件へ回収されやすくなる。これは営業の努力の問題ではなく、提案が価格で比較されるしかない状態に、すでに入ってしまっているからです。
価格で決まるのは値引き交渉の問題ではありません。その前の段階で、比較の土俵がそうなっていることが本当の問題です。
2. 課題の構造｜なぜ提案は「経営の言葉」に届かないのか
2-1. 業務課題と経営課題をつなぐ橋がない
提案が現場では評価されるのに、上位会議で止まる。このパターンが繰り返されるとき、多くの場合、業務課題と経営課題の間に橋が架かっていません。
以前、外資系アナリティクスベンダーで新製品3本を半年で売り切らなければならない状況に置かれたことがありました。社内は諦めムードで、既存の提案スタイルのまま出しても刺さらない。そこで参照したのが、米国本社のトップ営業が使っていた提案書でした。PowerPointではなくWord文書で、顧客のIR情報をもとに経営課題を特定し、そこから解決策と導入後の展望まで文章で書いてあった。機能の説明から始まる提案書とは、まったく構造が違っていました。
それまでの提案は「この製品でこの業務が改善できる」という構造でした。でも顧客の経営層が見ているのは、「自社の経営課題に対して、この投資は何を前進させるのか」という問いです。この橋を架けずに提案を出し続けていたことが、経営層に届かない提案を量産していた原因でした。
2-2. 「経営層の言語」に変換されていない提案は、上位会議で止まる
提案が経営層に届かない理由のもう一つは、使っている言葉の体系が現場語で止まっていることにあります。
提案の現場で日々接点を持つのは、部課長層や現場責任者です。そのため、ヒアリングで蓄積されるのは業務の困りごとであり、経営層が投資判断で使う言語ではありません。「効率化」「省人化」「データ活用」という言葉は現場には届きますが、経営が見ている成長戦略や資本効率、重点施策との接続が見えない。
このズレは、担当者の勉強不足というより構造的な問題です。日々の提案活動が現場課題の解決に最適化されているほど、経営層の言語体系から遠ざかっていきます。
ある製造業の顧客への提案で、他業界の事例を転用しても刺さらない時期がありました。顧客のIR情報をもとに「製造業が導入するシナリオ」として一から組み直したところ、担当者の反応が変わり、「自分たちの課題」として検討が始まりました。事例の有無より先に、「この提案は自分たちの経営課題の話だ」と感じてもらえるかどうかが、上位会議への入口になっていたのです。
提案が比較に回される前に、経営課題への接続を設計しておくこと。それができていないまま評価に入ると、購買側は価格と条件で比べるしかなくなります。
3. 解決策｜評価基準を先に設計し、価格以外の比較軸を固定する
3-1. 提案の起点を「経営課題」に置く
DX提案が価格比較に入りやすい最大の理由は、提案が現場課題の解決として設計されており、経営目標への道筋として設計されていないことにあります。
外資系ITベンダー時代、あるSI案件でIT部門との関係は良好で稟議も通過していたにもかかわらず、役員会で半年以上止まり続けたことがありました。原因を競合製品との比較だと誤解し、比較資料を作り、役員同士の面談を設定した。しかし実際の原因は、欧州販売強化や工場ライン組み替えといった、IT投資とは無関係な経営アジェンダとの競合でした。IR・アニュアルレポートを読む習慣がなく、そもそも顧客の経営課題が見えていなかったのです。
提案の起点を現場課題ではなく経営課題に置くと、設計の順序が変わります。顧客企業のIRや中期経営計画を読み、「今この会社が経営上の優先課題として何を置いているか」を先に把握する。その上で、どの業務課題がボトルネックになっているかを接続し、自社のソリューションをその道筋の中に位置づける。
RPAやAIも、それ自体を提案するのではなく、この道筋の中の一要素として置かれて初めて、経営層に届く提案になります。「この施策を進めると、中計の重点テーマのどこが前進するか」が見えれば、提案は業務改善策ではなく投資判断の対象として扱われやすくなります。
3-2. 「いつ、何が変わるか」を時間軸で見せる
経営層が見ているのは、導入直後の効果だけではありません。「この施策が、いつ、どの段階で、どの経営成果につながるのか」という時間軸です。
多くのDX提案は「早期に業務改善できる」という短期効果を中心に語りますが、経営層はそれを中期経営計画や重点テーマの流れの中で見ています。このズレを埋めるには、提案をフェーズ構造で設計することが有効です。初期フェーズでは現場プロセスの改善、中期では部門横断の最適化、最終的には経営指標の改善へつなげる、という道筋が見えれば、提案は「今この施策を始める理由」を持つようになります。
短期の改善テーマを、経営が判断できる時間スケールへ翻訳すること。ここがないと、提案は目先の効率化策として扱われ、最終的には価格や導入スピードの比較に落ちやすくなります。
3-3. 評価基準を「価値×根拠×リスク」で先に固定する
経営課題を起点に道筋を描き、時間軸を設計しても、実務ではそれだけでは不十分です。RFPやベンダー選定の局面では、最終的に「比較できる形式」への整理が求められます。価格以外で評価される状態を作るには、価格以外の評価基準を先に定義しておくことが必要です。
重要なのは、評価基準を説明の補足として後から付けるのではなく、提案の前提として先に固定することです。IT・DX提案では、評価軸を「価値（Value）」「根拠（Evidence）」「リスク（Risk）」の3つで設計すると、価格以外でも比較可能な枠を作れます。
項目 | 内容 |
|---|---|
価値（Value） | 経営にとって何が良くなるのか（成果の定義） |
根拠（Evidence） | なぜ言えるのか（実現性・再現性の証拠） |
リスク（Risk） | 何が障害になり得るか（失敗条件と対策） |
たとえば「生産性向上」だけでは価値になりません。どの指標が、どの期間で、どの程度改善するのかまで定義されて初めて比較対象になります。根拠は過去実績だけでなく、体制・移行計画・現場データなどで補強できます。リスクは隠すのではなく先に示した方が、「判断材料が揃っている提案」として受け取られます。
この評価軸が曖昧なままだと、どれほど経営ストーリーを語っても、最後は価格と条件の比較に戻ります。良い提案書を作ることより先に、価格以外で比較される枠を固定すること。これが順序です。
3-4. 評価表テンプレ｜購買に渡せる比較軸の1枚
評価基準の大枠が決まったら、実際に購買・調達が比較に使える項目へ落とします。抽象語を並べると主観評価になり、最後はやはり価格へ戻ります。確認できる項目として設計することが必要です。
ベンダー選定チェック項目
項目 | 詳細 |
|---|---|
１．全体設計の能力 | 部門横断の対象範囲が明示されているか／依存関係の整理があるか |
２．移行・定着の設計 | 現場の運用変更・教育・権限・例外処理が設計されているか |
３．システム統合の現実性 | 前提条件（データ品質、連携方式、責任分界）が明記されているか |
４．KPIと分岐条件 | 成果指標と、Go/No-Goの条件が先に定義されているか |
５．ガバナンスと意思決定 | 誰がいつ何を決めるか（稟議・会議体・役割）が置かれているか |
これらの項目は、価格では代替できません。価格は「安い／高い」を示せますが、ここで見ているのは「設計されているか／されていないか」という差だからです。
次に、それを裏づける証拠の種類も先に揃えておきます。大手邦銀のグローバル業務担当部門への提案で、関連部門を集めた勉強会を複数回開き現場の合意を取り付けたにもかかわらず、臨時の承認会議で否決されたことがありました。現場担当者が作成した詳細なレポートが、幹部にそもそも読まれていなかったのです。
移行や定着の設計を「現場が丁寧に整理した資料」として出しても、幹部が判断できる粒度になっていなければ意味がない。これは移行設計の問題というより、誰向けに何を証拠として示すかの設計が抜けていた問題でした。
証拠の種類（根拠を補強する3要素）
項目 | 詳細 |
|---|---|
１．実績の証拠 | 同種の業務・同規模での導入経験、失敗事例と学び（成功談だけは弱い） |
２．体制の証拠 | 誰が責任を持ち、どの役割で伴走するか（人月の話ではなく“意思決定の支援体制”） |
３．移行の証拠 | 現行業務への影響、移行ステップ、データ・権限・運用の切替条件が書かれているか |
特に移行の証拠は重要です。移行設計が薄い提案は、導入後に高い確率でトラブルになり、購買側にとっては責任問題になります。逆に言えば、移行条件まで証拠として先に示せる提案は、価格だけでは比較しにくくなります。
最後に、これらを1枚の評価表として統合します。
提案比較表（購買に渡す1枚）
項目 | 詳細 |
|---|---|
１．価値（Value） | ■ 経営課題への接続（中計・重点テーマとの接続） |
２．根拠（Evidence） | ■ 実現計画の具体性（フェーズ、体制、前提条件） |
３．リスク（Risk） | ■ 失敗条件の明示（何が起きると止まるか） |
この1枚を先に作っておくと、評価は自然に価格以外へ移ります。比較するための材料が揃い、「価格だけで決める理由」が薄くなるからです。
さらに言えば、この1枚をRFPが出た後の採点表として使うのではなく、RFP化する前に顧客と合意できれば、比較軸そのものを主導できます。価格競争を回避する鍵は、提案内容を後から良く見せることではなく、比較される形式を先に変えることです。
まとめ｜「何を基準に比較するか」を先に設計することから始めてみてください
提案が丁寧に作られていても、最後に価格で決まってしまうのは、誰の努力が足りないからではありません。比較の土俵がそうなっていれば、そうなります。
提案書の出来を競う前に、「何を基準に比較するか」を先に設計しておく。経営課題への接続、成果指標の定義、時間軸の整合、移行条件、ガバナンス——こうした項目が比較基準として先に置かれていれば、RFPが出た後も、価格だけで決まりにくい状態を作れます。
次の提案案件で一度、RFPが出る前に評価表の骨格を1枚作って顧客と共有してみてください。比較軸を先に握ると、提案の会話は価格勝負から投資判断へ戻りやすくなります。まず1枚、そこから始めてみてください
【次に読むべきコラム】
👉️ PoCから本番に進まない理由｜事前に合意すべき分岐条件と判断設計
👉️ 「今年度の課題ではない」と言われる理由｜来期送りになる比較軸と見直し方
👉️ 提案が差別化できない本当の理由｜比較される前に「前提」を設計し直す手順
【参考】CaseScenario™なら
RFPやベンダー選定で価格比較へ流れるのは、提案が弱いからではありません。その前の段階で、「何を基準に比較するか」が設計されないまま案件が進んでいるからです。経営課題との接続、成果指標、時間軸、移行条件、ガバナンスといった論点が初期段階で整っていなければ、調達・購買は価格と条件で比べるしかなくなります。
CaseScenario™は、この前段を整えるための初期提案の設計図です。企業のIRや中期経営計画をもとに経営課題を体系化し、現場の業務課題と接続しながら、案件化・検討開始・承認前進に必要な判断材料を初期段階で揃えます。業務課題を経営課題に翻訳した上で、「誰に、何を、どの順番で、どの比較軸で伝えるか」を設計します。
提案書の見せ方を整えるためのサービスではありません。価格比較に入る前に、そもそも何を基準に比較すべきか、その評価軸から設計するための支援です。
