【スペシャリスト解説】サプライチェーンマネジメントにおけるデータ活用の課題

ENTユニットの位置づけと、サプライチェーンを取り巻く課題

株式会社ブレインパッド・八坂 裕一郎（以下、八坂）　そもそもENTユニットをはじめとした、ブレインパッドの3つのアカウントユニットは、各々の対象となる業界のお客様と共に課題を解決していくため、ブレインパッドの持つソリューションや人材をチームとして提供していきます。私たちはお客様と一緒になって、課題を設定するところから解くところまでを一気にやらなければなりません。そのためには、お客様の属している産業とその構造を理解し、それらの課題を解く経験や実績を積み重ねることが重要です。そこから、データサイエンスを用いてそれぞれの産業独自の課題を解決するソリューションを生み出す。この役割をアカウントユニットが担っていきます。

ENTユニットが関わる製造業や流通業はこれまで日本を支えてきた産業なのに、なかなかデータ利活用が進まない実状があります。こうした状況を早川さんはどう捉えていますか？

【関連記事】
サプライチェーンマネジメント（SCM）とは？成功事例や必要性・メリットをわかりやすく解説

株式会社ブレインパッド・早川 遼（以下、早川）　企業におけるデータの蓄積が比較的早かったのがECサイトやWebマーケティングが発達したBtoCの領域で、webのログデータを中心に蓄積がすすんでいったという時代的な背景がありました。技術の進歩やデータの有用性の理解が進み、ようやく製造や流通領域のデータが少しずつ取れるようになってきて、そのボリュームもかなり増大してきたました。それに伴い我々が支援できる領域も広がってきています。データが整理されていなかったり、ところどころ歯抜けがあったりするなどまだまだ問題は多いのですが、チャレンジできる土台がそろってきた状況だと言えます。

八坂　それに加えて、お客様のやりたいことやDXの定義が明確になってきて、データ利活用で何ができるかについての解像度も高くなってきています。明確な要望が上がるようになってきて、それを実現するため弊社の培ってきたノウハウや、お客様のドメイン知識を融合させて課題解決をしていっているのが、ENTユニットの現在地です。

それでは、サプライチェーン全体のトレンドや課題感およびDX推進が必要な理由について考えていきたいと思います。

SCM全体のDXは、まだまだ進んでいないという実感です。これはバリューチェーンの中でも、サプライチェーンの中でもなかなかデータが集まっていなくて、しかもやりたいことが細切れになっているからだと思うのですが。

株式会社ブレインパッド・塩見 佳大（以下、塩見）　何をやりたいかはまだまだ整理できていませんが、社会的に要請されていることは結構ある気がしています。代表的なのが「2024年問題」への対応やCO2の可視化です。そうした労務管理や環境保護など、直接利益や売上には結びつかないけれども、管理はきちんとやりなさいと社会から求められることが多くなっているのでないでしょうか。

株式会社ブレインパッド・魚井 英生（以下、魚井）　SCMに関して言うと、たとえば在庫や物流の計画に関しては、「Excel職人」と呼ばれるベテランが2人ぐらいで1週間ほどかけて、経験を元に計画を立てています。その方々が高齢化していて、退職までにそのノウハウをITの力で現場に残したいというニーズがかなり高まってきていると感じます。あくまで一例ですが・・・。

早川　魚井さんが言うベテランの退職と、それに加えてそもそも人手不足が深刻で、特にサプライチェーン領域は裏方仕事で影が薄い印象があって、若手が定着しにくいようです。そんな背景から、業務の負荷を極力小さくして、少ない人数で回していけるようにしないといけなくなっています。

八坂　私の見立てですと、サイロ化されている組織やデータを改めて横断的に見ていくことによって、その中で起きていることを定量的・定性的に捉えつつ、次の効果を出す。そのための策を、我々のような企業と一緒になって考えていくところが第一歩と思うのですが、みなさんどうですか。

塩見　それに加えてオペレーションの整流化も必要です。データが細分化されているということは、業務や会社が細分化されているということです。会社間のデータの形式が違う、会社ごとに求める配送のレベル感が違う、など統一されていないオペレーションが物流全体に対してかなり悪影響を与えていると思うのです。データを活用することだけでなく、それがオペレーションとどう関連しているのかをしっかり見極める必要があると最近強く思います。

