脱Excel・業務のシステム化はなぜ進まないのか？移行の選択肢4つと進め方・費用【2026年版】

執筆：Swooo編集部／監修：諸藤 哲耀（株式会社アイビス Swooo）

「この業務、そろそろExcelでは限界だ」と分かっている。それでも移行が進まない。脱Excelを検討する企業の多くが直面しているのは、ツール選びの問題ではなく、この「分かっているのに動けない」状態そのものです。実際、キーマンズネットの2025年調査（回答330人）では、Excelマクロ（VBA）を代替ツールに置き換えることに「対応できない」と答えた人が65.8%にのぼります。

本記事は、Excel・Access・VBAで回っている業務のシステム化を検討する情報システム部門・経営企画・業務部門の責任者の方に向けて書いています。特定のツールをおすすめする記事ではありません。
Excel運用の限界がどこから来るのかを構造的に整理し、移行できない組織的な理由を一次データで確認したうえで、SaaS・ノーコード・個別開発・AIによる自動化という4つの選択肢の使い分け、進め方の5ステップ、費用相場、典型的な失敗パターンまでを1本にまとめました。

自社の状況に近い章から読み進めてください。

Excel運用の限界はどこから来るのか：3つの構造的な原因

Excelは業務ツールとして非常に優秀です。だからこそ、本来はデータベースやワークフローで扱うべき業務までExcelで組まれ、そのまま何年も使われ続けます。限界は突然来るのではなく、次の3つの構造から徐々に進行します。

原因1：属人化 — 「作った人しか直せない」ファイルが業務の中枢になる

複雑な関数のネスト、シート間の参照、そしてVBAマクロ。Excelは作り込むほど、その中身を理解している人が作者本人だけになっていきます。
業務ロジックがドキュメントではなくマクロのコードの中にしか存在しない状態になると、作者の異動・退職と同時に、そのファイルは「動いてはいるが誰も触れないブラックボックス」に変わります。

この構造は、経済産業省とIPAが2025年5月28日に公表したレガシーシステムモダン化委員会の総括レポート「DXの現在地とレガシーシステム脱却に向けて」が整理した、レガシーシステムの構造的課題とちょうど同じ形をしています。同レポートは、レガシーシステムの課題として「技術の老朽化（対応できる技術者の高齢化・離脱）」「システムの肥大化・複雑化」「システムのブラックボックス化」などを挙げ、ブラックボックス化については「システムの運用維持保守が属人的な状態に陥っている」「障害発生時に原因がすぐに特定できない」状態と定義しています。

なお、このレポート自体はメインフレームなど基幹系の大規模レガシーシステムを主な対象としたもので、ExcelやVBAに直接言及したものではありません。ただし「業務を支える仕組みの中身を、特定の個人しか説明できない」という構造的リスクの定義は、部門の基幹業務を支えるExcelマクロにそのまま当てはまります。規模が違うだけで、放置したときに行き着く先は同じです。

原因2：同時編集とバージョン管理 — 「どれが最新か分からない」ファイルの増殖

Excelファイルはコピーが自由にできます。これは便利さの源泉であると同時に、業務データの管理としては致命的な弱点です。
「売上管理_2026_v3_最新_修正済.xlsx」のようなファイルが共有フォルダに並び、誰かが古い版を更新してしまい、突合と修正に半日かかる。メール添付で送られた版と共有フォルダの版が食い違う。こうした事象は、運用ルールの徹底で防ぐものではなく、「データの正本が1か所に存在しない」という構造の問題です。

クラウド版の共同編集である程度は緩和できますが、行単位の権限制御、変更履歴の監査、入力値の検証といったデータベースなら標準で備わる機能は、Excelの設計思想の外側にあります。利用者と更新頻度が増えるほど、この差が事故の確率として表面化します。

原因3：データの分散 — 集計・突合が永遠に手作業のまま残る

部署ごと、担当者ごと、取引先ごとにファイルが分かれていると、全体像を見るためには必ず「集める・転記する・突合する」という手作業が発生します。この作業は毎月・毎週発生し続けるうえ、転記のたびにミスの機会が生まれます。

