00:02
エンジニアリングマネージャーの問題集。
株式会社株式スタイルの後藤秀之です。
この番組では、エンジニアリングチームで起きている問題について、
技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、プロダクトを通してお客様ごとの現場とどう向き合うのか問題です。
プロダクトというもので、いろいろなお客様の問題を解決していくといったときに、
業界によっては、銀の弾丸のようなプロダクトで一気にいろんなお客様の問題を解決できるというところもあるでしょうし、
とはいえ、やっぱり多くの業界ではお客様ごとにかなりいろんな違いがあって、
そう一筋縄では全てのお客様に対して一気に問題を解決するということが難しい場合も多いのではないかと思っております。
今回お話を伺うのは、どちらかというと、やっぱりお客様ごとの違いというところと格闘していらっしゃるのではないのかなと思っておりまして、
そのあたりの生々しいお話をいろいろ伺いたいなと思っております。
本日のゲストをご紹介します。
株式会社オプティマインドエンジニアリングマネージャーの古市さとしさんです。
古市さん、軽く自己紹介をお願いできますか。
株式会社オプティマインドエンジニアリングマネージャーをしております古市と申します。
まだ入社半年というところではあるんですが、会社第1号のエンジニアリングマネージャーとして今活動しているそこです。よろしくお願いします。
よろしくお願いします。
このポッドキャストではエンジニアリングマネージャーの皆さんをゲストにお呼びして、
その会社の事業ですとか、それから組織のこと、それからエンジニアリング観点といくつかの観点でいろいろお話を伺っていこうという感じで進めております。
今回は事業のことをいろいろ伺いたいなと思っているところなんですが、
まずその前にオプティマインドさんの会社のミッションだとかビジョンとか、それから事業とかサービスのことについて、
まずいろいろ概要でお話しいただきたいなと思うんですが、お願いできますか。
オプティマインドでは新しい世界を技術で作るというミッションのもとですね、
社会課題を我々が持っている技術で解決していこうということで立ち上がっている会社になります。
中長期としては今、世界のラストワンマイルを最適化するというビジョンを掲げてですね、物流業界特定の領域ではあるんですけれども、
まずはここに我々の技術を使って難しい社会課題を解決しようということで取り組んでいる会社になります。
ラストワンマイルのところをプロダクトでもって革命を起こしていこうというような感じかなと思います。
03:05
実際そこの事業とサービスというかプロダクトというところはどんなものになるんですか。
物流の領域はいろいろあるんですけれども、我々が取り扱っているラストワンマイルというのは最後の配送区間と呼ばれていて、
最後の倉庫から皆さんのご自宅とかコンビニですとか薬局ですとか店舗の配送ですね。
実際の利用者のもとに届けられる区間を対象としているんですけれども、我々が提供しているサービスはその中でも配車計画ですね。
注文入ったものに対して誰がどのように物を運ぶのかというのを計画をするフェーズがあるんですけれども、
この配車係がやっている業務を我々のサービスで代替していこうというより便利になるような機能を提供しているというところになります。
なるほど。ありがとうございます。ラストワンマイルのところの配車計画ですね。
そこも会社によっていろいろやり方が違ったりだとか、相当コストを削減できる余地だとか、いろんなところがあるんだろうなと素人ながらに想像しております。
そういった事業のところについて、今回はより深掘ってお話しして、エンジニアリングマネージャーとしてそこをどう見ているのかとか、そういったお話を聞けるといいなと思っております。
改めて、プロダクト名だとか、プロダクトとしてどんな強みがあるのかとか、そういったところから教えていただけますか。
我々が今提供しているサービスはルージアという名称で、配車の自動作成を行うサービスを提供しております。
一般の配車の仕組みというのは、基本的にはいくつかの1人で荷物を、例えば50個の荷物を今日配送します。
50箇所回って帰ってくるルートを作るんですけれども、これを会社さんで抱えているドライバーさん、配送できるトラックですね。
これを使って一度に計画を作ります。
なので、配送の単位というか1日分、午前中分とか午後分とある塊でまとめて最適化したルート、配送の順番というのを一度に計算して提供することができるようになっています。
我々のサービスのポイントはいくつかあるんですけれども、Googleマップのように2点間のあるAからBの間をどの道を通るといいかというような計算ではなくて、
06:01
運ばなければいけない全てのポイント、我々はスポットと呼んでいるんですけれども、全ての場所の経路探索を行って全体最適をして結果を出しているというところですね。
そこに使われている最適化をするエンジンと、実際どの道を通るのが最適かという答えを出す経路探索のエンジンですね。
この2つが我々のサービスのコアの技術となってサービスを提供しております。
ありがとうございます。結構その経路探索、最適化というところで、アルゴリズムの分野というかソフトウェアエンジニアリングでその強みをプロダクトにそのまま活かせるような、
そういったところがあるんだなというふうに思いまして、エンジニアとして結構魅力的なプロダクトだな、関われると面白いだろうなというふうにも思ったりしますが、
一方でそういった経路の最適化探索みたいなところをサービスとしてお客様にはどういう形で打っているんでしょうかね。
そうですね、直接組み合わせ、最適化の結果を意識したりとか、経路探索の結果をお客様が目にすることというのはあまりないというか、
画面で地図の出てきた道を見ても、なるほどと思う部分でしかないところはあるので、
なかなかサービスとして我々が持っている強みを意識しず、直接画面でサービスを使って知るというのは難しいところなんですけれども、
これまでの手で作っていた計画と比較したり、もしくはより我々のサービスを使い込むことによって精度が高まってきたり、
あるいはいろいろな要望を取り入れて、より細かい条件でこの計画を作れるようになった場合に比較すると、
ドライバーさんが前手でやっていたときより30分以上早く帰ってくるようになったとか、
車が1台少なくても同じ荷物の量を実は運べることが分かったりとか、
最適化した結果、良くなっているというのを後になって実感できるということは多いんですね。
なるほど、今のお話って逆にすごいなというふうに思ったんですけれども、
画面上とかでここがすごいんですよみたいな話ではなくて、
実際に出てきた結果で現場の方々が動くと、すごい良くなってるじゃんって実感されてるっていうことですよね。
なんで本当に結果を出しているプロダクトになっているんだろうなというふうに今思いました。
これってお客様の課金体系とかってどんなふうになっているんですか。
基本的には契約する拠点単位の課金になってますね。
09:04
なるほど、拠点単位ということはそこそこ大きな規模で事業されているところはやっぱり結構なお金をお支払いすることになるでしょうし、
小さなところであれば少ないと、そういうサイズによっての課金という感じなんですかね。
そうですね、そうなります。
毎回どの方にもお伺いはしてるんですけれども、
そういった事業のビジネスモデルみたいなところと裏側のソフトウェアでかかるコストとか、
そういったところがどういう関係性があるのかなみたいなところを聞きたくて、
そういった拠点の数によって計算コストが増えるとか、そういったことがあったりするんですか。
そうですね、仕組みとしてはやはりこの計算量に依存してかかる費用は、
インフラ代という意味では実際には変動はあります。
ただ計画を作ることを考えたときに、毎日基本的には明日の分の計画を作るとか、
今日この時間までに注文が来た分で計画を作るという形で、
運送会社さんも業務をしている以上、必ず配送というのは途切れることなく実施されているので、
割と安定しているというか、使う分量をある程度想定した課金体系にはなっているので、
厳密には荷物の運ぶ数だったり、運ぶ先の拠点の数によって裏で動く費用は上下はあるんですけれども、
基本的には使われる規模、相当の課金体系にはなっていますね。
なるほど、なるほど。
じゃあ裏側の計算量だとか、そういうところに相関ぐらいはあるけれども、
厳密に結びつけたようなロジックでの課金体系ではないといった感じなんですよね。
はい、そうなりますね。
なるほど、なるほど。
でもお客様にも拠点数といえば、お客様の考え方的には納得いただけるような数字になるでしょうし、
それが大きく裏側のコストのかかり方とも乖離していないのであれば、
事業としてもそんなに変なモデルでもない、もちろん変なモデルでやってるってことはないと思うんですけれども、
そういった形でビジネスをしているという感じなんですよね。
そうですね、急に全拠点入れるお客様というのは少なくて、
まず1拠点試してみようと、本当にこのサービスで効果が出るのかというのを検証する段階が割とあって、
我々のコンサルティングチームも実際にこの契約に漕ぎつけるところまでのオンボーディングでシミュレーションしたりして、
これなら効果出ますねと、分かっているところからスタートしているというか、
そこでうまくいって残りの拠点に横転していきましょうと、そういう流れで進んでいるところですね。
12:05
じゃあ、この事業のやり方というか、どんなことをやってらっしゃるのかというところを概要はつかめたところで、
とはいえ、このラストワンマイルみたいなところをいろんな会社さんがどういうふうに取り組んでいるのか、
それに対してプロダクトというものでどう解決を提示しているのかというところで、
いろいろ難しさというか、そういうこともあるんじゃないのかなとも思ったりするんですが、
実際どうなんでしょう、ここのプロダクトにするというところでの課題というか。
我々の配送業務に対して提供している機能が、同じものを運ぶ区間、ラストワンマイルの区間で同じなんですけれども、
水を運ぶにしてもガスボンベを運ぶにしても宅急便だったとしても、
運ぶものと届ける先があって、同じように配送計画を作るんですけれども、
実際には結構業務が異なっていて、結果としては同じことになるはずではあるんですけれども、
そこに至るまでの業務がかなり会社ごと違う。
同じものを運ぶにしても会社ごとにいろいろなアレンジがあって、計画の立て方が違うので、
我々がサービスサーズとして1個機能を提供しても、
なかなかすべての会社さんにかゆいところに手が届かないということが起こる部分が多くて、
そのあたりが結構難しいというか、プロダクトとして会社業務全体をカバーしようとしたときに難しさが出てくるところですね。
そうですよね。
2Bを扱うときってやっぱり一つの銀の弾丸みたいなプロダクトで、
どの会社さんでも通用するみたいなものってなかなかないんだろうなと思っていますし、
それがなおさら現場の仕組みというところにアプローチするものなら、
なおさら会社ごとにいろいろな工夫をされているところだと思うので、
当然違いはあるだろうなというところを思っております。
グリーンにかけない転職裏話ラジオ、略してグリテンラジオは、
転職アプリグリーンの運営メンバーが個人的一押し企業について語ったり、
現場で感じる転職や中途採用のリアルについて話す音声番組です。
毎週月曜朝6時更新です。
通勤や休憩時間のお供にぜひお聞きください。
詳細はカタカナでグリテンラジオと検索してチェックしてください。
実際に会社業務というところについて、
15:00
具体的にどういうパターンの会社業務があるのかというところまで聞きたいなと思うんですが。
はい、そうですね。
まずこの計画を作る基本となるのが、
どの車がどの配送先をどういう順番で、
さらにどの道を通るといいかという、
この4つをベースに計画を作るんですけれども、
例えばで言うと宅急便みたいなものをイメージしたとすると、
ある地点、トラックがある場所が倉庫であれば、
そこで荷物を積み込みます。
その先に20件とか30件とか、
一度集荷して、あとは配送していくだけというパターンが1つあります。
それ以外に、
集荷する場所と配送する場所が利拠点にない、
途中で集荷したものを配送するというパターンがあります。
これって積んだものをあと順に下ろしていくだけでいいものと、
トラックにはもう積載量が決まっているので、
配送しないと集荷できないという条件が生まれたり、
運ぶものだったり、運び方、
集荷のタイミングとか、
それらの条件が業態というか、
運ぶ業種によって差があるところが出てきますね。
なるほど。
まずそもそも運び方っていうか、
ところに違いがあるっていうのがまずあるわけですね。
それ以外にもあるんですか、
計画するっていうところ、業務としてやってるので、
もっといろいろあるんではないのかなとも
想像したりするんですけれども。
そうですね。
かなり細かい話でいけば、
いろんなパターンがあると思います。
大きい会社さんですと、
配車係が専門で行って、
計画を作って、あとドライバーさんお願いしますねと、
一方的というか指示を出していくパターンもあれば、
配送を自社で持っていない運送会社さんの場合は、
配送だけをどこかにお願いするので、
この計画であとお願いしますと、
ドライバーさんに割と丸投げして、
ドライバーさんがあと自分で考えて、
配送するというパターンもあったりしますね。
なので、計画の作り方がそもそも違ったり、
ある程度ざっくり決まれば、
あとは現場で何とかしますと、
うまいことやる場所もあれば、
必ずこのようにやるのがいいんだと、
業務を固定してやる場合もあったりしますね。
なるほどな。
その辺の使い方というか、計画の仕方というんですかね。
そこ自体もかなり差があるような感じなんですね。
そうですね。バリエーションがあまりにも多いので、
なかなか難しいというか、
どこまでこれを有効に使えるかというのは、
18:00
結構課題ではあって、
そういう意味では、ベテランさんになればなるほど、
道も分かっているし、
配送先もある程度聞けば分かるというと、
この仕組みを使うメリットが、
少し今現状では薄れていくと。
ビギナーさんになればなるほど、
走る道も分からないし、
運ぶ先も土地感もよくまだ馴染みませんという場合は、
ひたすらこのシステム通りに行くのが一番ベストというか、
計画の通りに業務が進むので、
非常に重宝されるというところはありますね。
なるほどな。
といったときに、
プロダクトとしては、もちろんコアの配送計画を
自動的に作って最適なものを提示してくるというエンジンが、
一番の強みであるとはいえ、
お客様ごとにそこまで違いがあるとすると、
どういった部分でお客様に価値提供するのかというのが、
全然違うとかそういう感じになってくるんですかね。
なりますね。
非常にそこが難しいというか悩ましい部分はあります。
超大手のお客様に限っては、
自社にそういう仕組みが存在しているので、
我々はこのSaaSとしてではなくて、
PaaS文脈に近い、
完全にAPIとして機能だけを提供するので、
あとはお客さん側で仕組みを作ってもらうと、
自由にそのあたりは制御してもらって、
我々は最適な答えを出すことに集中するという提供の方法も
今用意しているので、
できるだけ画面に依存するとどうしても業務の制約で、
あれはできるとかこれはできないという話が
たくさん出てきてしまうので、
そのあたりはお任せしてしまうというやり方も
今一つ持っていますね。
なるほど。
そこだけ欲しいところももちろんいらっしゃるでしょうね。
特にそこが強みだということなので、
そこだけ販売できる方がむしろ、
分からないんですけど、
会社としての利益率がめちゃくちゃ高いとか、
そういうことになるのかなというふうにも想像したりもしました。
そうですね。
やっぱり注力していきたい領域ではありますね。
ありがとうございます。
そういうふうにいろいろなタイプのお客様、
異なる課題を抱えていらっしゃるところに
プロダクトもしくはAPIみたいなものをお持ちで、
それでソリューションを提供しているといったところだと思うんですが、
お客様ごとの違いというところでは、
やっぱりプロダクトを通して基本的には解決していこうという方針自体は、
素人的に言うのは申し訳ないんですけど、
それ自体は間違ってないような気はしているんですけれども、
とはいえやっぱりいろんなお客様ごとの状況があると思うので、
そういうところに対してちょっと違うアプローチが必要だったりだとか、
21:03
そういうところもあったりするんでしょうか。
そうですね。
全てのお客様にまんべんなく使える機能を提供するのはやっぱり難しいし、
全ての要求を取り入れるのもやっぱり難しいので、
現状今ある機能がしっかり業務にフィットするかっていうところを
あらかじめ契約の前段階で絞っているというか、
我々のサービスが確実に業務に刺さるであろう会社さんに
まずは今当てにいっているというところですね。
ある程度適応性があることが分かっているお客様に対して、
そこに追加機能をつけてより使ってもらうと。
それが全ての市場にうまく当てはまるかというと、
それはまた別の話にはなるんですけれども、
誰が使うか分からない機能をとりあえず声があるから入れていこうというのは
さすがに難しい世界なので、
ある程度業種というか業態を絞って、
特定のお客さん向けにまず機能を強化してそれを横転していくと、
そういう作戦を考えているところですね。
分かりました。ありがとうございます。
結構授業のところはいろいろ聞かせていただいて、
僕自身がすごく興味があるテーマなので、
掘っていくと無限に時間がかかっちゃうので、
ちょっと一旦ここぐらいにして、
Optimindさんってこの授業と個人だったり、
エンジニアリング組織だったりというところの距離感とか、
エンジニアが授業とどう向き合っていくのかみたいなところについて、
設計だったりカルチャーとしてこういうふうにしているみたいなところがあれば
伺いたいなと思っています。
はい、そうですね。
距離感という意味では、
Viz側と開発組織の間には、
プロダクトチームという組織横断型のチームがいて、
そこで次の戦略というか、
どういう機能をどこの市場に提供していくといいかというようなことを考えたり、
UXリサーチャーの方がいたり、
デザイナーが所属していたりということで、
プロダクトとしてどう消化させていくべきかみたいなことを
メインで考えているチームがいます。
開発チームはそことアライメント取りながらやってはいるところなんですけれども、
ちょっとそういう意味ではVizとの距離感であるというところが
課題とは言い切れませんが、
我々の今の組織の特徴としてそういう体系を取っているので、
それでいかに開発者が実際に手触り感というか、
我々が自分たちが作ったサービスが成果を上げているという感覚を
掴んでもらうにはどうしたらいいかみたいなところが
割とマネージャー視点では気になるというか、
24:01
これからもっとより近づけたりダイレクト感が出るような
やり方を探していく必要があるかなと思っていますね。
そうですよね。確かに現場の舞台と、
それから間のプロダクトを考える組織と、
それからViz側みたいな感じになっていて、
それ自体はすごく合理的な作り方ですし、
そういった体制で今もやられているということなので、
それ自体はワークされていると思うんですよね。
でもやっぱりエンジニアが割と難しいドメインの問題を理解しながら、
かつお客様ごとの違いみたいなお話もかなりあったので、
そういったものを主体的に理解しながら
ものを作れるみたいになるとよりいいんじゃないかな
というのも思ったりもするので、
そういったところにエンジニアマネージャーとして
どういうふうに方向づけていくのかみたいなところも
気になったりはしております。
そういったどちらかというと組織というかチームというか、
いう観点でのお話は後半のほうでまた
伺えたらなと思っております。
というわけで、今回オプティマインドの古市さんに
いろいろ事業に関するお話というところで
お話しいただきました。ありがとうございました。
ありがとうございました。
古市さんありがとうございました。
次回は組織の問題について古市さんとお話ししていきます。
今日古市さんからオプティマインドさんのお話、
事業のお話というのをいろいろ伺いまして、
最初に私が抱いていた感想をどういうと言いますか、
かなりお客様ごとに違いがあるような業界で、
でもプロダクトというもので価値提供していこうと
格闘していらっしゃるということが改めて分かりました。
そこって当然難しいところでもあると思いますし、
特にエンジニアとしてそういったお客様ごとの
違いみたいなものをどうプロダクトというか
ソフトウェアで表現して価値を提供していくのか
というのはとてもチャレンジングですし、
面白いことではないのかなというところも
強く思いました。
さて、この番組では感想や質問、リクエストなどを
お待ちしております。番組詳細欄にあるリンクより
お気軽にご投稿ください。
TwitterではハッシュタグEM問題集を付けて
ツイートしてください。EMはアルファベット、
問題集は漢字でお願いします。
そしてはApple PodcastやSpotifyのPodcastでは
レビューもできますので、
こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株区スタイルCOO兼CTOの
後藤秀典でした。
