Verticalかつhorizontal。システムで完結しない、物流業界における開発の複雑性【イベントレポート】
こんにちは、オープンロジでエンジニアをしています原田です。
2024年9月に行われた「プロダクトエンジニアが語る！医療、決済、物流、不動産ドメイン」に、「物流プラットフォーム オープンロジで課題に向きあうための複雑性の要因」というタイトルで登壇させて頂きました。
今回はそのレポートとして、登壇内容を振り返ります。
自己紹介
大手企業向けEPRパッケージベンダーでキャリアをスタートし、BtoB業界をメインに開発を行っています。オープンロジには2015年のサービスローンチ時に入社し、当時荷主向けの機能しかなかった所からWMSシステム（倉庫管理システム）の基礎を開発。その後マネジメントなども経験したのち、現在はテックリードとしてプロダクト価値を最大化するための開発に従事しています。
登壇スライド
※以下に記載の内容は、登壇でお話した内容になります。
荷主・倉庫を中心にサービスを展開
まずは今回の「複雑なドメインに向きあう」というテーマを背景から理解して頂くため、オープンロジの事業について紹介します。
物流系のスタートアップには特に配送周りのプレイヤーが多く存在しますが、オープンロジでは上流の、荷主・倉庫を中心にサービスを展開しています。
ビジネスモデル
荷主の中でもオープンロジは現在EC物流を対象にサービスを展開しており、
通常EC事業者が運用を行う、”消費者が商品を購入した後の物流業務”全てのアウトソース先として、物流運用、及び最適化を進めています。
「サイロ化」された物流業界
オープンロジが物流業界において課題意識を持っているのは、業界の「サイロ化」です。「サイロ化」とは、システムやステークホルダーが有機的に連携せず、それぞれが孤立している事を主に指します。
物流におけるサイロ化には、
EC販売に関わるステークホルダーをEC事業者、倉庫、配送とした時、各々の持つ情報が連携されず合理化が進まないことが挙げられます。
オープンロジはこのサイロ化を
上流のEC事業者と倉庫間、そして、倉庫と配送間の情報をシームレスにし、最適化していくことで、
物流業界全体で合理化や効率化をしていきたい、と考えています。
「物流版AWS」
この合理化や効率化を実現するにあたって、オープンロジは「物流版AWS」をコンセプトとしたサービスを提供しています。AWSが「データウェアハウス」をサービスとして提供したように、我々は「ウェアハウス = 倉庫」をサービスとして提供することで、荷主のもつ物流課題を高度に解決したいと考えています。
登壇内容
事業のご説明をしたところで、実際にオープンロジのエンジニアがどのような複雑性に取り組んでいるか、ご紹介していきます。
１．Vertical * horizontal
オープンロジの事業は物流の上流から下流まで、物流全体の課題解決をしているという意味で「バーティカルなサービス」だとお伝えすることが多いのですが、一方で、”様々な業界の物流課題を解決する”という意味で、ホリゾンタルとも言えます。
ここからは、バーティカルな課題解決、ホリゾンタルな課題解決、両面への取り組みをご紹介します。
■バーティカルな課題解決
まず、物流の中でもオープンロジが特にケアしている領域は、いわゆる倉庫の庫内業務になります。
庫内作業には「入庫→在庫管理→ピッキング→梱包→出荷」という作業に加えて、
倉庫の作業者の管理や生産性の計測、ECサイトからの情報連携対応や、配送会社との連携業務などもあります。
（庫内作業について詳しく知りたい方は以下の記事をご覧ください）
また、物流版AWSのスライド中にある「拡張性」に関する部分で、
EC事業者は一定の事業規模になると倉庫に商品を保管するようになります。その後も販売量の増加にあわせて保管先倉庫をより大きいものへ変更していくことになるのですが、
オープンロジは荷主の成長に合わせて、倉庫ネットワークの中からより広い倉庫での運用にシームレスに切り替えていく、または分散させるといった倉庫活用（キャパシティー）のプランニングをサポートをすることもあります。
物流ドメインではこの対応を「波動対応」と言いますが、オープンロジはこのように様々な倉庫作業・活用における課題解決に取り組んでいます。
モノが届くまでの基本的な流れをお伝えすると、
消費者がECサイトで商品を購入すると、その情報が受注連携モジュールを通してオープンロジシステムに連携されます。それが倉庫の指示となり、ピッキング・検品・梱包された荷物が配送会社に渡され、消費者に届きます。
このモノの流れを生む作業それぞれをシームレスにつなぐということが大切になるのですが、
直面する課題の一つが、ECサイトから注文情報を取り込む、「受注連携」という仕組みにあり、EC上購入ができても、下流である配送サービスに連携できない事象が発生することがあります。
例えば末尾0000の郵便番号。これは「その他」をあらわすものですが、山奥や島なども含まれており、送り先によっては時間指定を受け付けていないとか、クール便を扱っていない、などの事情で配送日程が変わることがあります。
しかし、その宛先に指定の配送が可能かを判断するためには営業所に問い合わせる必要があります。
そして、購入時に指定した時間指定などが実は利用出来ない場合、配送会社に連携するデータを誰かが修正する必要があります。
配送会社とのインターフェースの違いも、課題になる要素の一つです。
消費者がECサイトに送り先の住所を打ち込む際、入力フォーマットが都道府県市区町村/番地/建物とが分かれて入力する場合もあれば、都道府県以下は全て一つの枠に入力するようなパターンもありますよね。
同じように配送サービスによっても住所入力フォーマットはそれぞれ異なっており、必要に応じて上手く住所から市区町村だけを抽出したり、文字数調整のために分割したりする必要があります。
ここの差を吸収しなければ、配送サービスに連携することができないのです。
しかし、これらの課題は消費者としてモノを買う際に悩むことはありません。
ではこれを誰が調整・修正しているかというと、多くは倉庫事業者が、手作業で修正しています。
上流からデータがきてしまうので対応するしかない、と。
これが最初にお話したサイロ化、つまり上流と下流が切り離されている弊害の一例です。
受注情報の連携をするにあたって必要なのは、「上流部分で取り込む」だけでなく、その後の下流の利用における事象を考慮することが大切になります。
■ホリゾンタルな課題解決
一方、ホリゾンタルといえる部分が何かというと、”様々な業界の”物流オペレーションを解決するという点です。
要するに、扱う商材によって物流に求められる機能が変わる、ということです。
例えば
食料品を取り扱う場合は期限管理や温度帯の管理を行い、電子機器を取り扱う場合はロット管理やシリアル番号の管理を行います。
大型の家具の場合は高額な配送費用を少しでもおさえるため、各地に分散して在庫管理を行う倉庫分散を行ったりしています。
販売方法の観点でも、例えば予約販売、受注生産のような形態だと、発売日前に届かないような管理が必要になります。
このように上流から下流への流れ、商材特有の管理や業務など様々な要素を考慮して、物流課題の整理を行っています。
２．Multitenancy
ここで言うMultitenancyとは、いわゆるSaaSのアプリケーション構造におけるマルチテナントの意味ではなく文字通りの意味で、「一つの物理的な倉庫で、複数、数十から数百の荷主の荷物を集約して、同一のオペレーションで運用している」ということです。
一般的に倉庫のオペレーションというのは、荷主の商材の特性や、受注量の変動を考慮して1対1で構築されます。この左の絵のような状態ですね。
しかしこの一般的な倉庫オペレーションの場合、例えば倉庫が新規顧客の獲得や庫内の有効活用のために新しい荷主を取り入れたいと思っていても、新しく1から行うオペレーション構築しなければならないため、取り扱う荷量が少なければコストと利益が見合いません。結果、荷主に伸びる可能性があったとしても契約を見送らざるを得ないことが多々あります。
荷主もなかなか受け入れ先の倉庫を見つけられず、物流が要因で事業を始められない、加速させられないという事態に陥っていました。
これがオープンロジが最初に着手した課題です。
オープンロジは右の絵のように一つの倉庫を複数の荷主で利用できるようにするだけでなく、荷主を統一的に扱いオペレーション構築のコストをかけずに運用開始できるようにすることで、荷量の少ない荷主でも倉庫を利用できるようにしました。これにより、倉庫も気軽に新しい荷主を取り入れられるようになります。
ただ、Multitenancyによって集約し、統一的に扱うことで倉庫は数のメリットを享受する反面、今度は様々な種類の荷物が混在している状態特有の課題を抱える事になります。
統一的に扱うといっても、商材が異なれば、少なからず最適なオペレーションは変わります。
一倉庫内で様々な運用が混在すると、作業者は都度何をすれば良いのかの判断が求められるため、作業ミスにつながりやすくなってしまいます。そのため、「本来的には異なる最適解があったとしても、できるだけ統一した運用ができるようにする（＝標準化）」という観点で課題に向き合うことも重要になります。
一方で、荷主の規模によっては一社で倉庫を占有するケースもあります。このような場合は、逆に荷主の商材や効率をより重視した運用を構築する必要や、UIを検討する必要があります。
実際の開発ではこういった様々な事情を含めて、
Multitennacyとして、標準的な解を模索するか、
Not Multitenancyとして、個別の最適解を突き詰めるか。
状況によって運用効率が全く変わることを考慮して、設計に取り組んでいます。
３．Physical Operation
倉庫の仕事はシステムを触ることではなく、モノを動かすことです。
そのため、システムの外で発生する問題に目を向けることが重要で、
システム上のことだけ考えると、落とし穴にハマってしまうことがあります。
さきほどこちらの絵をお見せしましたが、この庫内作業の部分。
各工程でシステムを触りますが、それと同時にモノを動かします。
何か作業に間違いがあった場合、画面上でエラーを出すような通知はできますが、作業の対象は目の前にある実物です。画面のエラーをみていても、配送会社に引き渡す場所においてしまえば作業は次に進んでしまう。こういったPhysicalが中心の世界です。
例えば、「予約注文」を実現したいとするとどういう機能が必要でしょうか？
予約注文には、
・発売日に購入者に届くようにしたい
・発送先地域によって発送にかかる時間が異なる
・予約期間の中で注文が発生する
このような特徴があります。
ここで大切なのは、
発売日前に絶対に届いてはいけないということ。
とすると、
・「配送日」を注文に設定する
・発送日数を考慮して作業日を計算する
・作業日になるまで作業が行えないようにする
など、倉庫作業の最初をおさえる、といった機能が考えられます。
ただ、ここで忘れてはいけないのは、予約の注文を受け付けているということは、大量の注文となる可能性があるということ。さらに、それらの全ての注文を、発売日に届けたい。ということです。
当たり前ですが、倉庫では一瞬で作業が行われるわけではありません。1日で作業が終わらないこともありますので、倉庫ではある程度事前に出庫の準備を行う必要があります。
つまり、データ上だけの制約は実は全く意味を成さないのです。
梱包というオペレーションの後、倉庫では荷物はこのような形で管理されます。
下にあるピンク色のものが「パレット」と呼ばれる台座で、出庫準備を終えた荷物が順に積まれていますが、これらを指定の日より前に誤って配送会社に渡してしまえば、発売日前に届いてしまいます。
つまり、
・発送日よりも前のタイミングで倉庫作業は終わっている可能性が高いが、
・それを指定の日よりも前に配送会社に誤って渡してしまうと、発売日前に届いてしまう
＝出荷のタイミングで物理的に止める必要がある、ということになります。
この課題の解決方法としては、
・パレットに載せる際に、どの注文をどのパレットに載せたかを紐づける
・配送会社に引き渡す際に、引き渡すパレットを登録する
という業務を倉庫作業として新たに行う事で、
・引き渡しの際に、引き渡して良いものかをチェックできる
ようになります。
「予約注文を行いたい」という課題は、単に発売日を指定する対応だけではなく、
パレットの引き渡し管理という新たな業務の発生につながります。
これは当然通常の作業よりもコストのかかるオペレーションです。その為、発売日前に発送されるリスクとのバランスをとって、運用を構築する必要があります。
デジタルなデータの流れだけではなく、フィジカルな現場のオペレーションを想像する。
既存に存在しない業務オペレーションを検討する。
新たな業務オペレーションのコストと、事故によるリスクのバランスをとる。
これが倉庫における課題解決の非常に重要なポイントです。
まとめ
Vertical * horizontal, Multitenancy, Physical Operationというキーワードで、オープンロジのプロダクト開発における課題へのアプローチについてお話させていただきました。
オープンロジのプロダクトの場合は、一つの仕組みが難しいというよりも多方面を気にする必要があり、変数が非常に多いというところに帰着します。
また、結局すべては最後のPhysical Operationに端を発していると言えるのかな、と思っています。
今日の内容は、「機能開発をする上で、いろんな要因を俯瞰して課題を解決できるエンジニアでありたい」という自分自身へのメッセージも含みます。
システムを作るうえで、フィジカルなオペレーションも考えながら課題を解決していくという、オープンロジのプロダクト開発、イメージいただけましたでしょうか。
We are hiring!
オープンロジの開発では、ユーザー業務全体を見通す事がビジネス上の課題解決に必要とされるケースが非常に多く、コーディング力・設計力以外のスキルも鍛えられる面白いフィールドです。
物流における社会問題解決をするためには、
まだまだ広い視野を持って挑むべき課題がたくさんあります。
もしこの記事を読んでオープンロジに興味を持って下さった方はぜひ、カジュアルに話してみませんか？