地方DXで失敗する9割の共通点。「前捌き」という業務構造の切り方。

【定義】一文で言い切る

前捌きとは、システムやツールを導入する前に、業務の構造を整理・可視化することです。

DXや業務改善の文脈で「前捌き」という言葉を使うと、こう返ってくることがあります。

「要件定義のことですか？」「ヒアリングのことですか？」

違います。もっと泥臭い話です。

現場に入って、誰が何を、どんな順番で、どんな判断をしながらやっているかを、自分の目で確認すること。そして「この業務、本当にこの順番でやる必要があるのか」を問い直すこと。

それが前捌きです。

ツールが好きな人は、現場を見るより先にツールを考えます。

「ここはVBAで自動化できる」「ここはRPAで自動化できる」「ここは——」

できる人がいると、ツールはどんどん積み上がっていきます。しかし現場は楽になるどころか、ツールの保守と運用で疲弊していく。

なぜか。前捌きをせずにツールを入れたからです。

以前、ある大手企業のBPO案件でこういう現場がありました。

特殊機材の手配業務を担うチームで、ミスが頻発していました。担当者は疲弊し、クライアントの管理者は矢継ぎ早にツールの投入をリクエストしていました。VBA、RPA——次々と開発され、現場に投入されていった。

しかし、シナリオにブラウザ参照が含まれていると、RPA（Winactor）はWebDriver更新のたびに止まります。止まるたびに改修する。改修してもまた止まる。その繰り返しでSVが体調を崩すという事態にまで発展しました。

「ツールのコードやシナリオをちゃんと確認しろ」という声が上がり、私がインスペクターとして現場に入ることになりました。

事前にコードとシナリオを確認し、二日間現場を視察しました。戻って二日間でレポートを書きました。

レポートの結論はこうです。

ツールそのものに大きな問題はない。むしろよくできている。スクリプト編集の履歴も丁寧に記録されており、使う人への配慮が随所に感じられる設計で、スキルは本物でした。問題は一度も、そのSVにはなかった。

問題はツールの使い方と、それ以前の業務構造にある。

具体的には三つでした。

センター・営業・パートナー企業の連携がすべてメールで行われており、誰も読んでいない状態になっていた。そのアラートメール作成や、基幹システムと発送システムの橋渡しにRPAを使っているのは明らかなミスマッチです。RPAの強みはそこではありません。

MS365を使っているのにタスク管理がメールで完結しようとしていた。PlannerやTeamsを使えば解決できる話でした。

そして最大の問題。基幹システムから直接手配が連携できていないことで、幾重にも手作業が重なっていた。これが手配ミス頻発の本当の元凶でした。ここに資源を集中すべきでした。

場合によっては「体制批判」とも捉えかねられないこのレポートは、意外なほど高く評価されました。その後、メール連絡の削減と基幹システム改修へと舵が切られました。

構造で切って、言い切った。それが刺さったようです。

ツールは悪くない。RPAもVBAも、正しい場所に使えば強力な武器です。

しかし正しい場所を見極めるには、前捌きが必要です。業務の構造を整理せずにツールを入れても、歪んだ構造の上に技術を積み上げるだけです。

AIやRPAを壊れた構造の上に載せると、壊れた構造を高速化するだけです。

前捌きは地味です。時間もかかります。しかしこれをやらずにDXを進めることは、土台のない家を建てることと同じです。

ツールより先に、構造を切る。それが前捌きです。