[ドメイン] Eコマース探究書: 注文書
Eコマースにおいて、最も重要なオブジェクトの一つである「注文書」について考察します。
ユーザーの多くの行動は、この「注文書」を中心に展開されます。
一方で、企業の視点から見ても、注文書は非常に重要なオブジェクトです。
その理由は、全て、またはほとんどの収益が注文書から生み出されるためです。
ノーコードのSaaSツールとしてコマース機能を開発する過程で、「注文書」をどのように構築していくかについて、これまでの経験や考えを整理してみたいと思います。
（なお、設計に関する正解を提示するものではなく、あくまで一個人の意見として見ていただけると幸いです。）
基本設計
注文書を設計する前に、まずどのような取引方式を採用するかを整理します。
購入方式
購入という行為については、以下のような様々な形態が存在します：
チームとして複数人で一緒に決済する場合
中古取引のように購入者と売り手が1対1で取引する場合
ブランド公式のウェブサイトで商品を販売する場合
クーパン（Coupang）のように複数の販売者が集うオープンプラットフォームの場合
購入方式に応じて、データの構造（深さや複雑さ）は異なります。
中古取引
最もシンプルな構造です。
商品ごとに異なる配送業者を考慮する必要はありません。
1つの注文書に1つの販売者と1つの商品情報だけを含めれば十分です。
中古取引または1対1取引というコアビジネスモデルが変わらない限り、注文書の構造もほとんど変更されることはありません。
専門モール
すべての商品が同じ配送会社を利用する場合、前述の「中古取引」と同様の構造に商品を追加する形になります。しかし、異なる配送会社や配送方式が選択される場合もあります。
配送方式については後述しますが、オンライン商品と実物商品を混ぜて注文するケースまで考慮する必要があります。
設計のポイント
したがって、構造としては以前と同様に「販売者（Seller）」を基準にまとめられていますが、さらに「配送」を基準にもう一度グループ化する必要があります。
オープンマーケット
最も複雑な構造を持つのがオープンマーケットです。
特徴
複数の販売者（Seller）が存在し、販売者ごとに異なる配送会社や配送方式が選択される可能性があります。
そのため、注文書の構造は次のように3段階でグループ化されます：
販売者（Seller）
最初にグループ化される基準です。
配送（Delivery）
各販売者ごとに配送方式や配送会社でさらに細分化されます。
個別商品（Products）
配送基準の下に具体的な商品情報が配置されます。
構造の複雑性
このような3段階構造を持つことで、データの深さや関係性が増し、非常に高い複雑性を持つ設計になります。
特に、異なる配送方式が混在した場合や複数商品が絡む場合、管理や処理ロジックも大幅に複雑化します。
その他
- ファンディング・チーム購入
ファンディングの場合、購入プロセスにおいて以下のようなポリシーを明確に定義する必要があります：
決済時点
決済はファンディング目標が達成されるまで保留される場合があります。
目標の種類
目標は数量、金額、またはプラットフォーム内の特定のポイントで設定されることがあります。
目標達成後のポリシー
目標が達成された場合や達成されなかった場合に対応する以下のポリシー：
決済
キャンセル
返金
交換
ファンディングでは、これらの要素がプロジェクトの成功やユーザー体験に直結するため、柔軟かつ明確な設計が求められます。
- サブスクリプション（定期購読）
定期配送ではないケース
サブスクリプションは主に支払い手段の登録などを含むプロセスが中心となり、取引対象は基本的に単一商品に限定されることが多いです。
このため、中古取引と似た構造を持つ傾向があります。
カート機能の不要性
場合によっては、中古取引と同様にカート機能を省略できる場合もあります。
特に単一商品が対象の場合、不要な操作を省略することでUXを向上させることが可能です。
商品の種類と配送
商品を分類する際、基準はさまざまありますが、プロセス上最も重要な基準は「配送の有無」です。これに基づき、以下の2種類に分類できます：
実物商品（Physical Goods）
オンライン商品（Digital Goods）
実物商品の配送方法
配送が必要な場合
通常の配送プロセスに従います。
ピックアップが可能な場合
配送とピックアップが共存する場合：配送会社ごとの分岐に「ピックアップ」というオプションを同じ階層に追加します。
ピックアップのみの場合：単一の販売者が複数の商品をまとめられるようにすれば対応できます。
商品オプションについて
注文書には商品に関する情報が必須ですが、その中でも特に商品オプションはフロントエンド開発で実装が難しい部分の一つです。
オプションの複雑性
「色が赤かどうか」「サイズがSかMか」だけの単純な選択肢に見えますが、実際には以下の複雑な課題があります：
オプションの組み合わせ管理
すべてのオプションの組み合わせを「同じ商品」として扱うことはできません。
各オプションの組み合わせは異なるユニークなデータとして認識されます。
SKU（Stock Keeping Unit）の管理
SKUは、すべての商品単位（ユニット）を個別に記録します。
つまり、オプションの組み合わせが存在する場合、それぞれ異なるデータとして取り扱う必要があります。
実例：カーテンの注文
オプション：色（10種類）、幅（10種類）、高さ（10種類）
組み合わせ：10 × 10 × 10 = 1000種類
これにより、実際には1000個の異なる商品データが生成されます。これを適切に管理し、ユーザーが選択したオプションに基づいて正確な商品情報を提供する設計が必要です。
ユーザー画面と管理画面での考慮事項
- ユーザー画面での処理
ユーザーに商品オプションを選択させる部分は比較的シンプルです。
すべてのオプションを選択した時点で、対応するSKUが確定されます。
バリデーション（Validation）
オプションの選択順序を強制するか、柔軟に許可するかを選択できます。
最終オプション選択時の在庫切れ: 即座にユーザーに通知し、選択できないようにする必要があります。
2. 管理画面（Admin）での複雑性
管理者が商品オプションと価格を設定する管理画面では、多くのポリシーを考慮する必要があります。
新しいオプションの追加/削除の例
例:
初期オプション: Color（色）
Red, Yellow → 組み合わせは2種類（SKU: Product Red, Product Yellow）
新しいオプションの追加: Size（サイズ）
S, Mが追加 → 組み合わせが4種類に増加
新たに生成されるSKU:
Product Red S, Product Yellow S
Product Red M, Product Yellow M
価格設定の課題
新しく生成された4つのSKUの価格をどのように設定すべきか？
初期化
すべての新しいオプションに対して価格を再設定。
手間はかかるものの、ユーザーに明確に通知すればメンテナンスがしやすい。
既存価格の引き継ぎ
既存のProduct RedやProduct Yellowの価格を継承。
新しいオプションは既存オプションの拡張とみなして同じ価格を適用。
どちらが正解かは一概に決められません。
管理画面では管理者の行動パターンを継続的に観察し、頻繁に発生する変化に基づいて設計を最適化する必要があります。
番外編: スナップショット (Snap!)
注文書には、購入した商品の詳細情報、決済情報、販売者情報が含まれますが、特に商品価格のように頻繁に変動するデータがあります。
商品データの変動要素
価格の変動
商品は流行の終了で値下がりすることもあれば、タイムセールやブラックフライデーで割引されることもあります。
価格には、消費者価格、供給価格、販売価格、割引価格など、さまざまな種類がありますが、販売価格は頻繁に変動します。
その他の細かい変更
ブランドのロゴ、商品名、画像などの細かい要素も変わることがあります。
スナップショットの重要性
こうした変更が頻繁に発生しても、新しい商品として扱うのは難しいです。
理由: ユーザーのレビューや有用なデータを引き継ぐことが難しくなるため。
解決策: 当時の情報をスナップショットとして保存
注文書には、変動しやすいがUI上で重要な情報を「当時の状態」で保存します。
これにより、ユーザーは購入時点の正確な履歴を確認でき、混乱を避けられます。
Discussion