受注管理システムを入れても出荷作業は自動化されない — 13手順に分解して分かったこと

受注管理システムは入っています。ネクストエンジンを使って、複数モールの注文を1か所に集め、在庫を同期し、伝票を発行しています。導入したのは何年も前で、これ自体はうまく機能しています。

それでも毎日、人が画面を触っている時間が残っていました。出荷指示です。

朝と昼の2回、担当者がブラウザとスプレッドシートとプリンタのあいだを行ったり来たりして、一便あたり1時間近くかけている。システムは入っているのに、この部分だけ手作業のまま残り続けていました。

この記事は、その出荷作業を13手順に分解して自動化するまでの記録です。うまくいった話だけでなく、送り状の並び順が乱れて現場に手作業が発生した日と、手順を丸ごと1つ飛ばした日についても書きます。物流の自動化に取り組んでいる方に効くのは、成功例よりそちらだと思うからです。

受注管理システムを入れても、出荷作業だけは手作業が残る

「システム化されている」と「自動化されている」は違う

受注管理システムを導入すると、注文データの集約、在庫の同期、受注処理、伝票の発行はまとめて片付きます。ここは確かに効率化されました。エクセルで受注管理をしていた頃には戻れません。

ところが出荷指示だけは残りました。理由ははっきりしていて、この業務が1つの画面で完結しないからです。

実際に必要なのは、受注一覧からのCSVダウンロード、受注明細の再抽出、スプレッドシートへの貼り付け、容積による発送方法の判定、受注分類タグの一括付与、納品書PDFの出力、ピッキングリストの印刷、配送情報のダウンロード、そしてメール送付。画面を7つ以上またぎ、そのあいだにスプレッドシートとプリンタが挟まります。

システムの機能が足りないわけではありません。機能はそれぞれ揃っています。揃っているものをどういう順番で、どの条件で使うかという部分だけが、ずっと人の頭の中にありました。

残っていたのは「判断」ではなく「画面をまたぐ回数」だった

私たちは長いあいだ、この作業が残っているのは「人の判断が要るから」だと思っていました。荷物の大きさを見て発送方法を決める、地域を見て運送会社を選ぶ。だから自動化できない、と。

13手順に書き出してみて、その前提が間違っていたことが分かりました。

自動化の前に、13手順を全部書き出した

作業を録画して、操作ではなく「なぜそうするか」を拾う

最初にやったのは、担当者に実際の作業を通しでやってもらい、画面を録画することでした。ポイントは、操作そのものより判断理由を拾うことです。操作は画面を見れば分かります。分からないのは、なぜその選択をしているのかという部分です。

たとえば最後の配送情報のダウンロードで、対象を選ぶ基準が「クリックポスト以外を全部」でした。運送会社の固定リストではありません。この違いは録画を見るだけでは分かりませんが、音声の解説には残っていました。

実際、同じ日の2便で内訳を比べると、佐川急便・ヤマト・ゆうパケット・ゆうパックの4種類すべてが、どちらかの便で0件になっていました。もし固定リストで実装していたら、新しい配送方法が増えた日に黙って落ちます。 判断理由を先に押さえておかないと、動いているうちは気づけない壊れ方をします。

書き出して初めて「手作業の正体」が分かった

手順の中に、担当者が毎回目で確認していた工程がありました。荷物の容積が一定以上なのに小型便のままになっている注文を探して、手で直す作業です。これこそ人の判断だと思われていました。

書き出して調べたところ、判断ではありませんでした。 発送方法を自動変換する処理の対象から、一部の店舗が設定上外れていたのです。人が毎日探していたのは、判断が必要な例外ではなく、設定のカバレッジ穴でした。穴を塞げば工程ごと消えます。

自動化を検討すると、その作業が何なのかを言葉にせざるを得なくなります。書き出しただけで消える作業がある、というのが最初の収穫でした。

分解して見えた、画面では気づけない3つの罠

罠1: 同じ役割のボタンが、画面ごとに違う

受注一覧と受注明細一覧では、同じ「検索実行」ボタンの内部的な名前が違います。アイコンの並び順で要素を指定すると、別の画面では違うものを掴みます。

ネクストエンジンにはAPIも用意されていますが、APIで届く範囲と、画面でしかできない操作の境目があるというのが実務上の結論でした。API連携だけで組もうとすると、届かない部分が手作業のまま残って中途半端になります。

罠2: 既定値が「効いていなかった」

これが一番大きな罠でした。次の章で詳しく書きます。

罠3: 固定ファイル名は、同じ日の2便目で上書きされる

出荷は1日2便あります。出力ファイル名を固定にしていたため、午後便が午前便のファイルを上書きしていました。データが消えたわけではないので気づきにくく、後から検証しようとしたときに初めて「昼の分がない」と分かります。 日付と便で分けて、既存ファイルがあれば止める、という二重の守りに変えました。

送り状の並び順が乱れた日

ある日の午前中、印刷を終えた後に指摘がありました。「今日の午前中の出荷、送り状の並び順がおかしかったっぽい」。

現場では、パートスタッフが1枚ずつ突き合わせてカバーしてくれていました。自動化した結果、現場の作業が増えていたわけです。

「伝票番号順」と表示されているのに、その順で出ない

原因は、納品書を出力するダイアログの並び順の指定でした。

ダイアログを開いた直後、画面には「伝票番号順」と表示されます。ところがその選択肢は、表示されているだけで選択されていない状態でした。何も触らずに送信すると、サーバー側の既定である「発送方法 → 支払方法 → 伝票番号順」で出力されます。

画面には正しい文字が出ているので、目視では永久に気づけません。

