拡張可能な在庫管理システムを構築する方法 (アーキテクチャ付)

2023年2月1日

653

「これをもう一つ持っていますか？在庫を確認できますか？」
このお客様の質問は、小売業の従業員にとって、小売りの歴史と共に長い間悩みの種となってきました。

しかし、かつては（迷惑ながらも）簡単に答えられる質問であったものが、デジタル時代においては非常に困難なものとなりました。オンラインとオフラインのショッパーが混在し、リアルタイムで商品を小売店舗とデジタルの棚から取り出す状況では、保有している在庫とその所在を把握することは容易ではありません。オンライン専門の電子商取引店舗でさえ、効果的な在庫管理システムの構築に苦労することがあります。

では、なぜ在庫管理はこんなにも難しいのでしょうか？そして、効果的で信頼性のあるシステムを設計する方法について見ていきましょう。

1. 全体像の在庫管理のリファレンスアーキテクチャー

では、成功した小売業者はどのように在庫管理を実現しているのでしょうか？まずは、全体像の例を見てみましょう。この匿名化された図は、年間売上高数十億ドルを誇るオンラインおよびオフラインの小売業者の実際のアーキテクチャを基にしています。

図では、中央に水平に配置された紫色の長方形は、ログインから購入までのオンラインショッパーのアクションを表しています。円柱はデータベースを表し、以下の4つがあります。

・ユーザーに関する情報を格納する顧客データベース。PII（個人を特定する情報）や注文履歴、閲覧履歴などのテーブルが含まれています。

・製品在庫に関連するすべてのメタデータを格納する在庫データベース。SKUの説明、製品の入手可能性、在庫の位置などを含むテーブルがあります。これは在庫管理のための真実の情報源データベースです。

・製品画像を格納する画像データベース。これは製品説明ページ（PDP）や顧客の検索結果などで提供される製品画像を保存しています。

・製品の仕様をPDPに提供するためのデータベースまたはAPI。このデータは通常、サードパーティのプロバイダから提供され、小売業者自体が追跡や管理を行っていない場合があります。

ユーザーの購入手順を詳しく見てみましょう。

ユーザーがログインすると、アプリケーションは顧客データベースをクエリする必要があります。
ユーザーが商品の詳細ページ（PDP）を閲覧すると、アプリケーションは在庫データベース（在庫状況、商品の説明など）、顧客データベース（おすすめ情報やユーザー固有の情報など）、画像データベース、および商品仕様データベースをクエリする必要があります。
ユーザーが商品をカートに入れると、システムアーキテクトによって商品の処理方法が決定されますが、一般的なアプローチとしては、商品を一時的に売り切れとマークし（一時的に在庫を減らす）、販売が完了するかタイマーの期限が切れるまで保留します。タイマーの期限が切れる前に販売が正常に完了すると、商品は在庫から永久に削除されます。販売が完了しない場合は、商品はユーザーのカートから削除され、在庫データベースで再び利用可能とマークされます。
ユーザーがチェックアウトに進むと、アプリケーションは顧客データベースをクエリして関連するユーザー情報を表示する必要があります。
ユーザーが購入を完了または完了しなかった場合、在庫データベースはステップ3で詳述された在庫の変更を永続的に反映させます。

これは比較的簡単な手順のように思えますが、スケール時に一貫性を維持しながらこのようなフローを実現するには、適切なツールの選択が必要です。スケール時の一貫性の欠如により、商品の過剰販売が発生し、顧客体験が悪化しました。

2. 在庫管理システムを開発する手順

在庫システムの設計と開発の期間とアプローチは、解決すべき在庫業務の具体的な内容とスケールに依存します。以下に、私たちMiichisoftが堅牢な在庫管理ソフトウェアを導入する際に通常取る手順を説明します。

2.1. 在庫管理システムの要件定義

期間：4 weeks

Miichisoftは在庫管理システムの実装プロジェクトを以下の手順で開始します。在庫管理システムの機能要件と非機能要件を明確にし、ユーザーロール、他のシステム（ERP、CRM、会計システムなど）との必要な統合、データ移行活動（現在使用中のスプレッドシートや在庫管理ソリューションからのデータ移行）を定義します。

在庫管理システムのタイプを決定します：ソフトウェアのみまたはバーコード/RFIDに対応したもの。ソフトウェアテクノロジーの選択を行います。必要に応じて必要なハードウェア装置のリストを作成します。主要なコンポーネントとそれらの間の相互作用を持つソリューションの高レベルアーキテクチャを設計します。UIのプロトタイプを作成します。

2.2. プロジェクト計画

期間：1 ~ 2 weeks

Miichisoftの専門家は、正確なプロジェクト計画が成功する在庫システムの実装の基礎であると強く信じています。この段階では、以下の項目をカバーします。

・作業の範囲と所要時間、関連するリスクとそれらを軽減する方法の概要。

