秋葉淳一のトークセッション 第2回　LexxPlussが描く物流エンジニアリングの新時代株式会社LexxPluss　代表取締役　阿蘓 将也　×　株式会社フレームワークス　会長　秋葉淳一

オープンソース化が産業構造を変える

秋葉：LexxPlussは国産であることに加えて、パートナーシップの取り方も特徴的ですよね。

阿蘓：LexxPlussのミッションは、「自律的産業インフラへの進化を加速させる」ことです。物流や製造業の生産現場を人手に依存する状態から、労働力の最適化、加速化、削減を支援し、グローバルな事業展開における持続可能な成長を促進します。
LexxPlussにとって自動化は目的ではありません。持続性を高めていく手段にはクリエイティブな仕事もあるし、人で支えられる仕事もあるし、自動化機器もあるというだけです。自動化やロボティクス化を目的にしていないので、課題解決から入ってロボットを普及させたいという欲は正直あまりありません。社会インフラをどう支えていくかというところでLexxPlussは誕生し、「自律的に社会インフラを動かす」というミッションを掲げているのです。
その手段として、LexxPlussは自分の手の内化した搬送システムを、ハードもソフトも含めて自分たちで作っています。私は、物流産業の課題はシステムの持続的な改善活動ができる状況がないことだと思っています。例えば配送システム、マテハン機器、コンベアをマテハン機器メーカーやSier（System Integrator：システムインテグレーター）に作ってもらうと、ベンダーロック（特定のベンダーに依存し、そのベンダー以外の製品やサービスへの移行が困難な状況）がかかってしまいます。社内で作らず、外部委託しているがゆえにブラックボックスの状態を生みながらも使っている。時代は変わり、eコマースの需要によってニーズも変わっていきます。ところが、この仕組みがボトルネックだから改善してビジネス成長したいとなった時に、サプライヤーしか分からないソースコードがあるとしたら、その人にお願いしないと改善できません。さらに、数千万円、数億円かけてお願いしても、改善したのはそこだけです。そんなことをしている間に時代は変わっていってしまう。この状態は健全ではないと思うのです。

秋葉：全体のエンジニアリングも含めて考えると、ブラックボックスはそこら中にあります。ベンダーは独占すれば当然有利なわけです。

阿蘓：私たちはマテハン機器を供給する側なので、ブラックボックス化すればビジネスとして優位に運べますが、全体を考えると、透明性が高い状態でお客様に提供しなければいけないと思っています。LexxPlussでは、搬送システムのAPI（Application Programming Interface ソフトウェア間で情報をやり取りするためのインターフェース）、ハードウェアの設計、製造工程など、ロボットを自動化する機器を作る全過程をオープンソース化しています。オープンソース化すれば、提供後にお客様が自分たちで保守ができたり、自分たちでシステムを作り変えることも可能です。そのほうが最終的にお客様のメリットになるし、自動化機器の普及につながると考えています。ものを作るという部分において、どれだけ透明性が高い状態で社会インフラを提供して普及できるか。こうしたビジネスの取り組み方によって、そこにイノベーションが起きると思ってオープンソース化を進めています。

秋葉：素晴らしいですね。もうベンダーロックがまかりとおる時代ではありません。私も元々製造系の人間で、物流業界に入ってきて思うことがあります。当たり前ですが、製造業は新しいものを産み出さなければいけません。そして、その新しいものを生み出すための設備も自分たちで考えなければいけないわけです。オーダーして、作らせて、試してみる。製造業にはエンジニアが必ず存在していて、例えば生産技術や生産管理部門はやはり力を持っています。それをやりたくて就職する人たちも大勢います。
一方、物流は製品を作るわけではなく、決められた仕事をきちんと正確に行うことが使命です。これはエンジニアの仕事ではないので、管理する人と仕事をする人がいればいい。そのため基本的にエンジニアはいません。ですから、製造業がロボットベンダーに依頼をして打ち合わせするのと、物流系の会社がするのとでは明らかに違います。このギャップがあるので、独占化しやすいわけです。そこをオープン化することで、物流サイドが自らもできるし、親しい会社に協力してもらうこともできるので、これは産業構造を変える大きなきっかけになると思います。
十数年前から高度物流人材をどうするかという議論をしてきましたが、ここで言っている「高度」とは何かというと、私は「エンジニア」が一つの括りとしてあって、そのあとに財務に強い等があると思っています。それを一緒にしてしまっている。財務も強くて、エンジニアとしての能力もあって、現場もよく分かる人だったら自分で社長をやっていますよね。けれども、ある程度の規模の物流センターのセンター長にはおそらくそれが求められます。物流センターを1棟建てれば、売上は年間で何億、何十億、何百億という規模になるので、それはもう社長と同じレベルなのです。エンジニアとしての能力が高い人に会社に入ってほしいし、業務に就いてほしいと思います。

