「神Excel」は、現場の悲鳴が結晶化したもの。――削除ボタンを押す前に「解読」せよ
情シス部門が「脱Excel」を掲げて、高価なSaaSや基幹システムを導入する。
しかし半年後、現場の実態を見てみるとどうでしょう。
新しいシステムの横で、以前と変わらず
「複雑怪奇なマクロが組まれた秘伝のExcel」が
こっそりと、しかし激しく稼働している――。
いわゆる「シャドーIT」の問題です。
多くのDX担当者は、これを
「現場の抵抗」
「リテラシー不足」
と捉え、Excelファイルの強制削除や利用禁止といった強硬手段に出がちです。
しかし、断言します。
そのExcelを、中身も見ずに削除してはいけません。
なぜなら、その歪な形をしたExcelファイルこそが、
システムが拾いきれなかった
「現場の悲鳴」が結晶化したものであり、
現状の業務を回すための「最も正確な仕様書」
だからです。
今回は、この「神Excel」を敵視するのではなく、
解読し、正しい構造へと書き換える
（そして最終的に削除する）
ためのアプローチについて考えます。
強制削除が招く「業務の崩壊」
なぜ、何度禁止しても「神Excel」は復活するのでしょうか。
それは、
現場がサボっているからでも、
新しいシステムが嫌いだからでもありません。
「そのExcelがないと、業務が回らない構造になっているから」です。
システムは「標準化」を求めますが、
現場の現実は「例外」と「微細なニュアンス」に満ちています。
「A社の請求書だけは、締め日の関係でこの項目をBに変える必要がある」
「システム上の在庫と実在庫にタイムラグがあるため、調整計算が必要だ」
「上長の承認をもらうために、特定のフォーマットで出力しなければならない」
こうした、
システム（正規のルート）に実装されていない「隙間」の機能を、
現場はExcelというパテを使って必死に埋めています。
この状況下で、Excelだけを取り上げればどうなるか。
現場は手足を縛られた状態になり、
ビジネスそのものが止まるか、
あるいは水面下で、もっと制御不能な
「裏マクロ」が量産されるだけの
イタチごっこに陥ります。
神Excelの正体 ＝「欠落した仕様の補完」
そう捉えると、
あの複雑怪奇なマクロの正体が見えてきます。
あれは、現場担当者が
「システムと現実のギャップ」をなんとか埋めようとして、
独学のVBAや関数を駆使して書き残した
「翻訳の痕跡」
なのです。
見るのも嫌になるほど複雑なそのコードには、
業務の例外処理
独自の承認フロー
データ加工ロジック
といった、
「本来システムが持つべきだったが、実装されなかった仕様」
がすべて記述されています。
つまり神Excelは、排除すべき敵ではなく、
現時点で唯一の「完全な業務仕様書」なのです。
「解読」して初めて、削除ができる
では、神Excelをこのまま放置して良いのかというと、
もちろん答えはNOです。
属人化のリスク、データ保全の観点から、
最終的には 削除（解消） できる構造にしなくてはなりません。
しかし、その手順が重要です。
「削除ボタン」を押す前に、やるべきことは一つ。
そのExcelを、徹底的に 「解読」 することです。
1. リスペクトを持って読む
「勝手なことをして」と叱るのではなく、
「よくぞここまで業務をシステム化してくれた」
と、その努力を認めることから始めます。
2. 機能を抽出する（翻訳）
Excelの中で何が行われているのか
（計算、分岐、転記）を分解し、
業務要件として定義し直します。
3. 正規ルートへ移植する
抽出した要件を、
本来あるべき基幹システムやSaaSの機能として
実装（構造化）します。
Excelが担っていた「機能」が
正規のシステムに完全に吸収されたとき、
現場は初めて、
「もう、このExcelは要らないですね」
と、自ら手放すことができます。
これこそが、
神Excelの正しい 「葬り方（成仏）」 です。
そのExcelを作った「翻訳者」を探せ
この「解読と移植」のプロセスにおいて、
鍵を握る人物がいます。
それは、
その「神Excelを作った本人」です。
彼らは、
業務の現場を知り尽くしており
それを（Excelとはいえ）ITロジックに落とし込む力を持っている
無自覚な
「業務設計者（アーキテクト）」
の原石かもしれません。
彼らを「シャドーITの犯人」として処罰するのではなく、
正規のプロジェクトメンバーとして巻き込みましょう。
彼らの持つ「現場の文脈」を、
正規の「システムの構造」へと
翻訳してもらうのです。
そうした人材をどう見つけ、どう育てるか。
それこそが、DXを成功させるための
「業務設計」の第一歩となります。
📚 関連記事・深堀り
神Excelを生み出してしまう構造や、
現場の言葉をシステムへ変換するスキルについて、
さらに詳しく知りたい方はこちらへ。
▼ なぜシステムと現場の間に「隙間」が生まれるのか？（定義）
👉 『#業務設計者論｜業務でもITでもない、しくみの“スキマ”に立つ』
▼ 現場の文脈を、ITの言葉へ変換するスキルについて（翻訳）
👉 『#業務設計者論｜翻訳者はしくみの言葉を編む』
▼ 「神Excel」の作者のような、名前のない職能について（人材論）
👉 『#業務設計者論｜名前のない職能に輪郭を与える』