SKUプロジェクトとは

SKUプロジェクトとは、SKU単位での商品登録・データを保持し、商品の探しやすさや選びやすさを改善する目的があります。変更点としては大きく分けて下記の3つになります。

①価格違い商品ページ

②単位価格の表示

③検索UIの改善

です。

突然ですが、Amazonはその実績も後押しして、とてもシンプルかつ分かりやすいUIであると評判で、なにかと参考にするのがAmazonという場合が多く感じます。そして今回はまさにそれって感じがしますね！

それでは、一つずつ掘り下げていきます。

一つの商品ページ内で入数や重さ違いなどの価格違いを表示できるようにし、魅力を伝えるための商品説明は残しつつ、

SKU単位でデータを管理して「見つけやすさ」を強化するプロジェクトです。

※ SKU (Stock Keeping Unit)とは、受発注や在庫管理をおこなう際の「最小の管理単位のこと。

変更点としては、大きくわけて3つあります。

①価格違い商品ページ

現在、楽天の商品ページは同一の商品の入数や重さなどの単位によって価格が異なる場合、商品ページを分ける必要があります。一つの品番に対して、価格が一つという状態なのですね。この商品ページを分けるという行為が必要なくなり、バリエーション（在庫別項目選択肢）の選択肢によってそれぞれの価格を持たせることが可能になる。これがひとつ目の変更点です。

例えば、ベッドのボックスシーツを売っているとします。

想定できるバリエーションとしては、柄とサイズです。柄による販売価格の違いはないケースが多いですが、（ある場合もあり）サイズに関してはシングル、セミダブル、ダブル、クイーン等、販売価格に違いがありますよね。

そのような違いをこれまでは、同じ商品なのに商品番号（商品URL）を分けて販売するか、もしくは〇〇をご選択の場合は、追加料金〇〇円です。と注意書きを入れて、受注情報から金額の修正を行ったりと、店舗側の負担が大きかった印象です。

今回のSKUプロジェクトにより、この面倒な作業も軽減されることになりますね。

ちなみに！

この選択肢に関しては、最大6個までつけることが可能のようです！

まだリリース前のため、想像の範囲を出ないのではっきりとは言えない部分ではあるのですが、プレゼント包装や熨斗などの追加料金が発生するものなんか分かりやすくできるのではないでしょうか？

現在はプレゼント包装や熨斗も、大体は項目選択肢で必要な場合はドロップダウンメニューから要・不要を選択してもらって、あとで店舗側で注文情報から金額の修正という形、もしくはプレゼント包装のみの商品ページを作成して、一緒にカートで決済してもらうといった形ををよく見ますが、

これらが自動で計算されるようになると、ユーザーもあとからのカートの時点でしっかりと決済額を確認できるので不安になることはない上に、店舗側としても確認事項や、メールを1通送る手間が省けるのではないでしょうか。できるとしたらかなり助かりますね！

②単位価格の表示

入数や重量によって商品価格が変更になるので、1つあたり1gあたりなどの単位によって価格がわかるように表示される。それがSKUプロジェクトふたつ目の変更点になります。

例えば、A店では500mlの水が24本で2,000円で販売されていて、B店では同じく500mlの水が36本入りで2,500円で売られているとします。ユーザーからすると条件が一緒なのであれば安い方を選択したいですよね。これをわざわざ電卓をたたく必要なく表示されるようになります。

入数が1つの場合は一つの単価がわざわざ表示されるのか、それともされないのかはまだわからないところです。

③検索UIの改善

そしてSKUプロジェクト最後の変更点が、検索UIの改善です。

まず、検索結果の一覧にバリエーションの表現が可能になります。サムネイル画像にこれだけあるよとバリエーション窓で見せなくとも出てくるようになります。

次に、例えば検索窓で「Tシャツ　ホワイト」と検索した場合、SKU単位での登録に変更になるため、ブラックで絞られた形で検索結果に表れます。そうです、ということは、、バリエーション毎に画像を準備し、登録する必要があるということです・・・(´・ω・｀)

ひとつ想定作業が出てきましたね。これは下手をすると追加撮影が必要な店舗さんも出てくるかもしれません。おそろしや。

こんな感じで主な変更点としては以上の3つになります。

そしてこちらのSKUプロジェクト、もちろん全店舗対応必須になります。

