電子商取引

電子商取引向けソフトウェア — 商品、価格、在庫のデータを保持し、インターネット経由で注文を受け付け、決済を行い、注文を実行部門へ引き渡すシステムです。引き渡し先は倉庫、配送、そして会計です。

通常のサイトとの違いは、ページではなく管理対象のオブジェクトを扱う点にあります。商品、価格、在庫、注文、支払い、出荷、返品 — いずれも自らの状態と履歴を持つレコードです。同じ注文が、アプリからも、自動販売機からも、担当者からも、マーケットプレイスからも入ってきます。

これはストアフロントそのものではなく、ストアフロントの上に載る管理の仕組みです。ストアフロントは、管理の仕組みを書き直すことなく、置き換えることも二つ目を追加することもできます。

システムの構成要素

• ストアフロント — 購入者向けの画面：サイト、モバイルアプリ、自動販売機のディスプレイ、セルフサービス端末
• データの中核 — 商品、カテゴリー、属性、価格、在庫、顧客、注文
• 業務ロジック — 価格、割引、商品の販売可否、配送料と税の計算に関するルール
• 処理レイヤー — 注文ステータス、引き当て、決済操作、出荷、返品
• 連携レイヤー — CRM、ERP、倉庫、レジ、決済サービスや物流サービスとのデータ交換
• 管理パネル — コンテンツ担当者、注文オペレーター、カテゴリー担当者の作業画面
• 分析 — 売上、ファネル、在庫、返品に関するデータの集約

自動化とは「販売員の代わりのロボット」ではなく、繰り返される操作をルールへ移し、システムがそれを自ら適用して結果を履歴に記録することです。

ルールは、その条件が変更されない限り有効であり続けます。統制は残ります：すべての自動処理には、実行者、時刻、変更前の値が記録として残ります。

自動処理へ移るもの：

• 商品の公開と販売停止
• ルールと値入率に基づく価格の再計算
• キャンペーンのスケジュールに沿った開始と終了
• プロモコードの確認と消し込み
• 注文に対する在庫の引き当て
• 注文ステータスの変更
• 代金の引き落としと返金
• 配送料の計算
• 出荷書類の作成
• 配送業者への注文の引き渡し
• 各段階での顧客への通知
• キャンセル後の商品の在庫への戻し入れ
• CRMおよびERPへのデータ連携
• レジでのレシートの記録
• レポートとデータマートの更新
• 在庫僅少の通知

価格 — は商品カードの一項目ではなく、問い合わせの時点でルールに従って計算された結果です。一つの商品に複数の価格が同時に存在し、システムが適用すべきものを選びます。

そのため、数千の商品カードで価格を直す必要はありません。ルールか基本の価格表を変更すれば足ります。

価格設定の層：

• 基本価格 — 会計システムから取り込むか、手で設定するもの
• 価格表 — 小売、卸売、パートナー向け、地域別
• 値入のルール — 仕入価格に対する割合または金額を、カテゴリー別・仕入先別に
• 個別価格 — 顧客セグメント別、または個々の契約に基づくもの
• 数量帯の価格表 — 注文数量に応じて価格が変わるもの
• 通貨と丸め — レートによる換算と、「きりのよい」単位への調整
• 税 — 品目ごとの税率、税込価格と税抜価格

価格の変更はすべて履歴に記録されます：誰が、いつ、どのルールで、変更前はいくらだったか。粗利のレポートや、争いのある注文の調査はこれに基づきます。

適用の順序

ルールは優先度に従って解決され、やみくもに合算されることはありません。品目の価格計算の標準的な順序は次のとおりです：

• 購入者に適用される価格表を判定する
• その価格表から品目の基本価格を取得する
• 数量に応じた数量帯の価格表を適用する
• 契約の個別条件を重ねる
• 最も優先度の高いキャンペーンを適用する
• キャンペーンと併用可能であればプロモコードを適用する
• ロイヤルティのポイントを付与・利用する
• 税と品目の合計を計算する

併用の可否は明示的に設定します：どの割引が重なり、どれが排他で、最低販売価格はいくらか。最低価格の制限があるため、それぞれは正しい複数の割引が重なって品目が赤字になることはありません。

カート — は注文の下書きです。購入者にも店舗にもまだ義務を生じさせていない品目の集まりです。中の商品は引き当てられておらず、価格も確定していないため、カートは開くたびに再計算されます。

再計算では四つのことを確認します：商品が販売中であること、倉庫に十分な在庫があること、価格が変わっていないこと、割引が有効であること。変更は代金が引き落とされた後ではなく、支払い前に購入者に示されます。

カートに求められること：

• 端末をまたいで保たれること — ブラウザで作ったカートが、ログイン後にアプリで開けること
• アカウントなしでも使えること — ゲストがすぐ注文を組み立てられ、ログインが必要なのは注文手続きの時だけであること
• ログイン時に統合されること — ゲストのカートが保存済みのカートを上書きせず、統合されること
• 制限を守ること — 最低金額、梱包単位の倍数、顧客ごとの数量制限
• 購入できないものを分けること — 販売停止になった品目や在庫切れの品目を別に出すこと
• 内訳を示すこと — 合計を、品目の金額、割引、配送料、税に分けて表示すること