典型例が、建設業の工事台帳です。協力会社ごとに帳票の書式がバラバラなため手入力がなくならず、台帳が属人化して担当者の退職と同時に業務が止まり、粗利は月次の集計を待たないと見えないため赤字案件の発覚が遅れる——という構造は、Excel台帳運用の限界が最も分かりやすく現れるケースです。詳細は建設業の工事台帳・原価管理DXの解説記事で実例とともに扱っています。

システム化を検討すべきサイン

3つの原因を踏まえると、「Excelのままでよい業務」と「システム化を検討すべき業務」の境界線は次のように整理できます。

• 複数人・複数部署が同じデータを更新している（正本が1つでないと事故が起きる）
• 特定の個人しか中身を説明できないマクロ・関数がある（属人化が既に始まっている）
• 毎月・毎週、転記や突合の手作業が定常的に発生している（データ分散のコストを払い続けている）
• 入力ミス・版の取り違えによる手戻りが四半期に一度以上起きている（構造的な事故が常態化している）

逆に、個人の試算・分析・一時的な集計は、今後もExcelが最適な領域です。脱Excelとは「Excelを全廃すること」ではなく、複数人で共有する業務データをExcelの外に出し、Excelを個人の分析ツールという本来の役割に戻すことだと捉えるのが現実的です。

「わかっているのに移行できない」のはなぜか：データで見る組織的背景

限界のサインに心当たりがあっても、移行はなかなか進みません。これは意思の弱さではなく、データで確認できる構造的な現象です。

VBAを代替できない：65.8%という数字

キーマンズネット（ITmedia）が2025年6月13日〜25日に実施したExcel利用実態調査（回答330人）から、主要な数字を引用します。

出典：キーマンズネット「マクロ地獄、属人化を覚悟しても『使うしかない』Excel利用現場の課題【2025年調査】」（2025年、n=330）

注目すべきは65.8%という数字の意味です。BIツールもクラウドアプリも普及した2025年時点の調査で、3人に2人が「それでもVBAは置き換えられない」と答えています。足りないのはツールではありません。同調査では、マクロが分かる人が退職して誰も触れなくなった、といった現場の声も紹介されており、業務ロジックがVBAの中に埋まったまま、それを読み解いて移し替えられる人がいない——という人と知識の問題であることが分かります。

移行を止める3つの組織的背景

実際の検討現場で移行を止めるのは、技術ではなく次の3つです。

①Excelは「無料に見える」ため、費用対効果の比較が成立しにくい。
Excel運用のコストは、転記の工数・ミスの手戻り・属人化のリスクという形で薄く広く発生しており、会計上はどこにも計上されません。一方、システム化には数百万円単位の見積もりが出ます。「ゼロ円 対 数百万円」に見える比較の中で、移行の意思決定は構造的に不利です。先述のIPA・経産省レポートも、レガシー脱却が進まない要因として「IT投資がコストとみなされ予算が確保されない」ことを挙げています。

②要件を書き出せる人がいない。
システム化の第一歩は「現在の業務ルールを言語化すること」ですが、そのルールはマクロのコードと担当者の頭の中にしか存在しないことが多い。業務を知る人はITの言葉を持たず、ITを知る人は業務の詳細を知らない。この分断があると、ベンダーに相談しても要件が固まらず、見積もりの幅だけが広がって話が止まります。

③現場は「今のやり方で回っている」。
限界のサインが出ていても、現場の担当者にとっては慣れたExcelが最速の道具です。移行直後は必ず一時的に生産性が下がるため、移行の便益を受ける層（管理側・経営側）と、移行の負担を負う層（入力する現場）が一致しない。IPA・経産省レポートが「古い制度・しがらみ」「現場の抵抗」を構造的課題に数えているのは、基幹システムに限らずこの種の移行全般に共通する力学だからです。

この3つはいずれも「もっと良いツールを探す」ことでは解決しません。後述する進め方（5ステップ）は、この3つを順に外していく手順として設計しています。

VBA・Accessの技術的な現在地：「終了する」は誤り、「細っていく」が正確

脱Excel・脱Accessの文脈では「VBAはもうすぐ終わる」という言説を見かけますが、2026年7月時点の事実関係は次のとおりです。移行の社内説明に使う場合は、正確な区別が信頼性を左右します。

