【ITニュース解説】A Supplier Changed Its Case From Twelve Bottles to Ten and We Found Out Three Times

システムエンジニアを目指す皆さんにとって、情報システムは様々なデータが複雑に連携し合って機能する巨大な仕組みであることが想像できるだろう。今回解説する事例は、一見シンプルなデータ変更が、複数のシステムと部門にまたがり、いかに大きな混乱と問題を引き起こしたかを示している。これは、システムの設計や運用において「データの一貫性」と「情報伝達の仕組み」がいかに重要であるかを教えてくれる貴重な教訓となる。

ある飲料メーカーが、標準的な商品のケース単位をこれまでの12本入りから10本入りに変更した。このメーカーは通常通り、製品コードは変えずに、新しい梱包サイズを示すスプレッドシートを事前に取引先へ送付していた。しかし、この一見単純な変更が、商品を受け入れ、保管し、流通させる側のシステムに大きな影響を与えてしまった。

まず、この変更は社内の三つのシステムに、それぞれ異なるタイミングで伝わった。最初に動きがあったのは購買システムだった。取引先からの請求書内容がおかしいと気づいた購買担当者が、12月にシステムを更新したため、それ以降の発注は新しい10本入りのケース単位で行われるようになった。これは正しい対応だが、問題は他のシステムとの同期が取れていなかった点にある。

次に、倉庫システムが更新されたのはさらに遅れて2月中旬のことだった。ある倉庫の管理者が「パレットに積まれた商品がいつもより少ない」と疑問に感じたことから問題が発覚した。それまでの約6週間、倉庫では届く10本入りのケースを誤って12本入りと認識し、受け入れていたのだ。つまり、実際には10本しか入っていない箱を12本入りと数え、システムに登録していたため、物理的な在庫とシステム上の在庫数に大きなズレが生じていた。

最も遅れて問題が発覚したのは、顧客である小売店が注文に使うポータルシステムだった。このシステムは、小売店が注文したボトル数をピッキング単位のケース数に自動的に変換する機能を持っている。ポータルシステムが更新されたのは4月に入ってからだった。それまでの3ヶ月間、小売店が例えば120本の注文を出すと、システムは旧来の12本入りケースを基準に10ケース（120本分）をピッキング指示として送っていた。しかし、実際には1ケースが10本入りに変わっていたため、小売店には10ケースで合計100本しか届かず、常に20本の不足が発生していたのである。

これらのシステムの不整合は、目に見える形で複数の問題を引き起こした。顧客には商品が不足した状態で届き、社内の在庫データは実際よりも約11%も高く表示されるという事態になった。さらに深刻だったのは、配送不足が発生するたびに、その原因が配送センターでのピッキングミスとして調査されていたことだ。本当の原因はデータの不整合にあるにもかかわらず、現場では全く別の場所で問題が起きていると認識され、時間と労力が無駄に使われていた。

なぜこのような事態が起きてしまったのか。根本的な原因は、商品の梱包サイズという一つの重要なデータが、社内の三つのチームによって、それぞれ異なる場所にコピーされて保持されており、それぞれが独立して更新を行っていたことだった。購買チームは請求書から、倉庫チームはパレットの物理的な状態から、ポータルチームは顧客からの苦情から、それぞれが「自分の仕事がおかしい」と気づいた段階で、バラバラにデータを更新していたのだ。供給元が一度変更を通知したにもかかわらず、社内でその情報が一本化されず、結果的に三度も同じ変更に「気づく」形となった。各部門はそれぞれのシステムの情報が正しいと思い込んでいたため、情報のズレに気づくまでに時間がかかった。

この問題に対処するため、会社は抜本的な解決策を導入した。まず、商品データ、特に梱包サイズのような重要な情報の「オーナー」を明確にし、「商品データチーム」という専門のチームを立ち上げた。このチームが管理するシステムが、商品データに関する唯一の信頼できる情報源（Single Source of Truth）となった。つまり、梱包サイズの情報は、この商品データチームのシステムでのみ維持・更新され、そこから購買システム、倉庫システム、注文ポータルシステムへと連携される仕組みに変わったのだ。

新しい仕組みでは、梱包サイズの変更にはその発効日も付与されるようになった。これにより、旧サイズで受け入れた在庫は、それがピッキングされるまでは旧来の数量として管理され、新サイズの商品とは区別して扱えるようになった。さらに、商品を受け入れる段階では、供給元が提供するケース外装のバーコードを読み取り、システム上の記録と一致するかどうかを自動でチェックする仕組みも導入された。もしバーコードから読み取った数量とシステム上の記録が一致しない場合は、その商品の受け入れを一時停止し、問題解決まで先に進めないようにすることで、早い段階での間違いの発見を可能にした。また、大口の顧客からの商品変更情報は、すべてこの商品データチームの専用アドレスに送られるようにルートを統一した。

これらの改善策を導入して以降、3つの供給元が梱包サイズを変更したが、一度も配送不足が発生することはなかった。この事例は、単一の事実が複数のシステムにコピーされてしまうと、それぞれが異なるタイミングで変更され、大規模なシステム障害や業務上の混乱を引き起こす可能性があることを明確に示している。供給元からの情報は一度で十分だったはずであり、それを社内でいかに一貫した形で複数のシステムに反映させるかが、システムエンジニアの腕の見せ所となる。

システムエンジニアを目指す皆さんにとって、この事例はデータ管理とシステム連携の重要性を理解する上で非常に役立つだろう。単にシステムを構築するだけでなく、そのシステムが扱うデータのライフサイクル全体、つまりデータがどこで生まれ、どこで保持され、どのように利用され、どのように更新されるのかといったプロセスを深く理解し、設計に落とし込むことが求められる。特に、複数のシステムが同じデータを参照する場合、そのデータが常に最新かつ正確な状態に保たれるような仕組みを考慮し、いわゆる「データの一貫性」を確保するためのアプローチを学ぶことが不可欠である。この原則を意識することで、今回のような問題を未然に防ぎ、信頼性の高いシステムを構築・運用できるようになるだろう。