ツールと人の確認を分ける仕組み化

実践者としての結論

拡大前に分けるのは、定型処理、例外、人の承認です。

情報収集、計算、差分検知、記録は、基準を定義すればツールへ渡せます。一方、商品一致、販売可否、重大な利益悪化、購入者対応、販売再開は人が確認します。

処理が失敗したときの動作まで決まって初めて仕組みです。

出品数より管理できる販売機会を見る

商品数が増えても、在庫と価格が古い、納期を確認できない、例外が未処理なら販売機会ではなく危険が増えています。

見る指標は次です。

• 基準内で販売中の商品数
• 最終確認からの経過時間
• 取得・更新失敗件数
• 未処理例外と最長滞留時間
• 注文期限内の処理率
• 見積利益と実績利益の差

手作業から自動化する順番

1. 一商品を手作業で最後まで確認する
2. 確認項目、基準、証拠、期限を文章にする
3. 通常、例外、人の承認へ分ける
4. 収集、計算、差分検知、記録を自動化する
5. 小さな商品群で並行運用する
6. 失敗時の停止と復旧を確認する
7. 問題がなければ対象を増やす

便利そうな機能から入れず、繰り返し説明できる処理から渡します。

ツールに任せる処理と人が承認する判断

値が取れなかった場合は前回値を正常値として使い続けず、取得失敗として例外へ送ります。

商品群単位で拡大する

一度に全商品へ適用せず、同じ特性と確認基準を持つ小さな商品群から始めます。

商品群ごとに、担当、確認頻度、利益下限、納期上限、例外条件、停止条件を設定します。問題が起きたときは、その商品群を止め、他の運用への影響を限定します。

ログ・再試行・停止を設計する

最低限、開始・終了日時、対象、入力値、出力値、処理結果、失敗理由、再試行回数、担当への通知を残します。

再試行は無制限にしません。同じ失敗が続いたら販売を止め、人の確認へ送ります。復旧後は、停止中の変化を再取得してから再開します。

外注できる状態を作る

外注へ渡せるのは、入力、作業、出力、期限、証拠、完了条件、例外時の連絡先を説明できる定型処理です。

判断基準が曖昧なまま「確認してください」と渡すと、担当者ごとに結果が変わります。例外の承認者と回答期限を決め、作業履歴を同じ場所へ残します。

拡大と停止の条件

拡大する条件

• 更新と注文処理が期限内に完了する
• 例外の滞留が管理範囲内である
• 実績利益の差を説明できる
• 停止と復旧を試せている
• 人が承認すべき判断が明確である

拡大を止める条件

• 取得・更新失敗が見えない
• 例外が担当不明で滞留する
• 誤停止や再開漏れが増える
• 購入者対応が遅れる
• 商品数だけ増え、記録品質が落ちる

まとめ

仕組み化の目的は、無人化ではなく判断品質を保った拡大です。

定型処理、例外、人の承認を分け、ログ、再試行、停止、復旧を設計します。小さな商品群で試し、管理品質が保てる範囲だけを増やします。