作ったのに現場で使われない｜実装外注だけで起きる定着失敗

「要件どおり作った。検収も通った。だが現場が使わない。」——実装外注だけのプロジェクトで繰り返し起きる。失敗の本体はUIの好みではない。定着（教育・運用・インセンティブ）がスコープに入っていなかったことだ。

使われないシステムは、未完成と同じコストを生む。定着を誰が持つかを発注時に決める。

典型失敗

1. 現場の業務フローを変えずに画面だけ新しくする
2. トレーニングがリリース後の「お知らせ」だけ
3. 旧手段が残ったまま、新システムに移る理由がない
4. 運用の問い合わせ窓口が空
5. 成功指標が「納品」で終わり、利用率を見ない

深掘り事例

匿名化した一例。社内申請の電子化を外注。検収は画面と帳票。現場はExcel並行運用を続け、3ヶ月後の利用率は低迷。追加で定着支援を発注し、結局初期見積もりを大きく超えた。

分岐点はRFPだ。「利用率○%を90日で」を成功条件に入れ、定着ワークショップをスコープに含めていれば、実装範囲そのものが変わっていた（例外業務の削減など）。

責任分界（企画〜定着）

フェーズ	社内が持つべきもの	外に出せるもの
企画	やめる旧業務、成功指標	要件の整理支援
実装	優先順位の決裁	設計・開発
定着	現場のインセンティブ、旧手段の停止	研修設計、同行、改善

判断軸

実装と定着をセットで発注	実装のみでよい
現場の行動変容が必要	既存ユーザーが待つ改善で、導線が同じ
旧手段を止められる権限が社内にある	止められないのに新システムだけ作ろうとしている（まず止める）

次に確認すること

1. 成功指標は利用率や業務時間か（納品完了だけになっていないか）
2. 旧手段を止める日はあるか
3. 定着の担当（社内）は名前か
4. 研修・同行は見積もりにあるか
5. 現場の例外業務を削減する合意はあるか

まとめ

使われない納品は、開発会社だけの責任ではない。定着をスコープ外にした発注設計が先にある。作る前に、使い続ける条件を書く。

---

定着まで含めた伴走の相談は、お問い合わせフォーム からどうぞ。