箱と箱の間にあるワークフロー

「注文は自動で移動する」という説明は、完成したワークフローのように聞こえます。例示的な追跡では、すべての注文が両システムに現れます。しかし、両者の間にスプレッドシートの列が見つかります。店舗のステータスはメールチームの期待する意味と違うため、担当者がアップロード前にその列を変更していたのです。

図は箱の水準では正確でしたが、仕事そのものを見落としていました。

記録システムからワークフローを学ぶ対談では、システムに入るものと修正されるものを観察して実務手順を組み立てます。これはよい出発点です。ただし、ログだけで人の意図が分かるわけではなく、観察のために顧客記録への広いアクセスを与えてよいわけでもありません。

手順名ではなく、1件の経路から始める

「注文同期」は1つの操作に聞こえます。注文1件を追うと、一連の出来事になります。いつ作成されましたか？ 最初に記録されたステータスは何ですか？ 支払いまたはキャンセルで変わりましたか？ どの項目が送信先に届き、送信先はそれをどう扱いましたか？ 後から人は何を修正しましたか？

出来事を時系列に書き、各段階に元の記録 ID を添えます。値が2回変われば両方を記録します。送信先が最新値しか保持しないなら、その間に何が起きたかを調べます。目的は見栄えのよい工程図ではありません。別の人が検証できる追跡記録です。

最初は通常の事例を追います。次はキャンセル、統合された顧客、返品、遅れた支払いなど、担当者が重要と考える例外です。2件だけで頻度は分かりませんが、仕様が答えるべき問いは見つかります。

1. 店舗の記録

   ステータスが到着
   観察
2. 担当者の修正

   意味を確認
   確認
3. メールシステム

   受け入れた状態

チームの説明	追跡で見つかり得ること	尋ねること
「注文は自動同期されます」	後から手動でファイルをアップロードします	ファイルはどんな変換をしますか？
「顧客ステータスは最新です」	古い値が後続イベントで上書きされます	最終状態はどのシステムが管理しますか？
「エラーはサポートに届きます」	チケットなしで元の記録を修正します	送信先は修正をどう知りますか？

これらは考えられる例であり、実際の顧客事故ではありません。連携ガイドは、実際の経路を理解した後に接続方式を選ぶ助けになります。

記録は行動を示し、担当者は意味を説明する

記録から値が pending から complete に変わったことは分かります。しかし、決済の完了、注文履行の完了、誤記の修正のどれを意味したかは分かりません。項目名は業務ルールではありません。

だから観察と聞き取りを組み合わせます。追跡で疑問が生じた事例を、担当者に順を追って説明してもらいます。例外を説明し、使用を許可された画面を見せてもらいましょう。そのルールを別のサンプルにも当てはめます。印象的な1例だけを基にした仕様では、1人の回避策を会社の方針にしてしまう恐れがあります。

アクセス範囲も重要です。問いに必要な最小限のデータを使い、承認されたアクセスを守り、可能なら個人情報を伏せます。同期設計を理由に顧客データベースを調査用ノートへ書き出してはいけません。監査イベントや検証環境があれば、そこから始めます。なければ、適切な記録を使って担当者に経路を示してもらいます。

この区別は、意味を理解する前に不便な手作業を自動化してしまうミスも防ぎます。スプレッドシートの列は無駄な重複かもしれません。一方で、争いのある注文からキャンペーンを始めないよう人が印を付ける唯一の場所かもしれません。理由を調べずに削除すると、新しい同期は誤った行動をより速く実行してしまいます。

追跡を契約に変える

経路が見えたら、状態と担当者で接続を定義します。各項目の正本となるシステム、値を動かすイベント、遅延・重複イベントの扱い、結果が不確かな場合の対応を決めます。不一致を修正できる人やチームを指定します。

契約では、記録された事実と業務上の解釈を分けます。「店舗が14:03に fulfilled を送った」は記録された出来事です。「この顧客にレビュー依頼を送るべきだ」は、返品、同意、各業務の方針にも左右される判断です。分けておくと後の変更が安全になります。

フィールドの対応付けは契約の一部を可視化します。このTajoの図では、各行に元の項目、送り先の項目、変換ルールを示します。同時に未定義の部分も見えます。購入イベントをレビュー依頼や配信判断に使うには、別の方針が必要です。

Tajoコンセプト図 · サンプルデータ

実行前に同期を確認

顧客の更新をメール配信サービスに同期してください。

Tajo MCPアプリ下書き

顧客同期

店舗メール配信サービス

フィールドの対応付け

元のフィールド	送り先のフィールド	ルール
email	EMAIL	そのまま
first_name	FIRSTNAME	そのまま
last_name	LASTNAME	そのまま

合成データでのプレビュー成功

3項目を対応付け · 送り先への書き込みなし

有効化には承認が必要です。

対応付けをプレビュー下書きを作成

Tajoの対応付けツールを基にした概念図です。合成データでのプレビューや保存した下書きだけでは同期は有効になりません。

実用的な受け入れ試験には追跡した事例を使います。検証環境で通常の注文と例外を再現し、API 呼び出しの成功だけでなく、送信先の最終状態を確認します。次に修正経路を試します。送信先が動いた後に元の記録が変わっても、整合させられるでしょうか。

「構築前にすべての例外を調べられない」という反論はもっともです。目的は網羅的な調査ではありません。初版の成否を左右する少数の隠れた手順を見つけることです。影響の大きい経路から始め、未知の点を記録し、新しい例外が見えるよう接続を計測します。

ワークフロー図が役立つのは、実務を担う人が欠けた箱を指摘できるときです。