医療系の請求・支払い業務は、データ量が多く、関係者も複数にまたがります。そこに「Excelマクロでなんとか回している処理」が混ざってくると、業務はどんどん属人化し、月次の締めが特定の人とマクロに依存したブラックボックスになっていきます。
この記事では、遠隔読影サービスにおける医療機関への請求と読影医への支払いを一元管理するシステムの事例を取り上げます。もともとExcelマクロで処理されていた業務をシステムに取り込み、大量データの取り込みから請求・支払いの発行までを一気通貫でつないだ案件です。
「Excelとマクロで請求・支払いを回していて、属人化が怖い」——そんな課題を抱える事業者の方に、参考になる内容だと思います。
どんなシステムか
遠隔読影サービスを軸に、運営会社が医療機関と読影医の間に立って、請求と支払いを発行する仕組みです。
登場人物は3者
- システム管理者(運営会社):請求書・支払い通知書を発行する。実際にこのシステムを操作するのはこの立場
- 医療機関:読影医に読影(診断)を依頼し、結果と請求を受け取る。システム自体は操作しない
- 読影医:依頼を受けて読影し、結果を返し、支払い通知を受け取る。システム自体は操作しない
医療機関と読影医は「使う側」ではなく「請求・支払いを受け取る側」で、運営会社だけがシステムを操作する——この役割分担が設計の前提になっています。
処理の流れ
- 医療機関が読影(診断)を依頼し、読影医が読影を実施
- その結果を運営会社が介して医療機関へ返し、実績として記録
- 各読影サービスから、実績データがCSVで出力される
- そのCSVを本システムにアップロードして取り込む(大量データのため自動取り込み)
- これを毎月実施し、医療機関には請求、読影医には支払い通知を発行
- 最終的な売上・支払いも本システムからCSVで出力し、別の財務・会計系システムへ連携
- 財務側で、医療機関からの実際の入金・読影医への支払いが行われる
つまり本システムは、**「実績データ → 請求・支払いの発行 → 財務連携」**という流れの中核を担っています。
導入前の課題:Excelマクロによる属人化とブラックボックス化
この案件でいちばん重い課題だったのが、新しい読影サービス(AIを活用した読影)の追加にともなって発生した処理でした。
具体的には、サービスの実績の集計と、回収代行(医療機関からの代金回収を代行する業務)。これらがもともとExcelマクロで実施されていたのです。
Excelマクロ依存には、次のような問題がつきまといます。
- 属人化する:特定のマクロ・特定の担当者に依存し、中身がブラックボックス化する
- 大量データに弱い:手作業やマクロでは処理に時間がかかり、件数が増えるほど破綻に近づく
- ミスが起きても気づきにくい:請求・支払いというお金に直結する処理で、これは大きなリスク
- サービス追加のたびに作り直し:新サービスを足すたびにマクロを拡張・改修する必要がある
請求と支払いという「絶対に間違えられない業務」が、Excelマクロという脆い土台の上で回っていた——これが解消すべき本質的な課題でした。
解決方法:マクロ処理をシステムに取り込み、請求〜支払いを一元化
対応の中心は、Excelマクロでやっていた処理を本システムに移行し、請求・支払い・売上を一つの仕組みに集約することでした。
- 実績データ(CSV)の取り込みをシステム化:大量の実績データを自動で取り込み、システム上で処理できるようにした
- 請求書・支払い通知書をシステムから発行:医療機関向けの請求、読影医向けの支払い通知を、それぞれシステムで出力
- 売上・支払いをCSVで出力し、財務システムへ連携:締めの結果をそのまま会計・財務側へ渡せる形にした
- マクロ処理(実績集計・回収代行)をシステムに内包:属人化していた処理を、誰が見ても流れの追える仕組みに置き換えた
これにより、毎月の請求・支払い業務が、Excelとマクロを行き来する作業から、システム上で完結する流れへと変わりました。
使用した技術
- バックエンド:Laravel(PHP)
- データ連携:大量CSVの一括取り込み・出力処理(自動取り込み)
- 外部連携:売上・支払いデータをCSVで財務・会計系システムへ受け渡し
大変だったこと
1. 大量の実績データ(CSV)の取り込み
このシステムでいちばん負荷が大きいのが、CSVの取り込みでした。実績データの量が非常に多く、取り込みだけで時間がかかります。いかに効率よく処理を回すかが、運用に直結する勝負どころでした。請求書・支払い通知の出力処理も、件数が多く時間のかかる部分です。
2. マクロ処理のシステム移行(最大の山場)
新しい読影サービスの導入にあわせて、実績の追加処理と回収代行を、もとのExcelマクロから本システムへ移し替える対応が、この案件で最も難しいところでした。マクロの中で何がどう処理されていたかを読み解き、それを正しくシステムの仕様に落とし込む——ここに一番神経を使いました。
3. 既存システムを「テストを通じて」理解した
この案件は新規構築からの参画ではなく、まずテスターとして参画したのが始まりでした。Laravel/PHPのバージョンアップに伴うリグレッションテストを担当し、テストを実行する過程でシステムの仕様を一つずつ把握。そのうえで、バージョンアップ後の改修・保守を請け負っていきました。ドキュメントではなく、実際の挙動とテストから巨大な既存システムを理解していく、という入り方そのものが難所でもありました。
工夫したこと
- 大量データを効率よく取り込む処理設計:取り込みに時間がかかる前提で、自動取り込みを含めて運用が回る形に作り込んだ
- 属人化の解消:マクロのブラックボックス処理をシステム化し、特定の人・特定のマクロへの依存をなくした
- 改修の土台づくり:リグレッションテストを通じて仕様を体系的に把握し、その後の改修・機能追加を安全に進められる状態にした
- 請求〜支払い〜財務をつなぐ:請求・支払い・売上を一つのシステムに集約し、財務システムへCSV連携することで、締めから入金・支払いまでの流れを一本につないだ
こんな課題をお持ちではないですか
ひとつでも当てはまるものがあれば、今回の事例がそのまま参考になるはずです。
- 請求・支払い・売上の集計をExcelマクロで回していて、属人化・ブラックボックス化が怖い
- 大量データの集計や突合に、毎月の締めで時間を取られている
- サービスや取引先が増えるたびに、マクロを作り直している
- 請求と支払いが別々に管理されていて、会計・財務へのつなぎが手作業になっている
- 既存システムがあるが、改修・機能追加を任せられる相手を探している
これらは、Excelマクロ処理のシステム化と、請求〜支払い〜財務連携の一元化で解決できる課題です。新規構築だけでなく、既存システムへの機能追加・改修・保守にも対応しています。「脱Excelで請求・支払い業務を立て直したい」という事業者の方は、お気軽にご相談ください。