バリエーションなどそもそもないのだという店舗さんは、切替作業があまり発生しないかもしれませんが、RMSの商品編集画面などは否が応でも変わってしまいます。

では、次は内部的にはどのような変更がなされるかについてです。

内部的な（RMS的な）変更点

主な変更点として、

①　商品登録（編集）ページ

②　タグＩＤ

の2点があげられています。いや、タグIDは商品登録ページ内に存在するやないかーい！というツッコミはなしでお願いします。

まず、商品登録（編集）ページですが、SKUプロジェクトにより追加項目ができます。

それが以下の項目になります。

・SKU管理番号

登録必須の項目。

SKU管理番号は商品番号、商品管理番号と重複しても問題ないが、同一商品ページ内の複数SKUに対して同一のSKU管理番号を登録することは不可能。

SKU管理番号を設定する際は、英数字の他にハイフン(-)やアンダーバー(_)が利用可能。

SKU管理番号は、既存のSKUと重複することはできない。

1度登録を行うと変更不可の項目となる。新たな値で設定を行う場合は、SKUの再作成が必要となる。

楽天RMSから商品登録のバリエーション設定を開くと、バリエーション作成画面がある。そこにSKU管理番号の入力が必要となるが、入力方法は以下の2つに分かれる。

・SKU管理番号を自分で決めて入力する

・SKU管理番号を自動入力機能を使用し登録を行う。

→SKU管理番号を自動生成することができる機能で、その際入力されるSKU管理番号はSKU管理番号の上から順に「r-sku」＋「数字8桁」のルールで入力される。

例)

1番目のSKUのSKU管理番号

r-sku00000001

2番目のSKUのSKU管理番号

r-sku00000002

3番目のSKUのSKU管理番号

r-sku00000003

店舗で番号をしっかりと決めているのであれば、前者の「SKU管理番号を自分で決めて入力する」を選択するのが良いでしょう！

・システム連携用SKU番号

登録は任意の項目。

システム連携用SKU番号とは、外部在庫システムと在庫連携をを行う際に、システム連携用SKU番号に外部在庫システムのSKU番号を入力することで楽天のSKUデータと外部の在庫システムの連携が可能となる。

日本語の文字列も入力可能。

一括入力が可能。

・SKU倉庫指定

登録は任意の項目だが、指定をしなかった場合は自動的に初期値で設定される。

今までは項目選択肢別在庫ごとの倉庫指定は不可能だったが、今回のSKUプロジェクト移行後より、SKUごとでも商品ごとでも倉庫指定が可能となる。

定期購入商品を登録する場合は設定不可

・商品属性

必須・任意については登録する商品により異なる。

従来のタグIDに変わる入力方法。

これまではタグIDは7桁の数字で構成されていたが、SKUプロジェクト移行後からはレッド、ブルーやメーカー名などよりわかりやすい項目名となる。

商品ページに登録しているタグは基本的にSKUプロジェクト移行後は、商品属性へ自動返還されるが〇〇〜〇〇cmなど変換先の値が不明瞭なケースの場合は変換が行われない可能性がある。

・・・これは、伸縮可能な商品など扱っている店舗様にとっては大きな問題になる予感。。

SKUプロジェクトの移行日以降(店舗により移行タイミングは異なる)、必須項目を含めた商品属性の入力が必要となる。

以下のように一部についてはタグIDでの登録が継続される

・レンタルタグ

・販売条件ありタグ

・回線契約向けタグ

・各種イベントページ向けのタグ

・ふるさと納税関連タグ

・楽天Carタイヤ交換サービスタグ

これまで倉庫指定もページ単位でしたが、SKU単位でできるようになるみたいですね！

システム連携用SKU番号がどういった場面で必要になるかは、もっと勉強してからにします。

そして2つめはタグIDです。

タグIDといえば、全商品ディレクトリIDの下に潜んでいる登録項目です。

全商品ディレクトリIDをメイン属性とするなれば、タグIDはカラーなりサイズなりのサブの属性です。

いままでこれらは、9桁の番号で表示させていましたが、これがどうやら実際の値での入力になるようです。

例えばですが、カラーがホワイトで「111222333」という番号を入力していたのが、単純に「ホワイト」と登録することになる。ということです。

