ベンダー選定が揉める現場の共通点
ベンダー選定の会議室。テーブルを囲む経営層、情報システム部、現場部門の担当者。各社から提出された提案書が山積みになっています。しかし、議論は平行線をたどります。「A社は価格が安い」「でもB社の方が実績がある」「C社の担当者は熱心だった」。誰もが自分の視点でベンダーを評価し、結論が出ない。こんな光景を、私はPMOとして10年以上見続けてきました。
ベンドー選定が揉めるプロジェクトには、驚くほど共通したパターンがあります。それは「何を基準に選ぶか」が曖昧なまま、ベンダーを呼んでしまうことです。評価軸が定まっていないのに、各社にプレゼンをさせ、見積もりを取る。当然、判断基準がないので、声の大きい人の意見や、印象論で選定が進んでいきます。
私が担当したあるプロジェクトでは、5社のベンダーが競合する選定プロセスになりました。最初の段階では「公平に選定する」という方針だったのですが、実際には各部門が「押しのベンダー」を持っており、選定会議のたびに対立が発生しました。情報システム部はセキュリティ重視でD社を推し、営業部門は使いやすさ重視でE社を支持し、経営層はコスト重視でF社に傾く。誰も悪気はないのですが、組織として一つの方向に進めないんですよね。
私はPMOとして10年以上、複数のベンダー選定プロジェクトに関わってきました。特に印象に残っているのは、ある中堅企業の基幹システム刷新で3社の競合になったケースです。1社目は価格が最も安く、経営層が傾いていました。2社目は実績豊富で高価格、現場担当者が推していました。3社目は中間でしたが提案内容が抜群でした。最終的に経営層が押し切る形で1社目に決定したのですが、開発フェーズに入ってから次々と仕様変更要求が発生し、結果的に2社目の見積もりを上回る追加費用が発生する事態に。『価格だけで選ぶリスク』を身をもって経験しました。選定基準を事前に透明化し、評価軸を経営層と現場で合意することの重要性を学んだ案件でした。現代ならRFP管理ツールやPoC実施プラットフォームで、もう少し合理的な判断ができるはずです。
このような状況は、決して珍しいものではありません。むしろ、ベンダー選定が順調に進むプロジェクトの方が少ないと感じています。なぜなら、ベンダー選定には「正解」がないからです。どのベンダーにも長所と短所があり、完璧な選択肢は存在しません。だからこそ、事前の準備と明確な基準が必要になります。
価格優先で選んだプロジェクトの末路
ベンダー選定で最も多い失敗パターンは「価格優先」です。見積もりを並べて、一番安いベンダーを選ぶ。シンプルで分かりやすい基準ですが、これが大きな問題を引き起こします。
私が関わったある案件では、3社のベンダーから見積もりを取得し、最も安価だったG社を選定しました。他社より30%も安く、経営層は大喜びでした。しかし、プロジェクトが始まると、すぐに問題が表面化しました。G社の提案には「要件定義支援」が含まれておらず、追加費用が発生する。カスタマイズの工数見積もりが甘く、当初予算の2倍に膨らむ。サポート体制が薄く、問い合わせへの回答に1週間かかる。
結局、プロジェクトは遅延し、追加費用も発生し、当初の「安い」という判断基準は完全に裏目に出ました。最終的な総費用は、2番目に高かったH社の見積もりを上回ってしまったのです。「安物買いの銭失い」という言葉が、これほど実感できた瞬間はありません。
価格優先の選定が失敗する理由は明確です。ベンダーは安い見積もりを出すために、何かを削っています。それは工数かもしれないし、品質かもしれないし、サポート体制かもしれません。見積もりに含まれていない作業が後から判明し、結局は高くつく。これが典型的なパターンです。
「顔の見える関係」と「契約上の関係」の温度差
ベンダー選定でもう一つ厄介なのが、営業担当者の印象と実際のサービス品質のギャップです。選定プロセスでは優秀な営業担当者が前面に出てきますが、契約後に実際にプロジェクトを担当するのは別の人材です。
私が経験したある案件では、I社の営業担当者が非常に優秀で、提案内容も素晴らしく、社内の評価も高かったため、I社に決定しました。しかし、契約後にアサインされたプロジェクトマネージャーは経験が浅く、コミュニケーションもうまく取れない人材でした。「あの熱心な営業の人はどこに行ったんですか」と尋ねると、「彼は営業専門で、実装には関与しません」との回答。顔の見える関係で信頼して選んだのに、契約上の関係では全く別の体制だったわけです。
この問題は、特にSaaS導入では顕著です。SaaS製品そのものは優れていても、導入支援やカスタマイズを担当するパートナー企業の能力にばらつきがあります。製品を作った会社と、導入を支援する会社が別であることも多く、「製品は良いが、サポートが悪い」というミスマッチが発生します。
RFPが機能しない本当の理由
ベンダー選定の基本は、RFP(提案依頼書)を作成し、各社に提案を求めることです。しかし、多くの現場でRFPが形骸化しています。なぜなら、RFPの内容が曖昧で、各社がバラバラの提案を出してくるからです。
「クラウドベースの販売管理システムを導入したい」というだけのRFPでは、各社の提案内容は大きく異なります。J社はフルカスタマイズ前提の提案、K社はパッケージそのままの提案、L社は既存システムとの連携を重視した提案。どれも間違ってはいないのですが、比較のしようがありません。りんごとみかんとバナナを並べて「どれが一番良いか」と言っているようなものです。
RFPが機能しない理由は、発注側が「何を求めているか」を明確にできていないことにあります。業務要件は書いてあるが、非機能要件(性能、セキュリティ、可用性など)が曖昧。優先順位が不明確で、「あれもこれも欲しい」という内容。予算や期間の制約が書かれていない。これでは、ベンダーも提案のしようがありません。
私が関わったプロジェクトでも、最初のRFPは「現状の業務フローを改善したい」という抽象的な内容でした。各社の提案はバラバラで、比較検討に膨大な時間がかかりました。結局、RFPを作り直し、要件を明確化してから再度提案を求めることになり、選定プロセスが3ヶ月遅れました。
評価軸が曖昧で意思決定できない組織
ベンダー選定で最も時間がかかるのは、実は提案を聞くことではなく、社内で意思決定することです。評価軸が曖昧だと、誰もが自分の視点で判断し、結論が出ません。
ある案件では、選定会議が5回行われましたが、毎回異なる評価軸で議論されました。1回目は価格、2回目は機能、3回目は実績、4回目はサポート体制、5回目は導入スケジュール。誰もが「自分の視点」でベンダーを評価するため、会議のたびに優先順位が変わります。最終的には、「もう時間がないから」という理由で決まりましたが、誰も納得していない選定結果でした。
評価軸が曖昧な組織には、共通した特徴があります。それは「意思決定の権限と責任が不明確」ということです。誰が最終的に決めるのか、誰が責任を取るのかが曖昧だと、誰もリスクを取りたがりません。だから、議論だけが続き、決断できないのです。
なぜベンダー選定は失敗するのか
ここまで現場のリアルな失敗例を見てきましたが、なぜベンダー選定は失敗するのでしょうか。根本的な原因を分析すると、いくつかの構造的な問題が見えてきます。
情報の非対称性という根本問題
ベンダー選定における最大の問題は、発注側とベンダー側の「情報の非対称性」です。ベンダーは自社の製品やサービスについて熟知していますが、発注側は詳細を知りません。この情報格差が、選定を難しくしています。
ベンダーの営業担当者は、自社の強みは強調しますが、弱みは積極的に説明しません。「当社のシステムは拡張性に優れています」と言いますが、「ただし、カスタマイズには多額の費用がかかります」とは言いません。発注側は表面的な情報だけで判断せざるを得ず、契約後に「聞いていない」という事態が発生します。
この情報の非対称性を埋めるには、発注側が積極的に情報を取りに行く必要があります。質問事項を事前に準備し、具体的な回答を求める。実績企業に直接話を聞く。可能であれば、実際のシステムを触らせてもらう。こうした地道な作業が、正しい選定につながります。
短期的視点と長期的視点のズレ
ベンダー選定では、短期的な視点(初期費用、導入期間)と長期的な視点(運用コスト、拡張性)のバランスが重要です。しかし、多くの組織は短期的視点に偏りがちです。
「今年度の予算内で導入したい」「できるだけ早く稼働させたい」という要求は理解できます。しかし、そのシステムは5年、10年と使い続けるものです。初期費用が安くても、ランニングコストが高ければ、長期的には損をします。導入が早くても、拡張性がなければ、将来的に作り直すことになります。
私が経験した案件でも、「初期費用ゼロ」を謳うSaaS製品を選定したことがありました。しかし、月額料金が高く、ユーザー数が増えるとコストが跳ね上がる料金体系でした。3年後には、初期費用がかかっても月額料金が安い別の製品の方が、総コストが低かったことが判明しました。短期的な判断が、長期的な損失を招いた典型例です。
組織内の利害対立
ベンダー選定が揉める背景には、組織内の利害対立があります。各部門が異なる目的を持っており、それぞれの視点でベンダーを評価するからです。
情報システム部は「技術的に優れたシステム」を求めます。セキュリティが堅牢で、拡張性があり、最新の技術を使ったシステム。一方、現場部門は「使いやすいシステム」を求めます。複雑な設定は不要で、直感的に操作できるシステム。経営層は「コストパフォーマンスの高いシステム」を求めます。安くて、早くて、効果が見えるシステム。
これらの要求は、しばしば矛盾します。技術的に優れたシステムは複雑で、使いにくい。使いやすいシステムはシンプルで、拡張性が低い。コストパフォーマンスの高いシステムは機能が限定的で、将来的な拡張が難しい。どこかで妥協が必要ですが、それを誰が決めるのかが曖昧だと、議論は平行線をたどります。
過去の失敗体験によるバイアス
ベンダー選定には、過去の失敗体験が影を落とします。「以前M社で失敗したから、M社は選ばない」「N社のシステムはトラブルが多かった」といった記憶が、客観的な評価を妨げます。
過去の失敗から学ぶことは重要ですが、それが極端なバイアスになってはいけません。当時のM社の体制と現在の体制は異なるかもしれません。N社のシステムのトラブルは、実は自社の運用体制に問題があったのかもしれません。過去の失敗を引きずると、新しい選択肢を公平に評価できなくなります。
私自身も、過去に失敗したベンダーを避けたいという気持ちは理解できます。しかし、PMOとしての経験から言えるのは、「ベンダーよりもプロジェクトのやり方が重要」ということです。同じベンダーでも、プロジェクトの進め方次第で成功も失敗もします。過去の失敗を個別の事象として分析し、構造的な問題なのか、偶発的な問題なのかを見極めることが大切です。
失敗しないベンダー選定の5つの鉄則
ここからは、私が10年以上の現場経験から学んだ、失敗しないベンダー選定の具体的な方法を紹介します。これは理想論ではなく、実際のプロジェクトで効果があった実践的な手法です。
鉄則1:選定基準を事前に明文化し合意する
ベンダー選定で最も重要なのは、評価基準を事前に明文化し、関係者全員で合意することです。これをせずにベンダーを呼んでも、後から「やっぱりこの基準も重要だ」という話になり、議論が混乱します。
評価基準は、大きく分けて「絶対条件」と「評価項目」に分けるとよいでしょう。絶対条件は、これを満たさないベンダーは選定対象外とする基準です。例えば、「ISO27001認証を取得していること」「日本国内にサポート拠点があること」「過去3年以内に同業種での導入実績があること」などです。
評価項目は、点数化して比較する基準です。機能、価格、実績、サポート体制、導入スケジュールなど、複数の項目を設定し、それぞれに重み付けをします。重要なのは、重み付けを事前に決めておくことです。後から「やっぱり価格より機能が重要」と言い出すと、評価が変わってしまいます。
私が関わったある案件では、評価シートをExcelで作成し、各評価項目に10点満点で点数をつけました。機能30%、価格20%、実績20%、サポート体制15%、導入スケジュール15%という重み付けで、合計点を算出しました。この方法だと、主観的な印象だけでなく、客観的な数値で比較できます。もちろん、点数のつけ方には主観が入りますが、少なくとも評価軸は明確になります。
鉄則2:RFPには非機能要件を必ず含める
RFP(提案依頼書)を作成する際、多くの企業が「何ができるか」という機能要件に注目しますが、実は「どう動くか」という非機能要件の方が重要です。非機能要件とは、性能、可用性、セキュリティ、保守性、拡張性などの品質に関する要求のことです。
例えば、「販売実績を検索できる」という機能要件だけでは不十分です。「100万件のデータから3秒以内に検索結果を表示できる」という性能要件が必要です。「システムダウン時に1時間以内に復旧できる」という可用性要件も重要です。「個人情報は暗号化して保存する」というセキュリティ要件も欠かせません。
非機能要件を明確にすると、ベンダー側も具体的な提案ができます。逆に、非機能要件が曖昧だと、ベンダーは最低限の仕様で見積もりを出します。そして、後から「こんなに遅いとは思わなかった」「こんなに止まるとは思わなかった」という問題が発生します。
私は、RFPのテンプレートに非機能要件のチェックリストを必ず入れるようにしています。性能、可用性、セキュリティ、保守性、拡張性、移行性、運用性の7項目について、それぞれ具体的な数値目標を記載します。これにより、各社の提案を同じ土俵で比較できるようになります。
鉄則3:PoCで実際の動作を確認する
PoC(Proof of Concept)とは、本格導入の前に小規模で実際にシステムを試してみることです。デモや説明だけでは分からない部分を、実際に使って確認します。これは、特にSaaS製品の選定では非常に有効です。
PoCでは、実際の業務データを使って、実際の業務フローを再現します。ベンダーが用意したサンプルデータではなく、自社のリアルなデータです。これにより、「デモでは良さそうに見えたが、実際に使うと使いにくい」という問題を早期に発見できます。
私が経験したある案件では、3社のSaaS製品をそれぞれ2週間ずつPoCしました。各社とも、実際のユーザー5名に使ってもらい、フィードバックを収集しました。結果、デモでは最も印象が良かったO社の製品が、実際には操作が複雑で評価が低く、デモでは地味だったP社の製品が、実際には直感的で評価が高いことが分かりました。PoCをしなければ、間違った選定をしていたでしょう。
PoCを実施する際は、評価項目を事前に決めておくことが重要です。「使いやすい」という漠然とした評価ではなく、「この業務がこの手順で完了できるか」という具体的な評価項目を設定します。また、PoCの期間は最低でも1週間、できれば2週間は確保したいところです。短すぎると、表面的な評価しかできません。
鉄則4:導入実績企業に直接話を聞く
ベンダーの提案書には、必ず導入実績が記載されています。しかし、その実績が本当に成功事例なのかは、ベンダーに聞いても分かりません。そこで、導入実績企業に直接話を聞くことをお勧めします。
多くのベンダーは、顧客の了解を得た上で、参考情報として連絡先を紹介してくれます。紹介してもらったら、電話やオンライン会議で、実際の使用感や苦労した点を聞きます。特に重要なのは、「どこで苦労したか」「今でも困っていることは何か」という質問です。成功事例だけでなく、課題も含めて聞くことで、リアルな情報が得られます。
私がある案件で導入実績企業に話を聞いたところ、ベンダーの提案書には書かれていない重要な情報を得ました。「導入時にデータ移行で半年遅れた」「カスタマイズの見積もりが当初の3倍になった」「サポート窓口の対応が遅い」といったネガティブな情報です。これらは、ベンダーが積極的に説明しない部分ですが、選定の重要な判断材料になります。
導入実績企業に話を聞く際は、同業種、同規模の企業を選ぶことが重要です。業種や規模が違うと、課題も異なるため、参考にならない場合があります。また、導入からある程度時間が経過した企業(1年以上)を選ぶと、初期のトラブルだけでなく、運用フェーズでの課題も聞けます。
鉄則5:契約書で曖昧な部分を残さない
ベンダー選定の最終段階は契約ですが、ここで手を抜くと後で大きな問題になります。特に、作業範囲、成果物、責任分界点を明確にすることが重要です。
作業範囲とは、「ベンダーが何をするか」を明確にすることです。例えば、「要件定義」という言葉だけでは不十分で、「要件定義書の作成」なのか「要件定義のファシリテーション」なのかを明記します。「データ移行」も、「移行ツールの提供」なのか「実際の移行作業」なのかを明確にします。
成果物とは、「何が納品されるか」を明確にすることです。設計書、テスト仕様書、マニュアルなど、具体的な成果物をリストアップし、それぞれのフォーマットや内容を定義します。「適切な設計書」という曖昧な表現では、後で「これは設計書ではない」という争いになります。
責任分界点とは、「どこからどこまでがベンダーの責任か」を明確にすることです。例えば、システムトラブルが発生した場合、ベンダーの責任なのか、自社の運用ミスなのか、外部要因なのかを判断する基準を決めておきます。クラウドサービスの場合、「クラウド基盤の障害はベンダーの責任外」といった条項が含まれることが多いので、注意が必要です。
私が担当したあるプロジェクトでは、契約書のレビューに1ヶ月かけました。法務部門も巻き込んで、一文一文を精査し、曖昧な表現を排除しました。これは時間がかかる作業ですが、後で「聞いていない」「契約に含まれていない」というトラブルを防ぐためには必須の作業です。
現代のベンダー選定を支援するツールとサービス
ベンダー選定のプロセスは複雑で、多くの情報を整理する必要があります。ここでは、選定プロセスを効率化し、質を高めるための具体的なツールやサービスを紹介します。これらは、私が実際のプロジェクトで使用し、効果を実感したものです。
RFP管理ツール:Nintex RFP
RFP(提案依頼書)の作成から回答の管理、評価までを一元管理できるツールです。テンプレートが豊富で、業種や目的に応じたRFPを短時間で作成できます。各ベンダーからの回答を一覧表示し、比較検討が容易になります。
このツールの便利な点は、評価プロセスの透明性が確保できることです。評価者ごとに点数をつけ、その平均や標準偏差を自動計算します。誰がどう評価したかが可視化されるため、「声の大きい人の意見」に流されにくくなります。
一方で、使いこなしの難しさもあります。初期設定が複雑で、評価項目や重み付けを細かく設定する必要があります。また、ベンダー側もこのツール上で回答を入力する必要があるため、ツールに不慣れなベンダーだと回答の質が下がる可能性があります。中小企業のベンダーは、こうしたツールに対応していないこともあるので、注意が必要です。
導入後の現実的なステップとしては、まず社内の評価基準を整理し、それをツールに落とし込む作業が必要です。これには、情報システム部門だけでなく、各事業部門も巻き込んで、1〜2ヶ月かけて評価項目を定義します。その後、実際のRFPプロセスでツールを使いながら、評価項目を微調整していくというアプローチが現実的です。
ベンダー比較サイト:ITreview、Capterra
実際のユーザーレビューを集めたベンダー比較サイトです。ITreviewは日本のサイトで、日本企業のレビューが豊富です。Capterraは海外のサイトで、グローバル製品のレビューが充実しています。
これらのサイトの便利な点は、ベンダーの公式情報だけでなく、実際のユーザーの声が聞けることです。「導入して良かった点」だけでなく、「困った点」「改善してほしい点」も率直に書かれています。特に、同業種や同規模の企業のレビューを見ると、自社での導入イメージが湧きやすくなります。
しかし、レビューサイトの情報を鵜呑みにするのは危険です。レビューを書く人は、極端に満足している人か、極端に不満がある人に偏りがちです。普通に使えている人は、わざわざレビューを書きません。また、ベンダーが自社の社員や関係者にレビューを書かせている場合もあります。レビューの内容だけでなく、レビュアーのプロフィールや他のレビュー内容も確認し、信頼性を判断する必要があります。
私は、レビューサイトを「参考情報の一つ」として使っています。レビューで気になった点は、ベンダーに直接質問し、確認します。「レビューで○○という指摘がありますが、現在はどうなっていますか」と聞くと、ベンダーも誠実に答えてくれることが多いです。
PoCプラットフォーム:各ベンダーの無料トライアル
多くのSaaS製品は、14日間や30日間の無料トライアルを提供しています。これを活用すれば、本格的なPoCを低コストで実施できます。複数のベンダーのトライアルを同時期に申し込み、並行してテストすることで、効率的に比較できます。
無料トライアルの便利な点は、実際の製品を制約なく試せることです。デモでは見せてくれない部分や、実際の業務フローでの使い勝手を確認できます。また、複数のユーザーに試してもらうことで、様々な視点からの評価が得られます。
ただし、無料トライアルには限界もあります。トライアル版は機能が制限されていることがあり、本番環境とは異なる場合があります。また、トライアル期間が短いため、じっくり評価する時間がありません。さらに、自社のデータを使ったテストができない場合もあります。
無料トライアルを有効活用するには、事前に評価項目と評価者を決めておくことが重要です。「とりあえず触ってみる」だけでは、表面的な評価しかできません。「この業務フローが実現できるか」「このデータ量で動作するか」といった具体的な評価項目を設定し、計画的にテストします。私は、トライアル開始前に1週間の評価計画を立て、日ごとにテストする内容を決めています。
契約書レビューサービス:LegalForce、GVA assist
契約書の内容を自動でチェックし、リスクのある条項を指摘してくれるAIサービスです。LegalForceは大企業向け、GVA assistは中小企業向けのサービスです。
これらのサービスの便利な点は、契約書の専門知識がなくても、リスクのある条項を発見できることです。例えば、「ベンダーの責任が限定されすぎている」「解約条件が不利」「損害賠償の上限が低すぎる」といった問題点を自動で指摘してくれます。
しかし、AIのチェックだけでは不十分です。これらのサービスは一般的なリスクは指摘してくれますが、業界特有のリスクや自社特有の事情は考慮してくれません。最終的には、法務部門や弁護士のレビューが必要です。また、AIが指摘した全てのリスクを排除しようとすると、ベンダー側が契約を拒否する可能性もあります。どこまでリスクを許容するかは、ビジネス判断が必要です。
私は、まずAIサービスでリスクを洗い出し、その中で重要度の高いものを法務部門に確認してもらうという使い方をしています。全ての条項を法務部門に確認すると時間がかかりますが、AIが指摘した条項に絞れば、効率的にレビューできます。
ベンダー選定は「始まり」であって「終わり」ではない
ここまで、ベンダー選定の失敗パターンと、それを避けるための具体的な方法を紹介してきました。しかし、最後に強調したいのは、「ベンダー選定は始まりであって終わりではない」ということです。
どれだけ慎重に選定しても、プロジェクトが順調に進むとは限りません。選定したベンダーとの関係構築、プロジェクトマネジメント、変更管理、品質管理など、やるべきことは山積みです。選定に時間をかけすぎて、その後のプロジェクト推進が疎かになっては本末転倒です。
私の経験から言えるのは、「完璧なベンダー選定」は存在しないということです。どのベンダーにも長所と短所があり、プロジェクトの途中で予期しない問題が発生します。重要なのは、問題が発生したときに、ベンダーと協力して解決できる関係を築くことです。
選定プロセスで透明性を確保し、評価基準を明確にすることは、単に「良いベンダーを選ぶ」ためだけではありません。それは、選定後に「なぜこのベンダーを選んだのか」を説明し、関係者の納得を得るためでもあります。納得感のある選定プロセスを経ることで、プロジェクトが困難に直面したときにも、組織として支援する体制が作れます。
ベンダー選定は、ゴールではなくスタートです。選定後のプロジェクトを成功させるための土台作りだと考えてください。そして、選定で得た教訓を、次の選定に活かしてください。失敗から学び、継続的に改善していくこと。それが、組織のベンダー選定能力を高める唯一の方法です。
私自身、10年以上ベンダー選定に関わってきましたが、今でも新しい学びがあります。技術は進化し、ビジネス環境は変化し、ベンダーの状況も変わります。常に学び続け、柔軟に対応していくこと。それが、PMOとしての私の姿勢であり、この記事を読んでくださったあなたにも持ってほしい姿勢です。
コメント