AccessからJava系基幹システムへ移行する際の注意点

結論：技術よりも「Accessの中に埋まった仕様」と「役割分担」でつまずく

Spring BootなどのJavaフレームワークでAccessを作り直す移行は、移行先の選択肢の中でも自由度が高いぶん、費用と期間が大きくなりやすい進め方です（この費用感は受託開発での当社の経験則です）。移行先の比較そのものはWebシステム化の記事に譲り、この記事では「Javaで作り直すと決めた（決めかけている）」段階で注意すべき点に絞ります。

先に全体観を言うと、データベース設計・画面・帳票といった開発作業そのものは、基幹システム開発の定石が通用する領域です。つまずきやすいのはその手前と外側、つまりAccess独自の仕様をJavaの世界へどう翻訳するかの見立てと、開発ベンダー・社内の役割分担です。

クエリロジックはSQL層とアプリ層に仕分けてから見積もる

Accessのクエリは、そのままPostgreSQLやOracleのSQLに貼り替えられるとは限りません。Microsoftの公式ドキュメントにあるとおり、Access SQLはおおむねANSI-89レベル1準拠とされる一方で、クロス集計を作るTRANSFORM文やパラメータクエリのPARAMETERS宣言といった独自機能を持ち、Likeのワイルドカードも「?」「*」とANSIの「_」「%」で体系が分かれています（どちらで解釈されるかは実行経路次第で、混用できないことも同ページに明記されています）。

さらにAccessでは、NzやIIfのような関数をクエリの式の中で使えます。フォームのコントロール値をクエリの条件から直接参照する書き方（[Forms]![検索フォーム]![開始日] のような形）も公式に案内されている定番の作りですが、これはAccessが実行時に値を解決する仕組みなので、SQL文だけを他のデータベースへ移しても動きません。

移行前に、クエリを次の3つに仕分けることをおすすめします。書き換え先はあくまで目安で、実際の可否は移行先データベースの機能に依存します。

受託開発での当社の経験則ですが、この仕分けを見積もり前にやるかどうかで金額のぶれ方が大きく変わります。クエリの総数と「SQLでは完結しない」側の比率が分かっていれば、開発ベンダーは工数を現実的に積めます。逆に本数すら不明なままだと、リスク分を上乗せした見積もりになるか、着手後の追加費用になるかのどちらかに寄っていきます。

トランザクションの単位は「業務の区切り」で決め直す

Access（DAO）にもトランザクションはあります。公式リファレンスによれば、BeginTrans〜CommitTransで一連の更新を1単位にでき、トランザクションはWorkspace全体に及ぶという独特のスコープを持ちます。裏を返すと、BeginTransを書いていなければ更新はその都度確定していく作りだということです。

Java側は事情が違います。Spring Frameworkの宣言的トランザクションでは@Transactionalを付けたメソッドの境界が基本の単位になり（伝播設定によっては呼び出し元のトランザクションに参加します）、既定ではRuntimeExceptionなどの非チェック例外とErrorのときにロールバックされます（通常のチェック例外では戻りません）。この既定を把握しないまま組むと、「例外が出たのにデータが半端に残る」「逆に、戻ってほしくない処理までまとめて戻る」という食い違いにつながります。

ここで大事なのは、どこからどこまでを1つの取引として扱うかは技術では決まらない、という点です。受注の登録と在庫の引き当てを一体で成立させるのか、別々でよいのか。明示的なトランザクションのないAccessでは、データベース上は個々の更新がその都度確定していて、業務としての区切りは画面の操作順という運用で保たれているにすぎません。作り直しでは、業務側がこの区切りを明示的に決め直す必要があります。移行工程のどこでこれを詰めるかは移行プロジェクトの進め方で解説しています。

帳票は「全部を1対1で作り直す」を最初に疑う

Accessにはグループ化・集計を備えたレポート機能があり、帳票をアプリの中で追加していけます。長年使われたシステムほど帳票が増えていきがちで、JavaのWebシステムで帳票を出すにはPDF生成や帳票ライブラリの選定からの再構築になるぶん、画面開発より工数の振れ幅が大きくなりやすい。当社が受託開発で見てきた範囲では、そういう傾向があります。

