Access移行が失敗する5つの典型パターンと回避策

結論：失敗パターンには共通の型がある

当社の移行支援では、頓挫したプロジェクトや移行後に再工事が発生したケースを複数経験してきました。原因を振り返ると、「システムが複雑すぎた」よりも「進め方の選択を誤った」ケースがほとんどです。

以下、当社の移行支援実務から抽出した5つの失敗パターンと、各パターンの回避策を解説します。移行を検討している段階で把握しておけば、同じ轍を踏まずに済みます。

失敗パターン1：現行仕様の把握をおろそかにして設計を始める

最も多いのが、現行Accessの仕様を確認しないまま「とりあえず新システムを作る」という進め方です。Accessファイルを開き、主要なフォームだけ確認して設計に入ってしまうケースがこれにあたります。

Accessには、フォームから直接呼ばれるVBAコード、クエリの中にネストされたクエリ、マクロから起動する外部Excelファイルなど、画面を見るだけでは把握できない業務ロジックが埋まっています。当社の解析では、長く使われたAccess1ファイルに50本以上のクエリが存在し、そのうちフォームから直接参照されないものが3分の1以上あるケースも珍しくありません（当社実務基準）。

こうした「見えない仕様」の洗い出しを省略すると、新システムを一通り作り終えた後で「この計算は昔のAccessと結果が違う」「このボタンが押せない」という差異が大量に出ます。修正コストは、最初から正しく解析して設計した場合の数倍になることがあります。

回避策は、移行設計に入る前に解析工程を独立させることです。ブラックボックス化したAccessの解析手順で整理しているように、Database Documenterはオブジェクトの定義を文書化する出発点になります。ただし、Accessのオブジェクトの依存関係機能はVBAモジュール・マクロ・サブクエリを追跡しないため、VBAコードの精査や動的な参照は別途確認が必要です（当社実務基準）。

失敗パターン2：一括移行にこだわり、現場が使えないシステムを作る

「いまのAccessをすべて一度に新システムへ移す」という計画は、聞こえはよいのですが現場にとっては負担が大きくなります。

一括移行で並行稼働も採用した場合、現場は新旧2つのシステムを同時に操作する必要があります。業務量が変わらないまま確認作業だけが増えるため、特に人手の少ない部門では「確認する時間がない」という状態になりやすいです。結果として、テストが形式的になり、本稼働直後に不具合が多発します。並行稼働を省略して一斉切替にした場合は、問題が起きたときの対処が難しくなります。

また、スコープが広いほど設計変更のコストも増えます。途中で業務フローの見直しが入ると、対象範囲が広い分だけ影響範囲も広くなります。

当社の進め方では、原則として段階移行を提案しています。まず止まると困るデータ部分や、リスクの高い箇所（ファイルサイズが2GBの上限に近い、サポートが終了しているバージョンで動いているなど）を先行して移し、残りは運用しながら順次進めます。費用の分散にもなりますし、現場が慣れる時間を確保できます（費用と段階移行の考え方も参照してください）。

失敗パターン3：帳票の再現を後回しにして本稼働が止まる

移行プロジェクトで「帳票は最後に」と位置づけると、本稼働直前になって大きな問題が発覚します。これはAccessに限らず業務システム移行全般で繰り返されるパターンですが、Accessでは特に顕在化しやすいです。

AccessのレポートオブジェクトはExcelやPDF出力と組み合わさっており、フォームより複雑な計算式やグループ集計を持つことが多いです。また、印刷レイアウトへの要求が厳格な場合（行政書類、請求書、納品書など）は、ピクセル単位での再現を求められることもあります。複雑な複数ページ帳票やピクセル単位の再現が求められる場合、当社の経験上、kintoneやPower Appsの標準機能だけでは対応しきれず、帳票プラグインや外部サービスとの連携設計が必要になることがあります。

回避策は、設計フェーズの早い段階で「帳票インベントリ」を作ることです。現行Accessに存在するレポートオブジェクトをすべて洗い出し、印刷先・出力形式・計算式・使用頻度を一覧化します。使用頻度が低い帳票は移行対象から外す交渉ができますし、複雑な帳票は移行先の制約を早めに把握して設計に織り込めます。

失敗パターン4：現場の反発を軽視して定着しない

