このたび、楽天市場が大がかりなデータ更新の仕様変更を行ったように、ベストなデータ更新ははたしてどのようなものかということばかり考えて難しく難しくしているのは、結局は自分たちだということに気づく時期までは少し時間を要します。
なまじっか賢いSEたちは、きっちり在庫を更新したいとなり、無駄なSQL文やクエリが増える結果となります。現在、サーバー容量は大きくなり、通信速度も処理速度もかなり早くなった時代にはなおさらデータ更新に関しては、ミラーリング的な更新方法が一番シンプルで早いものになる場合が多いです。また、精度もそのほうがよっぽど良くデータ更新がされないゴミデータが蓄積するという最悪な結果もなくなります。データ更新は、ピンポイントに更新するというロジックを確立をするよりも、ALLデータを上書きするミラーリング式を私は総括するとおすすめいたします。
商品マスタ管理
文字数の制御など制御系は、出力時よりも入力時に制限をかけた方がよい
各モールで出品データにかけられている制御や制限は、アウトプット時に振り分け処理をするのではなく、オペレーターが使うI/Fのブラウザ内で、Javascriptなどで直接入力時にかける方がよいです。それは、アウトプット時に制限をかけると、オペレーターが制限の内容を把握できず的外れなデータを作ってしまうからです。オペレーターが制限を把握し、または、制限の変更を把握し、現場がその回避をノウハウにしてしまうようなものでないとシステムエンジニア側で理解し制御しても、いずれある仕様の変更を把握し、対応することすら難しい状況になります。つまり、メンテナンスも含め、現場が毎日、肌で触れなけばいけない状況を作る、すなわち、I/F側で制御する方が私は、良いと考えています。
出品データのアップロードは、現場に任せログを見てエラーを取り除く
各モールの出品データに対するログ、すなわちエラーに関しては現場によりデバッグをするほうがよいです。先ほども申し上げたように、現場オペレーターが理解し、デバッグを販売向上を見込まなければ、システム担当は、カスタムや開発に追われており、出品ログまでを把握し、メンテナンスをし続けるわけはいかないというのが現実でございます。現場が売上向上を目指し戦う場所であり、その現場が販売棚に関してきちんと整理整頓された品質のよいものが表示されているかどうかを確認することは当たり前のことでございます。システムの改良が必要な場合も、現場から担当SEに、我々の成績がおかげで下がったくらいのクレームを入れる気持ちで、SEの尻を叩きデバッグや改良の指示を出すような現場づくりが望ましいです。
楽天市場のSKU販売強化のためのカスタマイズについて
今回の大がかりなシステムの仕様変更は、私は改善だと判断しております。
Yahooショッピングの出品データを作成する と 楽天市場とでは、現在、多くの店が約2~10倍くらいの時間を要しているのではないでしょうか。ファイルを抽出したり、なめたりしながら、2つのファイルを紐づけながら作成するという処理は、多くのDBへの負担を要します。また、新規・更新・削除とファイルを分けて作成する必要があり、この新規を商品の登録時間と出品時間によるタイムスタンプの差分で作成できているシステムは多くないのではないだろうかと私は憶測しております。
当社は、この新規を出品ファイルとの差分で判断しておりますが、この判断に相当の時間を要するわけでございます。また、この新規ファイルはとても少数です。多くは更新という処理になるわけでございますが、この更新を妨げる要因にもなりかねない状況です。
出品データの更新は、すべて入れ替えると方法が総括すると一番シンプルな方法、データの入れ替えに到達される方は多いのではないでしょうか。ヤフーショッピングのように、ファイルを入れえるか更新するか追加するという更新方法は非常にありがたい更新方法であります。今回の変更は、SKUの対策は、すでに済んでいた当社は、ヤフーショッピングに似たこの更新方法の改善の方が私は、大きな改善であると理解しています。それにしても変更は、つまり、システムのカスタマイズはあまりしたくないものでございます。夏休みの宿題と同じもので、締め切りまじかにバタバタしており、GWを返上して現在作業をしているわけでございます。もちろん、私が設計図を書いているのは当たり前でございます。新フォーマットに関しての評価
新フォーマットに関しては、可もなく不可もなしだが、Yahooショッピングとアマゾンを足して2で割ったような、アマゾンに関しては、フィールドではなく、自由項目フィールドを設けて定数をデフォルトにすることにより詳細な商品説明ができるようにというのは、斬新なのか、それともDB化する方がよいのかは、今のところどうなのかはわからない。
楽天市場のよいところは、町の商店街のようなアットフォームな自由なショップ同士が競い合えるような環境をつくるというコンセプトから、一方、スマホアプリでは、アマゾンのような一つの商品情報に、ショップがぶら下がるようなコンテンツ構造で、ユーザーが価格を比べやすく買い物をしやすい、いつも間にか合理的なスーパーのようなモールになりかわってしまった。独自販売やメーカーとのタイアップ販売も拡大し、ショップは、敵なのか味方なのかわからないような状態になってしまったような気がします。
個人的には、メガショップとギガショップの差とメリットがイマイチ感じられないとselectファイルが廃止になり、Yahooショッピングのようにitem内に吸収されるのはよいが、選択肢の項目設定と実際の選択肢の設定の2か所で選択肢の項目設定は必要あるのか、そこはitemとselectファイルを合体しただけで、AI処理が入れられなかったことは隠せきれない。今回の変更は、コントロールフィールドの新規・更新がAI判断により楽天サーバー側で判断をしてもらえるということがメインになろうかと思いますが、それは、すでに苦労してでも各ショップは課題をクリアしてきたことであり、今更、その苦労を取り除いてもらえても、仕様を変更するショップは少ないのではないだろうか。つまり、新規・更新ファイルをくっつけてアップするだけになり、楽天の負担が増えただけという変更になりかねない。それよりもできるだけ、フィールド数を減らすことに注力をしたほうがよかったのではないか、結局、ファイルを足して、まだフィールド数が増えた感はあり、今回の変更は、いったい何の改善かということは正直なところまだわからない。