POS連携システムの設計でまず何を決めるべきか
POS側とシステム側のどちらの情報を正として扱うかを、要件定義の最初の段階で決めることから始めます。
POS連携の設計は、画面や機能の検討から入りがちです。ですが先に決めるべきは、商品情報や在庫数といったデータの正がどちらにあるかです。ここが曖昧なまま進めると、後工程で仕様のやり直しが発生します。
正を決めるとは、POSサービス側の値と自社システム側の値が食い違ったとき、どちらを採用するかを明文化することです。この判断は、開発の初期段階で発注者と開発会社が合意しておく必要があります。
この記事では、情報源を一元化する考え方と、設計を進める手順を順に解説します。
なぜ情報源を一元化しないとうまくいかないのか
情報源が複数に分かれたまま連携すると、在庫数や商品情報の食い違いが後から発覚し、修正コストが膨らむためです。
この構造の課題は、POS連携に限った話ではありません。経済産業省は2018年9月7日公表の「DXレポート」で、老朽化・複雑化・ブラックボックス化した既存システムを放置した場合、2025年から2030年の間に最大で年間12兆円の経済損失が生じる可能性があると指摘しています(出典: 経済産業省「DXレポート～ITシステム『2025年の崖』の克服とDXの本格的な展開～」)。
同レポートでは、2025年までに先端IT人材が約43万人不足すると予測されています。また、2025年には大企業の約6割で基幹系システムが導入から21年以上経過するとされ、老朽化した既存システムがデータの一元管理やシステム間連携の障壁になっている実態が示されています(出典は同レポート)。
POSサービスと自社システムを連携する設計でも、情報源を決めずに進めると、同じ構造の課題を抱えることになります。データの不整合や連携の複雑化が、システムの老朽化を待たずに初期設計の時点で生まれてしまうのです。
情報源をどちらに置くかの制約は、次の見出しで具体的に説明します。
POSサービスを情報源の正にする場合の制約は
POSサービスのAPI仕様で取得できる項目と更新頻度の範囲内でしか、自社システム側は情報を追随させられません。
当社では、小規模店舗で広く使われているPOSサービスを在庫や売上の情報源の正として扱う設計を検討し、公式情報で仕様を裏取りしました。外部から参照できるAPIは読み取り専用でした。取得できるのは限られたカテゴリの日次集計にとどまり、商品単品(SKU)の粒度では取得できませんでした。書き込み用のAPIも提供されていませんでした(当社の実装経験による)。
API仕様で確認すべき項目
| 確認項目 | 当社が検証した結果 |
|---|---|
| APIの読み書き | 読み取り専用。書き込みはできない |
| 取得できる粒度 | 限られたカテゴリの日次集計まで |
| SKU単位の取得 | できない |
| 在庫の書き戻し | POS側へは書き戻せない |
この結果、POS側へ在庫数を書き戻す運用は成立せず、CSVの受け渡しを前提に設計するしかありませんでした。API仕様の制約は設計を縛ります。ですが、縛られ方を先に調べておけば、後から気付く整合性の事故は避けられます(当社の実装経験による)。CSVを使う際の注意点は、次の見出しで説明します。
設計を進める手順は
API仕様の確認、同期範囲の切り分け、競合時のルール設計の順に進めます。
- API仕様を確認する。読み書きの可否、取得できる粒度、更新頻度を洗い出します。つまずきやすい点は、公式ドキュメントに載っていない制約が、問い合わせて初めて分かることです。
- 同期範囲を切り分ける。全項目を自動連携するのではなく、正を一本化できる項目とできない項目に分けます。所要時間の目安は、項目数にもよりますが数日程度です。
- 競合時のルールを設計する。両側の値が食い違った場合にどちらを採用するか、差分反映か全件上書きかをあらかじめ決めます。つまずきやすい点は、この設計を後回しにすると、運用開始後に食い違いへの対応が場当たり的になることです。
- 取り込みのタイミングを決める。営業時間中の取り込みは、売上発生と処理のタイミングがずれる原因になります。営業時間外のバッチ処理を基本に検討します。
これらの手順は、要件定義の段階で発注者と開発会社が合意しておくべき内容です。