Hacobuの事業紹介と物流の現場

戸井田：初めまして、Hacobuの戸井田です。Hacobuへの入社は2019年1月で、もう7年、キャリア的には最長です。その前はソーシャルゲームのバックエンドエンジニアとして、大規模アプリケーションの高トラフィックを捌く仕事をしていました。

株式会社Hacobuというくらいなので、物流一本でやってきています。今12期目で、事業は4つ。物流プラットフォーム事業のMOVO、物流DXを支援するコンサルティング、SI・AI導入支援、物流特化の転職エージェントです。お客様はメーカー・小売・卸・物流倉庫と幅広く、物を作ったら必ず運ばなければいけないため食品や日雑、自動車、化学、電気など業界を横断しているのが特徴です。物流は社会インフラなので基本的に止められず、システム稼働率にはかなりこだわっています。

利用事業所数は4万5000カ所（※1）、ドライバー利用ID数は80万件（※2）にのぼり、利用継続率は99.8%、システム稼働率は99.99%と、物流の現場を止めない24時間365日の安定稼働を実現しています。

※1 利用事業所数とは、MOVO 導入拠点に加えて、MOVO を利用する事業所のIDを合計した数字
※2 利用者が「MOVO Berth」を利用する際に登録するドライバー電話番号の累計ID数

BtoBソフトウェア開発に潜む「二つのズレ」

では本題の二つのズレという話をしたいと思います。この絵、皆さん一度は見たことあるかなと思うんですけど、Tree swing cartoonといいます。BtoBにおけるソフトウェアの難しさを表現した絵です。

お客さんが木のブランコが欲しいと言って、いろいろ要望を伝えた結果できたのが紐がぶら下がっているものだけで、請求金額は大きく、実際欲しかったものは木に吊るしたタイヤだった、という皮肉めいた絵です。

ここで二つズレが起きています。1つ目は伝言ゲームで生まれる要望と実装のズレ、2つ目はお客様が欲しかったのはブランコではなくタイヤだった、というズレです。この二つを解決しないと、物流における課題は解決できません。

AIで解決できるんじゃないかという話があると思いますが、そんなに簡単にはいかないと個人的には思っています。作るコストは劇的に下がった一方、お客さんの業務を変えるコストは本当に大きいのです。業務を変えるとなったら現場への説明や社内調整が必要ですし、物流は企業間業務インターフェースなので、協力会社さんやドライバーさんも巻き込まなければいけません。メーカーさんは安全への配慮への意識が特に高いので、本当にそれは安全なのかという話にもなります。業務を変えるコストは下がらないので、二つのズレをAIで「ずれたら作り直せばいい」という考えで解決するのは難しいかと思っています。

じゃあもう愚直に解決しに行くしかないということで、伝言ゲームに関しては、作り手である開発者がお客さんに近づいて解決してしまいましょうというシンプルな話になります。開発はAIに任せて、開発者がお客さんの言葉に近づく。これはもう本当にやったらいいよねという話になってきます。

ただ難しいのはもう一つのほうで、どうやったらブランコじゃなくてタイヤを作り始められるかがすごく難しいと思っています。お客さんが木にブランコが欲しいと言ったとして、それはただの解決策の1つなので、なぜブランコなんですかという問いを立てて、何を実現したいのか、何を避けたいのか、誰にとって価値があるのかを問い、お客さんと話した結果、吊るしたタイヤで十分だ、よしそれを作ろう、というところに持っていかなければいけません。自分も最近頻繁に現場に行っているのですが、勘づくのが大事だなと思い、この「勘づく」というちょっと曖昧なワードを今回のスライドに入れてきました。

「感づく力」－物流現場のクオリアをドメイン知識で問いに変える

どうやったらタイヤを作れるかという、勘づく力の話をしたいと思います。これはレオナルド・ダ・ヴィンチの最後の晩餐という絵です。AIに聞いてみたところ、弟子は3人ずつ4組に分かれています、ユダは右手で銀貨の袋を握っています、といったことを言ってきました。僕は実際にこの絵をミラノまで見に行ったことがあるのですが、そのとき感じた「わ、すげえな」という言葉の裏には、言葉にはできない感情のようなものがあって、そういう体験の質感みたいなものをクオリアと言うそうです。AIは観測できる情報から言葉を生成できますが、その言葉に体験の質感は乗っていません。質感は体験した人にしか現れないものなのです。

物流現場にもこのクオリアのようなものが結構あります。音が激しくて声が届かない中で働いている方がいて、耳栓をつけて働かれている方もいます。ガントリークレーンの音は本当にびっくりするような騒音レベルです。冷凍冷蔵倉庫のマイナス10度の庫内は、僕も入ったことがありますが長くは入れません。分厚い手袋や安全靴、防寒具を着てスマホやタブレットを持って仕事をされている方もいます。そういったことをまず勘づいて、問いを立てるのがすごく大事だと思っています。

問いを立てるときに必要なのがドメイン知識だと思っています。例えばドライバーさんが荷物を下ろせずに待っていたり、積み下ろしの予約が守られていないというときに、一般道や高速だからコントロールは難しいよねで終わらせず、ここのバースは予約運用されているのか、有責待機問題をご存知なのか、法令違反をしているんじゃないか、というところに問いを立てられます。そうやって現場の違和感に勘づいて問いを立て、お客さんと会話を始める中で、そういえばなぜこういったやり方をしているんだっけ、効率悪くないか、という話をすることが重要だと思っています。

FDEから「フルサイクルエンジニア」への転換とチーム設計

こういったことをやるのが弊社でフルサイクルエンジニアなんですよという話をしたいのですが、実はFDEというワードを使うのをやめました。Forward Deployed EngineerはPalantirが作った用語なんですが、求職者の方と話すと、FDEって何なの、ちょっと怖いんだけど、という話が多く、応募に踏み切れないという声をよく聞いたので、あえて名前を変えました。

