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

2025/07/01

 提案書の「もっともらしさ」に惑わされる企業が後を絶たない

基幹システムの刷新を検討する際、多くの企業が「どう提案書を見極めるか」に頭を悩ませます。
ベンダー各社から提出される提案書には、それぞれ異なる構成や内容が並び、特に“具体的な記述”が多い提案ほど、信頼できそうに見えるものです。

たとえば「◯◯機能はこう実装します」「△△業務はこう整理できます」といった記載を見ると、「この会社はよく考えている」と感じてしまうのは、ごく自然な心理です。しかし、その“もっともらしい具体性”が、どこまで依頼側の実態や課題を正確に踏まえたものかまで、冷静に検証されているケースは、実は多くありません。

むしろ、その具体性が、情報不足や理解不足の中で作られた“表面的なもっともらしさ”であることに気づかず、結果としてプロジェクトの入り口で重大な誤判断をしてしまう例が後を絶ちません。

当社が知る実際のケースでも、こうした“見た目の具体性”に惑わされた結果、発注先の選定時点で既に“失敗の種”を埋め込まれ、最終的には大きな損失を被った企業が存在します。
このコラムでは、こうした事態を避けるために、提案書の見方、基幹システム刷新の本質、そして依頼側が持つべき視点について掘り下げていきます。

 誤判断①：「具体的な提案」が必ずしも“適切”とは限らない

基幹システム刷新の提案段階では、当然ながら情報には限りがあります。
依頼側企業が、現状の業務フローやシステム仕様、暗黙知までを細かく開示することは困難であり、ベンダー側も限られた時間と情報の中で提案書を作成することになります。

この状況下で“具体性”を求めすぎると、ベンダーは推測や一般論をベースに、もっともらしい話を作り上げざるを得なくなります。
例えば、業務構造や運用現場の実態を十分に知らずに「こう改善できます」「この機能が必要です」といった具体的な提案をする場合、その内容は“見た目は整っているが、中身が空疎”という危うさをはらみます。

一方で、慎重なベンダーほど、「現時点での具体的な機能仕様は決めきれない」「構想や業務理解を経て最適解を導きたい」といった、やや抽象的で地に足のついたスタンスを示します。

ところが、依頼側が“具体性”にばかり目を奪われると、こうした慎重な提案が「曖昧」「頼りない」と映り、逆に無理に作り込まれた具体的な提案が「信頼できる」と誤解されてしまうのです。

結果として、もっとも見た目が良い提案が選ばれ、実態に合わない設計がスタートし、後戻りのできない失敗に繋がるケースが後を絶ちません。

 誤判断②：「早く形を決めたい」が刷新の足かせになる

システム刷新は往々にして、現場の不満や経営層の焦りを背景に始まることが多いものです。
「使い勝手が悪い」「機能が古い」「早く新しい仕組みに移行したい」といった声が社内に渦巻き、プロジェクトを早期に“具体化”し、“結論”を出すことが求められます。

その結果、「具体的な提案書」を早く受け取り、即座に判断したいという心理が働きます。
しかし、ここで焦ってはいけません。

基幹システム刷新は、単なる技術的な入れ替えではなく、企業の業務そのものを根本から見直す大規模な取り組みです。
特に、現場には文書化されていない手順や、長年の慣習、経験に基づく判断、いわゆる“暗黙知”が数多く存在します。

これらを丁寧にすくい上げ、構造化し、再定義するプロセスは、どうしても時間がかかります。
この工程を省略し、見た目の具体性だけを頼りに刷新を急げば、将来の柔軟性や拡張性を犠牲にした“場当たり的なシステム”ができあがってしまいます。

また、システム刷新に伴う業務の変更や人の意識改革も、短期で進むものではありません。
これらを軽視すると、せっかく新しいシステムを導入しても現場が使いこなせず、結局は旧態依然とした運用が残る、といった事態を招きます。

 誤判断③：システムの「構造」を軽視すると失敗する

加えて、システムの“構造設計”そのものを軽視することも大きなリスクです。

昨今、将来的な機能追加や外部サービスとの連携を前提に、システムの柔軟性や拡張性を高める設計が不可欠とされています。
たとえばマイクロサービス化といった構成に移行する場合も、単なるプログラム改修では済みません。

「どの業務や機能を、どのように分割し、どう連携させるか」といった構想を丁寧に練り上げることが不可欠です。
これを省略すると、システムが複雑化し、将来の改修や連携に制約が生じ、結果的に再び“刷新のやり直し”に追い込まれる可能性すらあります。

刷新を「機能の寄せ集め」ではなく、業務構造とシステム構造を一体で設計する取り組みと捉えることが、将来を見据えた正しいアプローチと言えるでしょう。

 実際に起きた「見誤り」の代償──特別損失という現実

見た目の“具体性”に惑わされた結果、発注時点で既に失敗の種を抱え込んでしまった企業の例は、決して他人事ではありません。

当社が知るケースでも、基幹システムやECサイトのソフトウェア開発において、十分な業務理解や構想を経ないまま、もっともらしい提案書を鵜呑みにしてしまいました。

その結果、プロジェクト途中で根本的な設計不備が発覚し、システムの利用可能性や収益見通しが立たず、以下のような多額の損失が現実のものとなりました。

・基幹業務系システム刷新：125百万円の特別損失

・ECサイト構築：60百万円の特別損失

これは単なる開発途中の失敗ではありません。
発注先選定という“入り口”での誤判断が、最終的に数億円規模の損失に直結したという、極めて重い事実です。

この背景には、もっともらしい“具体性”に目を奪われ、本来時間をかけて詰めるべき業務理解や構造設計、柔軟性確保の議論が置き去りにされたプロセス上の問題がありました。

まとめ：見るべきは「裏付け」と「アプローチ」

基幹システム刷新において、見た目の具体性に惑わされないことはもちろんですが、以下の視点を持つことが欠かせません。

・その提案の“具体性”に、どこまで裏付けがあるのか
・業務構造とシステム構造を、どう捉え、どう対応させようとしているのか
・構想フェーズや業務理解を、提案する側がどこまで重視しているのか

慎重なスタンスや抽象度の高い提案は、決して“頼りない”わけではありません。
むしろ、企業の実態を正しく理解し、地に足のついた構想を進めるための“誠実さ”とも言えます。

基幹システム刷新は、目先のもっともらしさやスピード感よりも、将来を見据えた構想力と冷静な判断軸が成功の鍵です。
提案書を見るときこそ、裏付けとアプローチに目を向け、企業を守る視点を持つことが、結果として最大のリスク回避策になるのです。

 

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

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

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

関連記事