八坂　アウトプットされるデータも違いますし、それぞれの部署やカンパニーによって導入しているシステムが違うので、やりたいことはわかっても時間がかかります。

塩見　物流業界は多重請負構造で、倉庫の人手の調整は別の会社が入っているとか、さらにその会社が別のトラックの会社に委託しているということが多いです。企業が保持しているデータのほとんどは自社の事業領域に閉じていることがほとんどなので、全部を統一してデータを持っている会社は非常に少ない。サプライチェーンがつながっているように見えて、実は全然つながっていないという問題につながっています。部分最適で今までやってきたことを、事業として集約して一本化できるプレーヤーが出てくると状況がかなり変わるのではないでしょうか。

八坂　製造を除いた物流ネットワークを共有する形にし、企業はサービスで利益を上げてもらうのがゆくゆくは適正な戦い方ということでしょうか。

塩見　ネットワークの共有はその通りだと思います。

早川　プロセスの自動化もかなり実現している気はしていて、だからこそオペレーションの標準化やデータ管理がより重要になってくると思っています。ロボットやAGV（無人搬送車）を使おうと思うと「よしなにやって」では済まなくなり、現状把握やそれに伴うアクションをアルゴリズムやデータに置き換えないといけません。自動化していくためにも、そのあたりをきちんとやっていかないといけません。

八坂　まさしく魚井さんが言っていた、生産計画を立てているベテランのノウハウが引き継がれない問題とつながりますね。

魚井　おっしゃる通りで、自動化のテクノロジーは重要になってくると思います。ただ全社的にスケジューラーを導入して解決を図るトップダウンなアプローチを一部で見かけますが、それでは難しいと思います。企業ごとにルールも違いますし、データも違うので、汎用的なスケジューラーの導入自体が正直難しいと思います。

八坂　先ほど塩見さんが触れていたような、そもそもデータの可視化ができていないケースは結構あると思うのですが、いかがでしょう。

魚井　データがたまってからプロジェクトを始めるという話が多い気がします。特に研究開発のDXではよく聞くのですが、データの蓄積に人件費が大きくかかるため、それはむしろ非効率です。データをためながらプロジェクトを実施していく考え方が大事だと思います。

ツールによるサジェストを得ながらデータをためていくのがよく、データがたまりきってから始めてしまうとROIが合いません。

塩見　そもそも物流の全体像を捉えることが本当に難しいと思います。物流の体系立った考え方をインプットする機会は、おそらく新人研修ぐらいしかなく、その後は自分でキャッチアップしないと、どういうKPIで管理すべきといったこともわかりません。

その上で取り扱いが難しいデータが多い。手書きの伝票の中に実はとても重要な数字が入っている。出荷の情報と入荷の情報と在庫のデータを全倉庫・全商品分付き合わせなければいけない。在庫の名義変えが行われると商品コードが変わってしまい商品が連続して追えなくなるなど、さまざまな問題があります。

取りあえず分析してみよう、といったとっかかりすら得られていないケースがかなり多いと感じます。その上、物流の体系だった考え方がわからないので、お手上げになってしましますね・・・。

八坂　課題やKPIを定量化ができていないようですが、その理由は何でしょうか。

塩見　何を定量化していいかがまずわかりません。自社のトラックあたりの積載率がどういう数式で求められるかが曖昧になっている、という方も現場経験のない方々のなかにはいらっしゃったり、積載率から派生してどういう見方をするべきか、そのイメージも湧かない人が多い。さらにデータの取り回しが非常に難しいので、Excelでは太刀打ちできないということではないかと思います。

八坂　データを活用して何ができるか、それをするためにどのようなデータが必要か、そのデータが今どこにあるのか、そもそもあるのかなど、アセスメントが必要な状況ですね。

塩見　先ほどもあったように、物流は発注する人、在庫を見る人、出荷する人、営業する人とかなりサイロ化されています。物流のサプライチェーン全体を広い視点で見ている人もいないし、そういう役職もそうありません。工場や倉庫など建屋単位だと全体管理している人がいるから、そこでの課題はある程度見えています。ですがサプライチェーンという抽象的な業務の中で、入荷、在庫、出荷、受注、発注といった物流のすべてを見ている人はあまりいません。そのため、どこに自分たちのボトルネックがあるのかがわからないのです。

八坂　CSCO（最高サプライチェーン責任者）やCLO（最高ロジスティクス責任者）といった、全体を横断的に見る人がなかなかいないというのはまさしくそうですね。特に日本では。そういう人が任命されたとしても、まずは可視化から始めるというところですかね。

