スプレッドシートで管理していた約1,900件の旅行商品の業務をシステムへ移しました。商品情報の収集と変更反映、検索広告連携を自動化しながら、画面よりもデータの整合性と収集モジュールの処理限界を先に検証しました。

商品を最初に登録することより難しいのは、登録した商品を合わせ続けることです。販売条件が変われば管理中の情報も変わらなければならず、販売画面と広告に伝わる内容も一緒に更新される必要があります。

旅行商品管理のM社では、約1,900件の商品を人がスプレッドシートで管理していました。商品の変動を反映する作業と、広告につなぐ作業がそれぞれ別の仕事として残っていました。

商品数が増えていく状況で必要だったのは、入力画面を一つ新しく作ることだけではありませんでした。外部から入ってきた情報が保存され、販売と広告に反映されるまで、データの流れを管理するシステムが必要でした。

旅行商品管理の従来業務と自動化フローを比較した概念図
ファイルごとの更新を追いかけていた業務から、商品の変更をつなぐ構造へ移しました。

ファイルをウェブ画面に変えることと、業務を自動化することは違います

既存の表をそのままウェブ画面に移せば、アクセスは楽になるかもしれません。しかし商品が変わるたびに誰かが確認し直して入力しなければならないなら、核心となる業務はそのまま残ります。

M社のプロジェクトでは、商品の変動管理と検索広告連携を自動化の対象と定めてシステムを構築しました。外部の商品情報を収集する機能がその中心にありました。

自動化の範囲を理解するには、画面ではなく変化の起点を見る必要があります。商品情報がどこで変わり、その変更がどの経路を通って最終利用者に届くのか、です。

この観点から見ると、収集機能は単なる付加機能ではありません。後ろにある保存と表示、広告連携が使う情報を供給する出発点です。

収集が成功したという表示より、保存された値を確認しました

データを取り込む作業が終わっていても、その値が意図した商品の情報として保存されたかは別に確認しなければなりません。見た目のよい管理画面が、誤ったデータまで正しく見せることはできません。

QAでは、収集結果とデータベースの値を商品単位で突き合わせました。機能が実行されるかと併せて、収集した情報が保存の段階で一致しているかを確認しました。

データ整合性検証の問いは具体的です。入ってきた値と残っている値が同じ対象を説明しているか、後続の機能が使える状態で保存されたかを見ます。

このプロジェクトで画面確認とデータ検証を分けた理由もここにあります。販売に使う情報であれば、表示の誤りだけでなく、どのデータが実際に伝わっているのかを理解する必要があります。

収集した旅行商品情報と保存データの比較結果
収集の成否とは別に、保存された値を突き合わせました。

自動で多く処理するほど、限界を知ることが重要になります

人が処理していた業務を自動化すれば、繰り返しの作業をより速く実行できます。しかし処理速度が上がったという事実だけで、運用範囲が決まるわけではありません。

M社では収集モジュールに負荷をかけて処理限界を確認しました。収集結果と保存データの突き合わせに加えて、作業量が増える条件で何が先に限界に達するかを見たのです。

整合性検証と負荷テストは問いが異なります。前者は結果が正しいかを、後者はどの条件まで作業を受け止められるかを問います。どちらか一方の結果が他方の代わりになることはありません。

自動化システムの運用基準には、二つの問いの答えが揃って必要です。正確に処理できる範囲と、処理量が増えたときの制約を知ってはじめて、次の変更も判断できるからです。

旅行商品収集モジュールの負荷条件ごとの実測結果
処理量を増やしたときに現れる制約を確認した試験記録。

販売と広告が同じ商品の変化を追うようにしました

構築したシステムは、商品の変動を受け取って販売画面と検索広告に反映する流れを提供します。それぞれのチャネルを人が別々に合わせていた作業をつないだものです。

これは広告文を作る仕事や広告効率を改善する仕事とは区別されます。この事例の中心は、商品情報の変更がチャネルへ伝わる連携です。

連携があるからといって、すべての外部チャネルへの反映が常に即時に終わるわけでもありません。したがって重要なのは、変更を伝える経路と、使う情報の基準を理解することです。どのデータが次のシステムへ渡るのかを説明できなければなりません。

商品管理自動化の価値は、入力回数だけで表れるものではありません。同じ商品を説明する複数の場所が、互いに異なる状態のまま残らないように管理することにもあります。

構築後の運用まで、同じ範囲で続けました

環境はクラウドへ移行し、移行条件を整理したうえで運用を引き継ぎました。収集モジュールの処理限界とデータ整合性の基準も、その後の運用で参照できる結果として残りました。

このプロジェクトで起きた変化は、スプレッドシートを使わなくなったという一文では終わりません。商品の変更を人が追いかける構造から、システムが変更を収集して反映する構造へ移したことが重要です。

その上に検証がありました。誤った情報をより速く届ける自動化にならないよう、収集と保存のあいだで結果を突き合わせ、処理範囲を確認しました。

業務の自動化は、人が行っていた動作を代わりに実行することだけではありません。その作業が正しく処理されたかを確認する基準まで、システムと一緒に作ることです。