はじめに
「Access 2003でしか動かない──」そんなレガシーシステムに日々向き合う現場SEとして、私はとある“脱レガシー”対応で大きな壁にぶつかりました。この記事では、Access 2003環境でしか正常に動作しないシステムを現場でどう扱い、どこまで内製化で対応し、どこに限界があったのか、実録ベースで振り返ります。
Access 2003が今も現役の現場
今回取り扱ったのは、十数年前に構築されたAccess 2003ベースの業務アプリ。VBAで記述された出力処理、固定長のテキスト出力、そして謎の仕様名「振替」。当初は「簡単に修正できるだろう」と思っていたのですが──その考えは甘かったのです。
エクスポート仕様「振替」との闘い
Accessで固定長ファイルを出力するには、”エクスポート仕様”という設定が必要です。これ自体はウィザード操作で作れるのですが、仕様を1つ1つ手作業で調整するのは骨が折れました。フィールドごとに桁数を揃え、空白埋めやゼロ埋めの形式を決め、順番を変え──調整中に何度「マウスで幅合わせって原始的すぎない!?」と思ったことか。
DAOは非対応、Recordsetはエラー
当然のようにDAO 3.6が参照エラー。64bit Accessでは読み込めません。代わりにDAO 12.0を使おうにも、Access Database Engine 2010は配布終了。ADOに切り替える？いやいや、クエリが複雑すぎてADOじゃ通らない。OpenRecordsetが使えない、でもTransferTextで出力したい──。
やむなく採用したワークアラウンド
- クエリを一時テーブルに変換してパラメータなしにする
- TransferTextで固定長テキスト（仕様名：振替）として出力
- ただしヘッダーは出力できないため、VBAで1行目を追加
最終的には「ヘッダー無しで出力→1行目にヘッダーを追加→マージした新ファイルを保存」という地道な工程に落ち着きました。行数は2行増えただけですが、工数は3倍。中間ファイルや削除処理、エラー処理も必要です。
内製化の限界と決断
ここまでの対応はすべて内製ですが、率直に言って「保守性は低い」。DAOが使えない環境、エクスポート仕様の手作業、そしてVBAによる後処理──どれも人為ミスの温床です。今回は人手があり、予算も限られていたためやり切れましたが、今後のことを考えると「仕様そのものの刷新」や「外注での作り直し」も視野に入れざるを得ません。
まとめ
Access 2003ベースのレガシー資産は、間違いなく“過渡期”にあります。かつては手軽にデータベースアプリケーションを構築できるツールとして重宝され、今なお現場に根強く残っているのには理由があります。特に中小企業や予算の限られた現場では、「今も動いているから」と現状維持を選び続けた結果、十年以上前の技術が「業務の生命線」になっていることも少なくありません。
しかし、その延命には確実に限界が訪れます。OSやOfficeのバージョンアップに追いつけない。DAOなどの参照ライブラリが非対応。出力仕様は手動編集、トラブル対応は属人化──これらはすべて、現場のIT資産が「時代遅れ」になっているサインです。そしてそれは、トラブルが起きた瞬間に“業務停止”という最悪の形で顕在化します。
今回の事例でいえば、「Access 2003でしか出力できない固定長ファイル」を、何とかVBAとTransferText、ヘッダー付加処理を組み合わせて乗り越えました。これは確かに技術的な成功ですが、それと同時に「今後どうするべきか？」という問いを突きつけられた瞬間でもあります。
短期的には“手を動かしてなんとかする”という選択も必要です。しかし中長期的には、「構成の見直し」「外注での再構築」「SaaSやWebベースへの移行」など、段階的に脱Accessを進めていくことが、現場を守ることにつながります。単に技術だけでなく、予算交渉や経営層への説明も含めた「社内SEとしての戦略的視点」が問われるのです。
Accessは今なお便利なツールです。だが「便利」であることと、「継続して使うべきか」は別の話です。無理に使い続けて現場の足を引っ張るのではなく、「いまこのタイミングでこそ、次の一歩を考える」。その気づきこそが、今回のような苦労の中から得られる最大の収穫なのかもしれません。
Accessの「エクスポート仕様」は、見た目以上に深い沼…。でも「現場でなんとかした」って話は、きっと誰かの役に立つはずです😊
コメント