佐々木：そこはやはりデータの具現だと思います。われわれが1枚のシートにデータを出すだけでファクトを見ることができるのですが、皆さんまだ抽象論で、かつ定性的に話しているケースがほとんどです。國の議論もかなり抽象的です。それを具體に落とすとどうなるか、というところまで見たことがある人はほとんどいません。
例えば、字面で「データを共有し、共同配送を出す」と書いてあっても、それがどういうことなのか、おそらく皆さんわからないでしょう。しかし、Hacobuはすでに始めています。いくつかのユーザーデータを見ながら、どことどこがうまく一緒にやれるか検討し、お聲がけをする。そういったことを実際に始めています。実際のデータで具體を話すことで、秋葉さんや私たちがずっと言ってきた、「データを一緒に使うと出せる価値」というものがようやく理解されてきました。Hacobuのバースの仕組みで、「どこから、何が、どんな車で運ばれてくるのか」といったデータを取ることができます。「どこから」という情報をマッピングするだけで、「この辺にサプライヤーが固まっているのに、バラバラにトラックを回している。しかも、長距離なのに4トンを飛ばしている」ことがわかったりします。それならば、そこにまとめて10トンで行ったほうが、運賃が安くなります。そういったことがパッと見てわかるわけです。

秋葉：今のお話は、先ほどの中継物流の話ともつながりますね。中継物流というと、皆さん、大阪を出て浜松まで行き、東京を出て浜松まで行く、といったイメージを抱くと思います。しかし、これでは本來やりたい中継で長時間の待ちが発生してしまいます。そこで、関西は関西で一回バッファがあって、そこから浜松へ行く。関東は関東で、北関東や千葉、神奈川などで一回集まって、それから浜松まで來て、帰るようにします。そうなると、今の佐々木さんのお話と同じです。要するに、「どことどこの車がこう來ているのだから、ここで時間調整をして來れば、中継物流が綺麗に流れる」という話なのです。元のデータがないと、プランすらできません。
中継物流の考え方はわかっているし、物理的にどうすればできるかもわかっています。中継物流をやることで、一つ目は、ドライバーがその日に家に帰ることができます。二つ目は、荷臺だけ置いて帰れるので、待機時間をきちんと回せば、待機時間を減らすことができます。その結果、三つ目としてCO₂を削減することもできます。一つ目は簡単です。二つ目、三つ目をやるためには、まさにHacobuの仕組みが非常に効果的です。Hacobuのツールを入れることで、どのようなタイムスケジュールで、どれくらいのものを回していくと無駄がないのかがわかります。ここで大事なのは、データになって初めてみんなが納得してくれるということです。

佐々木：具體的にデータを見せると、「そういうふうに使うんだ！」「データの中身ってそういうものなんだ！」と驚かれる方がたくさんいらっしゃいます。逆に言うと、それが目に見えない狀態でデータを使っていてもあまり効果がありません。
私たちがよく使う言葉のなかでも、一番ややこしい言葉のひとつに「シェアする」があります。例えば、「データを共有、シェアすると、皆さんにメリットがありますよ」と言ったとすると、「データをシェアするとは何事だ」と、データの帰屬問題のような論點に移っていき、そこで時間を使ってしまうことがあります。ところが、実際のデータを見れば、それで何かが漏えいするものではないことがわかります。中間的に立つ人がいて、データをそれぞれ見て分析し、どんなことができそうなのかを提示することができれば、そこにはデメリットなどなく、メリットしかないことがわかってきます。
もちろん、データのガバナンス方針は必要です。「株主であっても１次データは閲覧できないし、ユーザーは他ユーザーの１次データを閲覧することができない」など、データの閲覧権限については、明確な方針と規定を策定します。
データの話は、とにもかくにもまずは具體的にデータを取って、やってみると、前に進みます。多くが抽象の議論で、「データの所有権とは」「データのポータビリティは」といった話で終始してしまうのは、仕方ないことではありますが非常にもったいないと思います。
例えば、バースのデータは予約者に入れてもらうので、自社だけのデータではありません。関係性の中で培われるデータです。このような関係性のデータは、今までのロジスティクスの世界にはありませんでした。私たちが行っている物流の仕事は、関係性のビジネスなのです。