出典：VBScriptの段階的無効化はImpress Watchの報道（Microsoftの発表に基づく）。VBAの継続利用はMicrosoft Q&Aを参照。

つまり、「VBAが終了するから今すぐ移行が必要」という説明は事実に反します。一方で、次の3点は事実であり、こちらが移行を検討する本当の理由になります。

• 周辺技術は確実に縮小している：VBScriptの2027年頃のデフォルト無効化のように、VBA資産が依存してきた周辺環境は段階的に整理されつつあり、VBScriptに依存する処理は動作しなくなる可能性があります
• 担い手は減り続けている：前章のとおり、VBAを代替できない人が65.8%という状況は、裏を返せば「VBAを読み解ける人材の新規供給がない」ということです。Microsoftの新しい自動化投資もクラウド側（Office Scriptsなど）に向いています
• 放置期間が長いほど移行コストは上がる：ロジックを説明できる人が社内にいるうちなら、要件の言語化は数週間で済みます。退職後にコードから復元するとなると、調査だけで別途の工数と費用がかかります

社内説明の論拠としては、「期限が来るから」ではなく「保守できる人と周辺環境が細り続けており、待つほど移行の難易度と費用が上がるから」が正確です。期限型の説明は、期限が来なかったときに検討自体の信頼を失います。

移行先の選択肢は4つ：SaaS・ノーコード・個別開発・AIによる自動化

脱Excelの移行先は、大きく4つに分類できます。それぞれに明確な得意領域があり、どれが優れているかではなく、対象業務の性質で使い分けるのが正しい選び方です。1社の中で複数を併用するのも普通です。

①SaaS：標準的な業務なら最速・最安の選択肢

顧客管理・案件管理・在庫管理のように業務の型が業界で標準化されている領域は、kintoneをはじめとする業務アプリ基盤や専用SaaSが最も速く、初期費用も小さく済みます。月額のユーザー課金で始められ、保守もベンダー側が担うため、この領域でノーコードや個別開発を選ぶ理由はほとんどありません。

判断の分かれ目は「業務をツールの型に合わせられるか」です。SaaSの標準機能に業務を寄せられるなら最適解ですが、自社固有のフローを再現するためにカスタマイズやプラグインを重ね始めると、費用と保守の複雑さが増していき、ある地点から個別開発と大差ない負担になります。カスタマイズ要件が最初から多いと分かっている場合は、②③と並べて総保有コストで比較する方が安全です。

②ノーコード・ローコード開発：固有業務を現実的な費用でシステム化する

「SaaSの型には収まらないが、フルスクラッチほどの投資は正当化できない」という中間帯の業務が、ノーコード・ローコード開発の主戦場です。Excel台帳からの置き換えで言えば、案件・工程・原価のように自社の商流に固有の構造を持つデータ管理がこの帯に入ることが多く、開発期間もスクラッチより短く収まります。

制約は、プラットフォームの機能の枠内で作ることと、大量データや特殊な外部連携に弱い場合があることです。将来の拡張計画（利用者数・データ量・連携先）を先に見積もったうえで、枠内に収まるかを確認してから選ぶ必要があります。

③個別開発：基幹業務・複数部署・内部統制が絡むなら本命

複数部署が同じデータを異なる権限で扱う、既存の基幹システム・会計システムと接続する、監査に耐える変更履歴が要る——こうした要件が重なる業務は、個別開発が本命になります。Excel・Accessで長年育った部門基幹業務の移行は、実態としては小型の基幹システム再構築です。進め方の考え方は基幹システム再構築の解説記事が参考になります。

なお、近年はコーディングAIの進歩で個別開発の生産性が変わりつつあり、「外注せず自社で開発を担う」選択肢のハードルも下がっています。内製を含めて検討したい場合はシステム開発の内製化ガイドを参照してください。

④AIによる自動化：「Excelを捨てられない理由」ごと処理する

