社長がITベンダーのプレゼンを聞いて「これはいい、うちにも導入しよう」と決める。稟議はすぐ通る。予算もつく。ところが半年後、作ったシステムを現場のスタッフはExcelと併用していて、入力は形だけ。実質的にはほとんど使われていない。
これは特定の会社の失敗談ではなく、業務システム導入における典型パターンのひとつだ。僕が相談を受ける案件の中でも、体感で3割くらいはこの構図が見え隠れしている。
なぜ経営層と現場の認識はズレるのか
理由はシンプルで、見ている景色が違うからだ。
経営層は「全社の生産性向上」「データの一元管理」「属人化の解消」といった組織課題を見ている。マクロの視点で判断するから、システムの機能一覧や導入効果の試算で「いける」と感じる。
現場は「自分の日常業務がどう変わるか」を見ている。今のExcelに慣れている人にとって、新しいシステムは学習コストそのものだ。「なんで今のやり方じゃダメなの」という疑問に対して、「全社最適のため」では納得しにくい。
この認識ギャップは、仕様書のレビュー会議では埋まらない。仕様書を読んで意見を言えるのは、ITリテラシーが高い一部のスタッフだけだ。現場の多くの人は、仕様書を渡されても何を確認すればいいのかわからない。結果として、経営層と情シスだけで仕様を固めて、現場には完成品が降りてくる。
仕様書レビューの限界
「ちゃんと現場の意見も聞いた」というプロジェクトでも、実態はヒアリングシートの配布と回収だったりする。「現在の業務で困っていること」を記入してもらい、それを要件に反映する。プロセスとしては正しい。
でも、困っていることを言語化できることと、新しいシステムで何が改善されるかをイメージできることは、まったく別の話だ。「顧客情報の検索に時間がかかる」と書いたスタッフが、新システムの検索画面を見て「これは使いやすい」と感じるかどうかは、触ってみないとわからない。
ヒアリングで出た要件をすべて盛り込んだのに現場が使わない、というケースが多いのは、「要件を満たすこと」と「使いやすいこと」が一致するとは限らないからだ。
デモを現場に触らせる
僕がこの問題に対して一番効果があると考えている方法は、動くデモを現場に触らせることだ。仕様書でもなく、プレゼン資料でもなく、実際に操作できるプロトタイプ。
7日で作ったデモのURLを現場のスタッフに送って、「5分だけ触ってみて、感想を教えて」と伝える。これだけで、仕様書レビューでは絶対に出てこなかったフィードバックが山ほど出る。
「このボタン、いちいち押すのが面倒」「ここにこの情報が出てくれたら、別画面を見に行かなくて済む」「入力欄が多すぎて毎回しんどい」。こういう声は、実物を触って初めて出てくるものだ。そして、こういう声こそが、システムが「使われるか使われないか」を分ける。
合意の質が変わる
デモを挟むことで変わるのは、合意の「質」だ。
仕様書ベースの合意は「機能に同意した」という状態。デモベースの合意は「この操作感で仕事ができると確認した」という状態。同じ「OK」でも、中身がまるで違う。
デモを触った現場スタッフが「これなら使える」と言ったとき、その言葉には自分の業務フローを想像した上での実感が入っている。仕様書に「OK」のハンコを押すのとは、覚悟の深さが違う。
経営層にとっても、現場が「触って確認した」という事実は心強い。導入後に「現場が使ってくれない」というリスクが、この段階で大幅に下がるからだ。
撤退コストが激減する
デモの段階で「これは現場に合わない」とわかった場合、かかるコストはデモ制作の費用だけだ。数十万円程度で方向転換できる。
これが本開発後の発覚だった場合、話は深刻になる。開発費200-300万に加えて、導入研修のコスト、データ移行のコスト、現場が使わないシステムを維持する月々のランニングコスト。さらに、「次こそ使えるシステムを」と二度目の開発に入れば、トータルで500万を超えることもある。
最初の200万を節約するためにデモを省略した結果、500万の支出になる。こういう事態を、デモの段階で回避できる可能性がある。
「現場に触らせる」を判断プロセスに組み込む
社内でシステム導入を検討するとき、判断プロセスのどこかに「現場がデモを触るステップ」を入れることを強く勧めたい。
具体的には、ベンダー選定の前にデモで方向性を確認する。見積もり比較の前に、何を作るべきかを現場と一緒に固める。この順番を変えるだけで、「社長はOKだけど現場が使わない」という事態をかなりの確率で防げる。
仕様書に100ページのドキュメントを積み上げるよりも、5分触れるデモを1本渡すほうが、現場の本音は引き出せる。合意形成のやり方を変えるだけで、プロジェクトの成否が分かれることは少なくない。