ExcelをDXの入り口にする：捨てずに共存しながらデジタル化を進める方法

なぜExcelを捨てられないのか

DXの文脈で「Excelをやめましょう」という言葉をよく耳にします。しかし現場に入ってみると、話はそう単純ではありません。Excelは20年以上にわたって日本の業務を支えてきた実績があり、使い慣れたUIで複雑な計算式を組み、自由なレイアウトで帳票を作れるという強みは本物です。

問題は「Excelが悪い」のではなく、「Excelが本来の用途を超えて使われている」ことにあります。データベースの代わりとして使う、ワークフロー管理システムの代わりとして使う、そして複数人が同じファイルをメールで送り合うという運用が、DXの障壁を生んでいます。Excelそのものではなく、その使われ方を変えることが出発点です。

筆者が関わってきた多くのDXプロジェクトで共通して言えるのは、「ExcelをすべてSaaSに置き換える」というアプローチは失敗しやすく、「ExcelをDXの入り口として活用する」というアプローチが成功しやすいということです。

Excel運用の問題を構造で整理する

まずは現状の何が問題なのかを正確に把握しましょう。Excelを使った業務の課題は、大きく三つの層に分けて考えるとわかりやすくなります。

データ層の問題は、データが人ごとのファイルに分散している、入力ミスや表記ゆれがあっても気づきにくい、バージョン管理ができず「最新版がどれかわからない」という状態が典型です。

プロセス層の問題は、誰がいつ何を承認したのかがメールの山に埋もれている、担当者が休むと作業が止まる、引き継ぎのたびに属人知識が失われるという問題です。

可視化・分析層の問題は、集計のたびに手作業が発生する、リアルタイムで状況が把握できない、経営層への報告資料を毎回手で作り直しているという問題です。

この三層のうち、どこに最も大きなボトルネックがあるかを先に特定することが、効果的なDX施策の第一歩です。すべてを一気に解決しようとするより、一層ずつ改善するほうが現実的です。

Excelと共存するDXのアーキテクチャ

データ層：Excelをデータ入力端末として割り切る

Excelをデータベースとして使うことをやめ、「データ入力の窓口」として割り切るという考え方があります。具体的には、Excelで入力されたデータを自動的にクラウドデータベースに送り込む仕組みを作ります。

Microsoft 365環境であれば、Power AutomateとSharePointの組み合わせが最初の一手として有効です。ExcelファイルをSharePointに保存し、特定の列が更新されたらPower AutomateがSharePointリストやDataverseにデータを書き込む、というフローはノーコードで実現できます。現場のExcel運用を変えずに、バックエンドだけをクラウド化できるのが利点です。

Google Workspace環境ならGoogle Apps Script（GAS）を使う方法があります。スプレッドシートに入力されたデータをスクリプトでBigQueryやFirestoreに送るほか、外部APIと連携して自動でデータを取得・更新することも可能です。GASはJavaScriptベースなので、エンジニアであれば比較的学習コストが低く取り組めます。

プロセス層：承認フローをシステムに乗せる

承認フローのメール運用は、Excelそのものではなくメールというチャネルの問題です。ここはExcelをいじるのではなく、フォームとワークフローツールを使って切り替えます。

Microsoft Forms + Power Automateや、Google Forms + GAS + Chatなどで、申請→通知→承認→記録という一連のフローを自動化できます。Excelへの入力は残しつつ、承認プロセスだけを別のシステムに分離するというハイブリッドな構成も十分機能します。

たとえば「Excelで作成した発注書の内容をフォームでシステムに登録し、承認が完了したらSlackに通知が届く」という運用は、現場のExcel作業をほぼ変えることなく、ワークフローの透明性と追跡可能性を大きく改善します。

可視化・分析層：レポートを自動生成する

集計・レポート作業を自動化するのが、最も即効性のある改善の一つです。Excelでの手作業集計をやめ、BIツールに接続することで、データが更新されるたびにレポートが自動で最新化される状態を作れます。

Microsoft 365環境ではPower BIが自然な選択肢です。ExcelファイルやSharePointリストをデータソースとして接続し、ダッシュボードを作れます。Google Workspace環境ではLooker Studio（旧Data Studio）が同様の役割を担います。どちらも無料で使い始められる点が魅力です。

移行の現実的なステップ

Excelとの共存を前提にしたDX推進は、一気に全部変えようとするのではなく、段階的に進めることが成功の鍵です。以下のようなステップで考えると整理しやすくなります。

このステップを一つの業務・部署に絞って試行し、成功体験を作ってから横展開するというアプローチが現実的です。全社一斉移行は調整コストが大きく、現場の反発も起きやすいため、パイロットプロジェクト型で進めることをおすすめします。

現場エンジニアが意識すべきポイント

「なぜExcelを使っているか」を必ず聞く

技術的に優れたシステムを作っても、使われなければ意味がありません。現場の人がExcelを使っている理由には、「自由にレイアウトを変えられる」「オフラインでも使える」「印刷しやすい」といった、合理的な背景が必ずあります。その理由を無視してシステムを押し付けると、必ず「シャドーIT」としてExcelが生き残ります。

導入したツールが本当に定着するかどうかは、設計の巧みさよりも、現場の不満や要望をどれだけ事前に拾えたかで決まります。ヒアリングと小さなプロトタイプを繰り返すアジャイルな進め方が、Excelとの共存期においては特に有効です。

データの「入口」と「出口」を統一する

複数のExcelファイルに同じデータが散らばっている状態は、どんな優れたツールを導入しても解消されません。「このデータはここにしかない」という状態を作ることが、データ品質向上の基本原則です。

入力経路を一本化し、そこから必要な形式にデータを変換・配信するという「シングルソースオブトゥルース」の考え方を、システム設計の段階から組み込んでおくと、後工程が劇的に楽になります。

マクロ・VBAの扱いに注意する

長年使われてきたExcelには、複雑なVBAマクロが組まれていることがよくあります。このマクロをそのままにしてシステム移行を進めると、「Excelのマクロが動かなくなった」というトラブルが後から噴出します。

VBAマクロの棚卸しは、DX推進の初期に必ず行いましょう。重要なロジックが埋まっている場合は、Python・JavaScript等で同等の処理を書き直してAPIやバッチ処理として切り出すことを検討してください。Excelへの依存度を下げながら、ビジネスロジックを安全に引き継ぐことが目標です。

まとめ：Excelは「敵」ではなく「出発点」

DXを進めるうえでExcelを否定する必要はありません。むしろ、Excelが現場に根付いている事実は、データを扱う素地がすでにあるということでもあります。その素地を活かしながら、データの流れを整理し、自動化できる部分を少しずつシステム化していくことが、持続可能なDXの姿です。

一度に全部変えようとするのではなく、一つの課題に絞って成功体験を積み、少しずつ範囲を広げていく。それがエンジニアとして現場のDXを支える際の、最も現実的で確かなアプローチだと筆者は考えています。