Access代替ツールの選び方｜移行の手順と「作った人がもういない」問題への備え

長年の運用や担当者の個別開発によって積み上がった大量の画面、クエリ、VBAマクロのうち、現場で日常的に使われている機能はほんの一部に過ぎないケースも多いでしょう。使われていない機能や過去のテスト用プログラムまで解読して新システムへ移植しようとすれば、無駄な開発工数が発生するだけでなく、システムの設計自体が複雑化して保守性を損ねる原因となります。

したがって代替ツールを探す際に最初に実施すべき取り組みは、製品のスペック比較やツールの選定ではなく、現行資産の棚卸しと使われている機能の仕分けです。

移行プロジェクトにおいて避けたい決定的な失敗は、以下の2点です。

1. 現行機能の完全再現を前提に見積もり、膨大な費用と期間がネックとなって計画が途中で頓挫すること
2. VBAマクロなどの仕様やロジックが分からないまま手探りで移行を進め、本番切り替え後に業務停止などトラブルを引き起こすこと

現行システムをそのまま新ツールへ移植する発想を捨て、現場の業務に必須の機能だけを厳選して移行させる割り切った判断こそが、トラブルを回避しプロジェクトを成功へ導く重要な条件となります。

動作環境と保守に関する事情

1つ目は、IT環境の変化に伴う動作環境と保守の制約です。

• クライアント環境の更新：
  WindowsやOfficeのアップデートに伴い、過去のVBAマクロが予期せぬエラーを起こすリスクと隣り合わせになります。サポート期限や互換性要件については提供元の公式情報を事前に確認することが不可欠です。
•  
• 共有ファイル運用での同時アクセスの限界：
  共有フォルダ上のAccessファイルへ複数人が同時にアクセスすると、ロック競合だけでなく、データベースの破損が頻繁に発生することもあります。
•  
• リモートワークとの相性の悪さ：
  社内LAN環境を前提とした設計であるため、在宅勤務や外出先からの安全かつ高速なアクセスに対応できません。
•  
• ライセンスと配布の管理コスト：
  端末ごとのAccessライセンス管理や実行環境の配布・更新作業が情報システム部門の負担となります。

「作った人がもういない」という事情

2つ目は、現場主導の追加開発が裏目に出る組織的な事情です。

弊社が実施したITシステムに関する調査結果（出典：レガシーシステムの実態調査）を確認すると、ドキュメントと実態について「ほぼ完全に乖離している」または「存在しない」と回答した企業が49.5%にのぼります。さらに「ベテラン社員の退職によってシステムが回らなくなるリスクを認識している」と回答した企業は75.4%（情シス実務担当者221名対象）に達しています。

個人の裁量でVBAや複雑なクエリが組み込まれ、仕様書が作成されないまま担当者が異動・退職する構造が原因です。技術的な限界を迎えるより前に、担当者の不在という組織的リスクによって移行を余儀なくされるケースが多発しています。

クラウドデータベース・ノーコード型（画面・入力中心業務の代替）

プログラミング知識がなくても、Web上でテーブル構造や入力フォームを構築できるタイプです。

• 向き不向き：
  テーブル、フォーム、クエリというAccess特有の構造をそのまま持ち込みやすく、日常的な画面入力と一覧参照が中心となる業務の代替に最も適しています。
•  
• 利点：
  システム運用の担い手を情報システム部門だけでなく業務部門へ置けるため、組織的な内製化を推進できます。構築手法の詳細は、ノーコードアプリ開発で業務システムを内製化する実践ガイドを参考にしてください。

表計算とクラウドストレージの組み合わせ（参照メイン・小規模資産向け）

クラウド型スプレッドシートやオンラインストレージへデータを集約する構成です。

• 向き不向き：
  登録データ数が少なく、たまに数値を参照・手入力する程度の小規模な資産に向いています。
•  
• 注意点：
  データ件数が数万件を超えると動作が遅くなり、複雑なリレーション管理には不向きであるため、適用範囲を明確に限定して運用する必要があります。

BI・帳票出力ツール型（集計・帳票出力メインの資産向け）

データの集計ダッシュボードや、指定レイアウトでの帳票発行に特化したツールです。

• 向き不向き：
  蓄積されたデータの集計や印刷出力が主目的であった資産の代替に適しています。入力画面としての機能は限定的となるため、参照主体の業務に向いています。

スクラッチでの再開発（複雑なロジック・基幹連携向け）

システム開発会社へ外注し、Webシステムとしてゼロからプログラミング開発する手法です。

• 向き不向き：
  業務ロジックが極めて複雑であり、他の基幹システムとリアルタイムで高度にデータ連携を行う必要がある大規模な業務に適しています。
•  
• 注意点：
  開発費用と期間が膨大になるだけでなく、導入後に仕様変更を行うたびに外注費用が発生します。開発を委託した外部ベンダーや特定の開発者に保守を依存し新たな属人化を引き起こす懸念があるため、安易に選択すべきではありません。

