注文ステータス状態マシン：遷移を間違えるとサポートラインが溶ける

Verdict first: OMS導入では、誰もが機能チェックリストとAPIドキュメントに目を向けるが、サポートラインを溶かすのは通常もっとも地味な設定項目――注文ステータス状態マシンである。遷移を設定し損ねると、注文が「消えた」「固まった」「生き返った」と言い出し、サポートも倉庫も経理もそれぞれ違う話をする。この失敗を私は3回見てきた。3回とも違うものだった。

注文ステータス状態マシンがこれほど重要な理由

注文ステータスは、すべての役割が共有する唯一の言語だ。サポートはそれを確認し、倉庫はそれに基づいて作業し、経理はそれに対して決済し、顧客は追跡ページでそれを見る。注文ステータス状態マシンは文法書である――どの状態がどこへ移り、誰がそれを動かし、詰まった注文がどこへ行くのか。

文法が間違えば、誰も同じ言語を話せない。倉庫は「出荷済み」と言い、サポートはまだ「引当済み」を見て、顧客は「注文はどこですか」と聞き、サポートは「確認します」としか言えず――その後チャットグループに駆け込んで倉庫に聞く。サポートがプロらしくないのではない。状態マシンが先に彼女を裏切ったのだ。

私の3回のメルトダウンのうち、もっとも学びの多かった2つを紹介する。

メルトダウンその1: 状態の凍結、何百もの注文が「消える」

2年前、私は1日数千件の注文を扱うカリフォルニアの3PLのOMS本番稼働を率いた。サンクスギビングのピークの2週間前の立ち上げだった。3日目、サポートのリーダーが電話してきた。「Lin Xiaoさん、注文のロットがシステム上『引当済み』で止まっています。でも倉庫は昨日商品を出荷したと言っています。」

根本原因：ピッキング完了時にWMSが「ピッキング完了」を返したが、状態マシンでは「引当済み」が「ピッキング中」に遷移することになっていて――WMSのイベントマッピングテーブルには「ピッキング中」の値がそもそもなかった。2つの統合ドキュメントは独立に書かれ、UATはハッピーパスしかカバーしなかった。WMSが送り得るすべてのイベントをOMS状態マシンに通して、それぞれに出口があることを確認した者は誰もいなかった。

結果：何百もの注文が「引当済み」で凍結した。サポートはどこを見ても「引当済み」、倉庫はずっと前に出荷済み、運送会社の追跡は「集荷済み」――3つのソース、3つの物語、サポートラインは溶けた。

修正は地味だった：夜中にイベントマッピングをパッチし、続いて止まった注文を実際のWMS進捗に一括更新するリコンサイルジョブを書いた。2日と2晩。運用は救ったが、ピークシーズン第一波の顧客体験は失われた。その教訓はそれ以来すべてのチェックリストに入った：イベントマッピングテーブルは状態マシンと1行ずつ整合させなければならない。1行も飛ばさない。

メルトダウンその2: キャンセル分岐の欠落、注文が「生き返る」

別の顧客、DTCブランドは美しい状態マシンを持っていたが、前方フローは1つだけだった：審査待ち → 引当待ち → 引当済み → ピッキング中 → 梱包済み → 出荷済み → 配達済み。顧客がキャンセルすると、OMSはWMSに引き止め指示を送った――しかし状態マシンには「引き止め中」「引き止め済み」「引き止め失敗」の状態がまったくなかった。

引き止め指示は倉庫に届いたが、ピッキングタスクはすでにリリース済みで、作業者は引き止めフラグを見なかった（WMSタスクステータスとOMS注文ステータスは別物だ）。商品は結局出荷された。OMSは「キャンセル済み」を示し、返金は出た。正味の結果：顧客は「すでにキャンセルした」注文を受け取り、会社は返送運賃を被り、サポートはなぜキャンセルした注文が届いたのか説明しなければならなかった。

この失敗を私は3回見てきた。どの顧客も「キャンセルに状態が必要だとは思わなかった」と言う。私の答えは常に同じだ：キャンセルはステータスの終わりではない。キャンセルは丸ごと1つの分岐だ。

注文ステータス状態マシン設計のための3テーブル・チェックリスト

十分な傷を負った後、私は今ではすべてのプロジェクトの状態マシンをこの3つのテーブルから設定している。そのままコピーしてほしい。

