最安値でも失注した理由と、提案で変えた4つのこと

プリセールスとして初めて最初から最後まで担当した案件が、失注しました。1ヶ月で提案書・見積・動くデモまで作り、競合各社のなかで最も安い金額を出し、2回目の提案では顧客からも良い反応をもらっていました。それでも選ばれませんでした。顧客が敗因を丁寧に言語化してくれたので、記録として残します。

---

案件の概要と1ヶ月の流れ

ある企業からの引き合いで、社内に分散していた管理業務を一つの Web ポータルへ統合する構築案件でした。用途ごとに別のツールを使い分けねばならず、状況を把握するまでに手間がかかる、という課題を解決するプロジェクトです。

前提はこうでした。

• 期限: 社外に向けたお披露目の期日が先に決まっていた
• 予算: 上限が明確に示されていた
• 競合: 競合各社との比較

顧客側の状況も押さえておきます。引き合いが来た時点で、顧客はすでに自分たちで動くモックを作っていました。AI 駆動開発で PoC まで実施済みで、商談に参加していた技術部門の方はクラウド側のマネージドサービスを検証した経験もありました。一方で、対象領域を自社で構築するのは同社にとって初めてでした。この非対称が、あとで敗因の中心になります。

初回提案までの流れは次のとおりです。

担当を引き継いだ直後だったため、1回目は提案とヒアリングを同時にやる形にしました。

1ヶ月で出したアウトプットは、ヒアリングリスト、提案書、機能別に工数を積み上げた見積根拠（3パターン）、提案スライド2回分、Next.js で作った動くデモ、クラウド利用料の試算（2環境）です。デモは、監視対象の状況をダッシュボードで一元表示し、異常を検知した項目をアラートとして出して担当者が対応する、という画面まで作りました。

1週間で提案を全面再構成した

1回目の提案の場で、顧客から3つの要望が出ました。

1. 当初スコープ外としていた機能を初期リリースに含めたい（相応の追加費用が発生する規模）
2. ただし予算の上限は維持したい
3. テストは多少の積み残しがあってもよい

同じタイミングで社内からも指摘が入りました。PM 責任者から「当初の期間に対して PM の工数が足りず進行が難しい」というものです。機能追加の要望と予算据え置きの希望、そこに社内の体制指摘が重なり、見積の部分修正では収まらないと判断しました。

上長との作戦会議で決めた打ち手は次の3つです。

• 要件定義フェーズを廃止してモック固定方式にする: 顧客が作っていたモックをベースに「この内容で作る」を先に確定させ、要件定義の工数を圧縮する
• テストの範囲をお披露目に必要な水準に合わせる: 顧客が積み残しを許容する意向だったため
• 開発期間を当初計画から数ヶ月圧縮し、PM の関与密度を上げる

結果、初回提案の金額からさらに下げて、その1週間後に2回目の提案を行いました。機能を増やしたうえで減額しています。

2回目の反応は良好でした。減額とスコープ拡充を歓迎してもらい、「前回から1週間でこの精度の提案」という評価もありました。この時点で他社の見積はまだ出ておらず、当社の内容が比較の基準になるだろうというコメントももらっています。後日回答をもらう約束をして、正直かなり手応えがありました。

そして約2週間後、他社に発注するという連絡を受けました。

顧客が語った4つの敗因

失注の連絡をもらったあと、なぜ選ばれなかったのかを顧客に聞きました。返ってきたのは次の4点です。

対象領域の実績を提案資料に載せていなかった

顧客が選定で最も重視していたのは、その領域の実績と経験値でした。自社で構築するのが初めてで、失敗するリスクを避けたいというのが第一だったためです。

グループ内には同じ領域を担当するセクションがあり、構築実績もありました。それを提案資料に載せていませんでした。2回目の提案の場で「この領域の事例はあるか」と聞かれ、その場で cloudpack の事例ページを投影して対応する形になっていました。

AI 駆動開発の速さと安さに寄せすぎた

当社側の訴求は、AI 駆動開発で速く安く作れるという点に寄っていました。対象をどう連携させるか、データをどう収集するか、運用フェーズの更新をどう回すかといったドメイン課題への踏み込みが薄く、早い段階で能動的に課題解決を提案するところまで行けていませんでした。

