起業のきっかけは、前職で「雑誌のEC」事業（現Fujisan.co.jp）を立ち上げたときの経験です。楽天のように注文が入ると出品者である出版社から発送してもらう仕組みで、順調に事業が成長していました。しかし、事業を続けていくと配送の遅延や誤配送などのミスが目立つように。物流を出版取次に任せていた出版社にとって個別の在庫管理や出荷作業といった物流業務が大きな負担になっており、そのような物流の課題から事業の成長も鈍化しました。

そこで私が取り組んだのが物流オペレーションの標準化です。倉庫と契約して商品の受注から出荷、在庫管理までを一元化し、出版社には倉庫に指定した部数を送ってもらうだけにしました。その結果、出版社の負担は減り、配送も正確かつスムーズになったことで事業はさらなる成長を遂げました。

当時、出版社から「物流業務をしてもらって助かるよ」と感謝されたのが起業の原点です。ECが世に普及し始めた頃だったので「同じように物流業務で悩んでいる事業者が他にもいるのでは」と考えました。その頃は、物流業務をアウトソーシングしようにも、どこの倉庫がいいかわからず、料金も不透明なため問い合わせによる見積もりが必要で、やりとりがアナログでシステム化されていませんでした。シンプルに、これだけECが簡単に立ち上げられる環境にも関わらず、物流だけが取り残されていると感じました。そのような想いから立ち上げたのがオープンロジです。

私はこれまでエンジニアとして、事業の立ち上げをメインにキャリアを重ねてきました。前職でもベンチャー企業のCTOとして携わっていたものの、事業がうまくいかず畳むこととなり、次のチャレンジを考えている時に、伊藤に声をかけてもらいました。

当時、他にもお声がけをいただいた企業もありましたが、物流という大きな既存業界に対しチャレンジしようとしている大胆さと、それが社会に与えるインパクトの大きさに魅力を感じ、可能性に賭けてみたいと思ったのです。

また、他の企業はある程度組織やプロダクトができており、私が役立つことはあっても「私でなければいけない」状況ではありませんでした。一方で、当時のオープンロジは立ち上げたばかりで何もない状態。何もないからこそ、私がやらなければならないと感じたのもジョインした理由の一つでした。

私は新卒でNTTデータに入社し、大規模システムなどのSEやPMをした後、商社やコンサル会社などで経営に携わる仕事をしてきました。前職ではRIZAPグループで企業の買収や再生をしていましたが、これから新しいビジネスを創っていくベンチャーに携わりたいと思い、縁があってオープンロジに参画しました。

ビジネスモデルに可能性を感じたのはもちろん、一番惹かれたのはCEOである伊藤の熱い想いです。それまでたくさんの企業を見てきて「経営者の想いが弱いと事業はうまくいかない」と感じていたので、伊藤の強い想いは事業の将来性を感じさせるのに充分でした。

一番大きな課題は「人材不足」です。コロナ禍においてECの市場は拡大しており、EC化率は8%にまで伸びました。アメリカは20％、中国は既に40%を超えており、日本もすぐに今の倍になるだろうと言われています。

一方で物流量が倍になっても、配達するドライバーは倍になるわけではありません。このままでは「注文した翌日に届く」という今のレベルのサービスが受けられなくなる日もそう遠くないでしょう。

これは国交省や大手物流会社の経営陣も頭を抱えており、それぞれの事業者で解決に向けて取り組んでいる状況です。

現在はそれぞれの事業者が解決に取り組んでいるため、「部分最適」になっている状況です。倉庫はロボットを取り入れ、配送事業者はAIで効率的な配達ルートを導くなど、各事業者の努力は素晴らしいです。

しかし、一方で荷主と倉庫、配送事業者は依然分断されたままで連携が取れていない為、「全体最適」にはなっていません。加えて倉庫事業者同士の横の繋がりもないため、様々な非効率が生まれています。

それらの課題を解決して全体最適化するには物流をデータ化し、そのデータをもとにした物流ネットワークの構築が欠かせません。荷主からお客様のもとに商品が届くまでを一気通貫でデータ管理することで、無駄なくスマートな物流が実現できるのです。

私達が現在、取り組んでいるのが「倉庫ネットワーク」の構築です。現在は、業務提携させていただいている倉庫事業者が約50拠点ありますが、その数を300拠点、500拠点とのネットワークを作っていきたいです。数ある倉庫事業者が分断されて存在しているために、様々な課題が発生しています。

例えばEC事業者は倉庫事業者を選ぶのも一苦労ですし、事業が拡大して在庫量や出庫量が増えれば、新たに倉庫を契約するなど煩雑な手続きも発生します。倉庫事業者によって料金やオペレーションも違うので、複数の倉庫に依頼するとなれば在庫管理だけでも大きな負担に。

私達の倉庫ネットワークでは、全ての提携倉庫が同一のシステムや標準化されたオペレーションを導入しており、在庫が増えても新たに倉庫を探して契約する必要がありません。同じ性質を持つ倉庫が繋がることで、クラウドサーバーの様に急な在庫や出庫の増加にもスムーズな対応が可能になるのです。まさに、我々の目指すプロダクトの姿が、「物流版のAWS」です。