ただ、一部の販売方法や特定のサービスに関してはタグIDが継続されるものもあるそうなので、すべてがそうなるというわけではないのでご注意を！

ここを見る限りでも全商品に手を加えないといけないのでは・・・とちょっと冷や汗をかきますね。なんなら滝汗です。

SKUプロジェクトの懸念点

商品情報を全部修正しないといけないのでは・・・という見えない膨大な作業量に打ちひしがれる不安感・焦燥感もさることながら、その他にも懸念すべき点がでてきます。

それが、

・お気に入り

・レビュー

・ランキング

は、一体どうなってしまうのか。です。

今回のSKUプロジェクトで、これまでバリエーションにより価格で分かれてしまったページたちを統合することになるでしょう。

そうなった場合、

・各ページのお気に入りはどうなってしまうのか・・・

・各ページについているユーザーからのレビューはどのようになってしまうのか・・・

・分かれていたバリエーションのページのひとつがランキングを取っているが、それはどうなってしまうのか・・・

という疑問が発生します。

これらのお気に入り、レビュー、ランキングについては、「商品ページ毎の粒度」としているので、あまり影響はないと発表されています。

要は、親の商品番号があって、SKUは親に対して紐づいてるものだから、SKUである子商品が親に回帰して商品ページが統合されたとしても、

今ユーザーが登録しているであろうお気に入り登録も商品ページ単位で残るし（SKU管理番号なるものがあるので、それに紐づくかもしれないですね）、

レビューも親商品ページに統合されて、どのSKUに対してのレビューだというのは別途表示されるからOKだし、

ランキングも商品ページ単位で計測されるので問題ないでしょう！

ということらしいのです。

といっても、そうは問屋が卸さないって状況になるのではないかなとちょっと疑ったりもしています。

例えば、同一商品であるにも関わらず商品番号を変更して販売している場合には果たして商品ページを統合することができるのかどうか・・。

まさかそれが無視されるということはないでしょうが、なにかしら申請等がいりそうな気もしています。（これも想像の範囲を出ないので聞き流してください…）

こういったケースを含め、他にもいろいろ問題点が発生してくるのではないかと思います。店舗さん毎に色んな運営方法がありますから、その分だけなにかしらが出てきそう…。

早めに想定して、こういった場合はどのようにすればよいかなど、追い込まれて爆発炎上する前にイメージだけでも持っておいた方がよいでしょう。そして楽天に問合せです。こちらが爆発炎上するまえに楽天のコールセンターさんが爆発炎上しそうな気もします・・・。さて、爆発炎上と何回言ったでしょう。

そしてなにより一番恐ろしいと思っているのが、クロスモールやネクストエンジンなどのベンダー製品を使用している場合です。

さらには在庫情報のみならず商品情報までガチガチに連携しちゃってる場合が一番こわいです。ベンダー側がどこまで対応してくれるかによっても対応範囲が異なってくるでしょうから、見えない敵に臆している状態ではありますが、きっとなかなか骨のおれる作業が待っているのではないかと想定します。

SKUプロジェクトさん…場合によっては要件定義からがっちり進めないといけない強敵になりそうです。

ちなみに弊社のクライアントはネクストエンジンが圧倒的に多いのでこの場を借りてお知らせですが、ネクストエンジンがSKUプロジェクトに対応するのが、2023年4～5月だそうです。（予定）

【特報】

■ランキング

ランキングの表示は、SKUプロジェクト後からは1ページ内に含まれる全SKUの総合評価をもとに「商品ページごと」のランキングを作成する。

検索結果・ランキングで表示される価格については、SKUの中で価格が異なる場合最安値のSKUが表示される

レビューはSKUプロジェクト移行時に商品レビュー移行申請を行うことでレビューの移行・複数ページで管理していたレビューの統合が可能となる！ (2023年2月1日発表)

すばらしい(ぱちぱち)

<商品レビュー移行申請の際に気をつけること＞

①    結合したいSKUで、ジャンルID（＝全商品ジャンルID）が一致する

②    結合したいSKUで、両方にカタログIDの値が入っている場合、カタログIDが一致する

③   移行先商品ページのSKUに、必須商品属性が入力されている

移行先の商品がまとめOKのSKUであること

商品レビュー移行申請については指定のエクセルファイルをダウンロードの上、以下の情報を入力する