予算内に収めなければという意識が先行して、顧客が本当に解決したい課題と、恐れているリスクを理解しきれていませんでした。

技術の質疑にエンジニアを同席させなかった

選定された会社はエンジニアが同席していて、自身の経験に基づいて「こう解決できる」と自分の言葉で具体的に答えていたそうです。他の候補は一般論の回答で具体性に欠けた、とも聞きました。顧客側にも技術者がいたため、技術者同士の会話の質が意思決定を左右した形です。

インフラと Web アプリケーションの開発経験はあっても、この領域では経験が浅く、ドキュメントで裏を取って「この構成なら要件を満たせるはず」と話す程度にとどまっていました。デモは作れました。ただ、作れることと、実装をその場で語れることは別でした。

開発体制の柔軟性を提案書に書いていなかった

案件開始後の人月単価の調整やメンバー入れ替えに対応できる点が、選定された会社の強みとして挙がっていました。当社でも対応できる話でしたが、提案書に書いていませんでした。

価格では負けていなかった

金額面の評価は、はっきり言葉でもらっています。競合各社のなかで当社が最も安く、早い段階から競争力のある提示をしたことに感謝している、苦慮した決定だった、という内容でした。

最安値で、好感触で、それでも負けました。

ここから引き出した学びは2つです。ひとつは、持っている武器は聞かれる前に出すということ。実績はありました。載せていなかっただけです。顧客が最重視する軸で、自分から土俵を降りていました。

実際、2回目の提案の直前に、提案資料を社内レビュー観点でチェックするスキルにかけていて、そこで「AWS 実績と KDDI グループの押し出しが弱い」「実績のスライドを1枚足せ」と指摘を受けていました。それでも行けるだろうという根拠のない自信で、その指摘を反映せずに提案の場へ出しました。

もうひとつは、値引きは選定軸を外すと効かないということです。予算の上限を下回るところまで下げた判断自体は間違っていなかったと考えています。最安かつ高評価という結果は出ています。それでも顧客の選定軸は価格ではなくリスク回避でした。初めての領域に挑む顧客が買いたいのは、安さより「失敗しない確からしさ」だったわけです。

翌日から変えた4つのこと

上の4つの敗因に対して、提案プロセス側で手を打ちました。

実績スライドを提案テンプレの標準構成に入れる

ドメイン特化の実績スライドを、提案資料を生成するスキル側に組み込みました。毎回思い出して足すのではなく、テンプレの一部にしています。

商談前に顧客の選定軸を言語化する

顧客が何を求めていて、何を怖がっているのかを、商談の前に必ず言葉にして確認するようにしました。今回の案件でも、初回の場で聞けたはずのことでした。

顧客側の参加者を見てこちらの体制を決める

顧客側に技術者が入る商談では、こちらもエンジニアを同席させます。顧客側に技術者がいない場合でも、その技術に明るい人が入っていることはあるため、自分が詳しくない領域なら詳しいエンジニアを連れて行く方針にしました。

社内レビューの指摘を反映しきってから出す

社内レビューでもらった指摘を100%反映した状態にしてから提案の場に出します。今回はここで落としました。

資産として残ったもの

失注しても手元に残ったものがあります。今回作ったデモ一式は、同種の案件のテンプレートとして再利用できます。見積根拠も、機能別に工数を積み上げた形が残ったので、次の案件で組み替えて使えます。

敗因と申し送りは、各種 SaaS に記録しました。次に同じ負け方をしないための型に落としています。

まとめ

はじめての提案でやれたことは、1ヶ月で提案書・見積・スライド・動くデモまで到達したこと、顧客要望を受けて1週間で全面再構成したこと、最安値かつ好感触の提案を出せたことでした。

はじめての失注で分かったのは、提案の質と選定の軸は別物だったということです。良い提案書を作ることと選ばれることは同じではありませんでした。顧客が何を怖がっているかを掴めておらず、速さと安さは信頼の代わりにはなりませんでした。

固定予算・短納期で MVP を立ち上げる進め方はAIDD MVPとして提供しています。提案プロセスそのものも、こうした振り返りを社内で継続的に反映しながら改善しています。AI 駆動開発での新規開発や内製化の進め方について、お気軽にご相談ください。