物流DXの進め方｜自動化率を上げるほど、残った仕事は難しくなる

物流DXの話をする前に、どんな物流を扱うのかから始めます。物流と一口に言っても、扱う荷物と規模で話がまるごと変わるからです。

題材は、産地から仕入れた食品を、自社の倉庫から個人宅へ届けるECです。冷蔵、冷凍、常温の3つの温度帯を扱います。倉庫でのピッキングと梱包があり、そこから配送に出る。 食品ECでは、ごく普通の構えです。

流れはこうなっています。

→ 利用者がスマートフォンで注文する
→ お届け日が決まる
→ 決済が走る
→ 倉庫の出荷指示が1件立つ
→ その指示を見て、人が棚から商品を取る
→ 保冷剤を入れて梱包し、便に載せる

最後の2行が重要です。最終的には、人が棚から取って、人が箱を積みます。 どれだけ自動化しても、物理的な商品を動かすのは人です。

物流DXとは、倉庫・配送・配車・受注・在庫といった物流業務を、技術で作り変える取り組みです。倉庫の自動化、配送ルートの最適化、需要予測、伝票の電子化。

なぜ、いま加速しているのかというと、ドライバーの労働時間に上限が課されたからです。同じ人員で同じ量を運べなくなった。運べる量を戻すには、人手を減らすしかない。 だから自動化に投資が向かいます。

食品の場合は、もうひとつ理由があります。在庫が傷むからです。 期限のある商品は、余らせれば捨てることになる。だから需要予測の精度が、そのまま廃棄率になります。

ここで、ひとつ区別しておきます。物流の自動化には、2つの層があります。

→ 物理の自動化 — 倉庫のロボット、自動仕分け、無人搬送。設備の話
→ 情報の自動化 — 受注、配車、伝票、問い合わせ。手続きの話

この記事は、後者の話です。 商品そのものは人が運びます。変えるのは、その手前の手続きのほうです。

前置きはさておき、本題に入ります。

今日は、この受注から出荷までを自動化していって、その先で何が残ったかという話をしていこうと思います。

① 教科書どおりに、自動化を進める

最初は、ほとんどの工程に人が介在していました。

→ 注文の電話とFAXを受けて、紙に書く
→ 商品と数量を、手で出荷リストに転記する
→ 料金と送料を手計算して伝える
→ 在庫は棚を見て数える
→ 決済は代引きか、後から振込

ここから、順番に自動化していきます。

→ 注文をカート化 → 転記が消える
→ 送料と料金を自動計算 → 計算ミスが消える
→ 決済をオンライン化 → 代引きの手間が消える
→ 在庫を引当てで持つ → 棚を見に行く回数が減る
→ 出荷リストを自動生成 → 手作業が消える
→ ピッキングの順路を自動で並べ替える → 倉庫の中の歩行距離が減る

きれいに減りました。 1件あたりに人が触る時間は、最初とは比べものにならない短さになります。

そして、人が触るのは例外だけになりました。棚に在庫が無い、指定された温度帯と違う棚に入っていた、箱に入りきらない。その程度です。

ここまでは、教科書どおりです。

② 自動化率が上がると、残った仕事が難しくなる

ところが、現場の手応えは予想と違いました。自動化を進めても、担当者が楽になった実感を持たない。 同じ話は、自動化を入れた現場でよく聞きます。

件数で見れば、人が触る件数は激減しています。それなのに、負荷感が下がらない。

理由を聞いて、分かりました。残った仕事の性質が変わっていたのです。

→ 自動化を始めたころ、人に残っていたのは「量が少ないだけの、同じ作業」でした。手順書が書けるし、誰でもできる
→ 率が上がりきったあたりから、残るのは「一つひとつ理由の違う例外」になります

引き当てたロットの賞味期限が、お届け日を下回っている。冷蔵の商品が常温の棚に戻されていた。欠品したので代替品を出したいが、アレルギー表示が違う。オートロックで置き配ができないのに、要冷蔵だから持ち帰れない。定期便の変更が締切を1分過ぎて届いた。

どれも違う理由で、自動化を外れています。 だから手順書が書けません。毎回、判断が要る。

判断が要る仕事は、人数では割り切れません。 分かる人が一人で抱え、その人が休むと止まります。

自動化率を上げるほど、残った1件あたりの難易度が上がる。 これが、負荷感が下がらないことの正体でした。

率でいえば、99.9%まで持っていったとしても、残りの0.1%は消えません。 そして残る0.1%は、量が少ないだけの仕事ではありません。性質が違う仕事が、丸ごと残ります。

③ そして、数字が合わない日が来る

ある日、決済側と倉庫側の数字が合わないことに気づきます。

深夜に、決済側には注文が1件立っています。 利用者のカードは、その金額ぶん押さえられている、ということです。

ところが、倉庫側の出荷指示に、その1件だけが出てきません。 前後の時間帯の注文は、普通に並んでいます。1件だけ、無い。

