【しくじり現場部長 | 現場DX実践録 #3】 高額多機能システム。でも、なぜ現場では使われないのか？

第1章　完成したはずのシステムが、静かに使われなくなる

数百万円、時には数千万円を投じて導入したシステムが、半年後にはほとんど使われなくなり、現場が以前のExcelや紙へ戻っている。
私は、そうした光景を何度も見てきた。
外部ベンダーは技術の専門家である。要件定義書を作り、画面を設計し、データベースを構築し、決められた期限までに納品する。経営側から見れば、専門家へ任せたのだから安心できるはずである。
それでも、なぜ現場では使われなくなるのか。
導入直後は、研修も行われる。操作マニュアルも配布される。担当者は新しい画面へ入力しようと努力する。
しかし、数週間たつと別のExcel表が作られる。
システムへ入力した後、取引先へ送るためにExcelへ転記する。システムでは確認できない項目を、紙のメモで補う。例外案件だけはベテラン担当者の個人ファイルで管理する。
そして、いつの間にか正式なシステムと、現場が独自に作った表が並行して動き始める。
これは、現場が新しい技術を嫌っているからとは限らない。
使わなければ業務が止まるから、現場は自分たちで不足部分を補っているのである。
私は国際物流、輸出入実務、レンタカーの配車、売上管理、在庫管理など、異なる現場に関わってきた。分野が違っても、同じ問題が起きる。
たとえば輸出業務では、商品名、数量、重量、原産国、取引条件を複数の書類へ転記する。通常案件ならシステムで処理できても、取引先ごとの備考、輸出先国ごとの表示、過去の通関トラブルを踏まえた注意事項までは、標準画面に入っていないことがある。
レンタカーの配車でも、予約台数だけを管理すればよいわけではない。車両の保管場所、清掃状況、点検予定、回送スタッフの動線、店舗ごとの出庫時間が絡む。
現場の仕事は、マニュアルに書かれた標準処理だけでは回らない。
ところがシステムは、書かれた要件をもとに作られる。
ここに、最初の大きな断絶がある。

第2章　外部ベンダーが悪いのではない―失敗を生む構造

外部ベンダーへ発注したシステムが使われないと、「ベンダーが現場を理解していない」と批判される。
確かに、現場を十分に見ないまま開発を進める事例はある。しかし、すべてをベンダー側の責任にするだけでは、同じ失敗を繰り返す。
問題は、発注する側と作る側の間にある構造である。
第一に、要望が途中で薄まる。
現場担当者の困りごとは、上司、管理部門、情報システム担当、経営層を経て、外部ベンダーへ伝わる。その過程で、「毎朝三つの表を見比べている」という具体的な苦労が、「情報を一元管理したい」という抽象的な要望へ変わる。
抽象化された要望は、会議では説明しやすい。しかし、現場の作業を再現するには情報が足りない。
第二に、契約は書かれた範囲を基準にする。
開発途中で現場から「この例外も必要だった」と言われても、当初の仕様書になければ追加費用や納期変更が発生する。これは外部ベンダーの都合だけではない。契約で仕事を進める以上、範囲を明確にしなければならないからである。
第三に、完成の意味が違う。
開発側にとっての完成は、仕様どおり動き、テストを通過し、納品できる状態である。
現場にとっての完成は、忙しい時間帯でも迷わず使え、例外が起きても業務を止めず、担当者が替わっても続けられる状態である。
両者は同じ「完成」という言葉を使いながら、見ているものが違う。
第四に、現場の暗黙知が見えない。
担当者は、前月の数字と比較する。取引先の性格を思い出す。入力内容に不自然さがあれば、別の資料を確認する。
本人は当たり前に行っているため、それを要件として説明しない。ベンダーも、説明されていない判断を設計へ入れることはできない。
第五に、導入後の改善が遅い。
現場で使い始めると、初めて分かることがある。しかし、修正依頼、見積もり、承認、開発、検証という工程を経るため、小さな変更でも時間がかかる。
その間、現場は待てない。
だから、自分たちでExcelを作り、業務を継続する。
つまり、使われないシステムは、技術力が不足しているから生まれるとは限らない。
現場の情報が仕様へ変換されないまま、契約と開発が先へ進むことで生まれるのである。