塩見　物流に関わる会社の内部だけではなくて、SCM全体を見るのであれば下流にあたる小売の行動まで見ないといけないと思います。実は物流に悪影響を与えているのは物流会社ではなく、小売の発注だということもあります。規則性がなくて読めない発注に対し、製造数量や配送個数の調整で立ち向かうことを考えても解決できなくて、小売に対して「この発注、やめてほしいんですけど」という話をして初めて解決することがあるわけです。

ただやめてくれと言うだけだとクレームになってしまうので、可視化のための帳票を作って、それをさまざまなプレーヤーが見て、客観的に問題を見られるようにする必要があります。可視化の帳票はコミュニケーションの面においても、単に数字で見るだけとか、実務で大変だったときのエピソードを話すよりも大きなパワーがあります。まずは可視化から始めてどこに課題がありそうかを探索することが初手として有効です。

八坂　社内においては、お互いの部署で何が起きているのかとか、物やお金がどう動いているかなどを可視化の帳票ベースで会話をしていきながら、経営スピードを上げる。一方で社外に対しては、適正な価格交渉や契約の単位を変えるような話をするために、可視化の帳票ベースでロジカルなコミュニケーションをする。いずれにしてもまずは可視化からということですかね。

塩見　可視化を行ってから改善などにつながるまでの時間軸の論点もあります。たとえば物量が100個と200個のときで、対応する人間も1人から2人に増えるという比例関係にあればいいのですが、物量に人数が対応していない状況は毎日発生します。「人時生産性」と呼んでいますが、これは毎日見たいデータです。このような毎日取るべきKPIの可視化自体はごく簡単なのですが、データの収集加工やダッシュボードへのつなぎこみなど、エンジニアリングに負荷がかかります。一方で、物流倉庫の庫内業務の委託契約などというのは多くても半期に1回ぐらいレポートを出して、ある倉庫や委託先の契約単価が他と比較して著しく高いといったたことがわかればいい。同じ可視化でもオペレーションの改善につながるものと、ある時点での現状を俯瞰するための可視化という、大きく2つがあるのではないでしょうか。

魚井　テクノロジーの観点で補足すると、最適化というテクノロジーについては、むしろサプライチェーンから発生したところがあって、生産やR＆Dの最適化に関する知見がたくさんあるんです。ソルバーというツールもあり、できることは多いと思います。もちろんアセスメントして問いを設定できる力も重要です。

八坂　そうですよね。これまで人手でずっとやってきたノウハウが詰まっていますからね。

魚井　1つだけ補足すると、問を設定して、ソルバーを使うと一言でいっても難易度が高く、すべてのデータサイエンティストが同様にできるわけではありません。課題を設定するセンスとそれをソルバーで解くスキルの両方を持っている人は多くいません。
発注される方は、実施する人を、慎重に選ぶ必要があります。

可視化と予測

八坂　アセスメントのあと可視化をして、次に何をするかと言えば、需要などの予測をし、それに伴ってオペレーションや在庫の最適化をすることになると思うのです。我々が大きな強みを持っている領域です。その領域について触れていきたいと思います。

デマンドチェーンの話がありますよね。需要を予測して、それに基づいて生産計画や車両配置、シフトなどを最適化するという話です。実例に基づく話をしてもらいたいのですが、魚井さんいかがですか。

魚井　最適化のニーズは今もありますし、過去にも我々が取り組んできたことですね。ただ、最適化が上手く進まない意外な原因として、多くの会社様が需要予測に力を入れすぎな点が挙げられます。最適化というワードよりも、需要予測というワードの方がわかりやすいため、需要予測に先に手をつけてしまいがちですが、需要予測は最適化、計画策定の入力にしかなり得ないため、最適化から始めるというのがポイントです。もちろん需要を予測の精度が良いに越したことはないのですが、それですべて解決できるわけではありません。

たとえば販売計画を立てると言っても需要予測では100個売れると出ても、販売サイドの目標が120個売らないと達成できないということもあるわけです。これはほんの一例で、予測値がそのまま計画値にならないケースがほとんどです。「AIで需要予測をするがDXだ」というのは間違っていませんが、後工程（計画策定）から考えた方が、実地検証できるため、ビジネス成果に結びつきやすいと思います。

