「モノリス構造」が変革の足枷に 　オムニチャネル化とは、単にオーダーの入り口を増やすというだけの話ではない。
オムニチャネルのフルフィルメント（受注から出荷までの一連の作業）は、物流センターのみならず、店舗をも出荷拠点として活用しなければならないことから、オーダーを処理する社内インフラの再構築が必要になる。
　具体的には、ＤＣで保管する在庫だけでなく、店舗在庫、移動中の在庫、さらにはサプライヤー在庫までのトータル在庫を可視化して、どの在庫がすぐに出荷可能なのかを判断する「可用在庫（Abilable to Commens）」の管理が求められる。
多くの場合、既存のシステムをアップグレードしなければならない（図１）。
　また、ＥＣのフルフィルメントは、従来のＢ２ＢとはＩＴの仕組みのみならず業務プロセスが大きく異なる。
バッチ型で業務を流してきた物流センターが、小口のＥＣのオーダーの出荷に細かく対応するのは容易ではない。
従来のシステムのまま両方をこなそうとすれば、倉庫の作業員の業務効率は著しく低下する。
すなわちコスト負担が大きくなる。
ここでもやはり新たなシステム導入の検討が必要になってくるのである。
　そうしたＩＴインフラの構築に膨大な費用と時間が掛かってしまう点が、日本企業のオムニチャネル化を阻んでいる最大の要因だと筆者は認識している。
実際に日本では、予算面でのハードルが高過ぎるために、システム構築の経営上の優先順位を落とさざるを得なくなり、プロジェクトを先延ばしにしている企業が決して少なくない。
　そのような傾向は欧米も同じだろうと考える方がいるかもしれない。
しかし現実はそうではない。
われわれマンハッタン・アソシエイツはグローバルにビジネスを展開する流通事業者を主な対象に、オムニチャネル化を支える膨大な機能をクラウドアプリケーションとして提供している。
そのクライアントだけに限っても、欧米ではオムニチャネル化の成功事例が次々と現れているのである。
　それに対して日本では今のところ、ほんの一握りの先進企業だけがオムニチャネル化によって部分的な成果を出しているにすぎない。
ＩＴインフラ整備の遅れが、日本企業のオムニチャネル化が進まない大きな原因の一つとなっているのは明らかだ。
　日本企業の現行のシステムのほとんどは、日系の大手ＳＩベンダーがフルアウトソーシングに近い形で開発したものだ。
その仕組みはユーザーから見てブラックボックスとなっており、しかも古い技術をベースに部分最適とシステムの延命を繰り返してきたことから、全体を部分に分割することのできない「モノリス（一枚岩）構造」と化している。
　その結果として、ユーザーはレガシーシステムからいつまでも脱却できず、レガシーシステムをサポートするベンダーへの依存が継続するというロックイン状態に陥っている。
そうした構造にはまり込んでしまうと、システムを拡張する際にも、ユーザー企業はベンダーの提案をほぼ丸呑みにするしかない。
莫大な費用負担のみならず、導入にかかる時間への投資にも同意せざるを得なくなる。
　しかし、ベンダーだけを悪者にするわけにはいかない。
ベンダーはユーザーの要請に応えてきただけとも言える。
むしろユーザー企業自らが、自社に最適なＩＴインフラを構築するのに必要なノウハウを身に付けて来なかったことのほうがより本質的な問題だ。
　実際、日本企業のベンダー依存とは対照的に、欧米の有力企業はどこも社内にハイレベルなＩＴ人材を採用・育成している。
ビジネスモデルの革新にはＩＴの活用が不可欠であり、ダイナミックかつアジャイル（機敏）に、先進技術をベースにしたシステムに入れ替え続けていくことが、企業競争力を決定的に左右することを、欧米の経営層は常識として理解しているのである。
ウォルマートの物流システム開発 　Ｕｂｅｒ、Ａｉｒｂｎｂ、メルカリ、ＬＩＮＥなど、最新のテクノロジーを利用して既存市場に参入し、伝統的な産業構造を破壊する、いわゆる「ディスラプター」が、今やあらゆる分野に登場している。
いずれも従来のルールに縛られず、新たなビジネスモデルを創造することで旧世代のプレーヤーたちからシェアを奪い、急成長を遂げている。
　旧世代のプレーヤーはこれまで、「ウォーターフォール型」と呼ばれるシステム開発手法をとってきた。
「用件定義」に始まり「外部設計（概要設計）」「内部設計（詳細設計）」「開発（プログラミング）」「テスト」「運用」という順番で手戻りすることなく工程を進めていく。
プロジェクトの進捗を管理しやすいというメリットがある代わりに、開発に時間がかかるという問題がある。
　それに対してディスラプターたちは、高品質なＩＴシステムを短時間で利用可能にする「ＤｅｖＯｐｓ（デブオプス）型」と呼ばれる開発体制をとっている。
社内の開発チーム（Development）と運用チーム（Operations）が密接に連携して、スピード優先でシステムを構築し、運用しながら設計を進化させ続ける。
　ディスラプターに対抗するために、旧世代のプレーヤーたちは現在、生き残りをかけてＩＴの内製化やＤＸ（デジタルトランスフォーメーション）人材の育成・獲得を進めている。
ベンダーによるロックイン状態から抜け出し、市場の変化に機敏に対応できるアジャイル型の社内システムへの進化を図っている。
　そこでは情報システムのアーキテクチャが従来のモノリス構造から、必要な機能を「マイクロサービス」と呼ばれる個別のソリューションに分割して、クラウドネイティブなソフトウエアをそれぞれ導入して組み合わせる「マイクロサービスアーキテクチャ」に置き換えられる。
　米ウォルマートと米ベストバイはそうしたプレーヤーの代表格であり、またオムニチャネル化の先進企業として知られている。
両社とも在庫管理に「ネットワーク在庫」という概念を導入している。
自社の在庫はもちろんサプライヤー在庫やこれから生産される計画在庫まで含めて、サプライチェーンに分散する全ての在庫を可視化して管理する。
　さらには在庫だけでなく、出荷作業の工程まで見える化して、その進捗を全社規模でコントロールする仕組みを整えている。
さまざまな販売経路から入って来るオーダーを最適なネットワーク在庫に引き当て、ダイナミックにフルフィルメントを処理する「オーダー・マネジメント・システム（ＯＭＳ）」がその中核としての役割を果たしている。
　両社以外にも米国にはそうした仕組みを短期間で実現している流通企業が多数存在する。
オムニチャネルのフルフィルメントにおける現在のベストプラクティスといえる。
　それでは、どうすれば、日本企業がベストプラクティスを導入できるだろうか。
これまで筆者は国内外の流通企業のシステム構築に数多く関わってきた。
その経験から次のように考えている。
　事業を革新するための新規ソフトウエア開発を、現行システムを拡張するというアプローチで実現しようとすると、従来からのアーキテクチャに制約があることが原因となり、開発に膨大な時間と費用がかかる。
システムが出来上がる頃には、そのプログラム自体が既に時代遅れになってしまっている可能性が高い。
　それを避けるにはまず、アーキテクチャの制約を克服する必要がある。
　現行のシステムをベースにした、言ってみれば大昔に作られた土台（アーキテクチャ）の上に、ネット世代の多様かつ常に変化する要求を満たす柔軟なシステムを構築するというアプローチには、誰もが違和感を覚えるはずだ。
またＳＩベンダーに新規に発注してアーキテクチャからスクラッチでシステムを組み上げようとすれば、膨大な予算と時間がかかることも自明である。
　先進企業は、パッケージソフトやＳａａＳ型のアプリケーション基盤を積極的に活用することで、そうした問題を解消している。
開発コストを削減することよりもむしろ、スピードを重視するからである。
業界のベストプラクティスを取り込んだ先進のアーキテクチャを短期間に自社のシステムに取り込むために、評価の高いソリューションを採用している、というのが実態だ。
　常に最新かつ市場のニーズを取り込んだ優れたアーキテクチャを獲得するには、業界で評価を得ているソフトウエアソリューションを自社の既存システムと組み合わせて積極的に活用するというのが、ほぼ唯一の現実的方法なのである。
　ただし、そのためにはシステム開発の手法そのものを、従来のウォーターフォール型から、ＤｅｖＯｐｓ型に切り替える必要がある。
その上で、さまざまなツールを活用しながら短期間でプロジェクトを立ち上げ、継続的かつ柔軟な改善を続けられる体制を整えなければならない。
新世代の物流管理ソリューション 　コスト削減とシステム構築の迅速化の他に、ＳａａＳ型のアプリケーションを利用する狙いがもうひとつある。
イノベーションである。
　マイクロサービスアーキテクチャは、全ての機能をひと塊りにした従来のモノリス型とは対照的に、アプリケーションを構成する機能が個々のサービスとして独立している。
データも分散している。
そして、それぞれのシステムは独立性を維持したまま緩やかに連携している。
「疎結合」という。
　マイクロサービスアーキテクチャは、新たに登場した技術を容易に採用できる他、新しい機能を追加したり、度重なる変更に柔軟に対応できるといったメリットがある。
またマイクロサービスアーキテクチャで構築されたアプリケーションは、クラウド上で稼働させるのに最適であることから、「クラウドネイティブアプリケーション」とも称される。
　そのアーキテクチャを自社のシステム、ひいては業務プロセスに組み込むことで、ビジネスに大きな機動力が与えられる。
オムニチャネル化は物量の波動を極端に大きくする。
米国市場の事例を見るとピーク時のトランザクションボリュームが平時の５倍から10倍にも跳ね上がっている。
そうした変動にも柔軟に対応できるようになる（図２）。
　クラウドネイティブアプリケーションは、レガシーシステムの延長線上では絶対に実現しない俊敏性を獲得することも可能にする。
例えばわれわれマンハッタン・アソシエイツは、「オーダーオーケストレーション」や「オーダーストリーミング」と呼ぶオムニチャネル向けソリューションを提供している。
　オーダーオーケストレーションとはその名のとおり、さまざまなチャネル経由で入ってきたオーダーを統合して、フルフィルメントを最適化するオーダーマネジメントの核となる機能であり、オムニチャネル企業にとって必須のインフラだ。
　また、オーダーストリーミングは、店舗向けのＢtoＢと消費者向けのＢtoＣの出荷作業を統合して処理する仕組みだ。
　店舗向けのピッキング作業には一般に、オーダーをバッチで処理して複数店舗分をまとめてピッキングする「ウェーブピッキング（Wave Picking）方式」が採用されている。
ウェーブピッキングの生産性はバッチを切った直後にピークになり、次のバッチまで下がり続けていく。
そこで生産性が低下したタイミングで、ＢtoＣの小口オーダーをフルフィルメント業務のリソースに引き当てる。
これにより、ＢtoＢ向けの大規模ＤＣでも効率を落とすことなく、小口のＥＣオーダーに柔軟に対応できるようになる（図３）。
　オーダーストリーミングは２０１８年にリリースしたソリューションだが、欧米のオムニチャネル企業がこぞって導入を進めている。
日本でも数年のうちにオムニチャネル企業に不可欠のソリューションとなるだろう。
その導入準備に今すぐ取りかかる必要がある。
今やタイムリミットは迫っているとみるべきである。