前回の続きです

こんにちは。株式会社ヒアナウ今田です。

AIにVBAを読み込ませて解析する、という話です。

今回はその続編です。

「AIがVBAを読み解く」と一言で書きましたが、実際には何が起きているのか。ある移行案件で見つかったものをもとに、もう少し具体的にお話しします。

「テーブルさえ移せば終わり」ではありません

Access移行の相談を受けるとき、こんな風に考えている方が結構いらっしゃいます。

テーブルの中のデータを新しいシステムに入れ直せば、移行は終わりですよね?

半分正解で、半分違います。テーブルのデータを移すこと自体は、実はそれほど難しくありません。エクスポートしてインポートすれば済む話です。

本当に難しいのは、そのデータをどう扱うかという部分です。そしてそのルールは、たいていテーブルの中には書かれていません。

以前ご相談いただいた、卸売・物流の現場でAccessをお使いのお客さまの例です。

在庫の需要予測をするための独自のロジックがありました。取引先ごとに、注文された数量を3段階に分けて、時間軸に沿って配分していくというものです。取引先との力関係や納品サイクルによって、その分け方の基準が変わります。

これは既製の在庫管理ソフトには存在しないロジックです。

世の中に「見積があって、在庫があって、売上伝票が引かれて減っていく」という一般的な予測の仕組みはありますが、このお客さまの場合はそこに独自の商習慣が何層も積み重なっていました。

設計書はありません。作った人はすでに退職しています。テーブルの構造を見ただけでは、このロジックの存在にすら気づけません。

解析を進めていく中で、既知の不具合も見つかりました。

どちらも現場では「知ってはいるけど触れない」不具合として扱われていました。原因を直そうにも、そもそもどういうロジックでその数字が計算されているのかを、誰も正確に説明できなかったからです。

ほかにも、途中まで作って放置された機能がいくつも見つかりました。何年も前に着手して、そのまま止まっている機能です。使われているのか、もう不要なのか、テーブルを見ただけでは判断がつきません。

このお客さまのケースでは、5,000行を超えるVBAのコードをAIに読み込ませ、ロジックをひとつずつプログラミング言語に置き換えていきました。

ここで拾い上げているのは、単なる構文の変換ではありません。「この変数は何を意味していて、なぜこの条件でこの計算をしているのか」という、コードの奥にある業務上の意図です。取引先ごとの分割ロジックも、二重計上のバグも、この過程で見えてきました。

正直に言うと、AIが100%正確に読み解けるわけではありません。読み違えることもありますし、業務側での確認が必ず必要です。それでも、人が一行ずつ目で追うしかなかった作業を、大きく前に進められるようになったのは間違いありません。

テーブルだけを見て「大丈夫、移行できます」と判断するのは、正直なところ危ういと思っています。

弊社の脱Access移行サービスが、いきなり移行に着手せず「まずはAccessの健康診断から」という順番にしているのは、この経験があるからです。

テーブルの構造だけでなく、その奥にある業務ルールと、長年放置された不具合や未完成の機能まで含めて読み解く。それをレポートとしてお渡しした上で、移行するかどうかをご判断いただく流れは、前回の記事でご紹介した通りです。

「うちのAccessにも、そういう隠れたルールがあるかもしれない」と思われた方は、お気軽にご相談ください。

お問い合わせは下のフォームか、オンライン無料相談からお願いいたします。