業務システムが現場で使われない4つの理由

数千万円をかけて導入した基幹システムが、稼働から1年後、ほとんど使われていない。現場を見に行くと、担当者はシステムを開いたあとで、結局いつものExcelファイルに数字を打ち込んでいる。システムは「あとで記録を残すための箱」になり、実際の仕事はExcelとメールで回っていた。

稟議を通し、ベンダーを選び、半年かけて要件を固めて開発した。納品されたシステムは仕様書どおりに動く。バグもない。受け入れテストも通っている。それでも使われない。

こういうとき、原因はたいてい「現場のITリテラシーが低い」「変化を嫌う人がいる」という話で片づけられる。ベンダーは「ご要望どおり作りました」と言い、発注側は「うちの現場が悪い」と引き取る。誰も嘘はついていないのに、投資は回収されない。

本当に、現場のせいだろうか。いくつもの開発現場で「使われないシステム」を見てきた立場から言うと、そこにはもっと具体的で、もっと発注前に手を打てる共通点がある。

「使われない」の正体は、機能不足ではない

要件を満たしていても、稼働後に使われないシステムは生まれる。

「業務システム 使われない」で検索すると、多くの記事はQCD（品質・コスト・納期）の管理や、ベンダー選定のリスク、要件定義の抜け漏れといった話にたどり着く。どれも正しい。ただ、これらは「作りきれなかった」失敗の話だ。予算が足りない、納期に間に合わない、要件を取りこぼす——分類としては分かりやすい。

ここで扱いたいのは、別の失敗だ。機能は揃っている。仕様書の項目はすべて実装されている。テストも通った。それでも半年後には使われていない。「作りきったのに、使われない」という失敗である。

この失敗は、機能の数を増やしても、開発会社の技術力を上げても防げない。原因がコードの外側——業務と人間の側にあるからだ。私たちが繰り返し見てきた原因は、大きく4つに整理できる。

理由1：業務フローと、システムが噛み合っていない

ある受注管理システムを見せてもらったとき、現場の担当者はシステムとは別に、壁のホワイトボードを併用していた。理由を聞くと「システムの登録順と、実際の作業順が逆だから」。システムは「受注登録 → 在庫引当 → 出荷指示」の順に入力を求める設計だった。だが現場は、先に倉庫の空きと納期を見て、動かせるものから動く。頭の中の段取りと、画面が求める順番が、最初から逆立ちしていた。

結果として担当者は、まずホワイトボードで実際の段取りを組み、仕事が一段落してから、その内容をシステムに「清書」していた。システムは仕事を助ける道具ではなく、仕事のあとに発生する二重入力の作業になっていた。

こうしたシステムは、たいてい「あるべき業務フロー」から設計されている。標準化された理想の流れを描き、それに合わせて画面を並べる。きれいだが、現場に「システムに合わせて働け」と強いる構造になっている。現場の実際の流れを一日眺めていれば、登録順が逆であることは初日に気づけたはずだった。

理由2：入力する人と、得をする人が違う

現場が入力コストを払い、恩恵は管理側だけが受け取る。この非対称が、形骸化のいちばん深い原因だ。

ある会社では、日報システムの入力率が数か月で目に見えて落ちていった。機能に不満があったわけではない。項目は現場のヒアリングを踏まえて作られていたし、動作も軽かった。それでも入力されなくなった。理由は単純で、入力しても、入力した本人には何も返ってこなかったからだ。

そのシステムは、現場が毎日15分かけて作業実績を打ち込むと、管理部門にきれいな進捗レポートが上がる仕組みだった。レポートを見て喜ぶのは管理職と経営層で、入力する現場の手元には、余分な15分が残るだけ。「自分の仕事が楽になる」実感がどこにもなかった。

人は、コストとリターンが釣り合わないことを長くは続けない。入力側に何のリターンも設計されていないシステムは、号令や罰則で一時的に入力率を戻せても、必ずまた形骸化する。逆に、入力した内容がその場で自分の段取りに使える——たとえば入力すると次にやるべき作業が自動で一覧に並ぶ——なら、頼まなくても入力される。