秋葉：物流はもともとクローズドで、自社システムとして開発してきました。しかし、やはりクラウドでないとダメだと、意識、パラダイムが変わってきているのは非常に大きなことです。ロボットを入れる、人工知能を使うといった話が出ていますが、それは個別の話で、それをシェアしてどうやって使うかという話はその先にあります。しかし、Hacobuの仕組みは最初から個別ではありません。サービス型になっているので、入れると決めたらすぐに入れられる、使えるのが大きな利點です。事実を見て、議論が進めば、短いサイクルで意思決定プロセスを回すことができます。自分の會社だけでなく、周りも含めてどういう動きをしているのか知ることは、すごく大きなことですよね。

佐々木：一度データを見れば、こっちの情報はないのか、こっちのデータはないのかと、さらに需要が出てきます。具體を見ると、発想が湧いてくるのです。

秋葉：データの活用については、データガバナンスの観點で「株主であっても1次データは閲覧できないし、ユーザーは他ユーザーの1次データを閲覧することができない」となっています。だからこそユーザー自身がデータを活用し、自ら他社と連攜する動きをとることが重要になりますね。

個ではなくネットワーク全體を考えるということ

佐々木：昨年のプレスリリースで公表させていただいたのですが、佐川急便さんが受託された「ところざわサクラタウン」の管理業務に、Hacobuのトラック予約受付サービス「MOVO Berth」を導入していただいています。商業施設は、どうやってものが入ってくるかによってオペレーションが大きく変わります。実は、商業施設にものを入れるのは大変です。私は前職でものを輸入して百貨店に卸す仕事をしていたのですが、搬入が非常に大変で、サプライヤーとしていつもストレスを感じていました。
そうした問題に加えて、この仕組みによって、待機などに伴うCO₂排出量の削減、トラックドライバー不足の解消や、待機時間の削減による働き方改革にもつながるのではないかと思います。

秋葉：將來、そうした課題は今後ますます増えるでしょう。さらに言えば、私は、きちんとエリアを切って、加工食品やアパレルなど、そのエリアの中で必要な床面積を全體で把握し、そのシェアを何％取るかということから考えるべきだと考えています。エリアを切って考えるということは、他社にどのような物件があるか、使用目的に応じて何坪作るのがいいのか、といったことと合わせて考えるということです。
物流センターにおいても、今から土地を取得してマルチ型のセンターを建てるということは、この先30年後まで考えるということになりますから、30年後の賃料も考えなければならないわけです。現在の土地の高騰狀況を考えれば、30年後にその賃料をいただくことができるのかという大きなリスクを背負うことになります。その拠點がネットワークのノードとしてどのような役割なのか、合わせて考える必要があります。そのとき、Hacobuのデータが大きな意味を持ちます。

佐々木：トラックの動き、荷物の動きをすべて取れるのかというと、まだまだなのが現狀です。日本にはトラックが150萬臺ほどあり、全體からしたらHacobuの仕組みが入っているトラックは大した割合でありません。コネクテッド?トラックが進み、すべてのトラックメーカーの情報を分析することができ、メタデータとして使えるようになると変わってくると思いますが、かなり先になりそうです。また、入荷予約のデータなど、どこからどこへどういうふうにものが動いているか、途中の経緯はわかりません。しかし、どこから出てどこに入るのかはわかりますから、このメタ情報は活用の余地が大いにあると思っています。

