システム導入が失敗する本当の理由——「ベンダー任せ」の構造を知る

システム導入プロジェクトの失敗——予算超過、稼働延期、使われないシステム——は、珍しい事故ではありません。そして長くSIer業界で作る側にいた経験から言えるのは、失敗の多くはベンダーの技術力ではなく、発注者とベンダーの間の「構造」で起きるということです。

発注者に責任を押し付けたいのではありません。逆です。構造は発注者側の準備で変えられる——それがこの記事の主旨です。

失敗の型1：要件を「ベンダーが決めてくれる」と思っている

一番多い型です。「プロなんだから、うちに合うように作ってくれるはず」——しかしベンダーが知っているのはシステムの作り方であって、御社の業務ではありません。要件が曖昧なまま進むと、ベンダーは打ち合わせで聞けた範囲で解釈して作り、完成間近に「思っていたのと違う」が噴き出します。

ここで起きるのは追加費用の交渉です。契約上、書かれていない要件は「変更」であり、変更は有償です。要件の曖昧さのコストは、最終的に発注者が払う——この構造を先に知っておいてください。

打ち手はシンプルで、発注前に困りごとと実現したいことを文書にすることです。RFP（提案依頼書）はA4数枚でいいという記事に、最低限の書き方をまとめました。

失敗の型2：現場を巻き込まずに決める

経営層とベンダーだけでシステムを決め、現場は稼働直前に説明会で初めて画面を見る——この進め方は、高い確率で「使われないシステム」を生みます。

• 現場の実際の業務手順とシステムの想定がずれていても、気づくのが稼働後になる
• 「聞いていない」という感情的な反発が、操作の習得より先に立つ
• 入力が定着せず、データが入らないシステムには何の価値もない

要件を固める段階で、実際に入力する人に画面を触ってもらう。この一手間の有無が、稼働後の景色を分けます。

失敗の型3：テストと移行を「ベンダーの仕事」だと思っている

ベンダーはシステムが仕様通りに動くかをテストします。しかし、仕様そのものが業務に合っているかは、業務を知る発注者にしか確かめられません。受入テスト（発注者側のテスト）を形だけで済ませると、不具合はすべて本番で見つかることになります。

もう一つ見落とされがちなのがデータ移行です。旧システムやExcelのデータを新システムに入れる作業は、たいてい「マスタの整備」という地味で重い仕事を伴います。品目名の表記ゆれ、重複、欠損——これを整えるのは発注者側の仕事として契約に書かれていることが多く、見積もりの前提条件を読んでいないと、稼働直前に社内が回らなくなります。

「良いベンダー」は、発注者の準備で見分けられる

皮肉なことに、発注者側の準備はベンダーの見極めにも効きます。要件を文書で渡したとき——

• 曖昧な部分に質問をしてくるベンダーは、作る前に考えている
• 質問なしで「できます」と即答するベンダーは、リスクを金額に乗せているか、後で変更費用を取る前提でいる

質問の質は、提案書の見栄えより正直です。

発注者側に「作る側の経験者」を置く

ここまでの打ち手——要件の文書化、現場の巻き込み、受入テストの設計、移行の段取り——は、どれも特別な技術ではありません。ただ、初めての会社が独力でやるには経験が要るのも事実です。

私たちWhitebellのITアドバイザリーは、この「発注者側の経験者」を外から補うサービスです。要件整理からRFP作成、ベンダー提案の評価、契約交渉、受入テストの設計まで、発注者の側に立って伴走します。自社でシステム（Cosmil）を開発しているので、ベンダーの説明の裏側——どこに工数がかかり、どこにリスクが隠れるか——を作る側の言葉で読めます。

システム導入は、ベンダーに「発注する」プロジェクトではなく、ベンダーと「共同でやる」プロジェクトです。その認識に立った瞬間から、失敗の確率は下がり始めます。