最近は物流業界にいます
これはあくあたん工房アドベントカレンダー 2024 19日目の記事です。
はじめに
あくあたん工房が7年目だそうです1。 大抵の団体は初期メンバーが抜けると動きが止まって消滅していくのが普通だと思うんですが、これだけ続いてるのは驚きです。 後輩たちの活動力には脱帽します。
7年も続くと卒業して就職したメンバーがわらわらと東京に集まってくるので、定期的に年1くらいで東京会が開かれます。 これも後輩が声をかけてくれます。すごい。
ただ、半年前に開催された東京会では初対面のメンバーに「taxio さんって何をしてる人か分からない」と言われました。 同期にも言われるし自分でもよくわかってないです。
せっかくなので今回は、軽く何をしているか紹介しつつ今やっていることの技術的な難しさについて少し触れたいと思います。
物流の完全自動化
タイトルのとおり、ここ1年くらいはずっと物流業界にいます。 今年の8月に公開された『ラストマイル2』という映画を見るととても分かりやすいです。 あそこで出てくるようなモノの流れを、ロボットを用いて完全自動化するプロダクトを開発しています。
今までは Web 業界で開発をしていたので、良くも悪くも文化がかなり違うのが衝撃です。 触れる技術ももちろん違うし、プロジェクトの期間や関わる人の数も違います。 (ということは動く額もそれなりに変わってきます)
ビジネス的な観点は置いておいて、技術的な観点から主に Web 業界と比較していくつか難しさを挙げてみます。
物理的にマイクロサービス
サービスの構成を考えるときにモノリスかマイクロサービスのどちらにするかはよく話題に上がるトピックです。 どちらにも一長一短がありますが、ロボット系では物理的にモジュールが分かれるので勝手にマイクロサービスのような構成になります。
ただし、アプリケーションの冗長化はしにくいです。 例えば2台立ち上げて、LB で振り分けてーとかは簡単にはできないです。 なぜならそのアプリケーションから動かすハードウェアは1台しかないことがあるからですね。
そのハードウェア自体を複数台にする考えもありますが、次は物理的スペースの問題が出てきます。 また、そもそも全体のモノの流れを冗長化して、特定のラインが止まったら別のラインにフォールバックするということも考えられます。 いずれにしても冗長化には常に物理的な制約がつきまといます。
HTTP API を叩きあうことだけでは無い
通常、Web のマイクロサービスでは各サービスが HTTP で API を提供しているので、それを使った通信を行います。
ロボット系では責務よりかはハードウェア都合でサービスが分割されるため、色々な要因で通信相手をフレキシブルに変更する必要があります。 そのため、どちらかというと相手を選ばない Pub/Sub 系の通信方法が好まれます。
スキーマ駆動開発が主流ではない
完全に僕の観測範囲での話になってしまいますが、スキーマ駆動開発のエコシステムが整っていないように見えます。 HTTP API でのやり取りであれば OpenAPI や proto などが活用できますが、それ以外の通信だと途端に選択肢がなくなります。 JSON でやりとりをすると決めれば JSON Schema なんかも活用できますが、Pub/Sub の Topic も合わせて定義したいとなると力不足です。
一応 AsyncAPI というものが存在するのですが、コード生成側がまだ未発達なので自前でツールを作る必要があります。
通信周りはまだまだ業界的に課題が残っていると感じます。
そもそも一回の Internal Error が致命的
Web サービスであれば 5xx 系が返ってきたらユーザは一度離脱して、その後時間を置いて復帰してくれたり、別の方法を試してくれたりすることが期待できます。 ただ、ロボットの場合そこまで柔軟に動いてくれない (想定できるエラーならそもそも回避方法を作っているし) ので、Internal Error が起きたということはそこでロボットが止まっている (= ラインが止まっている) ということを意味します。
もちろん自動リトライや自動再起動なんかも入れますが、物理的に問題が起きている場合はどうしようもありません。
事前にテスト等で気付けるようには努力するのですが、ハードウェアが絡むとこれもまた難しい。 こういうのを見ていると形式手法を応用して事前に信頼性を上げることが求められるんだなぁと感じます。
現実の状態が正
通信から少し離れた話をすると、データと現実の状態ズレが難しいです。 DB に保存されている値も極論、現実のセンサーが返してくる値のキャッシュとも言えるでしょう。
内部的にはそこにモノがあると記録しているのに、センサーからはモノが無いという情報が返ってきているのであれば、無いことを前提として状態を修正する必要があります。 なるべく状態ズレを無くして、ロバストに正常なフローに復帰する設計が求められます。
しかし物流の自動化は面白い
もしかしたらこのままではマイナスな印象が残ってしまうかもしれないので、面白いところも書いておきます。
何より規模と成果の分かりやすさが良いです！
要は人の作業量を減らしてモノの移動量を増やせば良いわけです。 これは ISUCON をしている感覚と一緒です。
そしてモノの移動はほぼ全てのビジネスに関わります。 僕は技術的な挑戦がたくさんあり、何よりビジネス的なインパクトの大きい仕事が好きなので今の仕事に非常に満足しています。
おわりに
ちょっと抽象的な話が多いので想像がつきにくかったかもしれません。 実際に見たり、図示したりしないと伝わらないかなぁと思いながらこの記事を書いています。
採用強化中なので、興味を持った人はぜひご飯に行きましょう。