だからこそ、全帳票を1対1で作り直す前提を最初に疑ってください。おすすめする順序は次のとおりです。まず発行頻度と宛先（社内向けか、取引先・役所向けか）で棚卸しをする。次に、社内確認用の一覧ものはCSV・Excel出力や画面表示で代替できないか検討する。最後に残った「様式が固定で外に出る帳票」だけをPDFで丁寧に作り込む。この順で絞ると、帳票起因の費用膨張を抑えやすくなります。

データ移行はJavaから直接accdbを読める

データ移行のバッチはJavaだけで完結できます。UCanAccessというオープンソースの純Java製JDBCドライバがあり、accdb・mdbファイルをJDBC経由で読み書きできます（内部的にはJackcessとHSQLDBの上に作られています）。ネイティブコードを含まないため、ODBCドライバの入らないLinuxサーバーやCI環境でも動くのが利点です。

つまり「UCanAccessで旧Accessから読み、JDBCで新DBへ書く」という移行プログラムを、本番と同じJava環境で書いて繰り返し流せるということです（本番切り替え前のリハーサル段階なら毎回移行先を空にして全件入れ直すなど、再実行に耐える作りにしておくことが前提です）。移行リハーサルを繰り返す前提なら、手作業のエクスポート・インポートより安全だと当社は考えています。なお、型や文字コードの注意点は移行先データベースごとに異なります。PostgreSQLへ移す場合の型マッピングはPostgreSQL移行の技術ポイントにまとめています。

開発ベンダーと組むときは「現行仕様の正」を誰が作るかを決める

Javaの基幹システム開発が得意な会社が、Accessの中身を読み解くのも得意とは限りません。仕様書が残っていない場合、現行仕様のいちばんの手掛かりはAccessファイルの中（クエリ・VBA・マクロ）に残っており、誰かがそれを文書に起こさない限り、開発ベンダーは要件を推測で積むことになります。

当社では、作り直しの前に現行Accessを解析して仕様を文書化し、それを開発ベンダーへの提示資料にする進め方をおすすめしています。解析と開発を分けると、開発側は「読めないAccessを解読するリスク」を見積もりに乗せずに済み、発注側は複数ベンダーに同じ資料で相見積もりを取れます。あわせて、社内には業務の判断ができる人を必ず立ててください。例外処理をどう扱うか、どの帳票を残すかを決められるのは、Accessに詳しい人ではなく業務に詳しい人です。

手元のAccessが解析できる状態かどうかは、無料の解析可否チェックで事前に確認できます。

よくある質問

Q. VBAをJavaへ自動変換するツールで移行できませんか。

テーブル定義やデータの移送は機械化しやすい部分ですが、VBAで書かれた業務ロジックは、フォームのイベントやクエリと絡み合って動いているため、言語だけ機械変換しても設計としては成立しにくいと当社は考えています。ロジックは「何をしているか」を仕様として抽出し、Java側の設計に落とし直すのが現実的です。

Q. 費用はどのくらいを見ておくべきですか。

当社の受託開発の経験からいうと、スクラッチ開発はローコードなど既製の土台を使う方法より開発費がかさみやすい選択肢です。構成パターン別の考え方と相場感はWebシステム化の費用と進め方で解説しています。

Q. 一括で切り替えず、段階的に移行できますか。

できます。例えば、データベースを先に移し、AccessからはリンクテーブルなどでそのDBへ接続してフォームを当面のフロントとして残しつつ、Web画面を並行開発する構成です。成立条件を含めて段階移行の設計パターンを参照してください。

Q. そもそもJavaスクラッチにこだわる必要はありますか。

社内や既存の取引先にJavaの保守体制があるなら有力ですが、要件がシンプルならローコードのほうが早くて安いこともあります。移行先ごとの向き不向きは移行先比較の記事で整理しています。