第3章　現場を知る私も、「便利なら使われる」と思い込んだ

では、現場を知る人間が自分で作れば、すべて解決するのだろうか。
私は、そう単純ではないと考えている。
私自身、現場の手間を減らすために、受発注、帳票出力、配車、売上集計などの仕組みを作ってきた。
現場を知っている。必要なデータも分かる。毎日どこで時間を取られているかも分かる。
だから、便利な機能を入れれば、当然使ってもらえると思っていた。
入力した数字を自動集計する。ボタン一つで帳票を出す。検索や並び替えもできる。開発する側から見れば、便利な機能を増やしたつもりだった。
ところが、現場から返ってきたのは、必ずしも感謝の言葉ではなかった。
「入力が面倒だ」
「どこを押すのか分からない」
「画面に情報が多すぎる」
「今までの方法の方が早い」
私は、機能的には正しいのに、なぜ使われないのかと悩んだ。
ここで気づいた。
外部ベンダーと現場の間に距離があるように、開発する私と利用する人の間にも距離があったのである。
同じ会社にいても、同じ業務を知っていても、作る側になると「これもできる」「あれも自動化できる」と機能を中心に考えてしまう。
一方、利用者が見ているのは、前より入力が減るか、忙しい時に迷わないか、失敗しても元へ戻せるかである。
私は「便利なものを作った」と考えていた。
しかし、相手が「使い続けられる」と感じなければ、便利とは言えない。
このしくじりは、外部ベンダーだけを批判していたら気づけなかった。
現場を知っていることは大きな強みである。しかし、それだけで成功は保証されない。
現場知を、必要最小限の機能、分かりやすい操作、修正しやすい運用へ変換しなければならない。
ここから先では、現場知を実際の仕組みへ変える具体的な手順と、内製・外注を感情ではなく条件で判断する基準を整理する。

第4章　現場知を使われる仕組みへ変える五つの実務手順
第5章　内製か外注かを見極める七つの判断基準

次に読むなら

第10話「『便利そう』では、現場は動かない」
なぜ、読んだほうがいいのか：
第3話では、外部ベンダーと現場の距離だけでなく、現場を知る人が作っても失敗する可能性を示しました。第10話を読むと、機能的な便利さと、利用者が感じる使いやすさがなぜ一致しないのかを、さらに具体的に理解できます。

関連記事

第1話「AI時代に、あえてExcel VBAを選ぶ理由」

第11話「高額システムなら安心、は本当か？―現場で使われて初めて、システムは価値になる―」

【BOOTH】

【簡易システム（無料配布中）】
「トイレ清掃チェック表」
年月を変更すると自動的に曜日が変更される

「月次売上一覧表」
日次のカード売上&現金売上を入力すると当月売上一覧表が自動的に作成

「レンタカー配車早見システム」
異なる車両保管場所にある車両について、翌日出庫車両を教えてくれる

「かんたんJAN作成&管理」
JANコード自動作成

"Opening Movie"
超有名な映画会社米国ハリウッドのオープニングムービー全集

"FAX Database System"
業者毎のFAX送信のためのデータベースシステム

【簡易システム（有料）】
「かんたんメール一斉送信システム」\480
メールアドレス管理&メール送信機

「かんたんシフト管理」\480
観光施設やレンタカー会社、中小・零細企業用

「かんたん英文法」\480
中学生から社会人まで

「かんたん英単語ExcelPerfect」\980
幼稚園から社会人までの英単語を幅広くゲーム感覚で学習

「国際ビジネス受発注システム」（簡易版）\0
数値・数字を入力するだけで発注書や請求書等９つの書類作成

「国際ビジネス受発注システム」（完全版）\980
数値・数字を入力するだけで発注書や請求書等11もの書類作成

「海外発送スターターキット」\0
バーコードをスキャンするだけで、通関電子データ用のソース情報を成型