◆Access移行の工程表

【1.現行資産の棚卸し】──（現行Accessファイルの中身を可視化）
【2.機能の仕分け】 ──（不要なクエリ・レポート・マクロを除外）
【3.新システムの設計】 ──（画面・テーブル構造・権限の定義）
【4.データ移行】 ──（文字コード・型変換・リレーション再現）
【5.並行稼働】 ──（新旧システムの出力データ・数値検証）
【6.切替・運用開始】 ──（旧ファイルの参照専用化・繁忙期を回避）

各工程で実施すべき具体的な手順と注意点を詳しく解説します。

現行資産の棚卸し

移行プロジェクトの第一歩は、現在社内で稼働しているAccessファイル内部の構成要素を可視化することです。

Access内部に存在する「テーブル（データ構造）」「クエリ（抽出・集計条件）」「フォーム（入力・閲覧画面）」「レポート（印刷レイアウト）」「マクロ・VBA（自動化処理）」および外部ファイルへのリンクをすべて一覧表にリストアップし、それぞれの件数、作成者、最終更新日時を記録します。全体数を正確に把握せずに感覚で見積もりや開発を進めると、後から未知の処理が見つかり、大幅な工数超過や予算オーバーを引き起こす原因となります。

使われている機能と使われていない機能の仕分け

棚卸しで作成した一覧表を基に、現場のユーザーへのヒアリングと最終更新記録から、現在も実際の業務で日常的に使われている機能を特定します。

長年の運用や担当者の変更を経てきたAccessには、過去の担当者がテスト目的で作成した不要なクエリや、既に使われなくなった旧フォーマットの月次レポート、過去の特定イベントでのみ使われたVBAコードが大量に残存しています。使われていない機能を移行対象から明確に除外する判断こそが、新システムの構築費用と開発期間を最も大きく圧縮するポイントとなります。

新システムの設計

仕分けによって厳選されたコア機能（入力画面、必要なテーブル、出力帳票）をベースに、代替ツール上でのデータ構造と画面レイアウトを設計します。

現行Accessの複雑な画面や操作感をそのまま再現しようとするのではなく、新ツールの標準機能に業務を合わせるアプローチをとります。テーブル間の紐づけを整理し直すと同時に、部署や役職に応じた閲覧・編集権限の設計を事前に行っておくことで、セキュリティと操作性を両立させたWebシステムとしての基盤を定義します。

データ移行

新システム側のテーブル構造が完成した後、旧Accessから抽出した過去データの移送作業を実施します。

データ移行の際は、文字コードの変換（Shift-JISからUTF-8への変更）、日付型や数値型といったデータ型の適合、欠損値や重複データの補正（データクレンジング）を正確に行います。また、一括でのデータ移行を行う前に、必ずテスト用データを抽出して移行リハーサルを行い、新システム上で検索や表示が正しく行われるかを検証します。

既存システムを活かしながら移行するアプローチについては、レガシーな基幹システムを捨てずにクラウド化する方法をご覧ください。また、データの移送・移行手順に関しては、データを捨てずに新システムへ移行する3ステップで詳しく解説しています。

並行稼働

新システムが完成した段階で一斉切り替えを行うのではなく、一定期間は旧Accessと新システムを同時に運用する並行稼働期間を設けます。

同じ取引データを双方のシステムへ入力し、出力されるレポートの数値や集計結果にズレが発生しないかを厳密に照合します。現場の担当者が実際の業務の中で操作感や処理速度を確認し、不具合や運用の違和感を完全に解消したうえで本番切り替えの判断を下します。

切替・運用開始と運用ルールの確立

テストと並行稼働が完了した段階で、本番環境へ完全に切り替えます。本番切替日は、万が一トラブルが発生した際の業務影響を最小限に抑えるため、月末締め作業や決算期といった業務の繁忙期から、必ずずらして設定します。切り替え完了後、旧Accessファイルは誤入力を防ぐために参照専用のアーカイブとして別フォルダへ退避させます。

また、新システム稼働と同時に、新たな運用ルールを定めます。誰が新しい管理項目を追加できるかという権限設定、設定変更の履歴（更新ログ）をどこに残すか、仕様をどのような粒度でドキュメント化するかをルールとして定めます。ルールを確立せずに運用を開始すると、数年後に再びシステムがブラックボックス化する事態を招くため、移行完了時の運用ルールの厳格化が不可欠です。

仕様が分からない資産を読み解く手順

コードを開くことすら危険視されるシステムを読み解く際は、プログラミングコードを読むことよりも、利用者に聞くアプローチを優先します。

• 利用者のヒアリング：
  実際に画面を使っている担当者へヒアリングを行い、「どの画面から」「どのタイミングでデータを入力し」「どのボタンを押してどの帳票を出力しているか」という実業務の動線を特定します。
•  
• 画面とレポートからの逆算：
  普段使われている入力画面（フォーム）と出力結果（レポート・CSV）の項目を突き合わせ、業務に必要なデータを逆算します。
