2023年3月号
特集
特集
経産省 アナログな連携がDXの道を開く
明らかに荷主が悪い
──経産省が２０１８年に発表した「ＤＸレポート」を情報技術利用促進課長としてとりまとめた後、物流を担当されることになりました。
「ＩＴの世界と何から何までよく似ていることに驚きました。
ＤＸレポートでは、経営者がデジタルに疎く、関心がないためにレガシーシステムを刷新できない、情報システム部門がいくら訴えても、投資を決断できないという問題を取り上げました。
ろくに要件定義もしないままＩＴベンダーに丸投げして、標準パッケージを使わずカスタマイズを繰り返した結果、システムが複雑になって古くなり身動きが取れなくなってしまった。
このまま使い続けていけば、『２０２５年の崖』という言葉を使って、大変なことになると報告したわけです」 「これを乗り越えるには、経営層がデジタルの重要性を理解して必要な知識を身につけ、社を挙げてシステムの刷新に取り組んでいかなくてはなりません。
システムをカスタマイズするのではなく、業務を変革しなければならないのであり、そのためにはＩＴ人材を社内に抱えて内製化するくらいのことが必要だと書きました」 「物流も全く同じでした。
かつては社内にあった機能を子会社として切り出して、さらにはそれを売り払ってしまった。
その結果、自分では物流が分からなくなり外部に依存することになった。
各社が勝手なカスタマイズを繰り返して標準化されていないところもＩＴと同じで、このまま放っておくと物流は、25年の壁ならぬ24年問題が起きる」 「日本のＩＴ部門は社内の位置付けが低いと言われていましたが、物流に来てみたらさらにその下でした。
グローバル企業はデジタルを経営の中心に据えてチーフ・デジタル・オフィサーを置いているのに日本企業にはそれがいない。
チーフ・ロジスティクス・オフィサーもいない。
結局これは、日本がものづくりや販売には長けていても、全体を俯瞰的に見るのが苦手だということです。
デジタルは情報流、物流はモノの流れで、両方ともシステムです。
それなのに個別最適ばかりで全体最適を考えない。
協調領域と競争領域をごっちゃにしている。
多重下請け構造まで同じです」 ──解決策はありますか。
「ＩＴ業界が多重下請け構造になったのは、アジャイル型（小さな単位の実装とテストを短期間で繰り返していく開発手法）という言葉が人口に膾炙するようになる前、誰もがウォーターフォール型で開発していた時代に、システム構築や改修の時だけ一気に人手が必要になり、それが終わるといらなくなるという需要の変動があったからです。
忙しい時期に合わせて社員を抱えたら固定費になって暇な時期に困るので外に出した。
それを受けた側もまた外に出す、ということで多重下請けになった。
その点、アジャイル開発は常にシステムを手直しするので変動が小さい。
そうなると外に出さず社内にＩＴ人材を抱えるようになる。
その結果、多重下請けは自然と解消に向かっていく」 「日本のＩＴ人材は現状ではざっくりユーザー側に３割、ベンダー側に７割という比率です。
ところがアメリカはユーザー側が７割、ベンダー側は３割です。
つまりアメリカでアウトソーシングやオープンイノベーションが進んでいるというのは嘘であって、彼らはＩＴを内製化している。
そもそもＩｏＴやＤＸを本気でやろうしたら、営業機密に関わってくる話になるので外には出せない。
ＩＴ人材を社内に抱えない限りできないんです」 「物流業の多重下請けも需要の変動が原因です。
従って、小売りで言う繁閑差がある限り問題は解消されない。
これまで物流の多重下請け構造はともすれば国交省の問題だとされてきました。
しかし、『あれ？ 待てよ』と。
私が情報技術利用促進課長をしていた当時、経産省にはＩＴのユーザー側とベンダー側を別の課が所管していて、多重下請けの問題ではお互い『向こうが悪い』と言い合っていました。
私はユーザー側の課長でしたが、よくよく考えてみれば需要が変動するのだから元請けをとがめても仕方ない。
問題は明らかにユーザー側にある」 「そう考えてベンダー側の情報産業課に『今までベンダーのせいにして悪かった』と謝りに行きました。
そうしたら向こうも協力してくれるようになって両課で仲良くＤＸレポートを書きました。
今回も同じでした。
国交省に行って『明らかに荷主が悪い。
申し訳なかった』と謝ったら『まあそう言わず、一緒にやりましょう』と言ってくれた」 内製化が多重下請けを解消する ──物流も内製化に向かいますか。
「企業がＳＣＭを経営の中心に据えるのであれば、ＩＴと経営を一体化させたように、物流も経営と一体化させなければならない。
これから物流コストはさらに上がっていくのだから、企業の競争力は物流の能力にかかってくる。
それを外に依存していていいはずはない。
全ての機能を内製化するわけにはいかなくても、少なくとも物流も考えて経営する必要がある。
荷主が物流の効率性を考えるようになれば自ずと平準化に向かう。
別に物流のためだけではなく、稼働率を上げようとすれば平準化するしかない。
平準化がＳＣＭの基本です」 「そのために協調領域を見つけて標準化して連携する。
個別最適を求めない。
『すぐ持ってこい』をやめて３日以内にする。
その分、在庫を多く持たなければならないところを、データをシェアして需要調整で回避する。
そのためにデジタル化が必要なんです。
しかし、ＣＯＢＯＬで30年前に開発したような基幹システムではとても対応できない。
まずはレガシーシステムをどけないといけない」 「ロボットやＡＩなど経営者は目立つところばかり気を取られるけれど、問題はバックエンドです。
われわれ役人の仕事もそこにある。
フロントエンドは民間企業がどんどん自由に競争すればいい。
そのほうが役人が考えるよりずっと上手くいく。
しかしバックエンドは標準を作ったり、他社と協調したりしなければならない。
また、レガシーシステムの刷新に数百億円もかかるとなれば企業単独ではできない。
そこはインフラの話なので、役所の介入を歓迎してもらえるし正当化もできる」 ──ＳＩＰも連携の機会でした。
「そうです。
スマート物流サービスはＳＩＰの他のプログラムに比べて社会実装に近い。
良く言えば地に足が着いているけれど、ムーンショット的な先進性はそれほどない。
しかし、テクノロジカルなイノベーションではなくても、利害関係者が集まってソーシャルなイノベーションにそこで取り組んだ。
その結果、データ共有に必要な技術と共に、『ＳＩＰ物流情報ガイドライン』という副産物が生まれた。
そこに技術性はなくても、社会的な意味はある」 「デジタル化には実は、アナログな連携が必要です。
業界内や地域内のコミュニティ、アナログな連携をデジタル化することがＤＸだと言ってもいい。
シリコンバレーなどはその典型で、コミュニティが必要だからみんな出ていかない。
役所と業界団体の集まり、地域の商工会議所などを、日本は古くていらないものだと切り捨てた。
その結果として標準化に出遅れた。
デジタル化のためにアナログなネットワークを再生する必要があります」
「ＩＴの世界と何から何までよく似ていることに驚きました。
ＤＸレポートでは、経営者がデジタルに疎く、関心がないためにレガシーシステムを刷新できない、情報システム部門がいくら訴えても、投資を決断できないという問題を取り上げました。
ろくに要件定義もしないままＩＴベンダーに丸投げして、標準パッケージを使わずカスタマイズを繰り返した結果、システムが複雑になって古くなり身動きが取れなくなってしまった。
このまま使い続けていけば、『２０２５年の崖』という言葉を使って、大変なことになると報告したわけです」 「これを乗り越えるには、経営層がデジタルの重要性を理解して必要な知識を身につけ、社を挙げてシステムの刷新に取り組んでいかなくてはなりません。
システムをカスタマイズするのではなく、業務を変革しなければならないのであり、そのためにはＩＴ人材を社内に抱えて内製化するくらいのことが必要だと書きました」 「物流も全く同じでした。
かつては社内にあった機能を子会社として切り出して、さらにはそれを売り払ってしまった。
その結果、自分では物流が分からなくなり外部に依存することになった。
各社が勝手なカスタマイズを繰り返して標準化されていないところもＩＴと同じで、このまま放っておくと物流は、25年の壁ならぬ24年問題が起きる」 「日本のＩＴ部門は社内の位置付けが低いと言われていましたが、物流に来てみたらさらにその下でした。
グローバル企業はデジタルを経営の中心に据えてチーフ・デジタル・オフィサーを置いているのに日本企業にはそれがいない。
チーフ・ロジスティクス・オフィサーもいない。
結局これは、日本がものづくりや販売には長けていても、全体を俯瞰的に見るのが苦手だということです。
デジタルは情報流、物流はモノの流れで、両方ともシステムです。
それなのに個別最適ばかりで全体最適を考えない。
協調領域と競争領域をごっちゃにしている。
多重下請け構造まで同じです」 ──解決策はありますか。
「ＩＴ業界が多重下請け構造になったのは、アジャイル型（小さな単位の実装とテストを短期間で繰り返していく開発手法）という言葉が人口に膾炙するようになる前、誰もがウォーターフォール型で開発していた時代に、システム構築や改修の時だけ一気に人手が必要になり、それが終わるといらなくなるという需要の変動があったからです。
忙しい時期に合わせて社員を抱えたら固定費になって暇な時期に困るので外に出した。
それを受けた側もまた外に出す、ということで多重下請けになった。
その点、アジャイル開発は常にシステムを手直しするので変動が小さい。
そうなると外に出さず社内にＩＴ人材を抱えるようになる。
その結果、多重下請けは自然と解消に向かっていく」 「日本のＩＴ人材は現状ではざっくりユーザー側に３割、ベンダー側に７割という比率です。
ところがアメリカはユーザー側が７割、ベンダー側は３割です。
つまりアメリカでアウトソーシングやオープンイノベーションが進んでいるというのは嘘であって、彼らはＩＴを内製化している。
そもそもＩｏＴやＤＸを本気でやろうしたら、営業機密に関わってくる話になるので外には出せない。
ＩＴ人材を社内に抱えない限りできないんです」 「物流業の多重下請けも需要の変動が原因です。
従って、小売りで言う繁閑差がある限り問題は解消されない。
これまで物流の多重下請け構造はともすれば国交省の問題だとされてきました。
しかし、『あれ？ 待てよ』と。
私が情報技術利用促進課長をしていた当時、経産省にはＩＴのユーザー側とベンダー側を別の課が所管していて、多重下請けの問題ではお互い『向こうが悪い』と言い合っていました。
私はユーザー側の課長でしたが、よくよく考えてみれば需要が変動するのだから元請けをとがめても仕方ない。
問題は明らかにユーザー側にある」 「そう考えてベンダー側の情報産業課に『今までベンダーのせいにして悪かった』と謝りに行きました。
そうしたら向こうも協力してくれるようになって両課で仲良くＤＸレポートを書きました。
今回も同じでした。
国交省に行って『明らかに荷主が悪い。
申し訳なかった』と謝ったら『まあそう言わず、一緒にやりましょう』と言ってくれた」 内製化が多重下請けを解消する ──物流も内製化に向かいますか。
「企業がＳＣＭを経営の中心に据えるのであれば、ＩＴと経営を一体化させたように、物流も経営と一体化させなければならない。
これから物流コストはさらに上がっていくのだから、企業の競争力は物流の能力にかかってくる。
それを外に依存していていいはずはない。
全ての機能を内製化するわけにはいかなくても、少なくとも物流も考えて経営する必要がある。
荷主が物流の効率性を考えるようになれば自ずと平準化に向かう。
別に物流のためだけではなく、稼働率を上げようとすれば平準化するしかない。
平準化がＳＣＭの基本です」 「そのために協調領域を見つけて標準化して連携する。
個別最適を求めない。
『すぐ持ってこい』をやめて３日以内にする。
その分、在庫を多く持たなければならないところを、データをシェアして需要調整で回避する。
そのためにデジタル化が必要なんです。
しかし、ＣＯＢＯＬで30年前に開発したような基幹システムではとても対応できない。
まずはレガシーシステムをどけないといけない」 「ロボットやＡＩなど経営者は目立つところばかり気を取られるけれど、問題はバックエンドです。
われわれ役人の仕事もそこにある。
フロントエンドは民間企業がどんどん自由に競争すればいい。
そのほうが役人が考えるよりずっと上手くいく。
しかしバックエンドは標準を作ったり、他社と協調したりしなければならない。
また、レガシーシステムの刷新に数百億円もかかるとなれば企業単独ではできない。
そこはインフラの話なので、役所の介入を歓迎してもらえるし正当化もできる」 ──ＳＩＰも連携の機会でした。
「そうです。
スマート物流サービスはＳＩＰの他のプログラムに比べて社会実装に近い。
良く言えば地に足が着いているけれど、ムーンショット的な先進性はそれほどない。
しかし、テクノロジカルなイノベーションではなくても、利害関係者が集まってソーシャルなイノベーションにそこで取り組んだ。
その結果、データ共有に必要な技術と共に、『ＳＩＰ物流情報ガイドライン』という副産物が生まれた。
そこに技術性はなくても、社会的な意味はある」 「デジタル化には実は、アナログな連携が必要です。
業界内や地域内のコミュニティ、アナログな連携をデジタル化することがＤＸだと言ってもいい。
シリコンバレーなどはその典型で、コミュニティが必要だからみんな出ていかない。
役所と業界団体の集まり、地域の商工会議所などを、日本は古くていらないものだと切り捨てた。
その結果として標準化に出遅れた。
デジタル化のためにアナログなネットワークを再生する必要があります」