倉庫システムの刷新を検討したものの、要件定義の段階で止まってしまう。あるいは、費用が想定を超えて断念する。こうした経験を持つ企業は少なくありません。

ただし、刷新が難しい理由は、費用や工数だけではありません。もう一段深いところに、構造的な問題があります。そして、その構造を理解すると、刷新以外の選択肢が見えてきます。

会議室では、要件は固まりきらない

倉庫システムの刷新を検討したとき、多くの企業がまず取り組むのが要件定義です。現場の業務を洗い出し、必要な機能を整理し、仕様書に落とし込んでいきます。

この工程が、想像以上に時間を要します。範囲が広く、検討すべき項目が多い。会議室で机上の議論を重ね、参加者が納得したところで次に進む——という進め方が一般的です。

ここで起きやすいのが、認識のずれです。システム開発では、要件定義段階での認識のずれがプロジェクトの失敗要因として広く指摘されています。発注側と開発側の間で、完成形のイメージが噛み合わないという構造です。

ただし、現場のシステム刷新では、もう一段やっかいな現象が起こります。同じ会社で、同じ現場を見ている人同士の間でも、認識がずれるのです。

理由は、現場作業の多くが暗黙知として共有されているからです。ピッキングをどの順序で回すか。検品をどのタイミングで挟むか。例外品をどう扱うか。これらは日々の作業の中では自明のものとして動いていますが、言葉にした瞬間、人によって微妙に異なる説明になります。

しかも、そのずれは会議室では発覚しません。図面上では合意できてしまう。実際にモノが動き、人が手を動かした瞬間に、初めて「そこはそうではない」となります。

検証できないまま、仕様だけが積み上がる

この構造が、要件定義に時間がかかる根本的な理由です。開発に着手する前に、現場で検証する手段がない。

検証できないので、議論で精度を上げるしかありません。詳細設計まで仕様書に落とし込もうとすると、時間がかかります。時間がかかるほど、開発費は膨らみます。そして着手した後に「思っていたものと違う」が発覚すると、そこから後戻りする余地は残されていません。

想定外の開発コストが発生し、予算を超過する。この経緯を経験している企業は少なくありません。WMSの刷新が「やりたいが、現実的に難しい」と判断される背景には、費用や工数そのものより、この予測不能性への警戒があります。

入荷・在庫と出荷は、業務の性質が違う

一方で、倉庫業務のすべてが同じ性質を持っているわけではありません。ここを分けて考えると、選択肢が見えてきます。

入荷や在庫管理は、比較的時間的な余裕がある領域です。入荷は事前に予定を組めます。在庫管理は日々の積み上げで、当日中の完結を求められる性質のものではありません。安定して回ることが、そのまま正解になります。

出荷は違います。遅れが許されません。入荷のように事前に予定を組めない中で、当日中に作業を完結させる必要があります。BtoBでは、午前の注文を午後に納品するといった条件が課されることもあります。

負荷が高く、計画が立てにくく、リードタイムが短い。この三つが重なるため、出荷は日々改善を続ける必要がある領域になります。より良い方法を模索し続けなければ、現場が回らなくなる。

つまり、入荷・在庫は安定させたい領域であり、出荷は変え続けたい領域です。同じ倉庫の中にありながら、求められるものが逆を向いています。

入荷・在庫と出荷の業務性質を、時間的余裕、計画可能性、リードタイム、改善頻度の4項目で比較した図
入荷・在庫は事前に予定を組める領域、出荷は当日中の完結を求められる領域です。求められるものが逆を向いています。

改修サイクルが噛み合わない、という問題

ここに、システム設計上の難しさがあります。

安定させたい領域と、変え続けたい領域を、同じシステムの中で扱うと、両者が同じ改修プロセスに縛られます。

出荷フローを少し変えたい。検品のタイミングを見直したい。帳票の出し方を調整したい。こうした変更のたびに、要件定義から始まる改修プロセスを通すことになります。前述の通り、この工程は時間もコストもかかります。

結果として、日々改善したい領域が、改修サイクルの遅さに引きずられます。現場は「変えたいが、そこまでの案件ではない」と判断し、運用でカバーする。その積み重ねが、現場の負荷として蓄積していきます。

WMSが悪いという話ではありません。入荷・在庫という安定性を求められる領域を担うシステムとして、慎重な改修プロセスは正しい設計です。問題は、性質の異なる出荷を同じ枠の中に入れていることにあります。