棚から何を取ればいいのか分からない。そもそも注文があったことに気づけない。利用者はカードを押さえられたまま、商品は誰にも積まれない。

原因を追うと、こうでした。

→ ① そのとき、その配送エリアは翌日ぶんの受付を締め切っていた
→ ② それでも利用者が注文した。自動応答が、良かれと思って「明日お届けできます」と案内した
→ ③ 話が進んで決済まで到達し、与信が押さえられた
→ ④ ところが倉庫側は、締め切ったエリアの出荷指示を受け付けない。出荷レコードが作られなかった

決済だけが成立して、出荷指示が存在しない。 いちばん気持ちの悪い壊れ方です。

食品なので、もうひとつ悪いことが起きています。在庫の引当てだけは走っていました。 出荷されない注文のために、期限の近いロットが押さえられたままになる。動かないのに、傷んでいきます。

④ この1件は、監視では見つからない

いちばん厄介なのは、これがエラーとして飛ばないことでした。

→ 例外は出ていない
→ 画面も落ちていない
→ ログにもエラーが無い

壊れたものを探す仕組みは、全部すり抜けます。

ただ、道具の出来が悪いという話ではありません。監視の教科書のほうが、そもそも壊れたものを見るように書かれています。

2016年に出た『Site Reliability Engineering』の第6章に、「もし利用者向けシステムで4つの指標しか測れないのなら、この4つに絞りなさい」という一節があります。挙がっているのは、レイテンシ、トラフィック、エラー、サチュレーションです。

並べてみると、共通点が見えます。

→ レイテンシ — 通った処理が、どれだけ待たされたか
→ トラフィック — どれだけの量が通ったか
→ エラー — 通ろうとして失敗したのは何件か
→ サチュレーション — どれだけ詰まっているか

4つとも、通った処理を測っています。 作られなかった出荷指示は、待たされもせず、通りもせず、失敗もしません。測る対象が存在しないので、どの指標も動きません。

ところが監視ツールの側でも、「無い」を見るのは既定の動作ではありません。サーバ監視で広く使われるPrometheusには absent() という関数があり、公式ドキュメントの説明は「指定した名前とラベルの組み合わせで時系列がひとつも存在しないときに、警報を出すのに使う」です。一定の時間ずっと無いことを見る absent_over_time() も、別に用意されています。

その関数をわざわざ書いた人のところにだけ、「無い」が届く。 書かなければ、無いものは無いまま静かです。

今回この1件が表に出たのも、決済の明細と倉庫の出荷実績を、人が並べて突き合わせたからでした。

突き合わせをしていなければ、この事故は翌月も翌々月も起き続けていたことになります。

そして、この事故には工程がありませんでした。

システムの見積もりは、作る機能で構成されます。受注機能、決済連携、在庫引当て、出荷指示、送り状出力、通知。「自動化を外れたものを誰が拾うか」は機能ではないので、行がありません。

行が無いので、誰の担当でもない。誰の担当でもないので、事故が起きてから初めて存在が認識されます。

⑤ 直してみる — 例外を、工程として設計に入れる

やったことは3つです。

1. 例外の受け皿を、工程として書いた。
誰が、いつ、何を見て、どう処理するか。1日1回なのか、締切前なのか。これを機能一覧と同じ粒度で書き、見積もりに行を作りました。

2. 無いものを数える仕組みを作った。
決済明細と出荷指示台帳を毎日突き合わせ、片方にしか無い行を拾う。 実装は地味ですが、これしかありません。

3. 自動応答が「良かれと思って」やる範囲を、先に閉じた。
従来のシステムは書かれていないことをしませんが、自動応答は書かれていないことをします。 だから「やってよいこと」だけでなく、「やってはいけないこと」を明示する。 受付締切後、在庫の引当て不可、賞味期限が配送日を下回るロット。

そして、直す作業そのものは1時間で済みました。

最初の見積もりは「火曜日まで」でした。ところが実際に中を見たら、2分後には「1時間後」に書き換わっています。

→ 直すのは1時間
→ 見つけるまでのほうが、はるかに長い
→ 見つける仕組みは、そもそも要件に入っていなかった

コストは、直すところではなく、気づかないところに乗っていました。

⑥ あとで知った — 残る例外には、名前がついていた

素朴な対処のつもりでしたが、調べると同じものを指す言葉は、すでにありました。

1つ目。人が介在せずに最後まで通った処理の割合には、名前があります。ストレートスルー処理率（STP率）です。もとは金融の決済で使われてきた言葉で、注文から最終決済までを人手を挟まずに一度で通すことを指します。

そして、この率を上げていくと何が残るかも、同じ文脈で語られています。デジタルで完結する処理が増えるほど、人の側には、例外の対応と解決だけが残っていく。

負荷感が下がらないことの正体が、これです。 人に残るのが例外だけになる、というのは自動化の副作用ではなく、構造からの帰結でした。

