荷物・梱包・輸送・引き渡しをつなぐ、
TIXIMAXの物流管理基盤

物流サービスの裏側にある、複数の仕事

TIXIMAXは、購入代行や国際配送を案内する事業です。お客様にとっては「依頼した商品が届く」という一つの体験でも、その裏側には受付、倉庫、梱包、輸送予約、書類、発送、到着という仕事があります。公開サイトのサービス紹介と、その業務を支える管理システムは、役割が異なります。

本記事で扱うのは、TIXIMAXの物流管理側の開発です。荷物を登録して追跡番号を表示するだけではなく、荷物のまとまりと移動する区間、その時点で実行できる作業を扱います。なお、日本向けサイトと国際向けサイトでは、対象となるサービスの案内をご覧いただけます。

荷物・梱包・輸送を、同じものとして扱わない

複数の商品を一つに梱包したり、荷物を分割したり、複数の梱包をまとめて輸送したりする場面では、一つの番号にすべての情報を集めるだけでは関係がわかりにくくなります。商品や荷物と、それをまとめる梱包、移動を担う輸送を分けて考える必要があります。

物流サービスには、荷物、梱包、出庫、輸送区間の管理と、統合・分割・入れ子構造を扱う操作があります。倉庫や運送事業者、フォワーダー、航空運送状も別の情報として管理し、業務上の関係をつなぎます。

これはデータ項目を細かくするためではありません。「この梱包の中には何があるか」「どの輸送に載せるのか」「到着した荷物はどの依頼に対応するか」を、担当者が異なる工程から確認できるようにするための整理です。

出荷を、一つのステータス更新で済ませない

輸出工程には、混載、輸送予約、Commercial Invoice・Packing Listなどの帳票、通関済みの記録、発送、到着という流れがあります。「発送済み」という表示だけでは、その前に必要な仕事がどこまで終わったかを扱えません。

実装では、通関済みから発送準備完了へ、発送準備完了から輸送中へという状態の変化を扱います。発送処理は、現在の状態と通関済みの記録を確認してから進みます。輸送の更新と、その変更を伝えるイベントの記録も組み合わせています。

進捗を見せることと、次の工程へ進めてよいかを判断することは別です。 物流管理では、その両方を扱う必要があります。ここでいう通関済みの記録は、システムが通関の許可を自動で取得するという意味ではありません。

追跡は、荷物と輸送の関係をたどる仕事

お客様や担当者が知りたいのは、単に最後に更新された文字列ではなく、自分の荷物がどの工程にあるかです。一つの輸送には複数の荷物が関わり、一つの荷物の配送にも複数の区間が関わります。

物流基盤には、荷物や輸送区間に関連づく追跡情報を集約する接点と、配送会社からのWebhookを受け取る仕組みがあります。配送側で発生した情報を、荷物を管理する側へ受け渡す構成です。

外部イベントの受信と社内の業務操作は、同じタイミングで起こるとは限りません。どの情報をどの荷物へ関連づけるか、重複した操作や通知をどう扱うかも、システム連携の設計範囲になります。

顧客対応と倉庫作業を、役割で分ける

利用者が依頼や荷物を確認する操作と、担当者が出荷や輸送を管理する操作は異なります。物流サービスでは、管理者・業務担当者・利用者の接点を分けて、扱う業務を構成しています。

さらに、問い合わせ対応には、荷物だけでなく顧客の情報や相談の経緯も必要です。その領域はCRM・顧客プロフィール側と役割を分けています。物流の画面にあらゆる営業機能を詰め込むのではなく、それぞれが担当する情報と連携の境界を整理します。

会話、担当者、商談、注文ドラフトのつながりについては、TIXIMAXのCRM・マルチチャネル開発事例で詳しくご紹介しています。同じ事業を、物流と顧客対応という異なる開発領域から紹介するものです。

この事例で伝えたいこと

物流のシステム化は、紙の情報を入力欄に置き換えることだけではありません。現物のまとまり、移動の区間、業務の状態、担当者の役割を整理し、その関係を画面とデータに表す開発です。

Famgiaは、実際に動く業務を理解したうえで、どこを共通化し、どこを独立した管理単位にするかを考えます。国や拠点をまたぐ業務でも、一つの抽象的な「配送」にまとめず、次の仕事へ情報を渡せる構成を目指しています。