阿蘓：設計図公開の第2段階として今準備しているのが、複数台のロボットを群制御するフリート管理システムです。フリートマネジメントは業界ではRCS（ロボットコントロールシステム）にカテゴライズされるものです。ロボットが何台かいて、その配車作業をしているシステムが親玉でいて、プラスで設備の連携や、APIで上位の倉庫管理システムから依頼されるなど、その連携口になっています。LexxFleetは、WCS/SCADAに接続し、最大50台のAMR（Autonomous Mobile Robot：自律走行搬送ロボット）を制御できるウェブベースのロボット管理システムです。
このシステムのソースコードも含めてすべて公開し、透明化することで、それを使って設備のAPI連携の検証ができるようにします。今まではロボットの設計情報を公開するだけに留めていたのですが、ソフトの部分も近々公開を始めます。透明性の高い物流のネットワーク、サプライチェーンを作るという意味で、われわれとしては普及のきっかけにしていきたいと思っています。

秋葉：今まで誰もやったことがありません。やったほうが世の中のためだと分かっていても、その前に自社の数字を作らなければいけないので、ブラックボックスにして、その仕組み自体も乱立するわけです。なおかつお客様に都度お金を出してもらっています。
オープン化しないことで、ひとつの会社の中にいくつものシステムが存在するのは、本当にもったいないことです。フレームワークスはウェアハウスマネジメントシステムやウェアハウスコントロールシステムを扱っていますが、最初に「ウェアハウス」が付いた段階で、その仕組みを工場の中で使おうという発想になりません。しかし、データ構造からしたら何も変わらない。それなのに使われないのが不思議です。仕掛かり在庫もあるし、製品在庫もある。それらをどうやって管理するかで、製品在庫が出ていった後も最終的に名義が変わるまで、極端に言うと名義が変わってからでも物をトレースしていかなければいけないのに、製造部門の範囲でもブツブツに切れてしまう。ロケーションの移動でしかないのに、わざわざ仕組みを変えている時点で私の中では大きな違和感があります。
在庫の管理とそれを動かす人間がオペレーションすることを前提にして、1995年ぐらいに定義づけられたのがウェアハウスマネジメントシステムなので、もう30年も経っています。ウェアハウスマネジメントシステムというより、インベントリーマネジメントというような言い方で再定義したほうがいいのではないでしょうか。自動化が進む中でシステムの構造自体も大きく変わってきて、どちらかというとコントロールシステムに、ロボットやマテハンの制御側に重きを置かれる形になってきているので、定義し直したほうがいい。それによって提供する側も使う側も、頭の中をもう1回整理するきっかけにもなると思っています。

阿蘓：おっしゃる通りですね。既存の規格に沿った延長線上ではないところにも、いろいろな機会が転がっています。

現場をどうエンジニアリングしていくか

阿蘓：製造業は工場が商品で、工場をどう効率的に作るかによって良いものが輩出されます。一方、物流現場はオペレーションの一環でしかありません。ですから、物流会社で打ち合わせに参加されるのは、サプライチェーンマネジメントの管理の方です。エンジニアがバックグラウンドにあったり、だいぶ変わってきてはいますが、自分たちでトライアンドエラーしながらというより、まだ悩みを共有してサプライヤーから提案を求める段階にとどまっていて、自分たちでどうしたいかというのはまだまだこれからのような気がします。そこを能動的にできる企業は強いですね。例えばロジスティードさんのように、自分たちでどういう要求がほしくて、どういうシステムにしなければいけないか考えている会社はより早く進んでいきます。一方、外から見て大手に見えても、そこの企画力がないところも実態としてはあるようです。

秋葉：ロジスティードさんはもともと日立グループなので、日立製作所の人と一緒になっていろいろ作り込んでいるでしょうし、バックグラウンドとしてエンジニアもそれなりにいるし、システム子会社にも人を抱えています。

阿蘓：私たちからしたら要求が強いと大変なところもありますが、レギュレーションが厳しいのは合理的で理にかなっているわけです。私たちとしては大変な部分ではあるのですが、社内規定の後ろには安全のロジックがあります。今までこうやっていたからという慣習ではなく、そこにロジックが積み重なっていることに企業の強さを感じます。

秋葉：それに応え切ることができれば圧倒的な強みになりますよね。