4つめは、Excel運用が残ってしまう原因そのものをAIで処理するアプローチです。たとえば取引先ごとに書式の違う帳票が届くために手入力がなくならない業務では、書式の統一を全取引先に求めるのは現実的でありません。ここでAIに帳票の読み取り・解釈・転記をさせ、人は確認に回る形にすると、書式バラバラという「システム化を阻んできた前提」を変えずに手作業を減らせます。建設業の工事台帳でこの形を採った開発例を工事台帳・原価管理DXの記事で紹介しています。

注意点は、AIはあくまで入力・変換の自動化であり、データの正本をどこに置くかという設計は①〜③のいずれかで別途必要になることです。実務では「入口の自動化はAI、データの置き場はノーコードまたは個別開発」という組み合わせになることが多く、独立した選択肢というより②③に組み込む部品と考えると位置づけを誤りません。

4つを選び分ける判断軸

選択肢を1つに絞るための判断軸は、実務では次の4つに集約されます。

1. 業務の標準性：他社と同じ型で回る業務か（→SaaS）、自社固有の構造か（→ノーコード・個別開発）
2. データ量と利用者数：数万件規模のデータ・数十人以上の同時利用が見えるなら、プラットフォームの上限を先に確認する
3. 既存システムとの接続：会計・基幹・外部サービスとのAPI連携が必須なら、その連携実績を軸にベンダー・手法を選ぶ
4. 内部統制・監査要件：権限制御・変更履歴・ログの要件が厳格なら、SaaSの標準機能で満たせるかを最初に確認し、満たせなければ個別開発に寄せる

移行の進め方5ステップ：全部を一度にやらない

脱Excelの失敗の多くは、手順の前後を間違えることから生まれます。ツール選定から入るのではなく、次の順序で進めます。全体を貫く原則は「全部を一度にやらない」です。

ステップ1：現行Excelの棚卸し（2〜4週間）

最初にやるべきは、ツールの比較ではなく現状の一覧化です。対象部門の業務で使われているExcel・Accessファイルを洗い出し、次の項目を表にします。

• ファイル名・置き場所・用途（何の業務のどの工程か）
• 更新者と更新頻度（誰が・どのくらいの頻度で入力するか）
• マクロ・複雑な関数の有無と、その中身を説明できる人の名前
• 他のファイル・システムとのデータの受け渡し（転記元・転記先）

この棚卸し表は、後のベンダー相談・見積もり取得でそのまま要件資料の土台になります。「説明できる人の名前」の列が空欄になるファイルこそ、属人化が最も進んだ危険箇所であり、優先順位づけの重要な材料です。Accessの場合はテーブル・クエリ・フォーム・レポート・VBAの5要素で構造を書き出しておくと、移行方式の判断が速くなります。

ステップ2：対象業務の優先順位づけ

棚卸し結果から、最初に移行する業務を1つだけ選びます。選定基準は「痛みが大きい」かつ「範囲が閉じている」ことです。
複数部署をまたぐ最重要業務から着手したくなりますが、最初の1件は組織がシステム化の経験を積むための題材でもあります。関係者が少なく、成果が測りやすく、失敗しても撤退できる業務から始め、2件目以降で本丸に向かう方が結果的に速く進みます。

ステップ3：移行方式の選定と業務ルールの言語化

選んだ業務を前章の4つの選択肢に当てはめ、方式を決めます。このとき並行して必ずやるべきなのが、マクロと担当者の頭の中にある業務ルールの言語化です。「この列の値がこうなったら、この処理をする」というルールを、コードが読める人と業務担当者が同席して書き出します。

重要な心構えとして、現行Excelの動きを100%再現することを要件にしないでください。長年の運用で積もった「誰も使っていない列」「例外の例外処理」まで移すと、費用が膨らむうえに新システムが最初から複雑になります。棚卸しの時点で「実際に使われているルール」だけを選別するのが、見積もりを適正に保つ最大のポイントです。

ステップ4：小さく作って並行運用する

最初のリリースは、対象業務の中でも中核のデータフロー1本に絞ります。リリース後は一定期間、旧Excelと新システムの並行運用期間を設け、数字の突合で新システムの正しさを検証しながら、現場の入力負担・画面の使い勝手を改善します。
この期間の改善スピードが、現場の受け入れを決めます。「要望を出したら翌週直っていた」という体験が数回あるだけで、現場の態度は変わります。