注文 — は購入の内容、手続き時点の価格、購入者、配送と支払いの条件を確定させる書類です。以降、注文は限られた数のステータスに沿って進み、その遷移はすべて記録されます。

価格と割引は注文手続きの時点で確定します：価格の変更やキャンペーンの終了は、すでに作成された注文には影響しません — そうでなければ、請求額とレシートの金額が食い違ってしまいます。

注文手続きの流れ：

• カート：価格の再計算、購入可否と制限の確認
• 購入者の特定：ログイン、新規登録、またはアカウントなしでの手続き
• 配送の選択：住所、受取所、時間帯、料金の計算
• 支払い方法の選択とプロモコードの適用
• 注文品目に対する在庫の引き当て
• 注文と注文番号の作成、確認の送信
• 支払い、または受取時払いの確認
• 実行への引き渡し：ピッキング、出荷、配送

在庫 — は今この瞬間に販売できる商品の数量です。倉庫にある物理的な数量とは異なります：一部は注文のために引き当てられ、一部は輸送中、一部は不良品として保留されています。

販売可能数 = 物理在庫 − 引き当て − 保留 + 確定済みの輸送中の入荷（予約注文が許可されている場合）。

倉庫や店舗が複数ある場合、在庫は倉庫ごとに計算され、ストアフロントには、選ばれた地域へ配送できる倉庫の合計が表示されます。

データ交換の仕組み：

• 全件の連携 — 在庫一覧の全体を、通常は夜間に、スケジュールで送るもの
• 差分の交換 — 前回の同期以降の変更だけを、数分おきに送るもの
• イベント — 会計システムが、変更が起きたその時点で自ら知らせるもの
• メッセージのキュー — 倉庫やサイトが一時的に利用できなくても、交換が失われないようにするもの
• 競合の解決 — 値が食い違ったとき、どちらを正とするかをあらかじめ決めておくこと

引き当てには必ず有効期限があります：期限内に支払われなかった注文は、商品を販売可能な状態へ戻します — そうしないと、放置されたカートが利用可能な在庫をすべて「食べて」しまいます。

在庫を正しく管理すると得られること

• 購入者が、存在しない商品の注文をしてしまわない
• オペレーターが、キャンセルの電話に時間を取られない
• 店舗側の責任による返金処理が発生しない
• 仕入部門が、品目ごとの実際の消化速度を把握できる
• 予約注文と入荷待ちが、正直な期日で機能する
• 在庫回転のレポートが、信頼できるデータに基づく

不一致のよくある原因

• 実店舗での販売が、データ交換に間に合わなかった場合
• 放置されたカートから残った、期限のない引き当て
• 実際の入荷より遅れて倉庫に計上された返品
• 引き当てを再計算しないまま会計システムで行われた手修正
• 構成品の引き落とし設定が誤っているセット商品

倉庫担当者 — は商品を物理的に動かす人です。入荷を受け取り、棚へ置き、注文のために品目を取り出し、梱包した箱を配達員へ渡します。システムはこれらの行為を本人の申告からではなく知ります：どの操作もバーコードの読み取りで裏付けられます。

この違いは本質的です。リストの「完了」のチェックは意図を示すだけですが、読み取りは事実を示します：どの品番か、どの棚か、どの担当者か、秒単位でいつか。品番の打ち間違いは一か月後の棚卸しで表に出ますが、誤ったバーコードはアプリがそもそも受け付けません。

倉庫担当者がシフト中に行うこと：

• 入荷検品 — 納品書と入荷を一品目ずつ照合します。不足、品違い、不良は入荷の時点で記録され、仕入先へのクレームへ回ります。注文のピッキング時に初めて見つかる、ということがなくなります
• ラベル貼り — 読み取れるバーコードがない商品には、社内ラベルを印刷します。ラベルのない品目は倉庫に受け入れません
• 棚入れ — 商品の読み取りと棚の読み取りが両者を結び付けます：システムは、どこに何があるかを記憶します
• ピッキング — アプリが棚を回る経路を組み立てて案内します。各棚での読み取りが、正しい品目を正しい数量で取ったことを裏付けます
• 梱包 — 箱の中身は読み取りで確定します：読み取られていないものは箱に入っていません
• 出荷 — 箱は読み取りによって配達員へ引き渡され、その責任も同じ読み取りとともに移ります
• 移動と補充 — よく動く商品が手前にあるよう、棚から棚へ、保管区画からピッキング区画へ移します
• 棚卸し — 倉庫を止めずに棚ごとに数えます：棚は自分が数えられている間だけ止まります
• 引き落とし — 不良、破損、期限切れ：理由、写真、担当者を添えて

マイページ — は購入者が、オペレーターに連絡せずに自分のデータへアクセスできる場所です：注文、書類、住所、支払い方法、返品。マイページで解決した問い一つひとつが、サポートに入らずに済んだ電話です。

