【経理業務改善】Pythonで住所を自動改行する方法―窓付き封筒の宛名印刷で発生した想定外の問題
返金業務の自動化を進める中で直面した、窓付き封筒の宛名印刷問題。住所データを自動で2行に分割しようとした際に発生した想定外の課題と、最終的にたどり着いた考え方について紹介します。
はじめに
前回の記事では、返金業務の自動化を目的としてRPA導入を試みたものの、最終的には断念することになった経緯を紹介しました。
その後、
「RPAでは難しいなら、データを中心に処理する仕組みを作れないか」
と考え、Pythonを使った業務改善を検討することになりました。
その中でも、特に苦戦したのが、
窓付き封筒の宛名印刷
でした。
最初は、
「住所を2行に分けて印刷するだけだから簡単だろう」
と思っていたのですが、実際に取り組んでみると、想像以上に難しい問題でした。
宛名印刷の自動化を考えた理由
返金業務では、
- 返金明細書の作成
- 宛名用紙の印刷
- 封入作業
が必要になります。
特に宛名印刷では、Excelに登録された住所データを利用していたため、
「Excelの住所データをそのまま使えば簡単に自動化できそう」
という印象がありました。
しかし、ここに大きな落とし穴がありました。
宛名住所は見栄えが大事だった
返金明細書を窓付き封筒で郵送するにあたっては、2つの課題がありました。
- 住所の文字数が長いと窓枠内に収まりきらない
- 住所を区切りのいいところで改行したい
返金業務ではトラブルが伴っていることもあるので、封筒の第一印象は大事でした。
返金リストに記載された住所をそのまま転記すると、住所欄が崩れてしまう
これが、宛名住所用の紙を手作業でコピペしていた要因でした。
実際に宛名印刷の自動化にpythonで取り組むと、様々な問題に直面します。
住所は思った以上に自由だった
例えば、以下のような住所があったとします。
1
東京都千代田区千代田5-2-3スカイビル402号室
人間であれば、
1
2
東京都千代田区千代田5-2-3
スカイビル402号室
と自然に分けることができます。
ところが、単純に文字数で区切ると、
1
2
東京都千代田区千代田5-2-3スカイ
ビル402号室
となってしまいます。
これでは見栄えがよくありません。
マンション名だけではなかった
最初は、
「マンションやビルという文字を見つけたら、そこから後ろを2行目にすればよい」
と考えました。
しかし、実際には、
- ハイツ
- コーポ
- レジデンス
- 寮
- タワー
など、建物名の種類はさまざまでした。
さらに、
1
北海道札幌市中央区北1条西2丁目5矢代寮
のような住所も存在します。
この場合、
1
2
北海道札幌市中央区北1
条西2丁目5矢代寮
と分割してしまうと不自然です。
スペースがあるとは限らない
住所データによっては、
1
大阪府大阪市北区梅田2-3-9 グランフロント大阪タワーA20F
のようにスペースが入っているものもあります。
一方で、返金リストは他部署がコピペで作成していたので、
1
福岡市博多区博多駅東2丁目5番33号ハイツ博多103
のように、建物名まで連続して入力されているケースもありました。
つまり、
「スペースがある前提」
では処理できません。
完全自動化は難しかった
住所には、
- 表記ゆれ
- 入力ミス
- 長い建物名
- 特殊な住所
などが存在します。
そのため、
すべての住所を100%正しく自動判定することは難しい
ということがわかってきました。
最終的にたどり着いた考え方
試行錯誤した結果、
「100%自動化する」のではなく、「ほとんどを自動化し、怪しいものだけ人間が確認する」
という方法を採用することにしました。
例えば、
- 建物名が検出できた住所 → 自動処理
- 明らかに長い住所 → 要確認
- 判定に迷う住所 → 要確認
という形です。
つまり、
95%を自動化し、5%だけ人間が確認する
という設計です。
むしろ重要なのは「要確認フラグ」だった
振り返ってみると、
最初は、
「どうすれば100%自動化できるか」
ばかり考えていました。
しかし実際に重要だったのは、
「どの住所を人間が確認すべきか」
を判定することでした。
これは、返金業務全体の自動化でも同じでした。
業務改善において重要なのは、
「人間を完全になくすこと」
ではなく、
「人間が確認する件数を減らすこと」
だったのです。
おわりに
住所を2行に分けるだけ。
最初はそう思っていました。
しかし実際には、
- 建物名の判定
- 表記ゆれ
- 住所の長さ
- 例外処理
など、想像以上に多くの課題がありました。
次回は、実際にPythonを使って住所データを処理するプログラムをどのように作ったのか、実装の考え方について紹介したいと思います。