勘と経験への依存から脱却して アルゴリズムで作業を制御する 　熟練者の勘と経験でしのいできた現場はいずれ限界を迎える。
熟練者の高齢化による退職で業務の継続が困難になったり、ビジネスの伸張に伴う取扱量の増加で人間が管理できるレベルを超えてしまったり、日々の努力だけでは乗り越えられない壁に直面することになる。
　既にシステム化を済ませている現場でも、旧態依然としたレガシーシステムを更新することもなく使い続けていれば、いつかは保守切れとなり、対応できる業者がいなくなる。
いつシステムが止まってしまうか分からないというリスクを抱えることになる。
　21世紀の原材料はデータである。
物流現場は、膨大な量のマスター、いわば静的データと、トランザクションの動的データを生み続けている。
ただし、それを制御するのは人間には不可能であり、ソフトウエアによってのみ可能となる。
　物流を持続可能なものとするためには、これまで人間がやってきた仕事をシステムに任せて、人間という限られたリソースを、人間が得意とする領域に再配分しなければならない。
データがそれを可能にしてくれる。
　ただし、ただ集めただけのデータからは何も生まれない。
データをいくら眺めたところで答えは見つからない。
そのデータの中に答えがあるかどうかさえ分からない。
　必要な範囲かつ必要な粒度のデータを保持することの重要性は、これまで本連載でも繰り返し述べてきた。
そこで大事なことが、データの粒度と精度を必要とされるレベルにそろえることである。
データの粒度が粗いと、見たい視点から情報を見られず、データの取り直しが発生する。
データの精度が粗いと判断を迷わせる要因となる。
　データ駆動型ロジスティクスの実現に向けて第一にやるべきは、データの活用目的の明確化である。
目的に沿って集計・分析することで、初めてデータは生きてくる。
カイゼンのための仮説立案や効果検証を行ったり、業務判断をアルゴリズムに代替させたりすることができる。
　データの取り方は活用目的次第で変わってくる。
入荷・格納工程の場合であれば、格納間口を指定せず作業者に判断を委ねる、あるいはＳＫＵごとに決まった間口に格納するよう指示するのと、業務の効率性を上げる目的で指示を作成するのとでは、必要なデータの範囲や粒度が違ってくる。
　業務の効率性を上げる出荷指示とは例えば次の通りである。
　格納先として最適な間口は、ＳＫＵ別の出荷特性ＡＢＣを鑑みて判断する。
出荷頻度が高い商品はすぐに補充することが可能な場所に保管することで在庫補充の動線を短縮化する。
それがピックエリアの効率化にもつながっていく。
　保管効率という観点では間口サイズの標準化が必要になる。
その上で間口サイズごとの入数をＳＫＵ別に設定する。
入荷数量と各間口の保管状況を付き合わせて、既存の間口に追加して投入すべきか、新たなロケーションを指定すべきかをシステムに判断させる。
また、間口の空きが一定期間を過ぎたら、自動でサイズの小さい間口へ移し替える指示を出してスペースのムダをなくす。
　出荷工程でも、ＳＫＵの出荷特性にあわせて最も業務効率が高くなる出荷方式をアルゴリズムが選択して、出荷方式の組み合わせを行う。
　そのために、その現場の設計フェーズのエンジニアリングでＳＫＵの荷姿特性と出荷特性を分析する。
どのような出荷方式の組み合わせが最も作業数と作業タクトが少なくなるのか、どうすれば全体の所要工数が最小化するのか、どのようなレイアウトを組めば移動タクトやピックタクトが最適となるのかを検証して、その結果をＷＭＳの設定に反映させる。
　例えば、商品の出荷特性を見た時に、Ｓランク品で大量にケース出荷（またはパレット成り）される特性がある場合は、トータルピック（＆種まき）方式が最適となる。
一方、出荷量も物量も少ないＳＫＵは高回転のオーダーピック方式の方が作業効率は高くなる。
　ケース単位で出荷するからといって、一律にトータルピックのみ、オーダーピックのみという作業方法を選択すると、作業効率は最適化されない。
現場は忙しくしているけれど効率は悪いという状況を生んでしまう。
　複数ケースにまたがるバラ出荷の場合であれば、どのケースに何を詰め合わせるかが、ピック作業の生産性と出荷ケースの充填率に大きく影響する。
当社ではこれを「引当種別」と称してアルゴリズム制御している。
そのように、所要工数を最小化するには、指示書の組み方が重要なのである。
目的に沿った必要な粒度で 精度の高いデータを蓄積する 　データの活用目的を定めることで、必要なデータの粒度と精度が明らかとなる。
　データの粒度は、データ項目の定義に組み込んで定義する。
業界標準のデータ連携の分野では、データ項目定義の標準化が進んできている。
特に食品業界で採用が進んでいる標準ＥＤＩの「流通ＢＭＳ」の採用企業は２０２１年に１万６千社を超えた。
　他にも、識別コード、伝票、受渡データ、外装、搬送什器（パレット）など、データに限らず標準化の動きは活発化している。
物流危機が社会的課題として認識されるようになったことから、過去の商慣習や企業間の垣根を取り払い、連携しようという機運が大手企業を中心に高まってきている。
　ところがデータの取り扱いについては企業間・企業内の連携が進んでおらず、効率化の妨げになっている。
例えば商品マスターに荷姿ごとの正しい３辺サイズが定義されていて、そのマスターがサプライチェーン間で共有されていれば、それをアルゴリズムのマスターデータとして利用して庫内レイアウトの最適化や業務設計に生かすことができる。
　しかし、実際には商品マスターに３辺サイズを登録していないメーカーやアイテムがあったり、あるいはデータ項目はあっても不正確なデータが混ざり込んでしまっていたりして、使いものにならないことが大変に多いのである。
　一方、データの精度は運用で決まる。
データ管理の重要性はデータ精度の維持による直接的な効果は分かりづらいため見過ごされがちだ。
往々にして優先度が落とされてしまう。
しかし、目的認識を持ち、確固たる運用ルールを定め、それを支える仕組みに投資をしている企業は、生産性が高く、結果もしっかりと残している。
　例えばデータ登録にあたっては、表記の“揺れ”や誤記が発生しないように仕組みで担保することが重要である。
重量データの場合であれば、重量を表す数値とその単位を別項目として管理して、システム入力上も誤りがないように制御されていれば、ノイズは生じない。
　ところが、移行前の旧システムにおいて、データ項目は文字列、入力は人の手に委ねられている場合（そうしたシステムが実際に多い）、旧システムに登録されている「２５０ｇ」「250g」「250G」「250」などのデータが、同じ重量なのに別のものと見なされてしまうことになる。
あるいは、３辺サイズの「高さ」情報を「幅」や「奥行」の項目に入力したり、項目内の単位（㎝、㎜など）の認識相違から桁数を誤って入力したりといった間違いが発生する。
　移行期や運用当初にこうしたノイズが見つかった場合はデータのクレンジングが必要である。
その手間を惜しむと、新システムは設計通りに稼働せず目的を達成することはできない。
大量データのクレンジングには膨大な労力を伴うが、これもクレンジングのためのアルゴリズムを開発することで効率化できる。
正しいデータの蓄積と再利用が 物流ネットワークをＤＸする 　使用済みの原材料は再利用できる余地が限られている。
燃やせばＣＯ２を排出する。
しかし、データに関してはまったく逆である。
データは蓄積することで価値を増す。
配車・配送の実績データは、自動配車システムの機械学習の学習データになる。
構内作業の実績データはアルゴリズムに基づく作業指示に利用できる。
さらに環境データは自動運転に必要な原材料として今後その重要性が高まっていく。
　これまではデータを蓄積しても処理する能力がなかった。
しかし、コンピューターのＣＰＵ／ＧＰＵの性能が飛躍的に向上したこと、大量のデータを蓄積するストレージが安価になったこと、閉じたネットワークでなくクラウド上でデータを管理できるようになったこと、通信の高速化によって必要な情報をリアルタイムに入手することが可能になったこと、などによってデータを蓄積して活用する環境が整った。
　データをルール通りに標準化して蓄積することで、データの活用範囲を今後は社内から外部へと広げていくことができる。
　フィジカルインターネットなどが構想する未来の物流の在り方は、物流拠点と配送網をノード（結節点）とライン（線）とみなし、あるラインが分断されたとしてもその時々の最適ルートに遅滞なく切り換えることでモノの流れを維持できる世界だろう。
そこではネットワークに参加する各社のリソースが、あたかも一つのインフラのように仮想的につながれて、トランザクション単位で非稼働のリソースが活用される。
　標準化されたトランザクションをインターネット通信の「パケット」とみなせば、その単位でリソースの稼働率を高めることができるようになる。
当社ではそれを「パケット・ルーティング・ロジスティクス（ＰＲＬ）」と呼んでいる。
生産と需要のデータ、ネットワーク全体のリソースの稼働状況、原価データなどから構成されるビッグデータがＰＲＬを動かす燃料になる。
　それがデータ駆動型ロジスティクスの世界観である。
そこでは標準化された業務が、無人化された倉庫で、パケットのように処理されて、自動運転で届けられる。
空きパケットの情報までが常にリアルタイムで共有され利用される。
究極の省人化が実現して、物流ネットワークが再生可能かつ最小限のエネルギー消費で駆動する持続可能な社会インフラとなるだろう。