ステップ5：Excelの出口を決める（入力の一本化）

最後のステップが、実は最も省略されがちです。並行運用の検証が済んだら、旧Excelファイルを参照専用に切り替え、入力の窓口を新システムに一本化する日を明確に決めて実行します。ここを曖昧にすると、二重入力が恒常化し、やがて楽な方＝Excelに全員が戻ります。旧ファイルは削除せず、読み取り専用のアーカイブとして保管すれば、過去データの参照と監査対応には十分です。

費用相場：市場の一般的な目安

脱Excelのシステム化にかかる費用は、選択肢と規模で大きく変わります。以下は他社を含む市場の一般的な目安であり、個別の見積もりを約束するものではありません。

手法別の初期開発費

業務管理システムの規模感

Excel台帳の置き換えで最も多い「業務管理システム」に絞ると、目安は次のとおりです。

このほか、要件定義は全体の10〜15%（スクラッチで単独工程として発注する場合は50万〜200万円）、リリース後の保守はノーコードで月3万〜20万円、スクラッチで月10万〜100万円が目安です。

見積もりの幅を狭めるのは発注側の準備

同じ業務でも、見積もりには数倍の幅が出ます。幅を生む最大の要因は、現行業務のルールがどれだけ言語化されているかです。ステップ1の棚卸し表とステップ3のルール書き出しができていれば、ベンダーは調査工数を積む必要がなくなり、見積もりは精度が上がって金額も下がる方向に働きます。マクロの中身を誰も説明できないまま複数社に見積もりを依頼し、各社の金額がバラバラで比較できなくなった、という相談が典型的です。

よくある失敗パターン4つ

受託開発の現場で実際にご相談いただく内容から、脱Excelプロジェクトの典型的な失敗パターンを4つ挙げます。いずれも技術ではなく、進め方の設計で防げるものです。

失敗1：システムを入れたのに、現場がExcelに戻ってしまう

最も多いパターンです。数百万円かけてシステムを構築したのに、半年後には現場が使い慣れたExcelに戻り、システムには古いデータだけが残っている、という相談が典型的です。
原因はほぼ共通で、①入力がExcel時代より面倒になった、②並行運用の期限を切らず二重入力が続いた、③現場の要望が改善に反映されなかった、の3つです。対策はステップ4〜5そのもの——リリース後の改善を高速に回し、入力一本化の日を明確に決めて実行することに尽きます。

失敗2：現行Excelの完全再現を要件にして、費用と期間が膨らむ

「今のExcelでできることは全部できるように」という要件は、一見安全に思えて最も危険です。長年の運用で積もった例外処理まで全て新システムに移すと、開発規模が膨らむだけでなく、初日から複雑で使いにくいシステムが出来上がります。実際に使われているルールの選別（ステップ3）を省略した案件で起こりがちです。

失敗3：ツール選定から入って、業務の言語化を後回しにする

「kintoneにするか個別開発にするか」という手段の議論が先行し、肝心の業務ルールが誰にも書き出せていない状態で導入が始まるパターンです。どのツールを選んでも、業務ルールの言語化という工程は消えません。先に言語化が済んでいれば手段の選定は数週間で終わりますが、逆順だと導入後に「この業務はこのツールに載らない」と判明してやり直しになります。

失敗4：一斉移行で全部門を巻き込み、身動きが取れなくなる

経営主導で「全社の脱Excel」を掲げ、複数部門の業務を一度にシステム化しようとするパターンです。関係者が増えるほど要件調整は指数的に重くなり、最初のリリースまでの期間が延び、その間に推進の熱が冷めます。方向づけは全社で掲げつつ、実行は1業務ずつ——という二段構えが、遠回りに見えて確実です。

よくある質問

Q. Excelのままではだめですか？　全部システム化する必要がありますか？

全部をシステム化する必要はありません。個人の試算・分析・一時的な集計は今後もExcelが最適です。システム化を検討すべきなのは、複数人・複数部署が同じデータを更新している、特定の個人しか中身を説明できないマクロがある、転記・突合の手作業が定常化している、のいずれかに当てはまる業務に限られます。脱Excelとは、共有すべき業務データをExcelの外に出し、Excelを個人の分析ツールという本来の役割に戻すことです。

