ITベンダー選定で企業が犯す七つの失敗（と、その回避法）

失敗したITプロジェクトが技術力不足で失敗することは、ほとんどありません。原因は曖昧な合意、噛み合わない期待、そして発注側に責任者がいないことです。

以下の七つは、家族経営から大企業まであらゆる規模で繰り返されます。幸いなのは、すべて契約前に防げることです。そして契約前こそ、あらゆる修正が最も安く済む段階です。

最安値はたいてい三つのうちどれかを意味します。想定より範囲が狭い、品質が削られている、あるいは意図的に安く入り、後の変更依頼で利益を回収する計画である、のいずれかです。

処方箋： すべての見積もりを工程別に分解させます。調査、設計、開発、テスト、データ移行、研修、保証。分解できない見積もりはたいてい検討されておらず、検討されていない部分は後の請求書になります。

紛争の最大の原因です。発注側は「全社が滞りなく使えている状態」を完了と考え、ベンダーは「機能一覧を納品した状態」を完了と考えます。この二つは数ヶ月離れていることがあります。

多くの企業はベンダーを変えたくなった時に初めて気づきますが、その時点で交渉力はゼロです。契約前に答えるべき問いは二つ。自社向けに書かれたコードは誰のものか、関係が終わったとき全データをどう取り戻すのか。

この役割はベンダーには代替できません。決める権限を持ち、業務を理解し、実際に時間が配分されている人が自社に必要です。空席のままだと意思決定が数週間止まり、その待ち時間が請求されます。

処方箋： その人物を契約書に明記し、週あたりの投入時間と、不在時の代理者まで決めます。大げさに見えますが、順調に進むプロジェクトにはほぼ必ずこの役割の人がいます。

機能一覧は提案を比べる最も簡単な方法であり、だからこそ最も誤解を招きます。デモで印象的な機能が、現場が毎日触る機能であることは稀です。

処方箋： 機能一覧をシナリオ一覧に書き換えます。「レポート機能が必要」ではなく「毎週月曜の朝、店舗責任者が誰にも頼らずカテゴリ別の週次売上を確認できること」と書きます。シナリオは検証できますが、機能は約束されるだけです。

デモは常に滑らかです。データが整っていて、筋書きが選ばれているからです。問題が出るのは、システムが実データに出会ったときです。商品名の不統一、奇妙な過去取引、拠点ごとに異なる単位、これまで手作業で処理してきた例外。

システムは、建てたら独りで立っている建物ではありません。サーバー費用があり、セキュリティ更新があり、外部サービスの変更に伴う調整があり、そして決して途切れない小さな修正の流れがあります。

処方箋： 年間保守費用を最初に合意し、範囲を細かく定義します。何が含まれ、何が新規作業として扱われ、障害時の応答時間はどれだけか。