「使われるかどうか」は、機能の充実度ではなく、この入力と受益の設計で決まる。ここを詰めずに作られたシステムは、どれだけ高機能でも、現場から見れば「上に報告するための面倒」でしかない。4つの理由の中で、これがもっとも根が深い。

理由3：画面と操作動線が、業務を分かっていない

ある在庫管理の画面では、1件の入庫処理を終えるのに11回のクリックが必要だった。商品を選び、数量を入れ、確認ダイアログを閉じ、別タブに切り替えて棚番を入力し、また戻って保存する。1件なら我慢できる。だが現場は、繁忙期に1日400件を捌く。11クリック×400件が毎日積み上がっていく。

さらに悪いことに、入力を1か所間違えると最初の画面まで差し戻され、それまでの入力が消えた。ラベルは「与信区分」「引当ステータス」といった、現場が普段使わない社内用語のままだった。担当者はやがて、システムを避けて手書きの伝票に戻り、一日の終わりにまとめて入力するようになった。

これは一見「UIの問題」に見える。だが本質は見た目ではない。何件を、どんな順番で、どこで間違えやすいのかという業務そのものの理解が欠けているから、動線が業務と合わないのだ。ボタンの色を変えても解決しない。「この処理は1日何件発生し、1件あたり何秒で終わるべきか」を設計の最初に置けるかどうかの問題である。

理由4：完成してから、現場が初めて画面を見る

要件定義の打ち合わせに並ぶのは、情シスと管理職とベンダーだけ——実際にそのシステムを毎日触る現場の担当者は、その場にいない。決まった要件は現場のいない場所で固まり、開発が進み、そしてリリース初日に、現場は完成品と初対面する。

この順番だと、現場が違和感に気づくのは、もう作り終わったあとになる。「この順番では入力できない」「この用語は使っていない」といった声は、直すには作り直しが必要な段階で初めて出てくる。予算も納期も残っていないから、たいていは「運用でカバー」という名の我慢に回される。そして我慢は続かず、Excelに戻る。

使われるシステムは、逆の順番で作られている。現場が要件定義から関わり、完成前に何度も画面を触り、リリース時にはすでに「見慣れた道具」になっている。初対面をリリース日にしないこと。それだけで防げる失敗は多い。

発注側が、事前にできる3つのこと

「使われるか」は運任せではない。契約と進め方で、発注側からコントロールできる。

• 要件定義の場に、現場の実務者を入れる

• 画面は仕様書ではなく、動くプロトタイプで確認する

• 「定着まで」を開発スコープに含めて契約する

① 要件定義の場に、現場の実務者を入れる。理由1・4の多くはこれで防げる。管理職が語る「あるべき流れ」ではなく、実際に毎日入力する人の「今の流れ」を、設計の起点にする。半日でいいので、開発側に現場の仕事を実際に見てもらうのが理想だ。

② 画面は仕様書ではなく、動くプロトタイプで確認する。理由3のクリック数や動線は、文章の仕様書では絶対に気づけない。実際に触れる試作画面で「1件、入力してみる」だけで、11クリックのような問題はその場で発覚する。見た目の確認ではなく、業務を1周流す確認をする。

③「定着まで」を開発スコープに含めて契約する。納品して終わりの契約では、稼働後に見つかる「使われない理由」を直す責任がどこにも残らない。リリース後の改善と定着支援までを最初から範囲に入れておけば、理由2のような入力設計のズレも、運用データを見ながら直していける。作って終わりではなく、使われるまで伴走する前提で発注する。

まとめ：原因は技術力ではなく、設計プロセスにある

「作ったのに使われない」システムの原因は、開発会社の技術力でも、機能の不足でもない。業務フローとのズレ、入力と受益の非対称、業務を分かっていない動線、そして現場不在の進め方——いずれも、コードを書く前の設計プロセスの問題だ。

裏を返せば、発注側が進め方に関与することで、防げる失敗でもある。現場を要件定義に入れ、プロトタイプで確かめ、定着までを契約に含める。この3つを押さえるだけで、「1年後にExcelに戻る」確率は大きく下げられる。

私たちは、リリースして終わりではなく、使われる状態になるまで伴走する開発体制を前提にしています。自社の業務システムが「作ったのに使われていない」状態にあるなら、まずはお気軽にご相談ください。