技術的には問題なく移行が完了したのに、半年後には誰も使っていないという事例があります。現場が旧Accessに戻っていたり、並行して新しいExcelファイルを作って運用していたりするケースです。

Accessは長年使い続けたシステムであることが多く、担当者は操作手順を体で覚えています。新しいシステムの操作が増えると、移行した直後の生産性が一時的に落ちます。これは避けられないことですが、「なぜ移行するのか」の説明がないまま進めると、現場から見た変化はコストだけになります。

当社の移行支援では、要件整理の工程に現場担当者を必ず引き込むことを重視しています。新システムの設計に自分たちの意見が反映された経験があると、本稼働後の定着率が変わります。また、操作マニュアルは「移行ベンダーが作る文書」ではなく「自分たちが使うもの」として現場と共同で作ることが多いです（当社実務基準）。

失敗パターン5：データ品質の問題を移行後に発見する

長年運用されたAccessには、本来入るべきでない値が入っているフィールド、テーブル間の参照整合性がとれていないデータ、重複レコードなどが蓄積しています。移行先のデータベース（SQL ServerやDataverseなど）で制約を適切に設定した場合、こうした不整合データがエラーになることがあります。

Accessは整合性制約や入力検証を設定しないまま運用できる作りのため、長期間メンテナンスが入らないと不整合が蓄積しやすいです（当社実務観察）。テキスト型フィールドへの数値文字列の混入、Null値の扱い、外部キー先が削除されたままのレコードが残っているケースは珍しくありません（当社の移行支援では、100件以上のデータ不整合が移行直前に見つかったケースもあります）。

回避策は、移行実装に入る前にデータクレンジングの工程を設けることです。移行対象のテーブルを一通りエクスポートして、Excelや簡単なスクリプトで値の分布を確認します。異常値が多いフィールドや参照整合性に問題があるテーブルを先に特定し、業務担当者とどう扱うかを決めてから移行実装に進みます。

なお、Accessが持つ参照整合性の設定（リレーションシップでの連鎖削除・連鎖更新）は、SSMAなどの移行ツールでSQL Server側に移植できる場合もありますが、制約の一部は手動での設定が必要です（詳しくはAccessとSQL Serverの構成を参照してください）。

5パターンまとめ

これら5パターンは独立して起きるわけではなく、1と5が重なったり、2と4が連動したりすることも多いです。移行プロジェクトの進め方全体についてはAccess移行プロジェクトの進め方で7工程の詳細を解説しています。

自社のAccessの状態を先に把握したい場合は、無料の解析可否チェックからお問い合わせください。解析が可能かどうかを確認するだけなら費用はかかりません。

よくある質問

Q. 移行が頓挫した後からでも立て直しできますか。

可能です。ただし、頓挫した時点で何が問題だったかを整理することが先決です。当社では現行Accessの解析からやり直し、どこまで進んでいたかを確認したうえで、続行か再設計かを判断します。半完成の成果物がある場合、使えるものと使えないものを仕分ける作業が入ります。

Q. Access移行で失敗しやすいのはどんな規模のシステムですか。

規模よりも複雑さが影響します。テーブル数が少なくてもVBAが大量にある、帳票の種類が多い、複数のAccessファイルが連携しているといったシステムは、小規模に見えても移行の難易度が高いです。当社の解析では、こうした複雑さをD1〜D3の難易度で評価しています（当社実務基準）。

Q. kintoneへの移行で帳票が再現できないケースはありますか。

あります。当社の経験上、kintoneの標準機能で出力できる帳票は比較的シンプルなものが中心で、複雑なレイアウトや細かい印刷設定が必要な場合は、帳票プラグインや外部サービスとの連携が要ることが多いです。移行先を選定する段階で、現行の帳票要件と移行先の制約を照合することが重要です（移行先の比較は移行先の選び方を参照してください）。

Q. 現場担当者をどの工程から引き込むべきですか。

要件整理の工程から引き込むのが最低ラインです。できれば現状調査の段階から、業務担当者に「今どのAccessを何の業務で使っているか」を確認するヒアリングに同席してもらうと、後工程での差し戻しが減ります。引き込む人数は1〜2名で十分ですが、その人が意思決定できる立場であることが条件です（当社実務基準）。