秋葉：例えば、F-LINEさんは食品系の物流子會社が一つになった會社なので、エリアごとにセンターを統合していっています。北海道だったら何千坪、東北であれば仙臺近辺に何萬坪というように、きちんとエリアを切るわけです。そうすると、加工食品の中でF-LINEさんが何パーセントのシェアがあるのかわかっているので、エリアごとであれば他の食品メーカーでも同じなわけですから、全體としてこの辺のエリアにどれくらい必要で、F-LINEさんのシェアがどれくらいか逆算できるわけです。それを中心に考えることで、當たり前ですが、エリアの中で車がどうやって動いているかについてすべてを把握する必要はありません。何割かのデータが扱えるのであれば、そこから類推し、仮定するのはそれほど難しいことではないですし、デポをどのように置いたらよいかもわかるはずです。ところが現実には、それぞれの事業體としてやっているため、ネットワーク全體をどうするかが考えられていないのが事実だと思います。
佐々木さんのお話にもありましたが、基幹系の仕組みやWMSは規模が大きくなっていて、そこに手を入れるのは非常に大変です。時間もお金もかかりますし、要件の定義もしなければいけません。そこにあまり手を加えることなく、どうやって情報を出してくるかがポイントです。その一つとして、物流からするとバースの話があり、車からするとHacobuと日野自動車さんとの連攜があるのだと思います。また、基幹系は會計を中心とした仕組みであり、WMSは在庫を中心にした仕組みです。それとは異なる、オーダーを中心にした情報というものをどうやって捕えるかも一つのポイントだと思っています。それとバースの動きや車の動きなどが紐付けば、いろいろなことが見えてきて、無駄もよくわかるでしょう。

MOVO Vista

佐々木：Hacobuの次の軸になるのが「MOVO Vista」というサービスです。荷主から出荷指示が出て、最終的に配送するまでの部分をとらえるためのサービスで、SAPとの連攜がまさにここになります。SAPから出荷指示が出ると、プッシュでAPIにもらいます。出荷指示は「From To」で、「何を、納期はいつで、何個」という情報です。これがないと配車ができません。そこから、「トラック10トン車2臺と4トン車1臺」というように配送指示を割るのですが、この配送指示の情報を、これまではEメールやファックスなどで、実際に運ぶ実運送と呼ばれる人たちに共有していました。 さらに、運送は1社だけではありません。荷主が出荷指示を元請けに共有し、元請けが配送指示を割り、それを元請けが下請けに投げ、さらに下請けが孫請けに投げる、というように続いていくわけです。そのために、どこの會社でも、間に手作業が入ったり、集計に苦労していたのだと思います。Hacobuの「MOVO Vista」はこれを一気通貫で行い、どこまでもパスをすることができます。
昨年の秋から出していますが、非常に良い反応をいただいています。物流配送業界では、多層下請け構造が業界の課題だという話をよく聞きます。2015年、2016年頃は、私もその構造自體を変えなければいけないと思っていました。しかし、おそらくそれは無理なのです。なぜなら、需要には大きな変動があるのに、運ぶ側はアセットヘビーだからです。みんなで分散してアセットを持っていかないと、1社で直接受けると、変動に対応できません。
経済産業省や國土交通省の資料で、ピラミッド型で多層下請け構造になっている図をよく見ますが、そうではありません。あるときはA社からB社に流し、あるときはB社からA社に流しているのです。スポンジ構造全體で変動を吸収していくのが多層下請け構造の本質だと、私は思っています。

秋葉：全體でリスクをヘッジしているわけですね。

佐々木：多層下請け構造がなくなることはこの先20年くらいはないような気がします。だからこそ、それをきちんと表現できるデジタルツールが必要なのです。「MOVO Vista」では、何回かパスをしていても、最終的な人が、トラックの車番、ドライバーの名前、ドライバーの電話番號などを入れると、最初のところまで情報が屆きます。「配送管理をしました」ということを今まで伝言ゲームで伝えていたのを、一つの場所に皆で情報共有することができます。運送會社からすると、同じ仕組み上で荷物の情報を管理することができます。

秋葉：大和ハウスグループの立場からすると、どのようなカテゴリーの商品がどう動いているかがわかるだけでまったく違います。商品カテゴリーは、「From To」のところで見ていけばだいたいの想像がつくはずです。直接的に明確に利用できる人たちと、間接的に利用できる人たちが大勢いる情報なのだと思います。それにはやはり事実、現実を見ないといけません。物流センターの中の情報に加えて、出荷情報を見ることができれば、物流業務のプロセスも大きく変わるのではないかと思います。デジタルデータをいかに人が活用するか、データを活用することで、どれだけ付加価値の高い仕事に、人が従事することができるか、これがポイントだと思っています。