2つ目。例外処理ワークフロー（exception handling workflow）という呼び方があります。通常の流れを中断する予期しない事象を、検知し、管理し、解決するまでを一続きの手続きとして扱う、という意味で使われています。

「検知し、管理し、解決する」が、はっきり分かれているのが要点です。 僕が「受け皿を工程にする」「無いものを数える」と別々に扱っていたものは、同じ手続きの中の別の役割でした。

3つ目。確信度の低いものを人に回す組み方は、人間参加型（human-in-the-loop）と呼ばれています。曖昧なタスクは人のレビューへ自動的に回し、明快なものは自動処理を続ける。人が例外を解いたら、自動処理が再開する。その形を指す言葉です。

人を減らすのではなく、人の注意を配り直す。 これが、例外処理の設計思想です。

そして、人が解いた例外は次の自動化の材料になります。受け皿を作ることは、後退ではありません。

ただし正直に書いておくと、STP率をどこまで上げるべきかの正解は、どこにも書かれていませんでした。 高く保ちつつ人の介入を残す、という言い方に留まっています。業務ごとに決めるしかない、ということだと思います。

新しい理屈は、ひとつも要りませんでした。

⑦ 現場で使うなら、この3枚

表1：例外の受け皿（工程として見積もりに載せる）

| 例外の種類 | 検知方法 | 誰が | いつ | 所要（実測して埋める） |
|—|—|—|—|—|
| 棚に在庫が無い | ピッキング時 | 倉庫担当 | 即時 | — |
| 温度帯の取り違え | 検品 | 倉庫担当 | 即時 | — |
| 期限がお届け日を下回る | 引当て時の判定 | 在庫担当 | 毎日 | — |
| 締切後の注文 | 突き合わせ | 運用担当 | 毎日 | — |
| 決済のみ成立 | 突き合わせ | 運用担当 | 毎日 | — |

この表を、機能一覧と同じ扱いで見積書に載せてください。 載っていない工程は、誰の担当でもなくなります。

表2：突き合わせ（無いものを数える）

「ログを1行出して先へ進む」にしないでください。 止めて、人に通知する。

3行目を入れておくのは、食品だからです。出荷されない注文に引き当てられたロットは、動かないまま期限を迎えます。 件数の突き合わせだけでは見つかりません。

表3：自動応答に、やらせないことの定義

最終行が要点です。 「判断がつかないときは、作らない」を明示的に書く。書かないと、良かれと思って作ります。

⑧ 物流にAIを入れるなら、どこか

置き場所の整理もしておきます。

向いていないところ

→ 需要予測 — 従来型の機械学習のほうが精度も説明性も上です。食品では廃棄率に直結するので、なぜその数字なのかを説明できることが要件になります
→ 配車・ルート最適化 — 組合せ最適化の問題であって、言語の問題ではありません
→ 在庫の発注点計算 — 同上

向いているところ

→ 非定型な入力の読み取り — 産地ごとに書式の違う仕入伝票、手書きの規格書、写真
→ 問い合わせの一次対応 — ただし、表3を先に作ったうえで
→ 例外の振り分け — 自動化を外れたものが、どの種類かを判定して担当へ回す

3つ目が、この記事の主題と直結します。 0.1%を人が全部見るのは無理でも、「どの例外か」の判定を機械に任せて、判断だけ人がやる構成なら回ります。

そしてこれは、人間参加型の定義そのものです。確信度の低いものを人に回し、明快なものは自動で進める。

⑨ この考え方が効き続ける理由

自動化率は、これからも上がります。そして、上がるほど残った例外は難しくなります。 これは技術の進歩で解決しません。構造だからです。

→ 率が上がる → 残るのは例外だけになる
→ 例外は一つひとつ違う → 手順書が書けない
→ 手順書が書けない → 人数で割れない
→ だから、誰が持つかを決めるしかない

そして、決めていないと、見積書に行が無いまま誰も引き受けない場所に落ちます。 落ちた結果が、与信だけ押さえられた注文が宙に浮き、引き当てられたロットが誰にも届かないまま期限を迎える、という形で現れる。

自動処理の値段は、これから下がり続けます。差がつくのは、残りの例外を工程として書けるかどうかだけです。

冷蔵庫の整理をしたことがあります。手前から順に、賞味期限を見て入れ替えていく作業です。ほとんどは機械的に片づきました。

最後に、判断のつかないものが残ります。 開封済みで日付の消えた瓶、いつ作ったか思い出せない冷凍の作り置き、なぜか2つある同じ調味料。全体の1%にも満たない量なのに、その日いちばん時間を使いました。

分類はルールでやれます。「どのルールにも当てはまらないもの」は、こちらに残ります。

あの瓶は、結局そのまま戻しました。次に開けたときも同じ判断を迫られるはずです。引き受け手が決まっていない例外は、だいたいこうなります。

以上です。