・在庫システムの予想される総所有コスト（TCO）と投資収益率（ROI）の計算。

・在庫システムの実装プロジェクトのマイルストーン、目標、重要業績評価指標（KPI）の定義。

2.3. 在庫システムの開発

期間：4 ~ 6 months

Miichisoftでは、この段階では以下の作業が行われます。

・ユーザーがアップロードした在庫データや在庫トラッキングデバイスによって生成された在庫データ（バーコード/RFID対応システムの場合）を統合し、処理する在庫ソリューションのバックエンドの提供。これにより、在庫操作を自動化するためのデータに基づいたアクションがトリガーされます。

・ユーザーが利用するウェブおよびモバイルアプリケーションの提供。

・（任意）機械学習による需要予測モジュールの実装により、在庫管理プロセスを最適化します。

・本番前の品質保証手順を実行し、在庫ソフトウェアの品質を検証し、バグを修正します。

2.4. 他のシステムとの統合

期間：1 ~ 12 weeks

この段階では、Miichisoftのチームは在庫システムの設計段階で定義された統合パターンと手順を最終的に仕上げます。他のビジネスクリティカルなシステム（例：ERP、会計、CRM）や在庫関連データのレポートおよび可視化のためのビジネスインテリジェンス（BI）との統合を実装し、テストします。

2.5. 在庫データの移行

期間：移行の複雑さによる

・在庫管理ソフトウェアやスプレッドシートからのデータ移行について、Miichisoftは以下の手順でサポートを行います。

・移行シナリオの開発、移行の自動化に使用するスクリプト、データマッピングの作成。

レガシーな在庫管理システムやスプレッドシートから在庫データを抽出し、品質の検証を行い、問題を特定して解決します（例：データの紛失や破損）。

・専用の在庫データベースにデータをロードし、データの正確性と一貫性を確保するためのデータ検証手順を実行します。

2.6. 在庫管理システムの展開

期間：3ヶ月目〜

Miichisoftでは、在庫管理システムの展開は通常、以下のステージで行われます。

ステージ1. ソフトウェアインフラの設定、バックアップと災害復旧手順の構成を行います。必要に応じてハードウェアのインストールと調整を行います（例：バーコードプリンタやリーダー、RFIDタグやリーダーなど）。ソリューションを対象の施設（倉庫/流通センター）の一つに展開し、パイロット運用を行います。ハードウェアサポートが必要なシステムの場合、所要時間は2週間です。

ステージ2. 実際の環境でシステムの機能をモニタリングします。変更要求や問題（例：バーコード/RFID関連）の処理を行います。パイロット運用の期間は1〜2ヶ月です。

ステージ3. 最終バージョンのソリューションを全ての対象施設に展開します。RFID/バーコードベースのシステムの展開には約2ヶ月かかります（施設の数とレイアウトの複雑さによって所要時間は異なる場合があります）。

2.7. ユーザーのトレーニング

期間：2 ~ 4 weeks

Miichisoftでは、在庫に関連する業務に従事する従業員が日常の業務でソリューションを迅速に活用できるように、以下の手順を踏んでいます。

・従業員（在庫管理および調達のスペシャリスト、倉庫作業員など）のワークフローに新しい在庫システムを統合する計画を立案する。

・ソフトウェアおよびハードウェアの管理者ガイドやユーザーチュートリアルの作成を行う。

・関係するユーザーグループ（例：新しいシステムにおける在庫アイテムのラベリングを行う倉庫スタッフなど）に対してワークショップを実施する。

2.8. リリース後のサポート、メンテナンス、および進化

期間：ご要望次第

Miichisoftは、在庫システムが長期間スムーズに動作するためのさまざまなサービスを提供しています。これらのサービスには以下が含まれます:

・継続的なユーザーサポートの提供。

・ビジネスの成長やユーザーのフィードバックに基づいて計画的なシステムの更新と機能拡張を実施すること。例えば、在庫レポートの種類の追加、UIの改善など。

・バーコード/RFIDをサポートするシステムの場合、ハードウェアの欠陥修正やハードウェアの保守（ハードウェアベンダーとの協力による）を行うこと。具体的には、デバイスのサービス（RFIDリーダーの修理など）や消耗品（RFIDタグなど）のタイムリーな供給などが含まれます。

3. 在庫管理の技術的な課題は？

課題１、一貫性

在庫管理における最大の技術的な課題の一つは、リアルタイムでの一貫性を保つことです。特に大規模な運営では、これは企業にとってお金を失う可能性や評判を損ねる可能性があるため、非常に重要です。

例えば、ブラックフライデーセール中に商品が在庫切れになった場合、企業の電子商取引サイトが即座にその状況を反映しないと、数十、数百、または数千の顧客が存在しない商品を購入してしまう可能性があります。