阿蘓：ロボットの特性を理解し、自動化を進めている企業は、ロボットフレンドリーな感覚も持っていて、例えば、通路幅に人間と同じような要求をロボットに求めてはいけないといった観点もあり、通路幅の要求に応じた設計、運用をします。
既存の物流センター、既存のお客様の場合、今ある通路幅を通れるかという観点でものを見ています。現場改善的な観点で一つアプローチではありますが、ロボットが何でもできるわけではありません。オペレーションと自動化の折り合いをつけるためには、そこの要求のやりとりや妥協点を探らなければなりません。ここまでは妥協できるけれど、ここを超えるとそもそも自動化しても生産性が上がらないというポイントを見つける作業が必要です。これは私たちが頑張るだけではだめで、運用主体の方が一緒に考える必要があります。「現場をどうエンジニアリングしていくか」を物流業界は求められると思います。

秋葉：今のお話にあった通路幅も、棚の幅や高さを細かく自ら設計できるのであれば、通路幅に対して保管効率が変わらないためにはどうするか考えることも当然できるはずです。一方、既存の棚や既存のマテハン自動倉庫を入れることを前提にして、「この床面積で考えると、通路幅はこれしか取れません」という考え方もあるので、どこを起点に考えるかで全然違うのではないでしょうか。小売と同じように、物流にも床面積あたりどれくらい売上があり、どれくらいコストがかかって、どれくらい1日で通過させられるか、といった話にはなるのですが、それを目指すために、どのパラメーターをどう触るかが大事なのだと思います。
そうなると、物流施設の設計にも影響してくると思うのですが、阿蘓さんから見て、現在の日本の物流倉庫のつくりはどう見えますか。

阿蘓：日本のマルチテナントは階層があるので縦移動も考えなければいけません。上から下へ持っていく短い動線でも時間がかかってしまうこともあります。搬送ロボットは横に搬送できても、エレベーター連携をしたことがないものもあるのが現状です。LexxPlussのLexxHubは、エレベーター、シャッター、コンベアをはじめとするPLC（Programmable Logic Controller プログラマブルロジックコントローラ）制御機器とシームレスに同期するIoTデバイスです。

秋葉：エレベーターはようやく昨年か一昨年から標準インターフェースにすることが決まって、導入されているエレベーターは標準ではありません。その装置自体を作ったということですね。

阿蘓：そうですね。エレベーターに後付けして配線をつなぐことで、LexxHubが信号を出して開閉します。あらかじめ自動搬送システムと連携できるように設計されており、設備とのI/O（Input/Output 入出力）を取り決めるだけで、自動連携を可能にします。エレベーター連携は技術的より工数的に大変です。エレベーターメーカーさんにお伺いして、仕様を調整して、ロボットメーカーと調整すると、手間も費用もかかりますので、デバイスをつければ普通に連携できるものを作りました。横に広がらず縦になるのは、ある意味日本の特徴でもあると思います。

秋葉：土地の値段を考えると多層階になるのは仕方ないですね。

阿蘓：縦の連携は物量だけでは見えません。エレベーターを待って下ろしてで、2階から下ろす作業に長時間かかっているのであれば、コストの歪みにもなるので、そこも含めて自動化する。そうすれば、一つの階で完結しなくても、複数の階や階が離れたところでオペレーションすることもできます。間を全部自動化すれば自由度が持てます。縦移動は日本特有のテーマになり得ると思いますね。

秋葉：物流センターでは、縦搬送は常に課題です。自動連携か人間が押しているかは関係なく、必ずボトルネックになります。エレベーターはスピードが速いほうが高額になるので、床面積に対して、お客様の使い方で何基エレベーターが入れられるかという話との兼ね合いなのですが、やはりそこの難しさはありますね。自動連携と人で違うのは、自動化されていれば、エレベーターの縦搬送も含めてどれくらいの時間でどれくらい処理できるかの計算値が出しやすくなります。エレベーターをボトルネックにさせないためには、エレベーターの自動制御が一つのやり方としてあって、なおかつ回転の速いものにすれば、例えば、ECで使われるセンターであればこれくらいのスピードのエレベーターを何基入れておいたほうがいい、荷動きの少ないセンターであればこれくらいでいい、といった話ができると思います。
あとは防火シャッターも同じですね。ロボットがシャッターの下で止まってしまったら、火災が起きた時に下敷きになって防火シャッターの意味がないので、そのようなことが起こらないようにしなければなりません。

阿蘓：きちんと設備と連携できる搬送システムを私たちは作っていかなければいけません。LexxPlussはロボットもIoTデバイスも自分たちで作っています。エレベーター連携をしたい時にはあまり工数をかけずに提供できる製品があり、シャッター連携をさせないと火報連動が危ない時にも提案できるIoTデバイスがあります。そういったものを含めて私たちがやりたいのは、搬送の自動化だけでなく、設備全体をどう効率的に改善できるかなのです。そこはお客様の目的と一緒だと思うので、そこまで提供できるような会社にしていきたいですね。