課題解決　事例紹介

開発者の去ったExcelシステム

トラブル発生の背景

前任者が退職後も長期間動いた優れもの

R社は食品を扱う輸入商社です。数年前、業務に精通した社員が、Excelのマクロを活用して、どの倉庫からどこに出荷したかの基幹システムデータを基に、今どの倉庫にどの商品がどれだけ在庫しているか把握できるシステムを作りました。

多くの社内システムでは、拠点の増減や商品構成の変更により、プログラムロジックをいじる必要がありますが、このシステムは自動的に振り分けを行ってくれるため、開発した社員が辞めたあともしばらくそのまま活用できていました。

基幹システム変更により、基データも変更

これまで、処理の基にしていたファイルは、基幹システムから副産物的に出力されていた実績データでしたが、諸般の事情で新システムに入れ替えられることになりました。

当初は新システムからも同じデータが出力されるはずだったのですが、ベンダーの手違いからか、同じデータが出せない仕様になっていることに、利用開始後2ヶ月経ってから気づきました。

基になるファイルのレイアウトや項目数が変わったことから、そのまま読み込んでも処理をすることができず、エラーになってしまいます。

作り替えか？　でも時間が･･･

新任の担当者は、Excelを使って列を入れ替えれば動くのでは無いかと考えましたが、1行の単位が以前のシステムと意味が異なり、単純な入れ替えでは説明できない事が分かりました。
消去法的に、新しいファイル様式に合せて作り直すしかありません。

しかし、この業務は日々の在庫量を見ながら、どこからどこに出荷するかを判断するために、今すぐ必要です。商品種類も数百種類、倉庫も全国数十箇所にあるため、手作業ではとても追いつきません。

かといって、今から作り直している時間もなさそうです。

内部を分析、対象ロジックを抽出

入り組んだVBAロジックを分析

典型的なEUDの特徴

当社に相談いただいたのは、このタイミングでした。

すぐに今使っているファイルをお預かりし、分析を試みましたが、業務の間に段階的に拡張がなされた典型的な「ユーザー開発ファイル」だったため、該当する部分がどこなのか特定するのに苦労しました。

過去データを使って動かしながら、どの数値がどこに来る･･･といった分析を繰り返すことで、どうにか新システムデータの影響がどこに出て、どうすれば良いかが見えてきました。

該当箇所のみ置き換え ＆ コメントによるドキュメント化

いくつかある機能のうち、修正を要する箇所は限られています。

その部分だけを変更仕様書に抽出し、変更方針を記入した上で、まずはVBAのソースコードにコメント機能で「削除」「追加」を明記し、日付を入れることで、後で同様の変更があった場合、どこに影響するかを追えるようにしました。この間、わずか2週間です。

その後、前月データを使って完全に手作業と同じ結果になることを確認し、無事本番で従来同様に動かせるようになりました。