確定させたのは目視ではなくデータでした。出力された納品書48件の並びと、受注データの発送方法・支払方法を突き合わせたところ、ブロックの境界が発送方法と支払方法の変わり目と1件も外れずに一致し、各ブロックの中だけが伝票番号の昇順になっていました。これは「発送方法、支払方法、伝票番号順」という選択肢の挙動そのものです。

さらに厄介なことに、納品書と配送情報のデータは同じ並びで出力されます。納品書の指定ミスが、そのまま送り状の並びに伝播していました。

対処は「選ぶ」ではなく「選んだ結果を読み戻す」

修正は単純で、並び順を明示的に選ぶようにしました。ただしそれだけでは足りません。選んだ直後に選択状態を読み戻し、意図した値になっていなければその場で処理を止めるようにしました。同じ日の午後便で検証し、出力が完全な昇順になっていること、現場で追加作業が発生しないことを確認して決着しています。

ここは他社システムの不具合の話に見えるかもしれませんが、原因は私たちの側にあります。 触っていない項目を「既定のままで正しい」と決めつけて、手順書にまで「そのままでよい」と書いていました。

得られた教訓は一行です。「既定値だから触らなくていい」は、その既定値が実際に効いていることを確かめてから言う。

手順を飛ばした日 — 「0件だから対象なし」は正常の証拠にならない

翌日の午前便、72件の出荷で、今度は手順を1つ丸ごと飛ばしました。午前便だけに必要な発送方法の一括変換で、27件が変換されないまま出荷されました。

「見落とし」で片付けると再発するので、原因を3つに分解しました。

1. チェックリストにその行がなかった。 表を上から潰していく進め方だったので、載っていない作業は実行されません
2. 2つの作業が1行にまとめられていた。 使うプログラムが同じだったので「片方をやればもう片方もカバーされる」と読める書き方になっていました。実際は設定が違う別作業です
3. 検算が自分の実行結果同士で閉じていた。 27件を抽出し、27件にタグを付け、27件を出力し、27件を確認していました。何度も一致しているのですが、一致していたのは全部が変換前の同じ数字です

決定的だったのは、異常のサインを正常と読んだこと

途中の確認で「ヤマト0件 → 対象なし」と判定して先に進んでいました。しかし過去の午前便は24件、15件とヤマトが必ず出ています。午前便でヤマトが0件であること自体が、「まだ変換していない」というサインでした。

「対象が無い」と「まだやっていない」は、画面上どちらも0件に見えます。0件は正常の証拠になりません。

対策は手順を足すことではなく、出口を塞ぐこと

再発防止としてチェック項目を1つ増やすのは簡単ですが、それは同じ理由でまた漏れます。載っていない、読み飛ばす、という失敗の構造が変わっていないからです。

そこで、手順ではなく完了条件の側にゲートを置きました。午前便で変換前の発送方法が残っていたらエラーで止める。ヤマトが0件でもエラーにする。そして前回の同じ便の内訳を並べて表示する。自分の実行結果同士ではなく、独立した基準と突き合わせるためです。

80分が15分になった。ただし本当のリターンは別にある

初回の通し実行は約80分かかりました。ただしその大半は導線の特定とバグ修正で、次回は10〜15分の見込みです。実際、2回目は72件という初回の1.5倍の物量を処理しています。

ただ、時間の短縮は結果であって目的ではありませんでした。本当のリターンは別のところにあります。

手順が人の頭の中から出たことです。

• 担当者が休んでも出荷が止まらない
• 引き継ぎが「見て覚えて」ではなくなる
• 判断基準が文章になっているので、ルールを変えたときに何が壊れるか事前に分かる

在庫管理や受発注と違って、出荷業務は止まると当日の売上に直結します。それが一人の担当者の記憶の上に乗っている状態は、効率以前にリスクでした。

中小ECが物流の自動化を進めるときの順番

最後に、同じことに取り組む方向けに、順番だけ整理しておきます。

いきなりAPI連携から入らない

物流の自動化というと、倉庫設備やロボットの話になりがちです。ただ中小ECで先に効くのは、画面操作の側です。人手不足への効果もこちらのほうが早く出ます。

そのうえで、APIから入るのはおすすめしません。API で届かない部分が必ず残り、そこが手作業として残ると、結局「半分自動化」で運用が複雑になります。まず全手順を書き出して、どこがAPIで、どこが画面操作かを地図にしてから着手してください。

「自動化しないこと」を先に決める

すべてを機械の判定に任せると、例外のたびに壊れます。私たちの場合、特定の汎用品番は容積のルールから外して固定の発送方法にする、北海道と沖縄は別ルールで扱う、と先に決めて明文化しました。

例外を後から見つけて場当たりで足していくと、ルールが誰にも説明できないものになります。

検証を人の目ではなくコードに埋める

「成功しました」という表示は、入力側の確認でしかありません。指示が通ったことは分かっても、出てきたものが正しいかは何も言っていません。送り状の並び順の件がまさにそれでした。

出力されたファイルを1回読み直して初めて検算になります。手間はかかりますが、ここを省くと、今回のように現場が黙ってカバーしてくれている状態に気づけません。

---

私たちは自社のEC運営と物流を、外注ではなく内製で組み替えてきました。その背景については気づいたら社内ツールが20個超えていたやネットショップ運営を外注せず内製化した話にも書いています。逆に、自社でやらずに外に出す判断をどこで引いたかはアパレル発送代行の料金相場と選び方にまとめました。

出荷業務や受注処理の効率化、物流まわりの仕組みづくりについては、実際に自社で回している立場からご相談に乗れます。サービス紹介に取り組みの内容を、お問い合わせにご相談の窓口をご用意しています。同じところで詰まっている方の役に立てば幸いです。