このような事態を防ぐためには、在庫データを必要とするさまざまなアプリケーションサービスと同期できる、真実の情報源となる在庫データベースを持つことが必要です。在庫をゼロまで売ることは可能ですが、ゼロを超えて売ることはできません。そして、このようなシステムを構築し維持することは容易ではありません。特に、大量の負荷下でも高いパフォーマンスを維持する必要があります。

課題２、拡張性

小売業のトレンドは常に予測できるわけではありません。しかし、予測可能な場合であっても、高パフォーマンスのインフラストラクチャを維持しながら過剰な費用をかけずに済むようにするには、迅速にスケーリング（拡張・縮小）できる能力が必要です。

つまり、例えばブラックフライデーのような大量のトラフィックを処理できるシステムを構築する一方で、1月のランダムな火曜日に「ブラックフライデーのような」トラフィックを処理するための費用を無駄に支払うことは避けるべきです。

課題３、レイテンシ

レイテンシを減らし、顧客の体験を向上させるためには、顧客に関連するデータを彼らの地理的な位置に近いデータベースに配置することが合理的です。ただし、データベースを地理的に分割すると、一貫性を維持することがより困難になる可能性があります（後で詳しく説明します）。なぜなら、さまざまな地域のデータベースの分割間で一貫性を維持する必要があるからです。

課題４、製品の複雑

これまで主に販売を例に挙げてきましたが、在庫管理は単純に商品が売れたかどうかを追跡するだけではありません。商品は倉庫から倉庫へ移動する場合があります。商品が紛失したり、損傷したりすることもあります。一部の商品は期限切れになる可能性もあります。

また、曖昧な「カート内の商品」の期間も存在します。この期間中、特定の在庫はまだ販売されていないが、必ずしも利用可能とも言えません。正確な在庫を維持するためには、すべての要素を追跡する必要があります。

課題５、使いやすさ

上記のすべての問題を解決することは確かに可能ですが、多くの解決策は技術的に複雑であり、エンジニアリングの時間やトレーニングなど、大規模な投資が必要です。これにより、さまざまな新たな問題が発生する可能性があります。遅延や予想以上のコストなどがその例です。

4. 現代の在庫管理システムの技術的要件は？

上記の課題は実際には氷山の一角に過ぎませんが、企業がツールを選択し、独自の在庫管理ソリューションを設計する際に何を求めるべきでしょうか？
そのようなシステムには、以下の要件が必要です。

・高い可用性：システムが誤ったタイミングでオフラインになることは、たとえ数分間であっても企業に数百万の損失をもたらす可能性があります。在庫管理システムは高い可用性を持ち、データが決して失われないように十分な耐久性を備えている必要があります。

・グローバルな一貫性：在庫管理システムは、製品在庫に関する真実を追跡し、リアルタイムでその真実を必要とするすべてのアプリケーションサービスに直接またはchangefeedsなどのソリューションを通じて提供できる必要があります。

・柔軟なスケーリング：在庫管理を含む小売りバックエンドのすべての部分は、ピーク時の販売期間に重い負荷を処理するために簡単に拡張・縮小できる必要があります。同時に、閑散期にはインフラストラクチャの費用を最小限に抑えることでコストを削減することが求められます。

さらに、すべてのユースケースに厳密な要件ではないかもしれませんが、理想的な在庫管理システムは以下の特徴も持っている必要があります：

・地理的にスケーラブル：データの地理的な配置により、より良い顧客体験が可能になります（また、一部の場合には規制要件となる場合もあります）。

・（比較的に）使いやすい：在庫管理は容易なものではありませんが、システムの複雑さを減らし、可能な限りマネージドサービスを活用することで、システムの構築と管理に関連する内部コストを削減することができます。

これらの目標を達成するためには、適切に選ばれたツールと緻密なアーキテクチャの組み合わせが必要です。

5. 在庫システムの導入にかかる費用要素

在庫管理システムの構築にかかる平均費用は、中規模企業ではオフショア企業からすると1,000万円から3,000万円、大企業では2,000万円から5,000万円の範囲で異なります。
※ 日本開発企業ならより高くなる可能性があります。

主な費用要因は以下の通りです。

・在庫システムの種類：ソフトウェアのみのシステムか、RFID/バーコード技術を利用したシステムか（後者にはハードウェア機器の費用と保守費用が含まれます）。
・在庫管理ソフトウェアの機能の数と複雑さ。例えば、在庫データの分析の複雑さは、必要な分析の種類、機械学習アルゴリズムの有無と数、データの量、レポートの数と複雑さに依存します。
・ユーザーグループの数とユーザー権限システムの複雑さ。
・インターフェースデザインの独自性と複雑さ。
・必要なデータ移行手順の複雑さ（例えば、データテーブルの数やデータの種類に基づく）。
・他のシステム（ERP、会計ソフトウェア、CRMなど）との統合の数と複雑さ。
・システムの可用性、パフォーマンス、セキュリティ、容量、スケーラビリティの要件。