テーブル1：メインフロー――注文の通常の生涯。各行に4列必要だ：状態、誰がそれを動かすか、タイムアウト時にどこへ行くか、どこにロールバックできるか。

審査待ち：システム自動化または人が動かす；タイムアウトで手動審査へ；これが始まりで、ロールバックなし。
引当待ち：wavingまたはルールエンジンが動かす；在庫不足で保留へ；審査却下で審査待ちにロールバック。
引当済み：WMSコールバックが動かす；WMSが長く沈黙しすぎると例外へ；引当の解放で引当待ちにロールバック。
ピッキング中：WMSコールバックが動かす；ピッキング例外にタイムアウト；タスクのキャンセルで引当済みにロールバック。
梱包済み：WMSコールバックが動かす；引き止め成功で商品がステージングに戻るとき（承認付きで）ロールバック。
出荷済み：運送会社またはWMSコールバックが動かす；ゴール前の最後の追跡可能ポイント。
配達済み：運送会社コールバックが動かす；終点。

テーブル2：分岐状態――キャンセルと引き止めは専用レーンを持つ。

キャンセル申請 → 審査中 → キャンセル済み、またはキャンセル却下（元の状態に戻る）。引き止め中 → 引き止め済み（商品は梱包済みに戻り、対応待ち） → 引き止め失敗（元のフロー継続、サポートが介入）。

肝心な点：キャンセルと引き止めは別のアクションであり――1つのステータスに統合してはならない。「キャンセル済み」はお金と注文の結果、「引き止め済み」は物理的な商品の結果である。商品出荷後のキャンセルと、何も動く前のキャンセルはまったく異なる状況であり、状態は分けておかなければならない。統合すると「キャンセルした注文が出荷された」のような怪談が生まれる。

テーブル3：例外状態――すべての状態に脱出ハッチを。

審査却下、在庫不足による保留、住所例外、決済例外、WMSコールバックタイムアウト、運送会社例外。すべての例外状態に3つの割り当て：所有者、対応SLA、解決できない場合のエスカレーション先。所有者のいない例外状態は、ないのと同じだ。

各状態を設定するときは3つの問いを――これは私の本番稼働当夜チェックリストの固定ページだ：

この状態を誰が動かすか？所有者のいない状態は凍結する。システム駆動：どのジョブか、そのスケジュールを文書化する。人間駆動：どの役割かを文書化する。
タイムアウト時にどこへ行くか？すべての状態にタイムアウト出口が必要だ――それがなければ、未来の自分のために地雷を埋めている。
どこにロールバックできて、ロールバックに承認は要るか？ロールバックは状態マシンでもっとも忘れられがちな部分だが、本番では毎日起きている。

注文ステータス状態マシンが壊れる3つのもっとも一般的なパターン

第一に、イベントと状態の不整合。OMSの状態は外部イベント――WMS、運送会社、決済コールバック――によって動かされ、すべてのイベントはちょうど1つの遷移にマップされなければならない。ハッピーパスしかテストしないプロジェクトは遅かれ早かれここで失敗する。修正：外部システムが送り得るすべてのイベントを列挙し、それぞれを状態マシンに通し、隙間をその場で埋める。

第二に、表示ステータスとワークフローステータスの混同。サポートは顧客向けビューが欲しく、倉庫は運用ビューが必要で、経理は決済ビューが必要だ。3つを1つの状態マシンに押し込むと全員が怒る。修正：ワークフロー状態マシンは内部遷移のみを扱い、別の「顧客可視ステータス」マッピングテーブルが表示を扱う。2つのテーブル――1つの真実の源と1つの翻訳層。

第三――意外だが――状態マシンは細かいほど良いわけではない。30を超える状態のプロジェクトを私はかつて見た；サポートは3日訓練しても注文が検索できず、新人は皆遷移図を暗記した。もっとも安定した本番の状態マシンは、メインフローと分岐を合わせて十数状態で動いている。余分な状態は飾りであり、飾りはメンテナンス家賃を請求する：すべての状態にタイムアウト、ロールバック経路、権限、テストケースが必要だ。状態を1つ増やすたびにコストが増えるのではない――掛け算で増える。

もう1つのトレードオフ：自動遷移と手動確認の比率。自動化が多いほど効率は上がるが、例外は難しくなる。私の最低ライン：審査、引き止め、大規模返金は常に人間の確認を残す。完全自動化が欲しい？例外分岐のフォールバックロジックを先に仕上げろ。