☃️どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論2022/12/31に公開2024/05/034件設計技術的負債techDiscussionwint2023/01/29大変参考になる記録を共有いただいて、ありがとうござます！ 事業ドメインへの理解が深まるにつれて、モデリングとの乖離に苦悩する姿が克明に浮びました…！ 負債のメタファーのケーススタディーとして非常に学びになります。 ところで、 grouping tag という命名の困難についてですが、商品に名前を取られてしまってるという印象を受けました。そして pricing が商品種別ないし在庫保管単位の機能を持ってるとのことで、これは SKU に相当する様に見えました。 参考までに、 EC SaaS の Shopify では、 SKU のことを商品バリエーション (product variant) と呼び、それらをまとめた単位として商品 (product) と命名してたりします。一般に、商品ページ 1ページにまとめて表示される単位が product で、そこからドリルダウンして 1種別を選ぶのが SKU という理解でいました。 ref. https://shopify.dev/api/admin-rest/2023-01/resources/product-variant https://shopify.dev/api/admin-graphql/2023-01/objects/ProductVariant https://shopify.dev/api/admin-rest/2023-01/resources/product https://shopify.dev/api/admin-graphql/2023-01/objects/Product さざんかぬふ2023/01/29に更新@wint コメントありがとうございます！ また、参考になる意見をありがとうございます。この記事を書いた時に、なにか意見をいただけたりするといいなあ、という下心もあったりしたので、大変ありがたいです。 私の理解では、 Pricing -> Product、KioskPricing -> SKU（Product variant）に近い概念、と思っていました。 というのが、一般的なECの場合、例えば「トウカイテイオーTシャツ」みたいなものがProductで、これを選択するとProductからドリルダウンしてS、M、L、XLみたいなサイズをSKUで選ぶ、というような構成と思われます。 これについてチケット業界的な表現をすると、席種/券種という単純な2階層構造であればそう考えることもできて、例えば Product -> 「1月29日 第1公演 S席」（または「1月29日 第1公演」） SKU/Product variant -> 「S席おとな」「S席こども」（または「S席おとな」「S席こども」「A席おとな」「A席こども」） というような考え方ができると思います。 ただ、この時点で一つ課題があって、「S席おとな」「S席こども」は一見SKUのように見えるのですが、実際には「S席」という概念がSKUになっていて、S席おとな/S席こどもは金額を表現する概念ではあるが単独では在庫管理単位を意味しない、という事です。在庫と値付けに"ねじれ"があって、値付けの方が細かいんですよね（だから元々ProductではなくてPricingという言葉を選んだという背景もありました） これは、(1)Productに在庫をもたせるか、(2)Product variantの方に席種を入れてしまって、券種と同時に席種を購入するというビジネスロジックにするか、といった方法で解決できて、我々はこの事象の解決としては(2)を選んでいます。 （その意味で、KioskPricingについては、もうSKUとか在庫みたいな名前にしてしまうのもアリかなあという気がしています。ただ、既に管理ユーザーの人たち、少なくとも数百人ぐらいには「商品」という名前で説明してしまっていて、それが結構難しいところがあります。。。。。） 在庫管理で悩ましいのが、更に公演数を増やした時にどう考えるべきか、という事に課題があります。 具体的には、1月29日 第2公演、1月30日 第1公演、1月30日 第2公演、...などが増えた場合です。 我々が実際に登録しているデータでは、1つの施設の中の1つの展示群のチケットで SKUの単位では数万レコードを超えるものがあります。例えば、1日20コマぐらいあって、期間が60日ぐらいあって、チケットの種類が20種類あると20×60×20=24000SKUということです。 （このチケット20種類というのは、例えば大人、子供、障害者、優待A、優待B、グッズ付き大人、グッズ付き子供、グッズ付き障害者、....みたいなものによって構成されます） このSKUのレコード数が増えるのは、（スパースな行列を扱うようなやり方をしない限りは）原理的に避けられない事だと思っていますが、一方でProductのレコード数まで増やしてしまうと、例えば商品名みたいな概念を数万レコードでバラバラに管理するのか？というような課題があって、更新忘れとか名前の整合性誤りとか、そういった事が容易に想像されました。それで、商品名みたいなものはSKUに含めたくない（何らかの少数のマスタを参照する構成にしたい）というのがあります。 あと、より複雑な条件として、この場合に「公演を跨って販売可能数の上限がある場合」というものがあって、 ・各公演での在庫数はSKU/Product variant（KioskPricing）単位に従う ・特別なグッズ付きのため、公演全体での定量在庫がある というようなケースがあります。 つまり、「入場券、グッズ付き入場券」という2種類のチケットが全ての公演分存在していて、グッズ付き入場券は全公演を通して1000枚しか売ってはいけない、みたいな場合です。 これは、公演をまたいだ在庫管理が必要で、我々の仕組みではProduct（Pricing）の方に在庫をもたせて管理するという事をしています。 さて、これを踏まえてのgrouping_tagですが、きちんとマスタ化するとしたら、それは公演とか、あるいは一種の販売単位みたいな概念にあたると考えています。本質的にはProductとProduct variantの階層が1つでは足りないという事なのだと思っていて、Productの上か、ProductとProduct variantの間か、Product variantの下か、どこかに階層を増やした方が自然なのだろうと思っています。現状の仕組みでいうと、ProductとProduct variantの間が一番良いのではないかと思ってはいます。 ただ、その仕組にした場合、上述のように24000種類のSKU単位がある場合に、人間が3つの階層を適切に管理できるのか？という課題があります。 そもそも、現在の状態で、2つの階層構造でも管理をするのがそこそこ大変になっていて、これを3つに増やした時に一般的なユーザーが整合性を維持できるのか...？というのはすごく気になっています。 基本的には、24000種類みたいな大量のSKUは20×60×20みたいな組み合わせで生成されるものなので、組み合わせを適切に管理できればよいと思うのですが、これを丁寧に管理しようとするとテーブルが複数個増えるような気がしていて、逆に単純な販売案件でそこまでデータを登録しなければならないのか、といった課題が生じます。 おそらく、管理画面および入出力方法、特にインポート処理をめちゃくちゃわかりやすくする前提で、内部のデータ構造のみgrouping_tagを間の階層としてきちんとマスタ化して、利用者にはそれを感じさせないみたいな状態が解なのだろうと思っていますが、チケットシステム全体では在庫管理以外に大きな課題があって、まだそこまでは検討ができていません。 （ちなみに、パフォーマンスに関しても課題があって、正規化した場合にデータ取得等を最適化できるのか？というのがあるのですが、たぶんこれは"ちゃんと考えれば"正規化した方が早いんじゃないかなという気がしています。マスタデータの登録は遅くなる可能性がありますが。） wint2023/02/14おお…、種数が24000種類のオーダーで存在するんですか…！なるほど、これは難しいですね…。 物理的な席をSKUにするのがメンタルモデルとしてシンプルかと思いきや、大人・子供があったり、別の物理的なグッズとの“セット販売”があったりなど、全然一筋縄では行かないんですねぇ…。席より小さそうな単位で言いますと、たとえば子供料金は無理矢理「割引き」概念にマッピングした上で、表示を工夫するくらいはできるかも知れません。ただ、 Product ないし Product variant を跨ぐ制約は、対応物が無さそうですね。やはりフルスクラッチに至るのは必然のようですね。一端が見えた気がします。 改めて、モデリングの現場感が非常にエキサイティングな記事でした。これからも健闘をお祈りしてます！ 返信を追加skport2023/02/11に更新大変興味深い記事をありがとうございます。「綺麗に負債を返済した」というお手本のような学びのないスライドでなく、失敗例を赤裸々に書いていらっしゃるのが好感を持てました。 （まとまった時間があるときにじっくり読みたい…） 返信を追加
wint2023/01/29大変参考になる記録を共有いただいて、ありがとうござます！ 事業ドメインへの理解が深まるにつれて、モデリングとの乖離に苦悩する姿が克明に浮びました…！ 負債のメタファーのケーススタディーとして非常に学びになります。 ところで、 grouping tag という命名の困難についてですが、商品に名前を取られてしまってるという印象を受けました。そして pricing が商品種別ないし在庫保管単位の機能を持ってるとのことで、これは SKU に相当する様に見えました。 参考までに、 EC SaaS の Shopify では、 SKU のことを商品バリエーション (product variant) と呼び、それらをまとめた単位として商品 (product) と命名してたりします。一般に、商品ページ 1ページにまとめて表示される単位が product で、そこからドリルダウンして 1種別を選ぶのが SKU という理解でいました。 ref. https://shopify.dev/api/admin-rest/2023-01/resources/product-variant https://shopify.dev/api/admin-graphql/2023-01/objects/ProductVariant https://shopify.dev/api/admin-rest/2023-01/resources/product https://shopify.dev/api/admin-graphql/2023-01/objects/Product さざんかぬふ2023/01/29に更新@wint コメントありがとうございます！ また、参考になる意見をありがとうございます。この記事を書いた時に、なにか意見をいただけたりするといいなあ、という下心もあったりしたので、大変ありがたいです。 私の理解では、 Pricing -> Product、KioskPricing -> SKU（Product variant）に近い概念、と思っていました。 というのが、一般的なECの場合、例えば「トウカイテイオーTシャツ」みたいなものがProductで、これを選択するとProductからドリルダウンしてS、M、L、XLみたいなサイズをSKUで選ぶ、というような構成と思われます。 これについてチケット業界的な表現をすると、席種/券種という単純な2階層構造であればそう考えることもできて、例えば Product -> 「1月29日 第1公演 S席」（または「1月29日 第1公演」） SKU/Product variant -> 「S席おとな」「S席こども」（または「S席おとな」「S席こども」「A席おとな」「A席こども」） というような考え方ができると思います。 ただ、この時点で一つ課題があって、「S席おとな」「S席こども」は一見SKUのように見えるのですが、実際には「S席」という概念がSKUになっていて、S席おとな/S席こどもは金額を表現する概念ではあるが単独では在庫管理単位を意味しない、という事です。在庫と値付けに"ねじれ"があって、値付けの方が細かいんですよね（だから元々ProductではなくてPricingという言葉を選んだという背景もありました） これは、(1)Productに在庫をもたせるか、(2)Product variantの方に席種を入れてしまって、券種と同時に席種を購入するというビジネスロジックにするか、といった方法で解決できて、我々はこの事象の解決としては(2)を選んでいます。 （その意味で、KioskPricingについては、もうSKUとか在庫みたいな名前にしてしまうのもアリかなあという気がしています。ただ、既に管理ユーザーの人たち、少なくとも数百人ぐらいには「商品」という名前で説明してしまっていて、それが結構難しいところがあります。。。。。） 在庫管理で悩ましいのが、更に公演数を増やした時にどう考えるべきか、という事に課題があります。 具体的には、1月29日 第2公演、1月30日 第1公演、1月30日 第2公演、...などが増えた場合です。 我々が実際に登録しているデータでは、1つの施設の中の1つの展示群のチケットで SKUの単位では数万レコードを超えるものがあります。例えば、1日20コマぐらいあって、期間が60日ぐらいあって、チケットの種類が20種類あると20×60×20=24000SKUということです。 （このチケット20種類というのは、例えば大人、子供、障害者、優待A、優待B、グッズ付き大人、グッズ付き子供、グッズ付き障害者、....みたいなものによって構成されます） このSKUのレコード数が増えるのは、（スパースな行列を扱うようなやり方をしない限りは）原理的に避けられない事だと思っていますが、一方でProductのレコード数まで増やしてしまうと、例えば商品名みたいな概念を数万レコードでバラバラに管理するのか？というような課題があって、更新忘れとか名前の整合性誤りとか、そういった事が容易に想像されました。それで、商品名みたいなものはSKUに含めたくない（何らかの少数のマスタを参照する構成にしたい）というのがあります。 あと、より複雑な条件として、この場合に「公演を跨って販売可能数の上限がある場合」というものがあって、 ・各公演での在庫数はSKU/Product variant（KioskPricing）単位に従う ・特別なグッズ付きのため、公演全体での定量在庫がある というようなケースがあります。 つまり、「入場券、グッズ付き入場券」という2種類のチケットが全ての公演分存在していて、グッズ付き入場券は全公演を通して1000枚しか売ってはいけない、みたいな場合です。 これは、公演をまたいだ在庫管理が必要で、我々の仕組みではProduct（Pricing）の方に在庫をもたせて管理するという事をしています。 さて、これを踏まえてのgrouping_tagですが、きちんとマスタ化するとしたら、それは公演とか、あるいは一種の販売単位みたいな概念にあたると考えています。本質的にはProductとProduct variantの階層が1つでは足りないという事なのだと思っていて、Productの上か、ProductとProduct variantの間か、Product variantの下か、どこかに階層を増やした方が自然なのだろうと思っています。現状の仕組みでいうと、ProductとProduct variantの間が一番良いのではないかと思ってはいます。 ただ、その仕組にした場合、上述のように24000種類のSKU単位がある場合に、人間が3つの階層を適切に管理できるのか？という課題があります。 そもそも、現在の状態で、2つの階層構造でも管理をするのがそこそこ大変になっていて、これを3つに増やした時に一般的なユーザーが整合性を維持できるのか...？というのはすごく気になっています。 基本的には、24000種類みたいな大量のSKUは20×60×20みたいな組み合わせで生成されるものなので、組み合わせを適切に管理できればよいと思うのですが、これを丁寧に管理しようとするとテーブルが複数個増えるような気がしていて、逆に単純な販売案件でそこまでデータを登録しなければならないのか、といった課題が生じます。 おそらく、管理画面および入出力方法、特にインポート処理をめちゃくちゃわかりやすくする前提で、内部のデータ構造のみgrouping_tagを間の階層としてきちんとマスタ化して、利用者にはそれを感じさせないみたいな状態が解なのだろうと思っていますが、チケットシステム全体では在庫管理以外に大きな課題があって、まだそこまでは検討ができていません。 （ちなみに、パフォーマンスに関しても課題があって、正規化した場合にデータ取得等を最適化できるのか？というのがあるのですが、たぶんこれは"ちゃんと考えれば"正規化した方が早いんじゃないかなという気がしています。マスタデータの登録は遅くなる可能性がありますが。） wint2023/02/14おお…、種数が24000種類のオーダーで存在するんですか…！なるほど、これは難しいですね…。 物理的な席をSKUにするのがメンタルモデルとしてシンプルかと思いきや、大人・子供があったり、別の物理的なグッズとの“セット販売”があったりなど、全然一筋縄では行かないんですねぇ…。席より小さそうな単位で言いますと、たとえば子供料金は無理矢理「割引き」概念にマッピングした上で、表示を工夫するくらいはできるかも知れません。ただ、 Product ないし Product variant を跨ぐ制約は、対応物が無さそうですね。やはりフルスクラッチに至るのは必然のようですね。一端が見えた気がします。 改めて、モデリングの現場感が非常にエキサイティングな記事でした。これからも健闘をお祈りしてます！ 返信を追加
さざんかぬふ2023/01/29に更新@wint コメントありがとうございます！ また、参考になる意見をありがとうございます。この記事を書いた時に、なにか意見をいただけたりするといいなあ、という下心もあったりしたので、大変ありがたいです。 私の理解では、 Pricing -> Product、KioskPricing -> SKU（Product variant）に近い概念、と思っていました。 というのが、一般的なECの場合、例えば「トウカイテイオーTシャツ」みたいなものがProductで、これを選択するとProductからドリルダウンしてS、M、L、XLみたいなサイズをSKUで選ぶ、というような構成と思われます。 これについてチケット業界的な表現をすると、席種/券種という単純な2階層構造であればそう考えることもできて、例えば Product -> 「1月29日 第1公演 S席」（または「1月29日 第1公演」） SKU/Product variant -> 「S席おとな」「S席こども」（または「S席おとな」「S席こども」「A席おとな」「A席こども」） というような考え方ができると思います。 ただ、この時点で一つ課題があって、「S席おとな」「S席こども」は一見SKUのように見えるのですが、実際には「S席」という概念がSKUになっていて、S席おとな/S席こどもは金額を表現する概念ではあるが単独では在庫管理単位を意味しない、という事です。在庫と値付けに"ねじれ"があって、値付けの方が細かいんですよね（だから元々ProductではなくてPricingという言葉を選んだという背景もありました） これは、(1)Productに在庫をもたせるか、(2)Product variantの方に席種を入れてしまって、券種と同時に席種を購入するというビジネスロジックにするか、といった方法で解決できて、我々はこの事象の解決としては(2)を選んでいます。 （その意味で、KioskPricingについては、もうSKUとか在庫みたいな名前にしてしまうのもアリかなあという気がしています。ただ、既に管理ユーザーの人たち、少なくとも数百人ぐらいには「商品」という名前で説明してしまっていて、それが結構難しいところがあります。。。。。） 在庫管理で悩ましいのが、更に公演数を増やした時にどう考えるべきか、という事に課題があります。 具体的には、1月29日 第2公演、1月30日 第1公演、1月30日 第2公演、...などが増えた場合です。 我々が実際に登録しているデータでは、1つの施設の中の1つの展示群のチケットで SKUの単位では数万レコードを超えるものがあります。例えば、1日20コマぐらいあって、期間が60日ぐらいあって、チケットの種類が20種類あると20×60×20=24000SKUということです。 （このチケット20種類というのは、例えば大人、子供、障害者、優待A、優待B、グッズ付き大人、グッズ付き子供、グッズ付き障害者、....みたいなものによって構成されます） このSKUのレコード数が増えるのは、（スパースな行列を扱うようなやり方をしない限りは）原理的に避けられない事だと思っていますが、一方でProductのレコード数まで増やしてしまうと、例えば商品名みたいな概念を数万レコードでバラバラに管理するのか？というような課題があって、更新忘れとか名前の整合性誤りとか、そういった事が容易に想像されました。それで、商品名みたいなものはSKUに含めたくない（何らかの少数のマスタを参照する構成にしたい）というのがあります。 あと、より複雑な条件として、この場合に「公演を跨って販売可能数の上限がある場合」というものがあって、 ・各公演での在庫数はSKU/Product variant（KioskPricing）単位に従う ・特別なグッズ付きのため、公演全体での定量在庫がある というようなケースがあります。 つまり、「入場券、グッズ付き入場券」という2種類のチケットが全ての公演分存在していて、グッズ付き入場券は全公演を通して1000枚しか売ってはいけない、みたいな場合です。 これは、公演をまたいだ在庫管理が必要で、我々の仕組みではProduct（Pricing）の方に在庫をもたせて管理するという事をしています。 さて、これを踏まえてのgrouping_tagですが、きちんとマスタ化するとしたら、それは公演とか、あるいは一種の販売単位みたいな概念にあたると考えています。本質的にはProductとProduct variantの階層が1つでは足りないという事なのだと思っていて、Productの上か、ProductとProduct variantの間か、Product variantの下か、どこかに階層を増やした方が自然なのだろうと思っています。現状の仕組みでいうと、ProductとProduct variantの間が一番良いのではないかと思ってはいます。 ただ、その仕組にした場合、上述のように24000種類のSKU単位がある場合に、人間が3つの階層を適切に管理できるのか？という課題があります。 そもそも、現在の状態で、2つの階層構造でも管理をするのがそこそこ大変になっていて、これを3つに増やした時に一般的なユーザーが整合性を維持できるのか...？というのはすごく気になっています。 基本的には、24000種類みたいな大量のSKUは20×60×20みたいな組み合わせで生成されるものなので、組み合わせを適切に管理できればよいと思うのですが、これを丁寧に管理しようとするとテーブルが複数個増えるような気がしていて、逆に単純な販売案件でそこまでデータを登録しなければならないのか、といった課題が生じます。 おそらく、管理画面および入出力方法、特にインポート処理をめちゃくちゃわかりやすくする前提で、内部のデータ構造のみgrouping_tagを間の階層としてきちんとマスタ化して、利用者にはそれを感じさせないみたいな状態が解なのだろうと思っていますが、チケットシステム全体では在庫管理以外に大きな課題があって、まだそこまでは検討ができていません。 （ちなみに、パフォーマンスに関しても課題があって、正規化した場合にデータ取得等を最適化できるのか？というのがあるのですが、たぶんこれは"ちゃんと考えれば"正規化した方が早いんじゃないかなという気がしています。マスタデータの登録は遅くなる可能性がありますが。）
wint2023/02/14おお…、種数が24000種類のオーダーで存在するんですか…！なるほど、これは難しいですね…。 物理的な席をSKUにするのがメンタルモデルとしてシンプルかと思いきや、大人・子供があったり、別の物理的なグッズとの“セット販売”があったりなど、全然一筋縄では行かないんですねぇ…。席より小さそうな単位で言いますと、たとえば子供料金は無理矢理「割引き」概念にマッピングした上で、表示を工夫するくらいはできるかも知れません。ただ、 Product ないし Product variant を跨ぐ制約は、対応物が無さそうですね。やはりフルスクラッチに至るのは必然のようですね。一端が見えた気がします。 改めて、モデリングの現場感が非常にエキサイティングな記事でした。これからも健闘をお祈りしてます！
skport2023/02/11に更新大変興味深い記事をありがとうございます。「綺麗に負債を返済した」というお手本のような学びのないスライドでなく、失敗例を赤裸々に書いていらっしゃるのが好感を持てました。 （まとまった時間があるときにじっくり読みたい…） 返信を追加
Discussion
大変参考になる記録を共有いただいて、ありがとうござます！
事業ドメインへの理解が深まるにつれて、モデリングとの乖離に苦悩する姿が克明に浮びました…！
負債のメタファーのケーススタディーとして非常に学びになります。
ところで、 grouping tag という命名の困難についてですが、商品に名前を取られてしまってるという印象を受けました。そして pricing が商品種別ないし在庫保管単位の機能を持ってるとのことで、これは SKU に相当する様に見えました。
参考までに、 EC SaaS の Shopify では、 SKU のことを商品バリエーション (product variant) と呼び、それらをまとめた単位として商品 (product) と命名してたりします。一般に、商品ページ 1ページにまとめて表示される単位が product で、そこからドリルダウンして 1種別を選ぶのが SKU という理解でいました。
ref.
@wint
コメントありがとうございます！
また、参考になる意見をありがとうございます。この記事を書いた時に、なにか意見をいただけたりするといいなあ、という下心もあったりしたので、大変ありがたいです。
私の理解では、
Pricing -> Product、KioskPricing -> SKU（Product variant）に近い概念、と思っていました。
というのが、一般的なECの場合、例えば「トウカイテイオーTシャツ」みたいなものがProductで、これを選択するとProductからドリルダウンしてS、M、L、XLみたいなサイズをSKUで選ぶ、というような構成と思われます。
これについてチケット業界的な表現をすると、席種/券種という単純な2階層構造であればそう考えることもできて、例えば
Product -> 「1月29日 第1公演 S席」（または「1月29日 第1公演」）
SKU/Product variant -> 「S席おとな」「S席こども」（または「S席おとな」「S席こども」「A席おとな」「A席こども」）
というような考え方ができると思います。
ただ、この時点で一つ課題があって、「S席おとな」「S席こども」は一見SKUのように見えるのですが、実際には「S席」という概念がSKUになっていて、S席おとな/S席こどもは金額を表現する概念ではあるが単独では在庫管理単位を意味しない、という事です。在庫と値付けに"ねじれ"があって、値付けの方が細かいんですよね（だから元々ProductではなくてPricingという言葉を選んだという背景もありました）
これは、(1)Productに在庫をもたせるか、(2)Product variantの方に席種を入れてしまって、券種と同時に席種を購入するというビジネスロジックにするか、といった方法で解決できて、我々はこの事象の解決としては(2)を選んでいます。
（その意味で、KioskPricingについては、もうSKUとか在庫みたいな名前にしてしまうのもアリかなあという気がしています。ただ、既に管理ユーザーの人たち、少なくとも数百人ぐらいには「商品」という名前で説明してしまっていて、それが結構難しいところがあります。。。。。）
在庫管理で悩ましいのが、更に公演数を増やした時にどう考えるべきか、という事に課題があります。
具体的には、1月29日 第2公演、1月30日 第1公演、1月30日 第2公演、...などが増えた場合です。
我々が実際に登録しているデータでは、1つの施設の中の1つの展示群のチケットで SKUの単位では数万レコードを超えるものがあります。例えば、1日20コマぐらいあって、期間が60日ぐらいあって、チケットの種類が20種類あると20×60×20=24000SKUということです。
（このチケット20種類というのは、例えば大人、子供、障害者、優待A、優待B、グッズ付き大人、グッズ付き子供、グッズ付き障害者、....みたいなものによって構成されます）
このSKUのレコード数が増えるのは、（スパースな行列を扱うようなやり方をしない限りは）原理的に避けられない事だと思っていますが、一方でProductのレコード数まで増やしてしまうと、例えば商品名みたいな概念を数万レコードでバラバラに管理するのか？というような課題があって、更新忘れとか名前の整合性誤りとか、そういった事が容易に想像されました。それで、商品名みたいなものはSKUに含めたくない（何らかの少数のマスタを参照する構成にしたい）というのがあります。
あと、より複雑な条件として、この場合に「公演を跨って販売可能数の上限がある場合」というものがあって、
・各公演での在庫数はSKU/Product variant（KioskPricing）単位に従う
・特別なグッズ付きのため、公演全体での定量在庫がある
というようなケースがあります。
つまり、「入場券、グッズ付き入場券」という2種類のチケットが全ての公演分存在していて、グッズ付き入場券は全公演を通して1000枚しか売ってはいけない、みたいな場合です。
これは、公演をまたいだ在庫管理が必要で、我々の仕組みではProduct（Pricing）の方に在庫をもたせて管理するという事をしています。
さて、これを踏まえてのgrouping_tagですが、きちんとマスタ化するとしたら、それは公演とか、あるいは一種の販売単位みたいな概念にあたると考えています。本質的にはProductとProduct variantの階層が1つでは足りないという事なのだと思っていて、Productの上か、ProductとProduct variantの間か、Product variantの下か、どこかに階層を増やした方が自然なのだろうと思っています。現状の仕組みでいうと、ProductとProduct variantの間が一番良いのではないかと思ってはいます。
ただ、その仕組にした場合、上述のように24000種類のSKU単位がある場合に、人間が3つの階層を適切に管理できるのか？という課題があります。
そもそも、現在の状態で、2つの階層構造でも管理をするのがそこそこ大変になっていて、これを3つに増やした時に一般的なユーザーが整合性を維持できるのか...？というのはすごく気になっています。
基本的には、24000種類みたいな大量のSKUは20×60×20みたいな組み合わせで生成されるものなので、組み合わせを適切に管理できればよいと思うのですが、これを丁寧に管理しようとするとテーブルが複数個増えるような気がしていて、逆に単純な販売案件でそこまでデータを登録しなければならないのか、といった課題が生じます。
おそらく、管理画面および入出力方法、特にインポート処理をめちゃくちゃわかりやすくする前提で、内部のデータ構造のみgrouping_tagを間の階層としてきちんとマスタ化して、利用者にはそれを感じさせないみたいな状態が解なのだろうと思っていますが、チケットシステム全体では在庫管理以外に大きな課題があって、まだそこまでは検討ができていません。
（ちなみに、パフォーマンスに関しても課題があって、正規化した場合にデータ取得等を最適化できるのか？というのがあるのですが、たぶんこれは"ちゃんと考えれば"正規化した方が早いんじゃないかなという気がしています。マスタデータの登録は遅くなる可能性がありますが。）
おお…、種数が24000種類のオーダーで存在するんですか…！なるほど、これは難しいですね…。
物理的な席をSKUにするのがメンタルモデルとしてシンプルかと思いきや、大人・子供があったり、別の物理的なグッズとの“セット販売”があったりなど、全然一筋縄では行かないんですねぇ…。席より小さそうな単位で言いますと、たとえば子供料金は無理矢理「割引き」概念にマッピングした上で、表示を工夫するくらいはできるかも知れません。ただ、 Product ないし Product variant を跨ぐ制約は、対応物が無さそうですね。やはりフルスクラッチに至るのは必然のようですね。一端が見えた気がします。
改めて、モデリングの現場感が非常にエキサイティングな記事でした。これからも健闘をお祈りしてます！
大変興味深い記事をありがとうございます。「綺麗に負債を返済した」というお手本のような学びのないスライドでなく、失敗例を赤裸々に書いていらっしゃるのが好感を持てました。
（まとまった時間があるときにじっくり読みたい…）