その通りです。倉庫を選ぶのに「AとBの倉庫どっちがいいかな」と迷う必要がありませんし、在庫が増えても物流で頭を抱える必要はありません。これまで手間だった配送の負担が減ることで、本業に集中できるようになります。

加えて小ロットの在庫でも依頼できるようになるのも大きなメリットです。現在は小規模な事業者は倉庫事業者から相手にされませんし、最低料金が高いため在庫数が少ないともったいないのです。私達は従量課金なので小ロットから依頼でき、EC参入のハードルを大きく下げられます。

また、急成長するEC事業者でも、オープンロジのネットワークにより、物流がボトルネックにならないようにサポートすることも可能です。まさにこの発想が、「物流版のAWS」ということです。

一つはオペレーションを効率化できることです。今でも倉庫事業者の中にはアナログな業務をしている会社も多く、業務を効率化しようにも日々の業務に手一杯で効率化できていない業者はたくさんあります。私達はシステム化されたオペレーションを導入することで、そのような倉庫事業者の業務の効率化を支援しているのです。

また、倉庫のビジネスというのは、顧客ごとにオペレーションを組んで受託しているため、顧客が増えるほどオペレーションが多様化、複雑化し、売上は上がっていっても利益率が下がる構造になっています。共通システムを導入しオペレーションの平準化ができれば、オペレーションコストが下がり、利益構造が改善され、顧客が増えても利益率を下げずに事業を成長させられます。

開発メンバーには「自分で正しいと思ったものを作ってほしい」と伝えています。「上司に言われたから」ではなく、自分で考え消化できていることが成長サービスを作っていく上で最低限必要なことだと思っています。もしも、納得できないポイントがあれば納得できるまで議論するべきですし、経営陣も含め組織として議論を受け入れる素地があります。

本質的な価値を提供するためにも、開発組織も一人一人が物流業界に対して当事者意識と課題感を持ってサービスを作っています。

一つは実際に倉庫に行って現場を見られること。現場で見た課題感をプロダクトに反映できますし、自分たちが開発したプロダクトがどのように役立っているのか肌を持って体感することができます。

また、サービスの社会性が高いこともやりがいです。私たちのシステムは、全国にいる何万もの荷主様や倉庫作業者様が業務で利用しているため、リアルタイムなトランザクションの数も多く負荷も高いシステムとなっています。一方でシステムが落ちると、荷主様も倉庫事業者様も業務が止まってしまうため、絶対にシステムは落とせません。

そういったミッションクリティカルなシステムを作っているためか、開発陣も責任感の強い方が多いですね。お客様を支える社会インフラと捉えて開発してくれているので心強いです。

よく私達は「レイターステージ」と評されることも多いですが、物流業界はとても大きく、その一部にしかインパクトを出せていないので、全体から見ればまだまだ「0→1フェーズ」だと思っています。サービスの土台は出来上がっているものの、まだ追加しなければいけない機能はたくさんありますし、新しいビジネス創出のポテンシャルも大きいです。

また、事業は拡大しているので「オペレーションの最適化」と「ネットワークの拡大」の両輪を進めなければいけません。そのためには多様なエンジニアが必要ですし、自分で考えながらものづくりできる方を求めています。

たしかにまだ「0→1フェーズ」としてサービスの磨き込みはまだまだ必要ですが、一方で急速に倉庫ネットワークが拡大しており、より物流インフラとしての新しい価値を作って行かなければならないフェーズでもあります。そういう意味では、これからジョインするエンジニアにも「新しい価値を作る面白さ」を感じるチャンスは多いのではないでしょうか 。

加えて言うなら、新しいサービスをゼロから作るより、既に多くのお客様に活用いただいているシステムを動かしながら磨き上げていく方がずっと難しいです。提携倉庫も増えてきて、大量のデータが集まってきたからこそ、そのデータを使ってよりオペレーションを最適化していかなければなりません。そういった大規模なデータを扱いながら、より効率的なオペレーションを考え形にしていくのはエンジニアにとっても醍醐味となるはずです。

コンシューマーサービスのように分かりやすいサービスではありませんが、社会を支える物流という分野で社会的なインパクトを作っていきたい方はマッチすると思います。

議論好きなエンジニアは私達の組織に合うと思います。私達のサービスは荷主と倉庫、両方に展開しているので、開発チーム間や部署間での連携が多く発生します。

そのため、組織で議論を重ねながら開発していくのが好きなエンジニアは働きやすいと思いますし、現状をよしとせず違和感があれば解消するべきで、そのために必要な議論は会社としても役職関係なく受け入れる素地ができています。

12月25日は世界中の子供たちが、プレゼントを心待ちにしている日です。物流業界は地味で、普段は意識されることはありませんが、クリスマスはまさに「ものが届く体験」に一番心を踊らせる日と言えますよね。

そう考えれば、世界中の子供に、同じ日にプレゼントを届けられるサンタクロースは「物流」を代表する象徴だと思いますし、そんな体験を実現して広げたいという想いから、クリスマスに創業しました。

私達が目指す理想の物流を一緒に作っていってくれるエンジニアの方がいらっしゃれば、ぜひ気軽に話を聞きに来てください！