慎重な改修サイクルと日々の改善サイクルが、同じ改修プロセスに縛られている状態を示す図
回転速度の異なる二つの領域を同じ枠に入れると、変え続けたい側が慎重な改修プロセスに引きずられます。

出荷だけを切り出すという選択

そこで出てくるのが、出荷指示より後の工程だけを別のシステムで扱うという設計です。

入荷、在庫、ロケーション、引当は既存のWMSに残します。そのうえで、WMSや基幹システムから出荷指示データを受け取り、ピッキング、検品、送り状発行、帳票出力といった出荷現場の作業を、別の仕組みで扱います。

この構成の利点は、改修サイクルを分離できることです。安定させたい領域は既存のWMSで安定させたまま、変え続けたい出荷領域だけを、現場の判断で調整できるようになります。

ただし、ここは正直に書いておきます。システムを分けずに、ひとつで完結できるのが理想です。 分ければ、データ連携が発生します。役割分担のルールを決める必要があります。管理する対象が増えます。分けること自体が最適解というわけではありません。

分ける価値が出るのは、既存のWMS側で出荷フローを柔軟に変更しにくい場合です。逆に言えば、ベンダーとの関係の中で改修が迅速に回る、あるいは内製で出荷まわりを触れる体制がある——そういう現場であれば、WMS内で完結させた方が構成はシンプルです。

順序を変えるという使い方

もうひとつ、この構成には使い方があります。

冒頭に書いた通り、要件定義が難航する最大の理由は、動かす前に検証できないことでした。ならば、順序を変えるという方法があります。

先に出荷フローを動かし、運用を固めてから、要件にする。

出荷領域だけを切り出せる仕組みを使って、実際の現場で運用してみます。ピッキングの単位、検品の工程、帳票を出すタイミング。これらを実際に動かしながら調整し、現場で機能する形を確定させます。

運用が固まった段階で、その内容は「検証済みの仕様」になります。会議室で想像しながら書いた要件ではなく、現場が実際に回している運用そのものです。認識のずれは、既に動かす過程で潰されています。

その先の選択肢は、ひとつではありません。固まった運用をそのまま継続することもできますし、既存WMSの改修要件として整理し、WMS側に組み込むという判断もあり得ます。どちらを選ぶかは、改修コストと運用の安定性を比べて決める話です。

重要なのは、検証してから要件にする、という順序が取れることです。

要件定義から開発、運用へ進む従来の順序と、運用から検証、要件化へ変えた順序を比較した図
従来の順序では、ずれが運用開始後に発覚します。順序を変えると、動かす過程でずれが潰されます。

併用を検討するときに整理しておくこと

実際に役割を分ける場合、最初に決めておくべきは、システムの設定方法ではなく業務の分担です。

どのシステムが正となるのかを決めておかないと、運用が始まってから判断に迷う場面が出てきます。分担の線引きを先に決めることが、手戻りを減らします。

SHIPPの位置づけ

SHIPPは、既存のWMSや基幹システムから出荷指示データを受け取り、出荷現場の作業を扱うクラウド出荷管理システムです。入荷や在庫管理はWMSに残したまま、出荷指示より後の工程を担います。

ピッキング、バーコード検品、送り状発行、納品書や帳票の出力といった出荷作業を、現場条件に合わせて組み立てられる設計になっています。設定で出荷フローを切り替えられるため、運用を動かしながら調整するという使い方にも向いています。

WMSを置き換えるものではありません。安定させたい領域と、変え続けたい領域を分けたうえで、後者を担うという位置づけです。

まとめ

WMSの刷新が難しいのは、費用や工数だけが理由ではありません。動かす前に検証できないという構造があり、それが要件定義を長期化させ、開発コストの予測を難しくしています。

一方で、倉庫業務のすべてが同じ改修サイクルを必要としているわけではありません。入荷・在庫は安定させたい領域であり、出荷は日々改善が必要な領域です。この二つを同じ枠の中で扱うと、変え続けたい領域が、慎重な改修プロセスに縛られます。

出荷だけを切り出すという設計は、この噛み合わせを解く選択肢のひとつです。そして、先に動かして運用を固めてから要件にするという順序も取れるようになります。

システムを分けないで済むなら、その方が構成はシンプルです。ただ、出荷フローを柔軟に変えにくい状況が続いているなら、どこで線を引くかを検討してみる価値はあります。

費用の見通しを立てるうえでは、料金プランも参考にしてください。