【エンジニア】”SPL”という特殊なビジネスモデルに対応するために。在庫管理ツール「くら蔵」自社開発の裏側
こんにちは。KURAND公式note編集部です。
KURANDは、酒類業界で、商品企画、製造、物流、販売までを一気通貫するビジネスモデル“SPL”で事業をおこなっています。日本全国200社以上の酒造メーカーとパートナーシップを結び、500種類以上のオリジナル商品を販売しています。
そして、この”SPL”というビジネスモデルにおいて課題となっていたのが在庫管理。今回はこの在庫管理問題を解決するべく、KURAND独自の在庫管理ツール「くら蔵(くらぞう)」の自社開発に携わった、KURANDのオペレーションシステムチームのNagashimaさんとLucasさんに、開発についてお話しいただきました。
プロフィール:Nagashima
プロフィール:Lucas
ー「くら蔵」とはどのようなものか教えてください
Lucas:「くら蔵」とは、自社商品の在庫管理ツールです。取引先にある商品の在庫や自社倉庫の在庫をすべて一元管理ができる、自社開発のツールです。2023年5月頃から独自開発を開始し、夏頃から試用運用を開始しました。
これを導入することで、これまで様々な自社開発ツールやSaaSを介して在庫を管理していたのを、すべて「くら蔵」で管理できるようになるので、在庫管理が効率化されるというメリットがあります。
ー「くら蔵」の開発のきっかけを教えてください
Lucas:最初のきっかけはマーケティングチームからの「商品在庫の管理を効率化したい」という声でした。KURANDではこれまでSaaSの「受注管理サービス」をメインで利用していましたが、そこでは自社倉庫の在庫管理しかできませんでした。商品を仕入れるという形ではなく、商品開発から行っているKURANDのビジネスモデルでは、在庫が自社だけではなく取引先にも一部存在するため、現在利用している「受注管理サービス」では、すべての在庫が管理できないという問題があったためです。
Nagashima:実は私が入社した頃にはすでに「くら蔵」を開発するプロジェクトが動き始めている状態でした。マーケーティングチーム以外にも、商品開発チーム、ロジスティクスチームなど様々なチームを横断するかなり大きなプロジェクトになるため、社内への要件定義などを中心に私が担当し、機能の開発をLucasさんが担当する形で、2023年5月ごろから本格的に開発がスタートしました。
またKURANDでは、SaaSの「受注管理サービス」以外にも酒蔵の在庫や発注管理を目的とした「在庫管理ツール」や、商品1つ1つの情報を登録する「商品情報登録ツール」といった自社開発ツールを併用して使用していました。また、クランドの人気サービス「酒ガチャ」では、お客さまの要望に合わせ、選んだジャンルのお酒が届くようにしたり、炭酸やアレルギー原料の除外、過去当たったお酒の被り防止などにも対応しています。この特殊な要件に応じて商品が選ばれる自社開発ツールを通して、「受注管理サービス」と「Shopify」を繋いでいるなど、様々なツール、サービスを同時に使用している状態でした。私たちが求める仕様は既存のSaaSサービスでは対応できるAPIが無く、自社開発が必要だと判断しました。
ー「くら蔵」を開発するのにあたり、まずどのようなことから行いましたか?
Nagashima:まずは、現状の課題点を洗い出すことから始めました。パートナーサクセスチームやロジスティクスチーム、マーケティングチームなど、普段商品在庫を必要とするあらゆるチームへのヒアリングを行い、それぞれのチームがどの機能をどのように使用していて、どういった課題を感じているかを言語化していきました。
当時まだ入社したばかりだったので、KURANDの全体像が見えておらず、どこにどのような情報がストックされているかを集めるだけでもかなりの時間を要しました。
特に商品在庫については、パートナー酒蔵やステークホルダーとはメールやFAXなどでやり取りし、それを手動で入力しているという状態でした。また、それぞれのチームごとに必要な情報が抽出されたスプレットシートが並行していくつも乱立しており、管理者が不明だったり、どこにある情報が正しいデータなのかがわからない状態になっていて、早急に解決する必要があると感じました。
また、それぞれのチームごとに課題はたくさんあるものの、どんな機能があれば改善できるかといったところまでの言語化は全くできておらず、ヒアリングした情報から必要な機能を洗い出し、どのような設計にする必要があるかを定義するのが最初の課題でした。
ー開発期間はどのくらいですか?
Lucas:正式に開発がスタートしたのが2023年の5月で、実際に現場で使い始めたのは8月ごろと約3か月ですね。いきなりすべての機能をリリースするのではなく、まずは取引先の在庫を管理するところから少しずつ機能をリリースしていきながら、現場の声を聞いて改善していっているというような形です。これに関しては、元々あった「商品情報登録ツール」の機能を取り入れる形で実装したので、開発期間を短くすることができました。
ー現時点での「くら蔵」における課題点を教えてください
Nagashima:当初、「受注管理サービス」からの移管にあたり、商品管理や製造依頼、入荷管理の機能などを部分的に早い段階でリリースする予定で動いていました。しかし、実際に進めてみると「受注管理サービス」から「くら蔵」へのデータ連携をする予定が、製造依頼や入荷管理などのみを切り離せるAPIが無く、すべてを一括で移管できるAPIが必要であることがわかりました。
そのため、SaaSの移管という視点では苦戦しているなと感じています。様々な機能を実装する中で、これは連携できないといった課題が次々と生まれている状態です。
Lucas:今の「受注管理サービス」やそれ以外のツールがそれぞれ複雑になっているので、それをすべて把握し、たくさんの機能を一つも漏らすことなくすべて反映するとなると、かなりの情報量になるのでそれは現在進行形で課題に感じている部分です。
Nagashima:難しいなと思っているのは、とにかく情報量が多いことに加え、変化の速度が速いということですね。例えばお酒の瓶のキャップの種類だったり、商品の管理方法の違いだったり、ひとくちに「商品情報」といってもかなりたくさんの条件があります。またそれがお客さまのご要望に応じてどんどん増えていくので、それによってデータベースのフォーマットを変更していく必要があるという点です。
私たちKURANDの場合、「酒ガチャ」の存在はとても大きいです。最近の事例ですと、「酒ガチャ」の中で同じシリーズのお酒が被らないようにしてほしいというご要望にお応えするために、商品の登録方法を変更しました。最初は商品のブランドごとに登録し、その中に商品が登録されているような形でした。しかし、それでは「酒ガチャ」で同じシリーズが被らないような設定にすることが難しく、商品を登録してから一つ一つの商品にシリーズのタグをつけるという形でブランドを設定するという登録方法に変更しました。この要件がガラッと変わることは開発においてかなり大きな修正だと思います。
ー今後の展望を教えてください
Nagashima:現在まだ完全に「くら蔵」へ移管しきれておらず、まだ一部「受注管理サービス」やスプレットシートを使用している部分があります。これまで慣れ親しんできたやり方が身についているメンバーほど、新しい機能を使用することに抵抗を感じることがとても多いと感じています。
最終的には完全に「くら蔵」のみで一元管理していく環境を整えていくためにも、次は社内で「くら蔵」を使うことになれていってもらうように、浸透させていくことが必要だと思っています。
すべてが「くら蔵」に統一されることで、ヒューマンエラーが発生しにくくなると思っています。それにより、工数の大幅削減やお客さまへご迷惑をおかけすることも限りなく防げるようになっていくと思います。また、より一層多くのお客さまのご要望にお応えできるようになっていくはずです。
Lucas:クランドは一般的なECサイトに比べ、とても複雑なシステム設計が組み合わさって構築されているECサイトです。ビジネスモデルや商材の特性、またKURAND独自の「酒ガチャ」といったサービスもあることで、ほかに類を見ない新しい機能がたくさん詰まった特殊なサイトだと思います。
これまで様々な自社開発ツールを開発してきましたが、この「くら蔵」はその集大成だと考えています。今後のKURANDのサービスにもぜひご期待ください。
ーNagashimaさん、Lucasさん、ありがとうございました!
KURANDでは一緒に働くメンバーを募集しています
KURANDでは「お酒の新しい価値をつくり、世界中のあらゆる人々の人生に、楽しさ、豊かさ、幸せを届ける。」のミッションのために、新しいメンバーを募集しています。「KURAND Recruit Book」もご覧ください。