・店舗URL

・移行元商品管理番号

・移行元SKU管理番号

・移行先商品管理番号

・移行先SKU管理番号

申請については、RMS上から申請可能となります。

※申請後の申請取り消しは不可能

※申請の審査完了まで、再申請・追加申請は不可能

※移行完了後、申請を行い結合したレビューの削除は不可能

SKUプロジェクトの移行時期について

移行時期の決定方法

SKUプロジェクトの移行時期については、「RMS店舗様向け情報」に移行時期を知らせる内容が届いていると思います。まだ確認できていない店舗さんは急いでください！もし忘れたらえらいこっちゃです！！

その内容を開くと、移行時期は2023年7月～8月ですよ～、という仮決定の期間が書いてあります。その仮決定の期間に問題がないと判断した場合はそのままでOKですが、問題がある場合は、変更申請が必要になります。変更申請の時期は、2022年11月30日までです！！ちなみにこんな時期からいうのもなんなんですが、こちら先着順になっているので、希望の変更時期がとれない可能性もなきにしもあらずなのです。なので今からでも確認を！！

ちなみにベンダー製品を使用している場合、SKUプロジェクトの移行時期については利用有無を考慮してくれます。ベンダー側が対応できていませんというケースがありますので。

なので、

・ベンダーがSKUプロジェクトに対応する時期

・店舗側での移行作業の工数

それぞれを加味した上で移行時期は決定しておいた方がいいでしょう。スケジュールを制するものがゲームを制します。

移行日の決定方法

移行時期のときと同じく、「RMS店舗様向け情報」に2023年1月以降に順次案内が届きます。

その案内の内容の移行日をよしとする場合は対応なしでOKですが、変更が必要な場合は同じく変更申請が必要になります。移行時期と同じく変更申請の締め切りと上限が必ずあると思いますので、早めの確認をしましょう！！

本格的な移行開始は2023年4月から、事前に対応時期を決定した店舗から順に変更されていく形になります。

なので、とくにベンダー製品を使用せずにRMSで全て管理している店舗から順次といった形になると思います。

というか、もう半年後に迫っていますね・・・お、お、お、おそろしいです。

今のうちから自店舗の商品情報を再度確認して、対応の準備をしていくのをおススメします。不明点を早い段階で払拭しておきたいですね！

以降、わかったことがあれば、私もこの記事を更新していきます。

アプロ総研で代行作業行います！

SKUプロジェクトの移行への対応、これをみるだけでもかなり工数のかかる作業になるのではないかと想定できます。

・全商品ページの修正

・ベンダー製品への対応

・他プラットフォームとの連携

・CSV変更点の把握

etc、、、

なにより一番はこれまでのルールをどのように変更するか、変更せずに以降することが可能なのか、どのように進めていくのか。

の、設計の部分になりそうです。作業まで落とし込めればあとはやるだけですが、ここの部分が一番時間がかかり頭を悩ませる難しいところです。

アプロ総研では、現在の店舗商品情報や運営方法をヒアリング・相談して、SKUプロジェクトへの移行作業を代行することが可能です。

何から始めればいいのかわからない店舗さんや、対応範囲が多くて困っている店舗さんは、是非一度アプロ総研にご相談ください。

相談は無料です。お見積りは、商談のちに改めて提出させていただきます。まずはお気軽にご相談くださいね！！！！

まとめ

多分、もっと掘り下げると、もっともっともっと懸念点が湧いてくるような、そんな予感がしています(´・ω・｀)

店舗側の対応を考えてしまうとちょっと未来が不安になってしまうのですが、SKUプロジェクト移行後は楽天の利便性が向上すると思うので、ちょっとわくわくもしますね！SKUプロジェクト移行後の楽天でお買い物をするのも楽しみです！

とにかく現段階では、想定されるであろう作業をまとめてSKUプロジェクト移行時期や移行日変更の対応を速やかに行って、来るべき日に向けて頑張って対応していきましょう。

ここまでお読みいただきありがとうございました！それではまたノシ

アプロ総研では、楽天市場の作業代行サービスを行っております。時間がない、担当者がいない等、お困り事がある方はお気軽にご相談ください！

相談・見積無料です　→　アプロ総研の楽天運用代行「らくらく運用プランα」