Q. VBAはいつまで使えますか？　もう終わると聞きました。

2026年7月時点で、VBAの廃止・サポート終了に関するMicrosoftの公式発表はなく、デスクトップ版Officeでは引き続き利用できます。「VBA終了」という言説は正確ではありません。ただし、別技術であるVBScriptは2027年頃にデフォルト無効化の予定が公表されており、VBScriptに依存する処理は影響を受けます。また、VBAを扱える人材の減少は調査データにも表れており（代替に対応できない65.8%）、期限ではなく保守体制の観点で移行を計画するのが正確な判断です。

Q. Accessで作った業務システムの移行先はどう選べばよいですか？

まずテーブル・クエリ・フォーム・レポート・VBAの5要素で現状を棚卸しし、データ構造と業務ルールを書き出します。移行先は本文の4分類と同じで、標準的な業務ならSaaS、自社固有のフローならノーコード・ローコードか個別開発が候補です。Accessは同時利用・権限管理・拡張性が課題になりやすいため、利用者数とデータ量の今後の見通しを先に固めてから方式を選ぶと、選定を誤りにくくなります。

Q. 費用はどのくらい見ておけばよいですか？

市場の一般的な目安として、Excel台帳の置き換えに多い業務管理システムで、ノーコード開発なら50万〜200万円、スクラッチ開発なら500万〜1,000万円です。SaaSの標準機能に業務を寄せられる場合は、初期費用を抑えて月額課金で始められます。これに加えて保守費（ノーコード月3万〜20万円、スクラッチ月10万〜100万円）を見込んでください。見積もりの幅は発注側の準備で大きく変わり、業務ルールの言語化ができているほど適正な金額に収束します。

Q. どのくらいの期間がかかりますか？

最初の1業務であれば、棚卸しに2〜4週間、業務ルールの言語化と方式選定に2〜4週間、開発と並行運用を含めて全体で3〜6ヶ月が一般的な目安です。期間を左右する最大の変数は開発そのものではなく、業務ルールを説明できる人の確保と、関係者の合意形成です。対象を1業務に絞るほど期間は短く、確実になります。

まとめ：脱Excelは「ツール選び」ではなく「業務の言語化」から始まる

本記事の要点を整理します。

• Excel運用の限界は属人化・バージョン管理・データ分散の3つの構造から進行する。経産省・IPAのレガシーシステムレポートが定義する「属人化・ブラックボックス化」と同じ形が、部門のExcelマクロでも起きる
• 移行が進まないのはツール不足ではない。VBAを代替できない人が65.8%（キーマンズネット2025年調査・n=330）という人と知識の問題であり、費用対効果の見えにくさ・要件を書き出せる人の不在・現場の慣性という3つの組織的背景がある
• 「VBA終了」は公式発表のない不正確な言説。正確な移行理由は「保守できる人と周辺環境（VBScriptは2027年頃デフォルト無効化予定）が細り続け、待つほど移行コストが上がる」こと
• 移行先はSaaS・ノーコード・個別開発・AIによる自動化の4つ。優劣ではなく業務の標準性・データ量・接続要件・統制要件で使い分ける
• 進め方は棚卸し→優先順位づけ→言語化と方式選定→小さく作って並行運用→入力の一本化、の5ステップ。全部を一度にやらないことと、Excelの出口を明確に決めることが失敗を防ぐ

本メディアを運営するSwooo（東証グロース上場・株式会社アイビスの開発サービス）は、ノーコードとAI駆動開発を組み合わせた受託開発で累計50件以上の支援実績があります。Excel台帳の置き換えのような業務システム開発では、現行Excelの棚卸しと業務ルールの言語化から支援に入り、書式がバラバラな帳票をAIで読み取る構成（工事台帳アシストAIの開発例）まで、SaaS・ノーコード・個別開発の使い分けを含めて設計します。業務のシステム化を起点に、社外向けサービスとしての展開まで視野に入れる場合は新規事業開発の支援プランで対応しています。

「どのExcelから手をつけるべきか」の整理からで構いません。対象業務の概要と現在の運用状況を添えてご相談ください。