マイクロソフトのアクセスは、データベースとフォーム等を一体管理できるライトな素晴らしいソフトですが、有償のWindowsOSとOfficeライセンスが必要になる点、同時アクセスや排他制御の面での制約、インターフェースの制約、保守要員確保の困難さなど、LAMP構成等のWebシステムに比べ、劣位する部分も多い。
そこで、マイクロソフトアクセスのデータベースを長年利用してきているが、Webシステム等へのマイグレーションや置き換えを行いたい、といったことも、よくあります。あるいは、アクセスの動作環境周りをアップデートして延命する必要がある、ということもあるでしょう。
そういう時、どういう考え方をするのがよいか。
まず、アクセスの延命を考えるのは筋が悪いと思います。データ更新を行うのが１名のみであれば、その仕組みは触らずそのままにしておけばいいが、複数名なのであれば、Webにマイグレーションすべき。
Webシステムにする場合どうするか。
まず、アクセスのオブジェクトをさらいましょう。テーブル、クエリ、レポート、フォーム、マクロ、モジュールなどです。これらの数量を数えます。
次に、アクセスのユースケースをまとめましょう。フォームからのデータ更新はユースケースにカウントしません。登録されたデータを使って行う、データ活用のみに絞って、ユースケースを一覧化する。
それから、アクセスのデータ（テーブル）を、新しいWebシステムからメンテナンスする予定のデータベース（postgres, mysql, sqlサーバー, oracleなど）に、すべて突っ込みましょう。新しくスキーマを作って、そこにまとめておくのが良い。
その後、ユースケースに対応する、アクセスの代替手段を作成しましょう。クエリをエクセルにエクスポートするユースケースが多いはずなので、それらを解決していきましょう。新しいデータベースにクエリと同じようなビューを作って、該当のビューから、エンドユーザーが、エクセル形式でデータをダウンロードできる状態をつくればOKです。
すべてのユースケースを新しいビュー等で代替できたら、データ移行を完了しましょう。
完全に新しいシステムであれば話が単純ですが、一部新旧データが混ざるような場合は、「決め」の問題で、データの統合をやりきりましょう。
なお新しいデータのメンテナンス方法は、ブラウザ画面経由でのインターフェースを提供するのが簡単です。
このアプローチのポイントは、アクセスのフォームやテーブルの１項目ずつを、移行プロジェクトの進捗管理において「無視する」ことです。アクセスのフォームやテーブルの項目は、ユースケースに比して大変多い。ユースケースが２０だとすれば、テーブル項目数は３００，フォームのINPUT可能な穴は５００，というように、サイズ感が変わってきます。
ユースケースを進捗管理や設計の軸にすえることで、エンドユーザーと移行を行うエンジニアの間のコミュニケーションコストが下がり、「入力欄があるからデータ入れていただけど、実は後続の利用者がいなかったすでに」というようなデータの洗い出しが自動的にでき、システムのスリム化が自動的に達成される、というメリットがあります。
私自身、アクセスをつぶしてWebシステム化する取組をこれまでに複数回経験しました。これからもまだ機会がありそうなので、メモしておきました。