マイページは独自のデータを持ちません：オペレーターが管理パネルで見るのと同じオブジェクトを、その顧客のレコードだけ、その顧客に許された操作だけ表示します。

そこにあるもの：

• 注文の履歴 — 注文ごとの内容、金額、ステータス、書類、レシート
• 追跡 — 現在の実行段階と、配送業者の送り状番号
• 注文の再購入 — 過去の内容が、価格と在庫の確認を経てカートへ移されます
• 返金 — 理由を添えた品目単位の申請と、審査状況の追跡
• 住所と受取人 — 保存した配送先住所、連絡先、受取所
• 支払い方法 — 登録したカードはトークンとして保持され、番号は保管されません
• ポイントとステータス — ロイヤルティの残高、失効期限、利用できる提案
• 配信設定と同意 — 通知チャネルとデータ処理への同意。ワンクリックで撤回できます

法人のマイページ

B2Bではマイページはより複雑です：一つの組織に、権限の異なる複数の担当者がいます。購買担当が注文を組み立て、責任者が承認し、経理が締めの書類を受け取ります。注文は一つ、行為は分かれています。

• 一つの組織アカウントに複数の利用者
• 契約価格と、個別の支払い猶予条件
• 実行へ渡す前の注文の承認
• 書類の区画にある請求書、受領書、納品書
• 品番リストやファイルの読み込みによる注文

ログインと保護

ワンタイムコードまたはパスワードでのログイン、金銭や連絡先変更の操作での二要素認証、他人の端末を切断できるセッション記録。メールや電話番号の変更は、旧と新の両方で確認します。

連携 — は外部プログラムとの、取り決められたデータ交換です：何を、どの形式で、どれくらいの頻度で渡すのか、データを所有するのは誰か、障害時に何が起きるのか。

システムがつながる先：

• CRM — 顧客、問い合わせ、商談、個別価格や配信のためのセグメント
• ERPと会計システム — 品目マスタ、価格、売上計上の書類、相互決済
• WMSと倉庫 — 倉庫別の在庫、引き当て、ピッキング指示、返品の受け入れ
• レジと会計端末 — 販売と返金のレシート、実店舗とのデータ交換
• 決済事業者 — 与信、引き落とし、返金、突き合わせ用の台帳
• 配送業者 — 料金、スケジュール、送り状の作成、ステータス
• マーケットプレイス — 品揃えの連携、注文の受け取り、在庫の更新
• マーケティング — メールとメッセンジャーの配信、ウェブ解析、商品フィード

売上とお金

• 売上、注文件数、平均注文単価、一注文あたりの品目数
• 品目別・カテゴリー別の原価、粗利、粗利率
• 割引の影響：割引の総額と、割引ありとなしの売上
• 支払い方法の構成と、決済失敗の割合

商品と在庫

• 売上順位と、動きのない「死に筋」品目
• 在庫の回転と、需要を何日分まかなえるか
• 取りこぼした需要：在庫ゼロの商品への閲覧
• 結果が出なかった検索語 — 品揃えについての直接の手がかり

顧客と行動

• 新規と再購入の顧客、購入の頻度と最終購入からの経過
• 注文手続きのファネル：どこで注文が途切れるか — 配送、支払い、新規登録
• 放置されたカート：内容と金額
• 理由別・商品別・仕入先別の返品

スケーリングとは、作り直すことなく成長に耐える力です。増えるのは三つの量です：カタログの規模、同時に訪れる利用者の数、一時間あたりの注文件数。

カタログの限界は検索と絞り込みに、ピーク時の流入はページの配信に、注文の流量はデータベースと外部連携に現れます。対策もそれぞれ異なり、必要になった段階で導入します。

実務で使われる手法：

• キャッシュ — カタログのページと重い問い合わせの結果をキャッシュから返し、商品の変更イベントで更新します
• 検索の分離 — 検索インデックスを別に持ち、数十の属性による絞り込みが本体のデータベースに負荷をかけないようにします
• 読み取りと書き込みの分離 — ストアフロントはレプリカから読み、注文は本体のデータベースへ書き込みます
• 水平スケーリング — ロードバランサーの背後に複数のアプリケーションを置き、その数を負荷に応じて変えます
• キュー — 重い処理は裏側で実行し、注文手続きはそれを待ちません
• CDN — 画像と静的ファイルは、購入者に最も近い拠点から配信します
• モジュール化 — 検索、レコメンド、決済は、それぞれ独立してスケールし、更新できます

ピーク負荷の前に確認すること

• トップページではなく「カタログ → カート → 支払い」の流れの負荷試験
• 決済事業者や配送業者が利用できないときの挙動
• カタログ全体を再インデックスする速度
• バックアップからの復旧にかかる時間
• 外部システムの上限：ERPと倉庫が毎分いくつのリクエストに耐えるか

方向ごとの拡張

• 新しい販売チャネル：アプリ、自動販売機、マーケットプレイス、キオスク
• 新しい倉庫と受取所
• 新しい通貨、言語、法人
• 新しい販売形態：定期購入、予約注文、B2B契約