塩見　需要予測で出てきた数字がどのオペレーションにどのくらいの粒度で影響するかを理解しないと、誤差率が低いのが良い需要予測という考えに陥りがちです。発注単位が1,000個からだと1,000個未満の誤差は発注単位に丸め込まれてしまうし、リードタイムが1週間ならおおよそ１週間分の発注量を計算しないといけないので、何百個、の予測誤差があっても実務への影響は軽微でしょう。

だから本当に自分たちのオペレーションに必要な粒度に対して必要な精度を考えないと、まったく意味のない精度改善プロジェクトに陥ることになります。我々もどんなオペレーションで数字が変化するかを理解していないと、精度改善のわなを自分自身で掘りに行くことになりかねません。ドメイン的な力学が強い分野においては、お客様のオペレーションを理解した上で分析をして、次にやることを決めるのが重要と思います。

需要予測や最適化以前に、アセスメントのときに調べた簡単な帳票を引き続き見ていきたいという、管理の高度化についての話がアセスメントの次に来ることがけっこうあります。

予測と並行して、在庫や人の動きを時系列で追いかけて最新の状況まで見えるようになれば、需要予測や最適化によってどれだけ改善されたかわかりますし、自分たちの弱点は何かを現場の人たちが理解できます。つまり可視化できる状況を連続的に作るということが、アセスメントの後続のタスクとして重要だと考えています。

八坂　それは正しいですね。ある時点で可視化の話をしていたのですが、予測や最適化によって出てきた効果を時系列で見られるものとして活用するのも可視化ということですよね。

魚井　実績をダッシュボードとして可視化して傾向を見ることもとても重要です。それがなされていないと、天気予報やPOSのデータが手に入れば需要予測の精度が上がるといった全くデータドリブンではない感覚値による議論が、現場をややこしくします。実際にデータを可視化するとなぜか月末に向かって出荷が急に増えていて、別に天気予報やPOSは関係なく、営業が目標を達成するために月末に押し込むからということがあるわけです。数字の変化の原因が人手のオペレーションなのにも関わらず、POSと天気予報があれば需要は当たると話が進んでいき、外部データを調達して、ツールにかけましょうという全く現状の実績データを無視した話になっていく現状があります。

八坂　みなさんと話をして、可視化は改めて重要だというのがわかりました。我々にとってのホラーストーリーですが、需要予測をやりましょうというだけのプロジェクトは、大体それっきりで終わりますよね。需要予測の効果を評価する軸を持つことと、やみくもに予測精度を求めすぎないことが肝心ということです。その両輪でやっていかないと効果がわからず、テクノロジーの導入は進みません。

魚井　そうですね。自然現象の予測とは違いますし、人の仮説が必ずしも正しいわけではありません。私自身、需要予測プロジェクト（POC）を実施した経験がありますが、天気予報とPOSデータの追加によって予測精度が上がった経験はありません。それよりも、周期性を反映した特徴量の方が重要でした。

塩見　POSデータがあればという話が出ましたが、POSデータよりもダイレクトに物流に影響を与えているのは発注量とタイミングのデータです。売れ方ではなくて注文のされ方がより重要です。

店舗の販売量や在庫量を考えながら発注していることもちろんあるのですが、この販促でいくら売りたいという小売側の営業目標に引っ張られて発注が決まるところもあります。売れるからではなく売りたいという理由で発注量が跳ねただけなのに、物流センターは大量発注が来たので在庫を押さえないといけないとなります。それでも在庫が足りないから別のセンターから持ってきたり、その在庫の仕分作業や荷役作業のために通常の2倍の人数が必要だとなるわけです。

八坂　需要予測が重要なのは間違いありませんが、やみくもに精度だけを求めすぎても意味はありません。ある程度の予測を行い、その先の最適化で効果を出す方法を考えつつ、実績を可視化の帳票に落としこむ。そうして改善状況を時系列で評価をしていくことが重要ということですね。

早川　我々が2015年ぐらいに取り組んだ物流の最適化プロジェクトとそれほど変わっていないところがあります。その間にAIブームとなりましたが、実はしっかりと要点さえ押さえれば、最近の技術を無理に使わなくても、実現できることは多いという気がします。

最適化と「BrainPad FAST」

八坂　予測のあとは最適化がテーマになりますが、ブレインパッドに問い合わせが多いのは、製造計画や実験計画といった計画系の案件です。これについてお客様の課題は何なのでしょうか。

