DXが進まない理由は、技術ではなく"始め方"にあると思っている

現場には課題がある。でも動き出せない

情報システム部門や現場リーダーが「ここを改善したい」と思っていても、実際に動き出すまでに多くの障壁がある。

• 小さな入力改善でも、RFI（情報提供依頼）から始まる
• RFP（提案依頼書）を作るだけで数ヶ月かかる
• 複数ベンダーへの提案依頼・評価・選定のプロセスがある
• 稟議書を書き、上長の承認を得る
• 金額が大きければ投資委員会にかける
• ようやく承認が下りて、開発・導入・テスト・展開へ

これらのプロセスは大規模なシステム更改には必要だ。しかし現場の小さな改善にも同じプロセスを通すと、「改善コスト」が「改善効果」を上回ってしまう。動き出す前に諦める。あるいはそもそも提案すら上がらなくなる。

「本番前提」で始めるから重くなる

重くなる理由の一つが、「最初から本番投入を前提とした進め方」をすることだ。

本番前提で進めると、最初から品質・セキュリティ・運用体制・サポート・契約——すべての要件を固める必要がある。小さな改善のアイデアが、気づけば大きな調達プロジェクトになっている。

この「最初から本番品質を求める」姿勢が、試してみることを難しくしている。

小さく PoC して広げる考え方

現場改善を進めるための現実的なアプローチは、「まず小さく動かして確かめる」ことだ。PoC（概念実証）と呼ばれる考え方だ。

PoCの進め方

• 1店舗・1部門・1工程など、スコープを絞る
• 期間を決める（例：2週間〜1ヶ月）
• 評価軸を決める（作業時間・入力ミス率・スタッフの反応など）
• 検証後に「続ける・やめる・修正する」を判断する

PoCのコストは小さい。失敗しても影響が限定的なため、意思決定も速くできる。「うまくいった」という実績ができれば、横展開の稟議も通りやすくなる。

現場改善が止まりやすい構造的な理由

組織の中でDXが止まりやすいのには、構造的な理由がある。

評価基準が「成功したか」ではなく「失敗しなかったか」

組織の中で評価されるのは、大きな失敗をしないことだ。新しいことを試して小さく失敗することは、評価されにくい。結果として「やらない」が最も安全な選択になってしまう。

現場担当者に権限がない

現場のスタッフが「これを改善したい」と思っていても、予算も権限もない。上に上げるための書類を作るスキルも時間もない。せっかくの改善アイデアが、現場で消えていく。

IT部門が現場から遠い

IT部門が本社に集中しており、各店舗・現場の小さな課題に対応できる体制になっていない。現場からの要望は「次期システム更改で検討」と後送りにされ続ける。

「本番前提」をやめて「PoC前提」で動く

私がクラシスを開発した背景にも、この問題意識がある。

大規模な基幹更改を待たずに、現場の入力改善を「小さく・安く・早く」始められる仕組みを作りたかった。スマホでバーコードをスキャンするだけで棚卸ができる。OCRで賞味期限を読み取れる。これらは「本番前提の大規模開発」でなくても実現できることだ。

まず1店舗で動かしてみる。効果が出れば横展開する。うまくいかなければ修正する。この繰り返しが、現場のDXを着実に前進させると信じている。

技術は揃っている。あとは始めるだけ

現場改善に必要な技術は、もう十分に揃っている。スマートフォン、クラウド、OCR、API連携——どれも以前と比べ物にならないほど使いやすく、安価になっている。

足りないのは技術ではなく、「小さく始めることを許容する文化と仕組み」だ。失敗を恐れずに試せる環境を、現場に近いところで作ることが、DXを動かす最初の一歩になると思っている。