申込や取引の管理はWordPress、入金データと取引データの消込はExcelマクロ。複数の仕組みに業務が分散し、確認や保守に時間がかかっていませんか。
本記事では、WordPressとExcelに分かれていた業務をLaravel製の管理システムへ一元化した事例を紹介します。特に、Excelマクロで約2時間かかっていた消込処理は、API連携による自動照合に置き換えたことで約10分まで短縮できました。
日々変動する単価や送料・手数料など「数字がズレると困る」処理を、既存の仕様を洗い出しながら移行した進め方もあわせて紹介します。
課題：WordPressとExcelに業務が分散していた
旧システムでは、申込受付、取引管理、メール送信、帳票出力、集計など、業務に必要な機能がWordPress上に実装されていました。長く使われてきた仕組みのため、現場の運用に合わせた細かなルールが数多く組み込まれています。
一方で、入金データと取引データを突き合わせる消込処理は、システムの外のExcelマクロが担っていました。マクロがブラウザの画面を自動操作して入金明細を取得し、取引データと照合する仕組みです。
すでに自動化はされていたものの、この構成には次のような課題がありました。
- 処理に約2時間かかり、完了まで担当者が気にかけ続ける必要がある
- 画面の自動操作に依存しているため、画面構成の変更などをきっかけに止まることがある
- 止まった原因の調査が難しく、復旧の手順が属人化しやすい
- 業務ルールがWordPressとマクロに分かれ、改修時の影響範囲が見えにくい
仕組みそのものは長年業務を支えてきたものの、確認作業や保守にかかる負担が年々大きくなっていました。
実施したこと：Laravel製の管理システムへ一元化
今回の開発では、既存のWordPressシステムを単純に作り替えるのではなく、現場で使われている業務ルールを一つずつ確認しながらLaravelへ移行しました。
申込管理、取引管理、メール送信、帳票出力、集計といった機能をLaravel側に集約し、管理画面上で一連の業務が完結するようにしています。あわせて、誰がいつ何を変更したのかを追える変更履歴や、操作できる範囲を役割ごとに分ける権限管理も整備しました。
そして、これまでExcelマクロで行っていた消込処理は、入金明細を外部サービスからAPIで自動取得し、システム内で取引データと自動照合する仕組みに置き換えました。
ポイント①：消込処理の流れを「待つ作業」から「確認する作業」へ
移行前の消込処理は、マクロがブラウザの画面を自動操作して入金明細を取得し、取引データと照合する流れでした。すでに自動化はされていたものの、画面操作を介した処理には約2時間かかります。さらに、画面構成の変更や通信状況によって途中で止まることがあり、その場合は担当者が原因を調べて再実行する必要がありました。
移行後は、入金明細を外部サービスのAPIから直接取得し、名義や金額をもとに取引データと照合します。画面を介さずデータを直接やり取りするため処理は約10分で完了し、画面の変更に影響されて止まることもありません。担当者は、判断が必要なものだけを管理画面で確認すればよくなりました。
設計面では「安全側に倒す」ことを重視しています。名義や金額が完全に一致しない入金は自動処理せず、必ず担当者の確認に回す仕様としました。処理時間の短縮だけでなく、誤った消込による二重処理を防ぐことも目的の一つです。
ポイント②：数字がズレないように既存仕様を洗い出し
このような業務システムでは、画面が動くだけでは不十分です。
日々変動する単価、送料、手数料、帳票、メール、集計など、金額に関わる処理が複数あります。どこか一箇所でも計算のタイミングや条件が違うと、管理画面・メール・帳票・集計の数字がズレてしまいます。
たとえば「申込時点の単価を使うのか、確定時点の単価を使うのか」「送料はどの時点の金額で判定するのか」といった点は、コードを移植するだけでは引き継げません。移行にあたっては、既存システムの実装と実際の運用を突き合わせ、どのタイミングでどの値を使うのかを一つずつ整理しました。
検証では、旧システムと新システムで同じデータを処理し、帳票や集計の数字が一致することを確認しています。画面の見た目ではなく「計算結果が既存と一致すること」を移行の完了条件としました。
成果：消込は約2時間→約10分。業務ルールは1か所に
特に大きな効果があったのは消込処理です。Excelマクロで約2時間かかっていた処理が、API連携による自動照合で約10分まで短縮されました。処理が途中で止まって復旧に追われることもなくなり、担当者は確認や次の対応にすぐ移れるようになっています。
また、消込以外にも一元化の効果が出ています。
- 消込も含めた一連の業務が1つの管理画面で完結し、複数のツールを行き来する必要がなくなった
- 変更履歴と権限管理により、操作の経緯を後から追えるようになった
- 業務ルールが1つのシステムにまとまり、改修時の影響範囲を把握しやすくなった
日々の処理時間の短縮と、将来の保守・改修のしやすさ。その両方を実現できたことが、今回の移行の成果です。
「業務を止められない」場合も段階的に移行できます
業務システムの移行では、「移行期間中に業務が止まらないか」「新システムの数字が信用できるか」という不安がつきものです。
今回の事例でも、既存の運用を続けながら開発を進め、現場の担当者による受け入れテストを重ねたうえで切り替えています。一括でのリプレイスにこだわらず、既存の仕組みと並行して検証する期間を設けることで、リスクを抑えながら移行を進められます。
まとめ
レガシーシステムの移行は、単に画面を新しくするだけではありません。長年の運用で積み重なった業務ルールを整理し、既存の処理結果とズレが出ないことを確かめながら、新しい仕組みに置き換える必要があります。
今回の事例では、WordPressとExcelマクロに分散していた業務をLaravelへ一元化し、特に時間のかかっていた消込処理をAPI連携によって約2時間から約10分へ短縮しました。
既存システムの保守に不安がある、Excelマクロや手作業に依存している、日々の処理時間を短縮したい。そのような場合は、今の業務を活かしながら段階的にWebシステムへ移行することで、運用負荷を大きく下げられる可能性があります。
同じような課題をお持ちの場合は、既存業務の整理からシステム移行まで、お気軽にご相談ください。
