メインコンテンツへスキップ
見出し画像

なぜ現場は使ってくれないのか — 中小企業DXで、技術より先に見るもの

    打ち合わせの議事録より、机の上に置いてある紙のほうが正確だった。


    はじめに

    稟議を通した。説明会も開いた。マニュアルも配った。

    半年後に様子を見に行ったら、現場は元のExcelに戻っていた。

    怒られるかと思って理由を聞いたら、返ってきたのは「あれ、うちの流れだと二度手間になるんですよ」だった。責めている口調ですらない。むしろ申し訳なさそうだった。

    私は業務システムの要件整理や現場改善を20年以上やっている。近ごろは製造業の現場に入ることが多い。この「便利なはずなのに使われない」を、何度も見てきたし、白状すると自分でも作ってしまったことがある。

    原因を「現場の抵抗」に置くと、話はそこで止まる。けれど実際に困っている人の横に立ってみると、抵抗ではなかったことのほうが多い。単に、こちらが見ていたものが違ったのだ。

    この記事は、その「見るもの」の話をする。


    効くかどうかは、もう論点ではない

    まず前提を1つ置いておく。

    帝国データバンクが2026年3月に実施した調査(全国23,349社を対象、有効回答10,312社)によると、業務で生成AIを活用している企業は全体で34.5%、中小企業では32.4%だった。そして活用している企業のうち86.7%が「効果が出ている」と答えている[^1]。

    ただし、この86.7%は「活用している企業の中での割合」だ。試して合わずに離脱した企業はこの分母に入っていない。数字を額面どおり受け取るべきではない。

    それでも、1万社規模の回答で8割を超えている。道具そのものが効くかどうかを疑う段階は、実務レベルではもう過ぎたと考えていい。

    残っている問いは別のところにある。どこに当てるかだ。

    効く道具を持っていても、当てる場所を外せば、現場には「余計な手間が1つ増えた」としか映らない。


    当てる場所を外す理由 — 文章は現物の要約でしかない

    画像

    当てる場所を決めるとき、私たちは何を見ているだろうか。

    要望をまとめたメール。ヒアリングの議事録。仕様をまとめた資料。ほとんどが文章だ。現物そのものではない。

    ここに落とし穴がある。文章は現物の要約であって、現物ではない。そして要約は、必ず何かを落とす。

    先日こんなことがあった。ある製造業のお客様の案件で、Excelのチェック処理の仕様について、訂正の連絡が文章で届いた。それに合わせて実装を直そうとしたのだが、その前に、受領していた現物のファイルを開いて突き合わせることにした。

    チェック対象になる16項目を、1つずつ現物と照合した。結果は、4シートすべてが想定どおりだった。1件のズレもない。

    つまり、現物は最初から正しかった。ズレていたのは、それを説明していた文章のほうだった。

    誰かがミスをしたという話ではない。文章にした時点で、現物が持っていた情報の一部が落ちる。それだけのことだ。仕様を言葉にするというのは、そもそもそういう作業である。

    もし私が文章だけを見て手を動かしていたら、正しいものを「直して」いた。


    「使われていない」も、外からは判定できない

    もう1つ、自分で外した話を書いておく。

    自分用に作った仕組みが、2年半かけて増えていた。どれが生きていて、どれが死んでいるのか分からなくなったので、「もう使っていない仕組み」を自動で洗い出そうとした。実行ログも稼働記録も揃っている。機械的に判定できるはずだった。

    2つの基準を立てて試し、うまくいかないので両方を組み合わせた。誤判定率は68%、71%、組み合わせても48%。どれも当たらなかった。

    理由は、あとから考えれば当たり前だった。「年に1回しか動かないが、その1回が必要な仕組み」と「完全に死んだ仕組み」は、外から見た記録がほぼ同じ形をしている。どちらも、ほとんど動いていない。

    結局、86個を1つずつ人が判断した。うち46個は、記録をいくら見ても分からず、完全に手作業で確かめるしかなかった。

    これを顧客の現場に置き換えると、意味はもっと重い。「この帳票、もう誰も使っていないですよね」という判断を、こちらの手元の資料だけで下してはいけないということだ。使用頻度の低さは、不要であることの証拠にならない。


    だから、現物を見に行く

    ここまでの2つは、同じことを別の角度から言っている。身の丈に合うかどうかは、現物を見ないと決まらない。

    そして現物を見に行くと、だいたい予想と違うことが起きる。いちばん多いのは、思っていたより小さくていいと分かるパターンだ。

    以前、DOSで動いている生産管理システムのリプレースを検討したことがある。機能一覧には9つ並んでいた。文章の上では、9つとも必要に見える。

    現場で聞いてみると、実際に回っていたのは5つだけだった。残りは「昔そうしていた」という理由で一覧に載っていただけで、今は誰も触っていない。

    このとき、全部を作り直す案と、使われている5機能とCSV取込だけを先に移す案を並べて出した。合計金額はほぼ変わらない。違うのは1年あたりの負担だ。段階的に進める案なら、初年度は200〜250万円の枠に収まる。

    同じ総額でも、「一度に」と「年度をまたいで」では、通る稟議がまったく違う。そしてこれは、現場に行って「今いるのは5つだ」と確かめたから出せた案だった。

    「現場に行けない」場合はどうするか

    ここまで読んで、受託やリモート、副業の立場だと手が届かないと感じた方がいるかもしれない。私もすべての案件で現場に立てるわけではない。

    ただ、現物は現場にしか無いわけではない。

    本番データそのもの(サンプルではなく、実際に入っている値)。実際に運用されているファイルの現品。現場の人が撮った、作業中の写真1枚。エラーが出ている画面のスクリーンショット。

    これらはすべて現物だ。共通しているのは、誰かが要約していないという一点にある。要約を経ていなければ、机の上でも現物は見られる。

    逆に言えば、どれだけ現場に足を運んでも、聞いた話を自分の言葉でまとめた瞬間、それは要約に戻る。距離の問題ではない。


    現場サイズの決め方 — 3つの順番

    実際の進め方として整理しておく。

    ステップ1: 文章ではなく現物を突き合わせる

    要望メール、議事録、仕様書。どれも出発点としては必要だが、それだけで手を動かさない。

    文章と現物がズレていたら、疑うのは文章のほうから始める。現物が間違っていることもあるが、順番としては後だ。

    ステップ2: 「使われていない」を記録だけで判定しない

    削る判断は、増やす判断より慎重にやったほうがいい。増やして外したら「使われない機能が1つ増えた」で済むが、削って外したら業務が止まる。

    私は誤判定率7割近くを自分で踏んだので、これは自信を持って言える。

    聞く相手は、資料を作った人ではなく、その作業を毎日している人にする。

    ステップ3: 現物で確かめた範囲まで削ってから作る

    では、どこで線を引くのか。私が使っている基準は単純で、「今年、実際に動いた証拠があるか」と「動かなかった年に、誰かが困ったか」の2つを、人に聞いて確かめる。ログではなく人に聞くのは、ステップ2の理由による。

    両方を満たすものだけが、最初の範囲に入る。それ以外は捨てるのではなく、第2次・第3次として年度をまたいで積む。

    削らずに全部入りで作ると、どうなるか。私は自分の仕組みでそれをやった。1回の起動に14個の処理をまとめた結果、3回に1回しか最後まで終わらない状態になった。同じ時期、1回に1つのことだけをする単機能の仕組みは、84日間で19,379回動いて失敗は2回だった。

    壊れやすさを決めていたのは規模ではなく、1回にやろうとしたことの数だった。


    失敗しやすいポイント

    現場サイズで考えようとしても、途中で膨らんでしまうことがある。私が実際にやった、あるいはやりかけた3つを書いておく。

    「自由に設定できます」を売りにしかけた。 承認ルートを自由に組めるワークフローを設計していたことがある。柔軟性は正しく聞こえる。だが自由にできる状態は、裏を返せば例外を無限に増やせる状態だ。現場からすれば、決めなければいけないことが増えただけになる。実際に使われている形を数えたら3パターンしかなかったので、そこへ固定した。選択肢を減らしたほうが、運用は回った。

    機能を足すことを、改善だと思っていた。 前述の「14個をまとめた仕組み」は、6個から育てた結果だった。作っている最中は、良くしているつもりだった。実際に増やしていたのは、同時に止まる範囲のほうだった。

    AIの出力を、現物の代わりにしかけた。 打ち合わせの録音を文字起こしして議事録にしたことがある。1時間ほどの録音が30,796字になり、8つの議題に整理された。速い。便利だった。

    ただ、その現場特有の用語がいくつも誤変換されていた。たとえば「凍結期間」が「統括期間」になっていた。どちらも日本語として成立してしまうので、3万字を流し読みしていると気づかない。設計メモと1語ずつ突き合わせて直した。

    AIは要約が速い。だが要約は要約であって、現物ではない。この記事で書いてきたことは、そのままAIの出力にも当てはまる。


    まとめ

    画像

    「現場が使ってくれない」と感じたとき、たいていの場合、現場は抵抗していない。こちらが見ていたものが、文章だっただけだ。

    大きく始める必要はない。そもそも、大きく始められる前提が中小企業にあることのほうが少ない。現物を見て範囲を決めれば、予算も期間も、だいたい思っていたより小さくなる。

    冒頭に書いたとおりだ。議事録より、机の上に置いてある紙のほうが正確だった。

    まず開くのは、資料ではなくそちらのほうだと思う。


    この記事を書いた人

    業務システムの要件整理や現場改善を手がけています。
    「現場の"めんどくさい"をシステムで消す」をモットーに、
    紙・Excel・Accessの業務を無理なく整えるお手伝いをしています。

    現場のヒアリングから要件整理、段階的な改善設計まで。
    「何から手を付ければいいか分からない」という段階でも大丈夫です。
    ご相談・お仕事のご依頼は、no+eプロフィールからお気軽にどうぞ。


    参考情報

    [^1]: 帝国データバンク「生成AIに関する企業の動向調査(2026年3月)」2026年5月14日公表 — 調査期間2026年3月17日〜3月31日、全国23,349社を対象、有効回答10,312社(回答率44.2%)。業務での生成AI活用率は全体34.5%(大企業46.5%/中小企業32.4%/小規模企業28.0%)、活用企業のうち86.7%が効果を実感(「大いに効果が出ている」25.2%/「やや効果が出ている」61.5%)

    Web参考情報

     
     
    現場の『めんどくさい』をシステムで消す人。業務システム開発 20 年以上、近年は製造業 × AI 活用が主軸。Excel/Access VBA 整理・業務フロー可視化・AI 開発支援。DX 担当者・テックリード・副業層に実装と数字を発信。エンジニア兼会社経営。

    あなたへのおすすめ