早川　先ほども話にあった人手不足やベテランの退職の問題があって、特に計画系業務はベテランがこれまでの知見と経験、勘を用いて計画を立てることが非常に多い。それを引き継げずに退職されてしまうと業務が回らなくなるという課題感が大きいです。

あと計画系の問題が数理最適化という技術で解けるというのは意外と知られておらず、ひたすらルールを記述することで自動化しようとするのですが、ルールが複雑すぎて記述しきれないという問題があります。ですので数理最適化についての認知を広げる必要もあります。

八坂　いわゆる暗黙知的に伝承されてきたものが、引き継がれる人の中に暗黙知化する前に匠（たくみ）の技術を持ったベテランがいなくなったらどうすればいいのかが騒がれているということですね。我々のやり方としては、暗黙知を形式知に落としこみながら、計画業務などに生かすお手伝いをしているいるということでしょうか。

一般的なスケジューラーの批判ではありませんが、それだと我々が対面している会社の持つような複雑怪奇な制約条件が加味できず、導入はしたが結果的に使われなくなったという話がけっこうあります。

一方でプロフェッショナルがフルスクラッチでスケジューラーを作っていくと、コスパが悪い。その点、当社が提供する「BrainPad FAST（以下、FAST）」（※）は解き方を持っていて、あとはカスタマイズによってお客様の現場にフィットできるのがメリットということですよね。

※「BrainPad FAST」について

BrainPad FASTは分析・モデリング・データ活用アプリケーション開発を迅速に行うためのアプリケーション構築サービスです。一般的に、データ分析を伴うモデルの構築～アプリケーション開発を行うためには、これまではデータサイエンティストとアプリケーション開発エンジニアのチームを組成しAIプロジェクトを進行する必要がありました。そのため必然的にサービスローンチ・運用までの工数が膨大になりがちでした。
FASTでは、最新の技術を用いて開発部分の工数を大幅に削減。基本的にデータサイエンティストのチームのみでデータ活用アプリケーション開発までを行う全く新しい開発プロセスを実現しています。また企業ニーズの高い、需要予測、生産計画、配送計画などのアプリケーションを予めご用意しており、短期間で現場で利用できるデータ活用アプリケーション開発をブレインパッドが行います。

https://www.brainpad.co.jp/services/professionals/bp-fast.html

魚井　紹介ありがとうございます。また、POCの進め方として、倉庫や工場の計画系業務を1カ所からスモールスタートで進めることが重要です。まず特定の倉庫で実地検証してから全社展開をした方がリスクがなく進められるためです。プロトタイプ開発を高速に行って実地検証を行うことが重要に思います。フルスクラッチで基幹システムと連携するとなれば、現場で使われるのは遠い先になります。

また、予測や最適化といった高度なテクノロジーは「ユーザー体験」がとても重要と考えていまして、レポート提出では、テクノロジーの凄さ、活用のイメージが湧きません。POCを「レポート提出」と定義せず、プロトタイプ開発によって「体験を提出」することが実務においては極めて重要と考えています。

八坂　小さく始めてすぐ成果を得る、MVP（Minimum Viable Product）で進めていく形ですね。

ところで暗黙知化されているものを形式知に落としこむのはかなりのパワーが必要な作業ですが、具体的にはどのようなことをするのですか。

魚井　ヒアリングは大事ですが、1回のヒアリングですべての暗黙知を引き出すのは不可能です。取りあえず50%ぐらいを引き出してから、フィードバックによって改善していくことを速い速度で繰り返すことが大事です。

早川　魚井さんが言った通り、イテレーションをどれだけ速く回せるかが勝負だと思います。データサイエンティストが分析して報告書を出すという形ではどうしてもサイクルが遅くなってしまします。結果を動的にすぐに見せられる環境が必要です。

それがFASTというわけで、お客様とのコミュニケーションが円滑にして、イテレーションを速く回すためのツールと言うこともできます。

八坂　お客様としてもわかりやすいですものね。画面があって、操作すればすぐに結果が見られると。

早川　報告書に基づいて報告をすれば、「この値がこう変わると結果はどう変わるの？」といった質問をお客様は絶対にしてきます。今までは持ち帰って、再度分析を回して、翌週またパワポで説明するといったことをやってきました。ところがFASTならダッシュボードの感覚で操作すれば、その場で答えが出せるのです。リードタイムが大きく違います。

