多大な費用と時間をかけて開発したシステムが、稼働後数ヶ月で「現場で使われていない」状態になる──これは中小企業のシステム導入で頻繁に発生する悲劇です。なぜそうなるのか、防ぐにはどうすればいいのか。本記事では、発注前・契約前の段階で必ず確認すべき7つのチェックポイントを実例ベースで解説します。
「使われないシステム」が生まれる根本原因
システムが使われなくなる原因は技術的な問題ではなく、発注プロセスに起因することがほとんどです。具体的には以下の3つです。
- 現場の業務実態を反映しないまま要件定義が進んだ
- 使う側（現場担当者）が発注プロセスに関与していなかった
- 稼働後の改善体制が用意されていなかった
これらは、契約前の段階で適切なチェックを入れることで防げます。以下、確認すべき7つのチェックポイントを順に解説します。
チェック1：現場担当者がヒアリングに参加しているか
経営層・情報システム部門だけで要件を決めてしまうと、現場の実業務と乖離したシステムができあがります。「上から降ってきたシステム」は心理的にも使われません。発注プロセスのヒアリング段階から、実際にシステムを使うことになる現場担当者を1〜2名は必ず巻き込みましょう。
チェック2：「現状の業務フロー」が文書化されているか
システム化前の業務フローを言語化・図解せずに開発が始まると、現場の暗黙ルールや例外処理がシステムに反映されません。完璧な業務フロー図でなくても構いません。手書きの簡易図でも、「業務の流れと例外パターン」が見える状態であることが重要です。
チェック3：「動くもの」を契約前に確認できる開発手法か
仕様書だけを根拠に契約を結ぶ従来型開発では、納品されるまで完成像が見えません。納品後に「思っていたのと違う」が発覚しても、契約は既に結ばれているため修正には大きな追加費用がかかります。契約前にプロトタイプを実際に触れる開発手法を選べば、このリスクは構造的に解消されます。
関連記事：「並走型システム開発」とは？発注前に動くプロトタイプを見られる開発手法を徹底解説
チェック4：稼働後の改善対応がどこまで含まれるか
システムは稼働した瞬間から「業務に合わせた微調整」が必要になります。稼働後の改善対応が契約に含まれていない場合、「画面項目を1つ追加する」だけで都度見積もり・追加費用が発生します。結果、改善が止まり、システムが業務から乖離していき、最終的に使われなくなります。月額型で継続改善が含まれる契約であれば、この問題は予防できます。
チェック5：操作研修・導入支援が用意されているか
「システムを納品しました、あとはご自由に」という納品スタイルだと、現場が使い方を理解しないまま放置されます。マニュアルだけ渡されても読まれません。実際に現場担当者に1時間でも操作レクチャーをすることで、定着率は大きく変わります。導入支援の有無と内容を契約前に確認してください。
チェック6：データ移行の段取りが明確か
Excelや旧システムからのデータ移行は、想定以上に手間がかかる工程です。「データ移行はお客様側で」という契約だと、現場担当者が業務の合間に移行作業を強いられ、稼働開始が遅れたり、データ品質が低下したりします。移行の段取り（誰が・いつ・どのデータを・どの手段で移すか）が契約前に明確になっているかを確認してください。
チェック7：ベンダーロックを避ける構成になっているか
特定ベンダー独自のクラウドサービスや独自言語で構築されたシステムは、後で別ベンダーに切り替えるのが極めて困難になります。汎用的な技術スタック（業界標準のフレームワーク・データベース・クラウド）で構築されていれば、万が一の場合も他ベンダーへの移行や内製化が可能です。ソースコードの引き渡しの有無も契約前に確認すべきポイントです。
7つのチェックポイント早見表
| # | チェック項目 | 確認方法 |
|---|---|---|
| 1 | 現場担当者がヒアリングに参加 | キックオフ会議に現場担当が出席するか確認 |
| 2 | 現状業務フローが文書化 | 業務フロー図やヒアリング記録が共有されるか |
| 3 | 契約前にプロトタイプ確認 | 「契約前に動くものを見せてもらえますか」と質問 |
| 4 | 稼働後の改善対応の範囲 | 「軽微な機能追加は月額に含まれますか」と質問 |
| 5 | 操作研修・導入支援 | 「現場担当への操作レクチャーは付きますか」と質問 |
| 6 | データ移行の段取り | 「データ移行は誰がやりますか」と質問 |
| 7 | ベンダーロック回避 | 「ソースコードの引き渡しはありますか」と質問 |
よくある質問
Q. 7つすべて満たすベンダーは少ないですか？
従来型の受託開発ベンダーでは、特にチェック3（契約前プロトタイプ）と4（改善対応の月額包含）を満たすところは多くありません。「並走型システム開発」を提供している新しいタイプのベンダーであれば、これらをサービス設計の前提としていることが多いです。
Q. すでに「使われないシステム」を抱えています。どう対処すべきですか？
まず、現場担当者にヒアリングして「なぜ使わなくなったか」を整理してください。原因が「操作が複雑」「業務に合っていない」「データ入力が二度手間」など改善可能なものであれば、追加開発で立て直せる可能性があります。「根本的に方向性が違う」場合は、思い切ってリプレースを検討する判断もあります。並走型開発であれば、契約前にプロトタイプで「リプレースで本当に問題が解決するか」を確認できます。
Q. 経営層がチェック項目を理解してくれません
「使われないシステムを作ると、3年で500万円が無駄になる」という金銭インパクトで説明するのが効果的です。本記事や他社の失敗事例を共有して、リスクを定量化して伝えることをお勧めします。
まとめ：契約前に7つを確認するだけで失敗確率が大幅に下がる
「使われないシステム」を防ぐためには、技術的な高度さよりも、発注プロセスでの基本的な確認の方が重要です。本記事の7つのチェックポイントを契約前に確認するだけで、失敗確率は大幅に下がります。すべてを満たすベンダーが見つからなくても、できるだけ多くを満たすベンダーを選ぶことで、稼働後のリスクを抑えられます。
関連記事：「言った言わない」が起きるシステム開発の典型パターンと、認識齟齬を防ぐ5つの方法
無料相談のご案内
本記事の7つのチェックポイントすべてを満たす開発手法をご提供しています。御社の業務に即した具体的な提案を、30分のオンライン無料相談でお話しします。