三つの市場、三つのシステム
TSUKIは台北・東京・シンガポールで別々のコマース基盤を運用し、三チームで維持していました。一つの価格変更に同じ作業が三回必要で、そのうち一つは高い確率で漏れます。この構造を誰かが決めたわけではありません。積み重なったものです。新しい市場を開くたび、既存システムの複製がその週の最速手段でした。
抽象化への引力
この状況で最初に浮かぶのは、常に「汎用のルールエンジンを作る」です。税は式に、決済はプラグイン境界に、配送は対応表に —— 十分に抽象化すれば四つ目も五つ目も十個目も収まります。この発想は本当に魅力的で、そして誤りです。
意図的に狭く保った
実装したエンジンが支援するのは、この三市場が実際に使う規則の形だけです。税は内税か外税か、決済は指定の三統合、配送は重量帯か一律料金か。語彙はこれで全部です。あらゆる規則を表現できるエンジンは、やがて第二のプログラミング言語になります —— 型もデバッガもなく、読める人もいない言語に。
表現できないものを書き残す
最も省略されやすく、最も重要な工程です。ドキュメントには「このエンジンで表現できない規則」という節があり、七つの事例と、それぞれの場合にどうするか（多くは、コードを書く）が記されています。この節がなければ、二年後に誰かが八つ目を設定で表現しようとし、失敗し、この設計のせいにします。
四つ目の市場
2026年初めにマレーシアを開設されました。規則の形は支援範囲に収まり、コードは変更ゼロ。検討は六週間から二日になりました。賭けは当たりました。ただし正直に言えば、その市場が八つ目の形を必要としていればコードを書いていましたし、それでも汎用エンジンを二年維持するより安く済んだはずです。
汎用化が正しいとき
市場が二十あり、四半期ごとに一つ増えるとき。汎用化の費用はほぼ固定で、便益は件数に比例するため、ある件数を超えれば割に合います。TSUKIはその件数に達しておらず、多くの企業も達していません。難しいのは、ほぼすべてのチームが自分は達していると考えることです。