【要約】Access VBAのシステムを退役させるために、技術選定をした話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
担当者が長年稼働するAccess VBA製の納品業務システムを保守する中で、技術的負債と運用限界に直面した。\n・VBAの保守人材が不足している。\n・自動テストが困難で、スキーマ変更のリスクが高い。\n・5,500行超の巨大な混在モジュールが存在する。\n・Railsを経由しない直接的なDBアクセスが残っている。
// Approach
開発チームは、スキーマの再設計よりも先に「テストを完備できる状態」を作ることを最優先とした。\n・業務ロジックをRails（Ruby/RSpec）へ段階的に移行する。\n・ファイル操作をPython（PySide6/pytest）のアプリへ切り出す。\n・LGPLライセンスのPySide6を採用し、表現力と制約回避を両立する。\n・QTableWidgetを用いて、Accessの操作感を再現する。\n・選定状態をクライアントメモリ内で完結させ、設計を簡略化する。
// Result
開発チームは、テストの自動化を前提とした新しい技術スタックの選定を完了した。\n・プロトタイプが全ての自動テストをパスした。\n・「テストの完備」を基準に、不適切な技術候補を排除できた。\n・業務ルールの見直しにより、ログイン機構を不要にした。\n・今後は、他機能への横展開と実環境での検証を進める。
Senior Engineer Insight
> レガシー刷新において「テストの完備」を最優先する判断は極めて合理的だ。安全装置を先に作る順序は、リスク管理の定石である。業務ルールの再定義による設計簡略化も、優れた判断だ。ただし、アプリとAPIの二層構造は運用コストを増大させる。クライアント管理の負荷をどう抑えるかが、実戦での鍵となる。