「このExcel業務、DX化してください」
このリクエストを受けたことがあるエンジニアは多いのではないでしょうか。しかし、いざ取り組んでみると想像以上に難航する。技術的には簡単そうなのに、なぜかプロジェクトが進まない。
本記事では、Excel DX化が困難な本質的な理由を3つの視点から分析します。
1️⃣ Excelが解決しているのは「表計算」ではない
Excelの真の役割
多くの人は「Excelは表計算ツール」と考えますが、実際の現場では全く違う使われ方をしています。
Excelが本当に解決しているもの:
複雑な業務ルールの即時実装
- 「A部門は5%割引、B部門は10%割引」のような細かいルール
- 「前月比◯%以上なら赤字表示」などの条件分岐
- これらを「今日中に実装」できてしまう
人手不足への対応
- IT部門に頼むと3ヶ月かかる
- 外注すると数百万円かかる
- でもExcelなら現場の「ちょっと詳しい人」が2時間で作れる
開発コストと時間の節約
- 正式なシステム開発: 要件定義→設計→開発→テスト = 数ヶ月〜数年
- Excel: 作りながら考える = 数時間〜数日
2️⃣ DXが進まない真の理由:三者三様の「合理的な拒否」
（1）ユーザー側の視点
「今、動いているのになぜ変える必要があるの?」
- 現状のExcelで業務は回っている
- 新しいシステムの操作を覚えるコストがかかる
- 移行期間中のトラブルリスクがある
- Excelは既に習熟している
この主張は感情的な抵抗ではなく、合理的な判断です。「学習コスト > 期待メリット」と感じている新システムが本当に便利になるという確証がない限り、現状維持が最も安全な選択肢になります。
（2）技術側の視点
「要件が全くわからない」
- 業務ルールがExcelの数式やマクロの中に埋め込まれている
- ドキュメントが存在しない(あっても古い)
- 「このセルが赤くなる条件」を聞いても、誰も正確に答えられない
excel=IF(VLOOKUP(A2,秘伝のマスタ!$A:$Z,15,FALSE)>INDIRECT("'前年度'!B"&ROW()*2+3)*(1+C$5),"要確認","")
このような数式が何百個もあるExcelファイルを、どうシステム化すればいいのでしょうか?
「仕様書がExcelそのもの」という絶望
- 「このExcelの通りに動けばいいです」と言われる
- でも、なぜこの計算式なのか、背景がわからない
- 特殊ケースの処理が山ほど隠れている
（3）組織側の視点
「成功しても誰も評価されない、失敗したら責任問題」
最も深刻なのは、組織のインセンティブ構造の問題です。
変えた場合のリスク:
- 移行失敗で業務が止まる → 大問題
- データ移行でミスが発生 → 責任追及
- 使いにくいと苦情が来る → 担当者の評価ダウン
変えなかった場合:
- 特に問題は起きない
- 「検討中です」で済む
- 誰も責任を問われない
この構造では、「何もしない」が最も合理的な選択になってしまいます。
3️⃣ では、どうすればいいのか?
完全な解決策はありませんが、以下のアプローチが有効です:
（1）「全面移行」ではなく「段階的共存」を目指す
- いきなり全てを置き換えようとしない
- ExcelとWebシステムを並行稼働させる期間を設ける
- 「どちらでも同じ結果が出る」状態を作る
（2） 業務ルールの「考古学」を行う
- Excelファイルを分析し、埋め込まれたルールを発掘する
- 数式を読み解き、ドキュメント化する
- 「なぜこうなっているか」を関係者にヒアリングする
（3） 組織のインセンティブ設計を変える
- DX推進を評価項目に入れる
- 小さな成功事例を積み重ね、リスクを下げる
- 「失敗しても責任を問わない」文化を作る(これが最も難しい)
（4） Excelの「良さ」を理解し、活かす
完全な「脱Excel」ではなく、**「活Excel」**の視点も重要です。
- データ入力はExcelで行い、処理だけシステム化
- レポート出力をExcel形式にする
- ExcelをUIとして使い、バックエンドだけシステム化
まとめ
「DX化Excel」が難しい理由は、技術的な問題ではありません。
Excelは組織の構造的問題を吸収している
関係者全員に「変えない理由」がある
組織のインセンティブが現状維持に傾いている
この本質を理解せずに技術だけで解決しようとしても、プロジェクトは進みません。必要なのは、技術選定の前に、組織と人間の問題を理解することです。
皆さんの職場では、どんな「Excel DX化」の取り組みをされていますか?