配車計画を「デジタル＋人の手による最終調整」で100％に持っていく。わかりやすさを価値とする開発
ラクスル創業の頃からインターンを経て在籍する吉岡 渉は社内ではちょっとした有名人。ベンチャーの夜明けという過酷な時期も体験し、その後異動したハコベルもJV化し、偶然にもいつも「始まりの時期」に参画しています。「現場に出てリアルにイメージする」ことをずっと大切にして開発を手がける吉岡に、ハコベルのものづくりについて聞きました。
システム開発部 配車計画システムG
吉岡 渉 Wataru Yoshioka
2011年、大学4年生でインターンとしてラクスルに参加。2012年４月に正社員として入社し、創業期に印刷ECの立ち上げに関わる。４年ほどエンジニアとして従事したあと、2016年ハコベルへ異動。「ハコベル運送手配」のマッチング機能追加などに携わったあと、「ハコベル配車計画」のテックリードとして開発を担う。現職。
ラクスルからハコベルへ。いずれも立ち上げ時に参画する貴重なタイミングを経験
—— 吉岡さんは社員番号がかなり初期でときどき話題になっています(笑)。少しこれまでの歴史をお聞かせください。
2011年、当時大学４年生の夏にインターンでラクスルに参加したのが最初です。もともとは友人が先にインターンをやっていて声をかけてもらったのがきっかけ。そのときはラクスル創業者で現会長の松本さんと、あともう1人共同創業者の方2名がフルタイムでやっていて、あとはアルバイトのみ、みたいなタイミングで参加しました。
友人に声をかけられたとき、「プログラミングができる人」を探しているとのことで、私は大学で多少触っていたため、なんとなく興味を示したら「じゃ、来週からとりあえず来て」と言われ、軽い面接のようなものをしてすぐに「何日からお願いします」という感じのスタートでした。
当時は漠然と大学院に進むつもりでいたんですが、特別に何かやりたいわけでもなく、学部がだいたい70～80％の人が大学院に進む学部だったんです。社会に出て働くイメージも、就職活動のイメージもわかず、なんとなく「このまま大学院に行こうかな」と思っていたところでインターンを開始したら、純粋に楽しかったのです。
—— いまとなっては貴重な「創業前夜の空気感」を体感した方なんですね。最初はラクスルの印刷の仕事をしていたのですか？
いえ、当時まだ印刷のECもなかったときです。インターンを経て正規に入社したのは2012年の４月。そこからちょうど、印刷のEC立ち上げがプロジェクトとして開始になり、入社してすぐは印刷のECをつくるところに携わっていました。
そのころでもエンジニアは、立ち上げからいらした共同創業者の方と私と二人のみがフルタイムで、他は大学生のインターンと休日だけ手伝ってくれる人がいたりと、そんな体制でした。それから何年かが過ぎたころ、2016年の４月あたりにふと「会社を辞めようかな」と思うようになりました。そろそろ何か、新しいことを始めてみたいというタイミングだったのだと思います。
月１の面談で正直な想いとして伝えたところ、退職ではなく「ハコベルはどう？」と薦められました。当時のハコベルは、宮武さんとエンジニアの方、オペレーターが2名という体制で、宮武さんとお話してみていったんハコベルでやってみよう、となりました。
—— インターンから正社員、ラクスルからハコベルへ。常に訪れる機会に対して素直に乗っていくことでキャリアをつくっていらっしゃる。
結果としてそうかもしれません。退職しようと思ったのも、そろそろ新しいことにチャレンジしたいという気持ちが強くなったから。ハコベルは技術スタックというのがラクスルとは違っていましたし、人数もまだ少なかったので「また面白いチャレンジができるかな」と率直にワクワクしました。それで退職ではなくハコベルへ異動を選んだのです。
毎回たまたま、人が充足している状態ではなくゼロベースから関わっているというのは共通していますが、ラクスル立ち上げの頃と比較すると、既にいろいろな組織機構が整備されている段階でしたのでその点は働くうえで結構違いがあったかな、と思います。
私が異動した2016年、同じタイミングで石川 瞬さんがご入社になり、いろいろと動きだすことになります。ラクスルとハコベルとで技術スタックが違ったため、エンジニアとしては技術のキャッチアップを粛々とがんばる、という日々。あとは「印刷から物流」という業界の違いがあり、まったくわからないのである程度、業界動向を理解していくことに努めました。
エンジニアも現地に赴き現場の声を聞く。細部に至るイメージの解像度を高める
—— その段階にはマッチングのプロダクトは既にあったわけですか？
はい、ありました。なので最初に従事したのはマッチングのプロダクトへの機能追加や、社内のオペレーター向けの管理画面の開発・機能追加を担当していました。
現在は「ハコベル配車計画」のスクラムで、テックリードというかたちで開発をおこなっています。2023年の６月に立ち上がったサービスで、ようやく世に出せた、という感覚です。2021年あたりにはその計画の始動のようなことは既に話にあがっていて、当時はアルゴリズムというよりはロジックベースで配車計画を組めないか？といったような方向でした。
ラクスルグループ全体で「Hack Week」を年に1度開催しているのですが、そこで「ハコベル配車計画」で使っているアルゴリズムの検証をやったのがまず始まり。
その「Hack Week」でプロトタイプのようなものをまずつくって動かしてみて、ある程度手ごたえがあったのでそこからお客様と一緒にお話を詰めていき、スタートに至りました。なので、2021年の秋あたりから開発が始まって、実際にお客様の営業所の方と「どういうふうに配車を組んでいるか」などのお話をしながら、あとは現地に実際に足を運んで様子をうかがい、ヒアリングをしたりして要件を詰めていったのです。
私はラクスル、ハコベルしか知らないので他社がどうかはわからないのですが、ラクスル、ハコベルグループは少なくともエンジニアも現地に行って現場の声を聞くということを推奨していて、ラクスルにいたころは印刷会社様にうかがい、ハコベルに来てからは物流会社様を訪問したり、というのは何度もあります。
—— ハコベルでは「Reality」を重視していますから、開発担当者でも現場に赴くのはまれではないのですね。
そうですね。間に人を介するよりも自身で現場に行って、見て、聞いた方がイメージがしやすくなります。実際に人から状況を聞いたとしても、たぶん実際に足を運ばないと「これってどういうことだろう？」という細部までイメージしづらいんです。
現場に行って実際の作業を見ることで、そのあたりの解像度も深まるのだろうと思っているので、積極的にエンジニアは機会があったら現場に行くようにする風土があります。
「ハコベル配車計画」における私の関わり方は、アプリケーション開発です。いまは、アルゴリズムと呼ばれる部分の検証や機能追加をやっており、現在はまだ顧客も限られていますが、今後はさらに多くの会社さんにご利用いただけるように、商談をして実際にデータを提供いただき、シミュレーションを回してみるなど、商談する企業ごとに望まれる機能なども出てきているので、それらがアルゴリズムに組み込めるか？などの検証をしています。
お客様も営業所によって必要な機能や配送方法が違っていたりします。数十社とお話を聞いていくと、ある程度どの会社においても必要そうな機能や、優先度が高そうなことが見えてくるので、それらを優先的に組み込んでいくわけです。
—— 初期リリースまでしっかり時間をかけてつくり込み、さらに機能追加を継続していくのですね。
機能追加は機能追加で難しい部分がありますし、初期リリースはもちろん大変なことはあるのですが、我々がつくっているようなプロダクト開発で言うと、そういったあとからいかに簡単に拡張できるか、機能追加ができるか、というのを考えながら進めることも私たちの仕事です。わりと「ハコベル配車計画」のプロダクトは最初にしっかりと設計、こういう構成でいこう、といったことを決めていますので、機能追加も順調にできている印象があります。
もちろん想定していないことも若干あるのですが、実際にリリースして使用していただくことで、見えなかった部分がわかってきます。ですから、まずはリリースしてご利用いただくことが大切。また、つくり込んでいく過程でお客様との関係性も築くことができていくので、まずはしっかりとお届けし、実際に使っていただくことでフィードバックをいただき、さらに開発を進めていく、というのが実に大事なことなのです。
目指したのは「100％の正確性」ではない。「ハコベル配車計画」が担うこと
—— 「ハコベル配車計画」の特徴、どんなことを可能としたプロダクトなのでしょうか。
実際に導入いただいたお客様のひとつの営業所で見ますと、3名体制で配車計画をおこなっていたそうですが、「ハコベル配車計画」を導入したことで2名に減らすことができたそうです。
これは１人月分の工数が他の業務に回せるということで、数字だけでは見えにくい大きな効率化が進められたのだと思っています。他社でも同様のプロダクトはあるのですが、ハコベルのプロダクトでは、アルゴリズムで配車計画を自動化すると言っても、100％正確な計画を目指そうよ、という考えではないことが特徴。そこを突き詰めるのは相当に大変なことで、コストやリソースも掛かる。
それよりもアルゴリズムの結果は70～80％でよい、とします。そのうえで、実際に70、80％のものを最終的に人の手を介することで100％にしていく。人の、手動で変更する実際のアルゴリズムが吐き出したことを配車計画をする人が手動で100％にもっていく、そこの作業をいかにシンプルにできるか。実際にユーザーインターフェースだったり、そういったところで、手動で計画する部分をよりわかりやすくする、そういったことが価値のひとつの側面なんじゃないか、と考えています。
—— たしかにデジタルトランスフォーメーションというのは、デジタル化するのがゴールではなく、デジタル技術の活用で業務を効率化した結果、ビジネスモデルそのものを変革することだ、と言われてきましたね。
そうです。要するに100％デジタル化することが良しというのではなく、デジタルと人の手による合わせ技で100％に持っていくという。それによって業務プロセスの改善で生まれた時間を新規事業とか別の価値を生みだすことに使えるという考えですね。究極、それが現場は１番助かることなんだと思います。
余談ですが当時、アルゴリズムを開発してた2022年４月ころ、私ともう１人、基本的に2人体制で精度を高めるということに従事していました。業務の内訳は、私が主にWebアプリケーションとのつなぎ込みを担当し、もう１人のエンジニアがアルゴリズムの開発担当、というすみ分けで進めていました。ところがこのアルゴリズムの開発担当者が退職するということになり、それまで業務を分担していたこともあって、その方の退職に伴うアルゴリズムの引き継ぎに大きな不安を覚えました。
仕方ないのですが急な退職で実務以外のアルゴリズムの実装の引継ぎなど、コミュニケーションの部分はけっこうがんばった思い出があります。
要はアルゴリズム側がちゃんと動かないと無意味ですし、それこそがキモだったりしますので、たった1ヶ月ほどの引継ぎ期間で今後残ったメンバーだけで開発を進めていけるのか？ということや、この先機能追加があった場合に対応ができるのか？といったことを検証する必要がありました。このことは特に大変だったこととして記憶していますね。
働きやすい組織で「課題解決をするプロダクトをつくっている」というやりがい
—— 本来の前に進める業務を停滞させることなく、引継ぎ期間で今後対応可能なのかの検証を並行しておこなったのですね。そこから1年弱でリリースできたのは順調だったのでしょうか。
わりと順調だったのではないかと思います。
「ハコベル配車計画」は日付を入れてその日の配車計画を作成します。注文データ、その日の荷物の情報をアップロードすると荷物に対して、「この運送会社のチャーター車両と路線、という配送形式があるけど、チャーター車両ではこの荷物を運ぶといいよ」、「この運送会社で運ぶといいよ」とか、「この荷物はこの路線会社がいいよ」といったようなことがわかり、お客様の基幹システムと連携ができたりします。
いきなりポンとお渡ししても難しいので、お客様とは定例会を儲けて実際にプロダクトをつくる前に、モックのようなものを用いていろいろなフィードバックをいただきます。それを実際にプロダクトに落とし込んでは触っていただいて…というのを繰り返します。
これまでは印刷した紙に鉛筆でメモを書いてやっていらした業務が、いまでは画面上で動かしていらっしゃる。先ほどお話した「デジタルと人の手」という、ある程度システムが担って最後の調整を人の手でおこなうというのは、これまでに比べたら本当に時間も手間も削減できていると思いますし、そうあって欲しいと思うところです。
現在の物流課題というのは、以前よりも社会的注目度が増しているタイミングで一般的にも認識されているかと思うのですが、そういった課題に対するソリューションは絶対に今度必要となってきます。「ハコベル配車計画」は確実にそのひとつなのだと考えていて、そういった社会の課題に対して、課題解決をするプロダクトをつくりだしているというのは、個人的にすごくやりがいを感じるところです。
—— 難易度が高いけれど、やりがいも無限。どんな人に特に向いている仕事でしょうか。
難しいことですけれど、世の中のためになることをやりたい、という方はすごく大歓迎ですし、技術的にもどんどん新しいこと、新しいものを取り入れていくことはウェルカム。そういう好奇心のある方もぜひ一緒に働けたらうれしいです。
長い社歴ですが働きやすい環境だと思っていますし、理不尽なことが１度もないんですよね。単純に物の売り買いではなく、やっぱり社会に役立つものをつくる一員という実感が持てるのが「ハコベル」だと思っています。
この記事が気に入ったらサポートをしてみませんか？