システムを作ったのに現場で使われなかった｜失敗の構造と防ぎ方

「システムは作ったんですよ。でも、気づいたら誰も使わなくなってた」。

これは、ある製造業の小さな会社の話だ。受発注の管理を効率化したいと思ってシステムを作った。費用は300万円ほどかかった。半年後に現場を見ると、スタッフはまたExcelで管理していた。システムは、ほとんど開かれなくなっていた。

笑えない話だが、こういうことは思った以上に起きている。

なぜ誰も使わなくなるのか

使われなくなったシステムには、たいてい共通の経緯がある。

まず、仕様書が先に来る。「どんな機能が必要ですか」という質問に答えながら、打ち合わせを重ねて、最終的に分厚い仕様書ができる。それをもとにシステムが作られる。

問題は、この仕様書が「経営者や管理職の頭の中にあるイメージ」で作られていることだ。現場のスタッフが毎日どんな順番で何をしているか、どこで詰まるか、どんな例外が頻繁に起きるか——そういう生きた情報が、仕様書には入りにくい。

それでも開発は進んで、完成品が届く。触ってみると「ああ、なんか違う」という感覚がある。でも、もうお金は払った。作り直しにはまたお金がかかる。だからとりあえず使ってみようとする。

でも現場のスタッフからすると、今まで自分たちのやり方で回っていたものを、新しい、使いにくい画面に合わせてやり直すのは負担だ。「Excelの方が早い」という感覚は正直なものだ。一ヶ月経ち、三ヶ月経つと、そっとExcelに戻っている。

「仕様が正しかった」と「使える」は別の話

失敗したシステム開発でよくある言い訳に、「仕様書通りに作った」がある。

これは事実かもしれない。でも、「仕様書に書いたことを正確に実装した」ことと、「現場で使えるものを作った」ことは、全く違う。

仕様書は言語だ。文字で業務を説明する。でも実際の業務は、文字で説明しきれない部分を大量に含んでいる。「こういうときはこうする」「例外はだいたいこのパターン」「ここは慣れが必要」——そういうことは、書いた人も書けていないし、読んだ人にも伝わらない。

その結果として完成したシステムは、「書かれた業務」には対応しているが、「実際の業務」には対応していない状態になる。

触らないと、わからないことがある

これを防ぐ方法はシンプルだ。完成させる前に触ってもらうことだ。

仮のもので構わない。動く部分だけ動かして、現場のスタッフに実際に使ってみてもらう。そうすると、「ここが使いにくい」「この順番が逆の方がいい」「この項目は毎回入力するのが面倒」という声がすぐに出てくる。言葉では出てこなかった「使い勝手」が、触ることで初めて見えてくる。

完成後に修正するのは高くつく。でも、完成前のプロトタイプ段階であれば、修正は早くて安い。触って直して、また触ってもらう。これを繰り返すことで、「仕様書のシステム」ではなく「現場のシステム」ができあがる。

投資した費用が死ぬのを防ぐために

システム開発に数百万円を使って、誰も使わないものができたとき、その費用は完全に死ぬ。取り返しがつかない。

でも、このリスクは「触ってから作る」というアプローチでかなりコントロールできる。現場の人間がプロトタイプに触れて「これなら使える」と思えたものを本番化する。そういうプロセスがあれば、完成後に「誰も使わない」という最悪の結果は、かなり避けられる。

もし今、自社のシステム化を検討しているなら、発注する前に「プロトタイプを触らせてもらえますか？」と聞いてみてほしい。その質問に「もちろんです」と答えられる会社は、現場に合わせて作る文化を持っている可能性が高い。

システムは、完成して終わりではない。現場で生き続けて初めて意味がある。そのためには、現場の人間が「これ、いいな」と感じる瞬間が、開発のどこかに必要だ。