八坂　これも可視化の話に通じますよね。先ほどの可視化の話でも、FASTの話でも、目に見えるものによって顧客側の理解を逐一得ながら進めていくことが重要です。

塩見　理解しないとそもそも話を聞いてもらえません。数字を見せるだけでは、「結局当社のトラックの走らせ方はどう変わるの？」と聞かれるだけです。そういう具体的なイメージと数字を組み合わせて話をしないと、提案や提言がお客様にとってはノイズにしかなりません。現場で何が起きているかをイメージできるぐらいリアリティーのある話をしないと相手にしてもらえないのではないでしょうか。

魚井　現場の方々のフィードバックは、システムを継続的に使ってもらうために本当に重要です。

早川　ブレインパッドのデータサイエンティストは、倉庫や工場のなどの現場を頻繁に見に行って、プロセスや作業をつぶさに見ていると感じます。そうしないとお客様に刺さる提言はできません。また現場には、データ化されていないプロセスや動きがあり、それらをつかむためにも現場に行くことが必要です。

八坂　現場を見るのが好きなデータサイエンティストやコンサルタントは、ブレインパッドには多いですよね。だからこそお客様から高い評価をいただいていると思っています。

最後に、モデルを作ったあとの導入や運用の話をしたいと思います。よく言われていることとして、「ヒューマン・イン・ザ・ループ」があります。どこまでを人に任せて、どこからをアルゴリズムに任せるかという話です。先ほどの話と同様、現場を見てお客様と話をしないと、導入や運用の設計もできないですよね。したがって導入や運用に関しても我々の強みがあると思っています。

魚井　複数の会社の現場を見ているからこそ、「工場の生産であれば大体こういう要件がある」といった当たりがついているのは強みだと思います。一方で「それは本当に必要ですか？」というコミュニケーションも重要です。担当者だけがそう考えているのか、全社の意見なのか、それを考える機会が生まれるのがプロトタイプ開発の利点と思います。

塩見　ヒューマン・イン・ザ・ループの考え方は自然だと思います。全部が全部予測できるわけでないし、全部が全部アルゴリズム化できるわけではないと思います。業界・業務・現場を全部把握した上でないと、人間と機械の役割分担の議論はできません。どう役割分担するかは業界や業務ごとに違うからです。

そこでも重要なことは、やはり可視化だと思っています。可視化によって人間が状況を判断し、それをもとにアルゴリズムで解いてもらうことになります。データサイエンスだけをゴリゴリとやっても進まないというのがヒューマン・イン・ザ・ループの肝だと思います。

早川　先ほど需要予測ブームがあったいう話が出ましたが、その時代はとにかく精度を出すことを求められるケースが多かったような気がします。しかし時代の要請が精度競争ではなくなっているし、業務で使えるものは精度向上だけでは作れないことが一般的な認知を得たという気がしています。業界、業種、業務プロセス理解するといった基本の重要性が再認識されており、我々も時代の要請に合わせながら、基本も上手にできるようになったのではないでしょうか。

まとめ

八坂　今日の話をまとめます。製造や流通の領域は商慣習が複雑で、しかもサイロ化されすぎている世界です。それにも関わらず、労働人口は間違いなく減ってくるし、大量生産・大量消費の時代はとうの昔に終わり、多品種小ロット化の中で、一人一人の従事者に負荷がかかっています。それをお客様と我々でどうやって一緒に変えていくか考えていかなければならないという問題意識がまずありました。

そこで可視化のツールを使って、改善への取り組みの成果を時系列で評価するサイクルを回していくことが必要です。だからまずは可視化からから始めましょうということでした。またFASTのように、すぐに使えて結果が見える環境を使いながら、お客様も我々もどんどん理解を深めていくのがよいという話もありました。

塩見　2024年問題にリンクして国も動き出していて、「荷主も物流について考えてみませんか」と方針転換しています。大量生産・大量消費の時代が終わって、より個別的なきめ細やかなサービスがサプライチェーン全体に求められてきます。その中で荷主は消費者と密に接していますので、消費者個別にサービスを展開していくことをより深く考えつつも、自分たちも物流をちゃんと見て、配送業者や3PL業者に負荷を丸投げするべきではない。そういう潮流になりつつあります。

八坂　たしかにそうですね。今日はみなさんお忙しいところ、本当にありがとうございました。