概要
| この記事の結論 AccessからWebシステムへ移行するには、既存機能を棚卸しし、データ、画面、帳票、権限を分けて再設計します。全機能を一度に作り直す方法だけでなく、共通データベースを使いながら必要な機能からWebへ移す方法もあります。切替後の更新データを守れる運用と復旧計画まで決めて進めます。 |
この記事でわかること
- 業務と機能を棚卸し
- 段階移行も選べる
- 権限と更新を設計
- 切替後のデータを保全
この記事の主な内容
- AccessからWebへ移行する範囲を決める
- 業務とデータと外部連携を棚卸しする
- 移行方式と共通データ基盤を選ぶ
- Web画面と権限と帳票を設計する
- 移行リハーサルと業務テストを行う
- 本番切替と運用引継ぎを進める
- よくある質問
想定読了時間：約8分
AccessからWebへ移行する範囲を決める
AccessからWebへの移行では、最初に「誰のどの業務をブラウザーで使えるようにするか」を決めます。すべての画面を一度に作り直す方法もあれば、社外からの入力や参照だけを先にWebへ移す方法もあります。
全面移行と一部移行を区別する
Webシステムは、ブラウザーからの要求をアプリケーション側で処理し、データベースへ読み書きする構成が基本です。AccessのファイルをWebサーバーへ置くだけで、既存フォームとVBAがブラウザー上で動くわけではありません。［Microsoft公式資料］
また、リモートデスクトップでAccessを遠隔利用する方法は、操作場所を広げる選択肢ですが、アプリケーション自体をWebへ再構築することとは異なります。目的が社外利用なのか、端末への依存を減らすことなのかで選択肢を分けます。
移行の目的は、例えば利用場所の拡大、同時利用の改善、担当者交代への備え、外部サービス連携などです。目的と関係しない画面の作り直しを増やすと、費用とテスト対象が膨らみます。使われていない機能を廃止できるかも利用部門と確認します。
業務とデータと外部連携を棚卸しする
棚卸しでは、入力、処理、出力のつながりを記録します。入力項目だけを移しても、その後の締め処理や帳票が欠けていれば業務は完了しません。日次だけでなく、月次、年次、障害時の作業も対象にします。
IPOと例外処理を整理する
IPOとはInput、Process、Output、つまり入力・処理・出力の整理です。画面、クエリ、VBAの一覧に、業務の目的と利用者を結び付けることで、移行対象と優先順位を決めやすくなります。
| 棚卸しする対象 | 記録する情報 | 移行への影響 |
|---|---|---|
| 入力 | 担当者、頻度、端末、必須項目 | 画面と認証の要件 |
| 処理 | 計算、採番、締め、取消 | 業務ロジックの再実装 |
| 出力 | 帳票、CSV、PDF、通知 | 出力方式と検証範囲 |
| データ | 保存先、件数、型、関係 | 移行方式と照合条件 |
| 連携 | 他システム、ファイル、機器 | APIや代替方法の選定 |
返品、訂正、再発行、締め後修正などの例外も記録します。旧画面のボタンが多いからという理由でそのままWebへ再現するのではなく、どの業務上の判断に必要な操作かを確認します。
成果物は、機能一覧、データ一覧、連携一覧、帳票一覧、権限表、移行対象一覧です。各一覧には、移す、残す、廃止する、調査するという判断と理由を残すと、見積もりの前提が揃います。
移行方式と共通データ基盤を選ぶ
全面移行は最終形をまとめて切り替えられる一方、切替時の変更範囲が大きくなります。段階移行は機能を分けて確認できますが、併用期間のデータと業務の責任を明確にする必要があります。
共通DBと更新責任を決める
既存Accessを残す場合は、SQL Serverなどの共通データベースにAccessとWebシステムが接続する構成が候補です。Microsoftも、Accessのフロントエンドを残してSQL Serverをバックエンドにする方法を案内しています。［Microsoft公式資料］
例えば受注入力をWebへ移し、請求書発行を一時的にAccessへ残すなら、受注番号、確定状態、訂正方法を共通にします。両方から同じ項目を自由に変更できると、締め後の修正や競合の扱いが曖昧になります。
| 方式 | 利点 | 併せて決めること |
|---|---|---|
| 全面移行 | 運用を新方式へまとめやすい | 全機能の受入と停止時間 |
| 共通DBで段階移行 | 既存機能を残しやすい | 更新担当とDB互換性 |
| データ連携で併用 | システムごとに役割を分けやすい | 同期遅延と重複・欠落の処理 |
データ連携で併用するなら、正本となるデータ、同期の方向、削除の扱い、再実行条件を決めます。定期的にCSVを送るだけでは、途中失敗や訂正後の再送まで解決したことにはなりません。
Web画面と権限と帳票を設計する
Web画面はAccessの見た目を再現するだけでなく、ブラウザーの操作と通信を前提に設計します。戻る操作、再読み込み、複数タブ、通信切断、送信ボタンの連打で、二重登録や途中保存が起きないかを確認します。
認証と認可を分ける
認証は利用者が誰かを確認すること、認可はその人が何を操作できるかを決めることです。ログインできることと、すべての顧客や部門の情報を見られることは同じではありません。画面とAPIの両方で必要な権限を検査します。
DB接続情報をブラウザーへ渡さず、サーバー側で管理します。入力値はサーバー側でも検証し、データの更新には適切なパラメーター処理や制約を使います。フレームワークに機能があっても、アプリ側の権限設計や設定を省略できるわけではありません。［Microsoft公式資料］
帳票と更新単位を設計する
帳票はPDF、ブラウザー印刷、帳票エンジンなどの候補から、レイアウトと運用に合う方式を選びます。発行時点の内容を残す必要がある帳票では、再表示のたびに最新データで計算してよいかも確認します。
複数の明細をまとめて確定する処理は、途中だけ保存されないように更新単位を決めます。同時に編集されたデータを検出した場合は、無条件に上書きせず、再読み込みや確認を案内する設計にします。［Microsoft公式資料］
AccessからWebシステムへ移行する方法の進め方に迷ったら
既存の画面や帳票をどこまで残せるか、接続や外部連携をどこから調べるべきか。依存関係が多い場合は、現状調査から進めると移行・改修の範囲を判断しやすくなります。お気軽に現在の構成と困っている業務をご相談ください。
移行リハーサルと業務テストを行う
移行リハーサルでは、実際の手順でデータを取り出し、変換し、取り込み、照合するまでの時間を測ります。データ量の少ない試作だけでは、停止可能時間内に切替が終わるか判断できません。
差分移行と照合条件を決める
初回のデータ移行後も旧Accessで業務を続ける場合、切替時には追加・変更・削除の差分を取り込む必要があります。更新日時だけで判定できるか、削除の記録をどう残すかなど、差分の取得方法を先に設計します。
| 検証観点 | 確認する内容 | 完了の証拠 |
|---|---|---|
| データ一致 | 件数、キー、合計、関連 | 新旧照合表と差異の説明 |
| 入力と更新 | 通常処理と例外処理 | 業務シナリオの結果 |
| 権限 | 部門、役割、閲覧、更新 | 権限別テスト結果 |
| 帳票と連携 | 印刷、PDF、CSV、API | 出力比較と受け渡し結果 |
| 性能と復旧 | ピーク操作、障害、再実行 | 測定値と復旧記録 |
SQL Serverへの移行にSSMAを使う場合でも、フォームやVBAのWeb化は別作業です。また、すべてのAccessデータ型やクエリを無条件に移せるわけではないため、変換対象と手作業の対象を事前に分けます。［Microsoft公式資料］
検証の合格基準は、開発完了後ではなく実装前に決めます。対象件数、合計金額、重要帳票の一致、許容応答時間、停止時間、復旧時間を合意すると、切替可否を客観的に判断しやすくなります。
本番切替と運用引継ぎを進める
本番切替では、更新停止から再開までの担当者、順序、時刻、完了条件を一つの手順書にまとめます。利用者へ案内する新しい入口と、旧システムへの誤入力を防ぐ方法も準備します。
Go判定と復旧条件を決める
1. 旧Accessと関連バッチの更新を止め、最終バックアップを取得します。
2. 合意した方法で差分を移行し、処理結果を記録します。
3. 件数、重要集計、ログイン、主要業務を照合し、再開可否を判定します。
4. Webシステムへの利用を切り替え、対象者へ案内します。
5. エラー、更新件数、利用者の問い合わせを監視し、復旧条件に照らして対応します。
Go判定とは本番利用を開始してよいかの判断です。照合不一致、重要業務の未完了、復旧方法が成立しない状態など、開始を見送る条件も定義します。切替担当者の感覚だけで判断しないようにします。
切り戻す場合には、新システムで発生した更新と外部送信を先に保全します。旧Accessを起動し直すだけでは、新側で受け付けた注文や訂正は戻りません。データの差分を取り込むのか、新環境を修正して継続するのかを責任者が判断できる情報を残します。
運用引継ぎでは、監視、バックアップ、復元、権限変更、リリース、問い合わせ対応の担当を決めます。Web化後も運用は必要です。納品時のソースと設定、設計資料、検証結果を保管し、担当者が変わっても更新できる状態にします。
よくある質問（FAQ)
そのまま動くわけではありません。既存の入力・計算・保存・帳票の仕様を整理し、Webの画面とサーバー処理として実装します。データ移行も別に計画します。
Accessを遠隔操作する方法であり、アプリ自体のWeb再構築とは異なります。社外利用という目的に合う可能性はありますが、必要な端末、接続、ライセンスと運用を比較します。
できます。共通DBでデータを共有する構成などが候補です。ただし、併用する機能の責任、更新経路、切替順序と終了条件を先に決めます。
不要にはなりません。データ、ファイル、設定の保全と、復元できることの確認が必要です。サービスの自動バックアップだけで業務全体を復旧できるかも調べます。
機能数だけでなく、仕様調査、帳票、外部連携、権限、データ品質、停止可能時間、検証範囲によって変わります。移行対象と合格基準を整理して見積もります。
AccessからWebシステムへ移行する方法の進め方に迷ったら
既存の画面や帳票をどこまで残せるか、接続や外部連携をどこから調べるべきか。依存関係が多い場合は、現状調査から進めると移行・改修の範囲を判断しやすくなります。お気軽に現在の構成と困っている業務をご相談ください。
参考情報
Microsoft：Migrate an Access database to SQL Server
Microsoft：Ways to share an Access desktop database
Microsoft：Overview of ASP.NET Core
Microsoft：Handling Concurrency Conflicts