思想は同じで課題発見から解決までやるんですけど、非常勤ではなく自社チームに所属し、自社プラットフォームで開発するというところが、明確に弊社の場合はなっています。

チームで最前線に立つということを大事にしていて、スーパーマンのような天才FDEを一人入れたら何でも解決する印象があると思うのですが、それはスケールしないなと思っています。

そこでフルサイクルエンジニアとソリューションセールス、ソリューションアーキテクトの役割を設け、あえて重ねてチームでお客さんの課題に当たっています。案件ごとに人を増やすなど、チームで技術課題を解決するのも特徴の一つです。

よく聞かれる質問に答えると、客先常駐はせず、プリセールス・コンサルでもありません。プラットフォームを用いてプロダクトを開発し、言われたものをそのまま作るのではなく、ブランコではなくタイヤを作る人です。物流未経験でも問題なく、開発チームのメンバーはほとんど物流未経験ですが、ドメインエキスパートが社内にいて現場訪問も必須なので、業務をしながら知識を身につけられます。

Ontologyを核にしたプラットフォームで学びを資産化する

プラットフォームという話がでましたが、フルサイクルエンジニアの武器としてプラットフォームも持っています。プラットフォームがないと、ゼロから開発して納品・保守することになり、なかなかスケールしません。弊社でやりたいのは国内物流の業務を標準化して全体を最適化することで、個別最適化したいわけではなく、プラットフォームを設けて複利が効くようにしています。

そのプラットフォームが何なのかという話を最後にしたいと思います。弊社のプラットフォームもコアにOntologyがいます。レイヤーを6つに分けていて、対象や関係、操作、制約を共通言語で表しています。イメージとしては、データベース設計のER図のようなものをファイルで宣言する、物流業務がYAMLでモデリングされているようなものです。その上にアプリケーションとエージェントが載り、分析もそのOntologyを参照してBIを作る構造にしています。全顧客共通のOntologyにするのは現実的ではないので、業界ごとや個社専用のOntologyも定義できるようにし、基本はShared Ontologyに寄せつつ再現性と柔軟性を両立しています。

Ontologyからソースコードがどんな感じかという話をすると、YAMLファイルで物流業務をルールにのっとりモデリングして宣言し、それを自動でSDKを生成して、アプリケーションではそのSDKを使って組み立てています。

AIには考えさせないのが一番大事だと思っているので、いわゆるハーネスエンジニアリングやガードレールと言いますが、かなり決められたステップしか動かせないように制御して、その中で実装するようにしています。

AIエージェントの強化も大事なテーマで、2つのパターンで強化しようとしています。実行時は、コンテキストに必要な根拠を出すために履歴データからセマンティックサーチをかけて必要なものを渡します。データが溜まるほど精度が上がります。もう1つが改善時で、実際の実行ログと人が確定した業務データをもとに基準を作って比較し、良い方を人がレビューして一つ一つデプロイしていきます。まだこれから作るところですが、AIエージェントの強化も回す仕組みをやっていこうと思っています。

全体像としては、こういう二重ループのフライホイールを回せるといいなと思い、これを思想の中央に置いています。業務で成果が出てお客様から信頼を獲得できれば隣の業務にも広げていけるので、業務領域が拡張し、その拡張がOntologyという共通資産に還り、Ontologyが成長して実装速度や再現性が上がり、またお客様の成果につながって回っていきます。データが溜まればエージェントの精度も上がり、それがまた業務成果につながる。こうしてプラットフォームを成長させ、お客様の課題解決の速度を上げられたらなと考えています。

まとめ－コードを書く楽しさ、課題発見の楽しさ

まとめですが、4つの章をもとにまとめてみました。AIで実装が速くなっても、二つのズレはBtoBのソフトウェア開発をする上で起きてしまいます。伝言ゲームが多いと当然お客さんの要望はずれてしまいますし、そもそもブランコを作ってしまう可能性も絶対にあるので、ここは必ず防ぎたい。

防ぐためには、やっぱり現場に行かないと防げないと思っていて、現場でドメイン知識をもとにお客さんと対話し、本当に欲しいのはタイヤだったねとなってから作り始めることを大事にしています。それを実現するためにエンジニアが現場にチームで行って課題解決し、単発で終わらせずプラットフォームを用いて解決することで、物流全体の最適につながると考えています。

このフルサイクルエンジニアなんですが、コードを書くのは楽しいじゃないですか。僕はAIにコードを書かせて、自分で見て、こういう書き方をするのかと、かなりコードが好きな方なので、コードを書く楽しさをそのままに、課題の近くで発見できる楽しさも味わえます。AIがなかった時代は、コーディングで精一杯で、課題の本質に近づきたくても業務上時間的に無理という構造でしたが、そこが解かれて、コードを書く楽しさをもとに課題発見の楽しさも、エンジニアリングによる解決の楽しさも味わえるようになりました。物流のドメイン知識というバーティカルな知識を獲得する喜びもあり、深まるほど見える世界が広がり、知らないことが知れて楽しいですし、相手にする課題は社会課題に根付いていて、社会貢献という意義もとても大きいです。

物流は企業間業務です。たとえば、食品メーカーが製造した商品は、物流事業者や卸売事業者など、さまざまな企業を経て小売店舗に届けられます。企業間業務であることと物理が絡んでいること、産業横断していることで課題の寿命がとても長く、AIで簡単に解決できない領域だと思っておりとても面白いです。この体験を味わってみたいという方は、ぜひ声をかけてください。最後に採用のご紹介ですが、興味がわいたら応募していただけると嬉しいです。

以上になります。ありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画はこちら

※動画の視聴にはFindyへのログインが必要です。