「なぜそのベンダを選んだのですか？」──システム開発失敗の7割はその瞬間に決まる

2025/07/14

はじめに──システム開発の7割は失敗している

「システム開発は難しい」──この言葉は単なる印象論ではありません。国内外のさまざまな統計データにおいて、システム開発プロジェクトの成功率はせいぜい3割程度。つまり、実に7割が失敗または頓挫に終わっているという現実があります。

参考コラム「システム開発の成功率3割についてビル建設と比較してみる」

しかも、その失敗の要因としてよく挙げられるのは「ベンダ選びを誤った」「要件定義が曖昧だった」「ベンダとコミュニケーションが取れなかった」といったものです。技術力不足や開発スキルの問題は意外にも少数派です。これは何を意味するのでしょうか？

失敗後のお客様に必ず尋ねる質問

私たちは、システム開発がうまくいかず「やり直したい」「ベンダを変えたい」というご相談をいただく機会が多くあります。その際、必ずお聞きする質問があります。

「そもそも、なぜそのベンダを選ばれたのですか？」

驚くほど多くの方が、同じ答えを返してこられます。それは——

「提案が一番具体的で分かりやすかったから」です。

相見積もりを取り、比較した結果、説明が一番しっくりきた会社を選んだ。そんな選び方が、実は失敗への入り口となっているケースが非常に多いのです。

なぜ「分かりやすさ」が危ないのか？

プリセールス、つまり開発前の提案段階では、ベンダはお客様の事業や業務プロセス、細かな課題まで完全に理解しているわけではありません。限られたヒアリングや既存資料だけをもとに、提案書や画面イメージ、機能案を作成しています。

しかしこの時点で「具体的で分かりやすい提案」を作ろうとすればするほど、ベンダ側は自社のこれまでの経験やテンプレートを流用し、“思い込み”で提案をまとめるしかないのが実情です。

お客様側も、その提案を見た時点では「なるほど、これならわかりやすい」と感じるでしょう。しかし、その裏側にある技術選定や業務フローの適合性、セキュリティ要件、保守運用体制など、重要な観点はどうでしょうか？ほとんどの場合、そこまで深掘りせずに判断されているのが実態です。

また、システム開発は非常に複雑な領域です。提案内容の一部が具体的だったとしても、それが全体の完成度を担保するわけではありません。たとえば、画面イメージや操作フローが魅力的に見えても、データベース設計や内部ロジック、パフォーマンス設計など、一般的にお客様が目にしない部分の品質が低ければ、最終的には使い物にならないシステムとなってしまいます。

参考コラム「その提案、裏付けはありますか？──基幹システム刷新で陥りがちな誤判断」

主導権を手放した瞬間──要件定義をベンダ任せにすると？

システム開発の成否は、要件定義フェーズでほぼ決まると言われています。その要件定義を「分かりやすかったから」と選んだベンダに丸投げしてしまう。これが失敗する最大のパターンです。

本来、要件定義とはお客様自身が自社の事業課題や目指す姿を整理し、そのうえでシステム要件として具体化していく作業です。しかし、多くのお客様が「分かりやすかったから」とベンダ主導で進めてしまい、自社の本当のニーズや業務プロセスが置き去りになってしまいます。

さらに悪いケースでは、ベンダの得意技術だけでシステムが組まれてしまうこともあります。たとえば、マイクロソフト技術しか持たないベンダが提案する場合、本当は別の技術の方が適切でも、その選択肢が提示されないという問題が起きるのです。

要件定義は単なる仕様の洗い出しではなく、ビジネス全体を俯瞰し、業務の無駄を見つけ、どこまでをシステム化し、どこを人手で補うかといった根本的な方針決めも含まれます。これを他人任せにしてしまえば、たとえ立派なシステムが完成したとしても、期待通りの成果を出せない、むしろ混乱を招くことさえあります。

当社が実際に関わったケース

私たちが支援したある企業でも、まさに「提案が一番具体的で分かりやすかった」という理由でベンダを決めかけていたケースがありました。

しかし私たちはその提案書を細かく分析し、裏側のリスクや抜け漏れを整理してお伝えしました。例えば、

  • 技術選定が古く将来的な拡張性に難がある

  • セキュリティ要件が甘く、法令違反リスクがある

  • 業務フローが現状とズレている部分がある

  • 開発体制が脆弱で、プロジェクト途中のリソース不足が懸念される

  • ベンダ内の技術的偏りによる将来的なロックインリスク

といった具体的な問題点です。その結果、お客様は「具体的で分かりやすい」という表面的な評価をいったん脇に置き、慎重にベンダを選び直しました。

結果として、そのシステム開発は無事に完了し、事業への定着もスムーズに進みました。また、開発途中でも主体的に進捗確認や仕様見直しを行う文化が生まれ、単なるベンダ依存からの脱却につながった事例です。

まとめ──“選び方”を変えるだけで結果は変わる

システム開発の成功確率は、ベンダ選定の瞬間に大きく左右されます。これは決して大げさな話ではなく、私たちが日々現場で感じているリアルな実感です。

「提案が一番具体的で分かりやすかったから」——この評価軸は、発注者が主導権を手放す瞬間です。そうならないためには、お客様自身が主体的に要件を整理し、自社にとって本当に必要なシステム像を描く必要があります。

そのためには、RFP作成や第三者のアドバイザーを活用することも有効です。具体的には以下のような取り組みが推奨されます。

  • 自社内でシステム担当責任者やプロジェクトチームを設置する

  • RFP（提案依頼書）を丁寧に作り込み、ベンダ任せにしない

  • 提案内容の裏付けや技術的妥当性を第三者にチェックしてもらう

  • 初期費用や開発費用だけでなく、運用・保守・追加開発コストも含めた総コストで比較する

システム開発に失敗しないために、まずは“選び方”を見直すところから始めてみてはいかがでしょうか。単なる見積書比較ではなく、もっと本質的な視点でベンダを選ぶこと。それが成功の第一歩です。
こちらのレポート「基幹システム再構築の成功法則大全」も是非ご参考に！

この記事を書いた人について

谷尾 薫
谷尾 薫
オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。

関連記事