東京のEC担当、佐伯さんが、社員向けストアの注文受付を翌朝に控えているとします。机の上にあるジャケットの検品票では、Mの仕上がり身幅は五十三センチ。日本語の商品ページだけ、前年モデルの五十六センチを表示している。カートの品番は新モデルで合っていた。夕方には刺しゅうの発注枠を押さえる必要がある。佐伯さんは、日本語ページの表だけを差し替えて受付を始めるか、その品番を止めて他の商品を先に案内するか、決めなければならない。
Shopify MarketsとTranslate & Adapt、WooCommerceとWPML、Adobe Commerceのストアビューを比べるなら、最初に「同じ品番を選んだ人に、正しい版の寸法が届くか」を試すと判断しやすい。既存のShopifyの商品情報とテーマで表を管理できるなら、そのつながりをまず確認する。WordPressの運用チームが自分たちで翻訳と拡張機能を保守できるなら、WPMLで商品とバリエーションの関連を試す。Adobe Commerceでカタログの適用範囲を使い分けている組織は、ストアビュー別の上書きと既定値に注目する。どの方式でも、管理画面だけで終えず、日本語の入口から注文データまで同じテストを通す。
仕上がり寸法を商品データとして扱う
まず発注先が確認した仕様を手元に置く。商品コード、仕入先の型番、生地や型が変わった版、対象サイズ、採寸箇所、単位、許容差、適用ロットを確認する。身幅を平置きの脇下間で測る場合は、その方法が読んで分かるようにする。着る人の胸囲を測る案内が別にあるなら、同じ欄に並べて数字を比べるようには書かない。胸囲を基準にした推奨サイズを出すには、仕入先が確認した別の判断材料が必要だ。
同じMという表示でも、ユニセックスと別の型では実寸が異なる場合がある。色だけが異なる商品でも、別の工場や生地で製作した場合は、寸法の共用を前提にしない。表を選ぶ基準は、見た目のサイズ名より、注文で特定できる商品の識別子に置く。旧版と新版を同時に扱うなら、倉庫が区別できる単位まで記録する。倉庫に区別がつかないまま二つの表を掲載しても、購入者が自分の注文に対応する表を選ぶことはできない。
次に一枚の検品票から、変更の種類を分ける。身幅五十三センチという数値は、仕入先と担当者が確認した商品データとして持つ。日本語の列名、測り方、図の説明は表示用データとして別に管理する。日本語の表が欠けたときに受付を止めるか、承認済みの代替表示を使うかは、販売運用の判断として残す。測定値の変更と、用語の言い換えで、同じ人が同じ作業をするとは限らないからだ。
台帳には表の識別子と改訂番号を作る。たとえば外套J24の標準型は仕様表J24の第三版を参照し、別の型は別の表を参照する。日本語での表記を変えたときには、商品仕様を更新したのか、表示だけを直したのかが分かるようにする。画像で案内する場合も画像だけに採寸の意味を持たせず、仕上がり寸法と量り方は表または本文で確認できるようにする。ページの公開日時だけでは、どの表を使っていたのか分からないため、承認と切り替えの時刻も記録する。
| 運用方式 | 日本語ページで最初に試すこと | 残す証拠 | 保留にする条件 |
|---|---|---|---|
| Shopify MarketsとTranslate & Adapt | マーケットと日本語の経路を確かめ、テーマが読む寸法の項目を特定 | 招待の経路、実際の表示、カートのバリエーション、旧版が表示されないこと | アプリやテンプレートの代替表示が分からない |
| WooCommerceとWPML | 言語別の商品レコードとバリエーションの関連、寸法と翻訳の同期 | 翻訳と子商品の関連、項目の設定、更新後の日本語表示と注文SKU | インポートで表示やバリエーションが欠ける |
| Adobe Commerceのストアビュー | 商品属性の範囲と、日本語ビューでの既定値と上書き | 対象ビュー、属性設定、注文の子商品、切り戻しの結果 | 未承認の既定値を引き継ぐ、または他のビューに変更が及ぶ |
Shopifyでは日本語の入口とテーマの参照先を確認する
Shopifyの公式アプリ紹介には、Translate & Adaptで商品などのコンテンツを翻訳できることが記載されている。マーケットのドメインと言語の説明は、子マーケットが設定を継承する場合があることも説明している。社員への招待に使うリンクから試し、実際のマーケットと言語を確認する。ヘッダーが日本語でも、カートに進むまで同じ経路にいるとは限らない。以前の選択が保存されていないブラウザーでも試すと、初めて利用する人が見る状態を確認できる。
商品説明の中の寸法表、テーマが参照するメタフィールドのファイル、サイズ表アプリのポップアップは、画面では似た位置に見える。保守の方法はそれぞれ異なる。Shopifyのメタフィールド開発資料には、対応テーマでファイル参照型のメタフィールドを利用する方法がある。対象テーマがその項目を参照するか、商品全体で同じ表を出すのか、サイズや型を変えたときに表示が切り替わるのかを確かめる。アプリが独自に図を出す場合は、標準翻訳機能の説明だけで対応を判断しない。
担当者には、正しい日本語表を一度表示してもらったあと、テスト環境で意図的に項目を空にしてもらう。古い表、別言語の表、何も表示しない状態など、実際の動作を記録する。別言語の表を代替に使う提案なら、表の対象商品、数字、単位、採寸方法が同じかを点検し、日本語の説明がないことで選び方が曖昧にならないかも確認する。許容できる代替表示は、明示的に承認した版に限る。
テーマ更新時には、古いテンプレートから新しいテンプレートへ同じ商品を移した状態も試す。Shopifyのテーマ設定資料は、マーケット別のテーマ設定がどのように継承されるかを説明している。受け入れ試験では、未翻訳の箇所や古い寸法表が残っていないかも確認する。運用ではさらに、商品ページ以外の一覧、招待リンク、前回のカートから同じ品番を開く。特定のポップアップだけが古い画像を残すことも想定して、商品ページの更新と、実際に使われる表示を別々に確認する。
WPMLでは商品とバリエーションの関連を保守できるか
WPMLのWooCommerceの翻訳ガイドは、商品とバリエーションの翻訳手順を扱う。テーマ向けの多言語構造の解説によれば、異なる言語の商品は翻訳の関係で結ばれた別のレコードとして扱われる。日本語の商品レコードの識別子と、倉庫が使う品番を混同しない。テストでは親商品の関連と、MやLなどの子バリエーションをそれぞれ見て、注文データまで追う。
仕上がり寸法を同じ実物について共有するなら、元の値が変わったときに日本語側の数字がどう更新されるかを確認する。採寸の説明、図の代替テキスト、日本語特有の呼び方は、翻訳者が適切に管理できる項目として分ける。WPMLのカスタムフィールドの説明では、翻訳やコピーなどの設定が示されている。現場では、サイズ表がプラグイン専用の形式や画像の識別子の集まりで保存されていないかも見る。項目に名前が付いていても、どの情報をどの言語で描画するかは実装に依存する。
受け入れ試験には、元商品の一部だけが変わるインポートを入れる。たとえば二つの型に共通してMがある商品で、新しい仕入先が片方の型だけ身幅を変更する。日本語の画面で双方を選び、片方だけが更新されているか、選択肢を切り替えても説明と数値が同じ型を指しているかを確認する。続いてカートと注文の品番を比較する。管理者がバリエーションの並び順を変えても、表示が別の型にずれないことが必要だ。
障害が起きたときに誰が調べるかも決める。翻訳担当者は日本語が正しいかを確認できても、プラグインやインポートの同期を変更できないことがある。商品担当者、サイトの保守担当者、倉庫の受注データを見る人の連絡先を、変更記録のそばに置く。すでにWordPressを保守し、更新前に環境を分けて確認できる会社なら、この運用は比較しやすい。毎回プラグインの挙動を外部に聞く必要がある場合は、翻訳ができることとは別に、復旧にかかる時間を見積もる。
Adobe Commerceではストアビューの既定値まで見る
Adobeのカタログ管理の説明は、商品情報の翻訳を対象のストアビューで編集する手順を案内している。ストアのローカライズの説明では、インターフェースの地域設定と、商品名や説明などを翻訳する作業が分かれている。日本語のボタンが出ていても、仕上がり寸法が更新されているかは別に確認する。
まず現在の適用範囲を図にする。対象のウェブサイトとストア、そこに属する日本語ビュー、商品属性の範囲、実際に表を表示する部品の順にたどる。共通カタログで保持する寸法や子商品の識別子と、日本語ビューで上書きする説明を分ける。管理画面で変更する場合は、対象ビューを確認し、対応する商品項目で既定値を使っているのか、個別の値が入っているのかを見る。共有値が古いままなら、個別値を外したときに古い表が復活することがある。
Adobeの商品属性の説明では、コンフィギュラブル商品の選択肢に使うドロップダウン属性にはグローバル範囲が必要とされる。サイズの表示ラベルと、注文を構成する子商品を分けて検証する。画面を独自に実装している場合は、どのビューの値を取り、何をキーに寸法表を選ぶかを実際の環境で見る。運用側でキャッシュやインデックスを更新する手順があるなら、更新後に購入者側から再確認する。
日本語ビューで一つの説明を直したとき、別のビューの表示が変わらないことも実測する。作業前の上書き状態を記録し、検証環境で一項目だけ変更して、別のビューの同一商品を確認する。元に戻す手順では、適用範囲を取り違えず、同時に別の担当者が変えた在庫や価格を上書きしないことを確かめる。既存のカタログ運用でこの切り分けを日常的に行えるかが、機能表だけでは分からない評価点になる。
判断例一。旧版の身幅が残る商品をどう扱うか
検品票にある新型Mの五十三センチと、画面の旧型Mの五十六センチには三センチの差がある。どちらも平置きで同じ位置を測ったと仮定しても、新しい商品に古い値を当ててよいことにはならない。たとえば利用者が手持ちの上着の身幅五十四センチを基準にすると、旧表を見たときには二センチ広いと思う。新しい実物は逆に一センチ狭い。どちらが体に合うかを数字だけで断定できないが、購入者の比較が逆になるため、そのまま受付はできない。
佐伯さんは日本語の表を差し替える前に、古い値がどこから出ていたかを調べる。日本語ビューの画像だけが旧版だったなら、承認済みの新しい表を反映し、同じ図が商品説明や別の入口に残っていないかを見る。新モデルのMとLをそれぞれ選び、カートと試験注文から子商品の品番を取り出す。日本語の表示が別の型の表を参照する場合や、旧版の画面が残る場合には、この商品だけ受付を止める。他の商品に影響しないかも別の試験で確認する。
承認者には、仕様原稿、日本語の表示、選択したバリエーション、注文行を一つの記録として渡す。日本語の図が間に合わなくても、採寸の位置が承認済みの文章と表で明確に分かり、購入経路すべてで同じ数値を確認できるなら、その代替案を検討できる。測る箇所が文章だけでは特定できないときは、商品を保留したまま図を用意する。刺しゅうの枠が先に埋まりそうなら、予定を調整する判断も制作担当者と共有する。
判断例二。更新と切り戻しを別々に試す
次は別の想定だ。日本語ページに掲載した新しい表で、Mが五十三センチ、Lが五十六センチ、隣り合うサイズの差が三センチと確認できたとする。午後の更新でLの行だけ誤って五十三センチになれば、画面上の差はゼロになる。まず仕様台帳を見て、今回の更新がLの数値を変える作業だったのかを確認する。変更対象が列名だけなら、二つのサイズを同じ値にする理由はない。このような比較は、すべての数字を覚えていなくても異常を見つけやすい。
正しい版を切り戻すときには、直前という理由だけで選ばない。前日に撮った画面が旧型のものなら、戻しても現在の商品には合わない。現行の型と同じ版の承認済み記録を探し、そこから誤った項目だけを戻す。その版がなければ、受付停止を続けた上で供給元の仕様を再確認する。日本語の画面に正しいMとLが出て、同じ品番がカートに入り、他の言語の値が変わらないところまでを復旧の範囲にする。
検証の際は、商品の詳細ページの通常操作だけでなく、一覧から直接追加する操作と、以前に保存したカートも試す。新しいカートには正しい値が出ても、以前に選んだ商品の表示や案内が古いままのことがある。試験注文では識別子と処理時刻を控え、再現手順を残す。実際の注文が先に入っていた場合は、注文時の情報を保持し、影響のある品番と時間帯から候補を絞る。選んだサイズを自動変更せず、制作前に利用者の希望を確認する。
承認記録を次の担当者が使えるようにする
試験に使う商品は、通常サイズが二つ以上あり、同じサイズ名で別の型も選べるものが扱いやすい。試す前に、入口、言語、型、選択したサイズ、表の版、注文に届く子商品、表がないときの動作を書き出す。対象言語の担当者が画面を読み、別の担当者が仕様と注文を照合する。小規模な案件でも、入力した人と最終確認する人を分けると、見慣れた値をそのまま受け入れるのを防ぎやすい。
承認記録には管理画面の値だけでなく、購入者に見える画面も残す。スマートフォンで表の列が途中までしか見えない場合、単位や寸法の見出しが読めず、別の列と取り違えることがある。文字を拡大した状態と、キーボードでサイズ表を開閉する場合も見る。図を使うなら、どこからどこまで測るのかを文章でも示す。サイズを選び直した際に案内を再度開けることを確認し、直す必要があればテーマやアプリの保守担当に渡す。
記録を探す人が、仕様の更新と販売判断を区別できるようにする。どのファイルが元の承認資料か、ストアで参照する値はどの項目か、誰が販売を再開できるかを明記する。版番号だけでは商品や言語が分からないときは、仕入先の型番、対象のビュー、適用した日時を添える。日本語の確認に使ったデータは必要な範囲に絞り、実際の社員の住所などを試験の証跡に入れる必要はない。
複数の提案を同じ条件で見比べる
どの候補にも同じサンプルを渡し、担当者の説明だけでなく画面を使って実演してもらう。通常の表示、別の型への切り替え、日本語表を外したとき、承認済みの版への復旧の順に進める。最後にテスト注文で出荷担当が見る子商品を確認する。実演できなかった箇所は、機能が使えると採点せず、必要な環境と担当者を控えて次の確認事項にする。現行テーマ、利用中の拡張機能、商品を反映する経路が変われば、以前の実演だけでは判断できない。
比較では、何回表を差し替える予定かも考える。年度に一度しか変わらない制服と、色や仕入先が頻繁に変わる記念品では、同じ手順でも負担が違う。前者では、承認記録を手で維持しても、対象範囲を管理できるかもしれない。後者では、共通する数値を一か所で管理し、日本語の表示の変更と分けて承認できると、確認先を絞りやすい。かかる時間は仕様の受領から試験注文が通るまでを測り、代理の担当者でも同じ証跡を作れるかを見る。
例外が続く場合は、別の承認済み商品を同じ案内から選べるようにする方法もある。サイズ表が間に合わないジャケットの代わりに、もともと企画に含まれるサイズ選択の不要な品を選べるようにし、希望者はジャケットの復旧を待てる。案内する前に、同じ社員が重複して申し込めないか、在庫と配送の約束が正しいかを確認する。掲載を止めた商品が、古いリンクやカートから注文できないことも必要だ。
予定の前日までに連絡先と判断時刻を決める
採寸の仕様が遅れることは、翻訳の締切を延ばすだけでは解決しない。受注、制作、倉庫の締切を一枚の予定に並べ、どの時点で商品を保留にするか決めておく。たとえば、翌朝九時に社員向けの案内を送るなら、前日夕方までに検品票と現物が一致することを確認し、当日の送信前には購入経路からもう一度表示と注文の組み合わせを見る。確認が終わっていない場合は、該当する品番だけが案内から外れていることを、通知を送る人が確認する。
担当者が替わっても再開できるよう、画面の画像だけでなく、更新した項目名、参照元の版、確認した日時、残る例外を記録する。日本語の表を直した人と受付の再開を決める人が別なら、承認済みの情報がどこに置かれるかを共有する。たとえば倉庫は商品の識別子を確認できても、旧版の図を誰が取り下げるかは判断できない。サイトの運用担当者は図を取り下げられても、別ロットを同じ寸法で扱えるかを仕入先に確認する必要がある。
注文履歴に表示する情報も点検する。日本語ページの案内が修正されたあと、以前の注文の画面に最新の説明を出す構成では、購入時に何が見えていたかを後から読み取れないことがある。商品コード、当時の表の版、画面の記録を、必要な範囲で結び付けて残す。そうすれば、間違った表を見た可能性のある注文だけを確認できる。サポート窓口から利用者へ連絡するときにも、商品が止まっている理由と、今の注文に何を確認するかを説明できる。
店舗で試着できる企画では、オンラインの受付前に同じ型の試着サンプルを置くこともできる。その場合も試着品の型番とオンラインの子商品を照合する。展示品が旧年度の型で、注文が新版に切り替わっているなら、試着だけでは判断できない。試着を受け付ける場所と掲載ページの両方で最新版を指せることを確認し、差が見つかったら案内を一旦止める。運用の速さは、問題が起きたときに注文と現物を結び付け直せるかどうかでも評価する。
ストア運用を委託する場合も同じ試験を使う
商品制作とストア運用を一緒に任せる案を検討するなら、Giftpackのブランドストアも比較に入れられる。公式案内は、商品やストアのプレビューと、製作、在庫計画、配送の連携を説明している。日本語のサイズ表の細かな挙動は、対象商品のデモで確かめたい。佐伯さんが見せてほしいのは、今季の検品票を参照した日本語表、品番の一致する注文行、旧版が戻らない復旧手順の三つだ。そこまで確認できれば受付を始め、確認できなければ当該品番だけを保留して他の商品を案内できる。