こんにちは、こんです🦊
100日チャレンジ Day 59 の記録です！
今日は、これまで取り組んできた「特典配布自動化アプリ」に、出荷実績の追跡対応機能を新たに追加しました。
単に特典を割り当てるだけではなく、「どの注文にどの特典が付与され、どのように発送されたのか」を正しく追跡・照合できる仕組みを整備することが目的です。
🔍 実験のきっかけ：「受注番号ベースで戻す必要がある問題」
今回の特典付与処理では、複数の受注を顧客単位で名寄せして、1つの出荷にまとめるという処理を行っています。
これは、送料や出荷負荷を軽減する目的で、新たに「顧客番号」を出荷用の受注番号として扱うという設計でした。
一方で、出荷完了後にECモール側へ発送情報（追跡番号など）を戻す際には、元の「受注番号」ごとに戻す必要があるという制約があります。
このため、
「顧客番号単位で1回の出荷処理をしても、
EC側には受注番号単位で発送情報を反映しなければならない」
という実務上のギャップが発生していました。
つまり、出荷は顧客単位で行ったにも関わらず、
データ返却は元の受注番号単位で対応しなければならないという、
粒度の違う管理が求められるわけです。
🛠 今日取り組んだこと
この“出荷と受注の粒度ズレ”を解消するために、以下の3つの処理機能をアプリに組み込みました。
✅ 1. 出荷マッピング用データの生成機能
まず行ったのは、「どの注文番号が、どの顧客番号の出荷にまとめられたか」をリスト化する処理の実装です。
元データには、複数の注文番号がカンマでまとめられている列がありました。
それをPythonで展開し、1行につき1注文番号となるように変換。
そしてそれぞれに対して、「まとめ出荷で使った新しい番号（顧客単位の管理番号）」と「顧客ID」を紐づけて出力しました。
このデータがあることで、出荷はまとめて行いながら、注文単位での情報返却が可能になります。
✅ 2. 出荷データの整合性チェック表の表示
次に、アプリ内で作成した出荷データ（実際に倉庫に連携されるもの）と、今回生成したマッピングデータを照合して、以下の項目で件数を比較できる表を作成しました：
このようにして、アプリの処理結果が本当に一貫性を持っているかどうかを、UI上ですぐに確認できる仕組みを整えました。
✅ 3. 元注文データとの突合チェック
さらに、元となる受注データ（特典をつける前の状態）と照合し、
対象データと非対象データを横断して、重複を除いた注文番号の総数
顧客IDの総数（ユニーク件数）
を計算。
これがマッピングファイル内の「注文数」「顧客数」と完全に一致しているかどうかをチェックする仕組みも導入しました。
これにより、「まとめて処理したけど、何か見落としてないか？」という不安を解消できます。
✨ 今日の学びとよかったこと
「まとめ出荷」と「受注単位の処理」は業務上の目的が異なるため、両方の視点で情報を管理できる仕組みが必要
マッピング用CSVを明示的に出力することで、モール連携や問い合わせ対応の信頼性が格段に向上
一見地味でも、“誰が見ても分かる”形にしておくとチーム全体の安心感が違う
📝 まとめ
今日は、特典配布アプリに業務としての“信頼性”を支える最後の一手を加えることができた日でした。
出荷をまとめるのはコスト削減や効率化のため。
一方、ECの注文管理やモール連携には“受注単位の正確さ”が求められます。
このような「業務上の目的とシステム上の要件のギャップ」を埋めるためには、
単なる自動化ではなく、“整合性を確保する仕組み”が欠かせません。
今日はその仕組みを形にすることができて、とても満足度の高い取り組みになりました。
次回は、このマッピングデータを活用して「納品書への自動反映」や「出荷除外チェック」など、より現場に直結した施策に広げていく予定です📦💡
#業務改善 #物流DX #Streamlit #注文管理 #追跡番号 #整合性チェック
#100日チャレンジ #python #社内ツール開発 #出荷業務自動化 #UIUX設計 #受注処理 #データ可視化 #業務設計 #信頼性向上