•  
• テーブルとクエリの確認：
  入出力の関係が整理された段階で初めてテーブル定義やクエリの処理フローを確認し、データの紐づきを特定します。
•  

複雑なVBAコードを全て解析しようとせず、現場の入出力の関係性を整理することが、安全な解読手順となります。

属人化を再発させない作り方

新しいシステムを構築する目的は、単に動くものを移すことではなく、特定の人に依存しない状態を作ることにあります。

組織的な属人化を回避するための具体的な施策については、業務の属人化対策をご覧ください。また、社員の離職に伴うシステム運用の停止を防ぐ運用体制については、退職リスクに備える業務引き継ぎの仕組み化が参考になります。

管理項目の追加や変更を業務部門自身が行える設計を採用し、変更履歴がシステム側で自動的に残る仕組みを選ぶことで、特定個人のスキルに頼らない持続可能な業務環境を整えます。

※本セクションの事例は、筆者が実際に伴走支援したPoC（概念実証）の内容を基にしています。守秘義務により個別の社名は開示していませんが、複数の類似案件に共通する課題設定と対応プロセスを組み合わせて紹介しています。

ある商社（業務システムはAS400で、端末への手入力作業が残存）や、食品製造・販売事業者（既存システムはJustDB、一部でExcel手入力運用を実施）、リフォーム事業者（Excelマクロの肥大化によりファイルが重く脱Excelを検討）、教育関連機関（年度ごとの改修やファイル破損の恐れがあり、保守がデジタルシステム部1名に集中）といった現場では、共通した構造的課題を抱えていました。

いずれの現場においても、長年の改修によってマクロやプログラムが肥大化し、作成者以外の社員では不具合時の対応が不可能な状態に陥っていました。さらに、基幹システムへの再入力作業が発生しており、業務の二重手間と入力ミスのリスクが日常化していました。

これらの現場では、現行の複雑なマクロやプログラムをプログラミングで完全再現するアプローチを回避しました。業務に必要な入力項目と出力形式のみを抽出し、Web上で直感的に設定変更ができるノーコードの業務データベースツール上へ再構築する検証へ進みました。

既存の複雑なコードをそのまま移植するのではなく、誰でも保守可能なシンプルな構造へ再設計したことで、特定個人への依存を脱却する業務基盤の定義に成功しました。

Q1 Accessはもう使えなくなるのですか？

マイクロソフト社によるAccess製品自体のサポートが直ちに終了するわけではありません。ただし、提供元の公式情報を確認すると、オンプレミス環境や共有フォルダでの複数人同時運用には、ファイル破損やセキュリティ低下のリスクがあることが示されています。環境の変化に備えた計画的な移行検討が推奨されます。

Q2 代替ツールに移すと、いまのフォームやレポートはそのまま使えますか？

そのままの形で自動移植することは不可能です。新ツール側で入力画面（フォーム）や印刷レイアウト（レポート）を再構築する必要があります。現行デザインを参考にしながら、新ツールの標準機能を使って配置を設定します。

Q3 移行にはどのくらいの期間がかかりますか？

一般的な小〜中規模のデータベース資産であれば、棚卸し、仕分け、ツール選定、構築、データ移行、並行稼働を含めて、約3ヶ月から6ヶ月が標準的な期間となります。

Q4 仕様書がまったく残っていない場合、どこから手をつければよいですか？

プログラムコードの解読から着手するのではなく、現場のユーザーが実際に使っている入力画面と出力帳票の項目を書き出す作業から始めます。老朽化したレガシーシステム全般の根本的な見直し方針については、レガシーシステム対策を参考にしてください。

Q5 移行の必要性を上司に説明しても「まだ動いているから」と言われます。どう伝えればよいですか？

「システムが動いているか」という点ではなく、「担当者が不在となった際のリスク（障害発生時の業務停止損失）」を数値や事実として提示します。さらに、手作業での復旧コストや、ノーコードツールへ切り替えた場合の将来的な保守費用の削減効果を客観的に説明することが有効です。

Q6 移行プロジェクトは情報システム部門が主導すべきですか、それとも現場主導で進めるべきですか？

どちらか一方に限定する必要はありません。適した体制は代替ツールのタイプによって異なります。クラウドデータベース・ノーコード型のように画面入力や一覧参照が中心の業務であれば、日常的にツールを使う現場部門が主体となり、情報システム部門はセキュリティ設計やデータ連携面を支援する「現場主導・情シス伴走」の体制が機能しやすい領域です。

一方、BI・帳票出力型やスクラッチでの再開発のように、他の基幹システムとの高度な連携や全社的なデータ整合性が求められる領域では、情報システム部門が主導する体制が適しています。着手前に「誰が管理項目を追加できるか」「変更履歴をどこに残すか」という運用ルールを明確にし、特定の部門や個人に判断が偏らない仕組みを整えることが重要です。