前の記事で「古いシステムの作り直しは積極的にやりたい」と書いたので、実際にやった話を一つ書いておきます。一点ものの家具を数千点扱っている専門店の EC サイトを、ゼロから作り直した案件です。お客さまの名前は伏せています。
変えられなかったもの
最初に聞いた状況はこうでした。
- 商品管理は社内の FileMaker。かなり古いバージョン
- ショップは ASP のカートサービス、会社のサイトは WordPress で、ドメインも別々
- 商品をショップに載せるたびに、FileMaker から CSV を書き出して、ショップに取り込んでいた
- 店頭の家具には、旧ショップの URL の QR コードが印刷して貼ってある
FileMaker を新しくできれば話は早いんですが、社内の他の端末との互換性の問題で上げられない、とのこと。なので「FileMaker はそのまま」が前提です。こっちの都合で入れ替えてもらうのではなく、今あるものに合わせてつなぐことにしました。
検討した3つの案
- 今のショップと WordPress を API でつないで、見た目だけ一つにする — カートまわりを外から扱う制約がきつく、表示速度も思ったほど出なかったので見送り
- 別のショップサービスに引っ越す — 現実的ではあったんですが、数万枚ある商品写真の移し替えが手作業になる。FileMaker が古くて、API から写真を登録するのも難しい
- EC サイトをゼロから作る — データの取り込み口も、FileMaker からの受け口も、こっちの都合で設計できる
3 にしました。少し前なら選ばなかったと思いますが、AI を使った開発で、現実的な期間で作れるようになったので。6月に着手して、9月に公開しています。
古い FileMaker でできないこと
最初にやったのは、その FileMaker で何が使えて何が使えないかの確認です。
- 外から API でデータを読みに行く — 使えない。もっと新しいバージョンからの機能
- JSON を作る関数 — ない。文字列をつなげて自分で組み立てる
- 写真を文字列（Base64）にして送る — これも関数がない
- 写真を URL で公開して、こっちから取りに行く — 環境的に難しい
- FileMaker の側から HTTPS で外に送る — これはできる
外から取りに行くのは全滅で、FileMaker の側から送ってもらうのはできる。なので向きは「FileMaker → 新サイト」の一方通行にして、新サイト側に受け口の API を作りました。
商品データの送り方
FileMaker から商品の内容を JSON にして、新サイトに送ります。新サイト側は品番をキーにして、あれば更新、なければ新規登録。
JSON の関数がないので、FileMaker 側は文字列の連結で組み立てています。
"{" &
"\"customCode\":\"" & 商品::品番 & "\"," &
"\"name\":\"" & 商品::商品名 & "\"," &
"\"price\":" & 商品::価格 &
"}"
これは後でちゃんと痛い目を見ました。品番が数字だけの商品で、引用符なしの数値として届いて、書き込みに失敗する。受け口側で「品番は何が来ても文字列にする」と直しました。手で組み立てた JSON を受けるときは、型を信用しない方がいいです。
写真の送り方
家具は写真が命で、1商品に何枚もあります。ここが一番手間でした。
FileMaker の中の写真は、いったんファイルに書き出してから、そのファイルをそのまま送ってもらいます。新サイト側は受け取った時点で、長辺 1920px の WebP と、一覧用の 600×450 のサムネイルに変換して保存。
最初は「商品の写真を全部まとめて送って、入れ替える」作りにしていたんですが、写真の多い商品だと一度に送りきれない。そこで写真に 0 番、1 番、2 番…と番号を振って、「この番号の写真はこれ」と1枚ずつ管理する方式に変えました。こうすると、数枚ずつ何回かに分けて送っても、前に送った分は消えません。差し替えたいときも、その番号だけ送り直せば済みます。
途中で変えたこと
送信の方法そのものも、一度変えています。
最初は FileMaker に内蔵されている送信機能で組みました。ところが古いバージョンだと思ったように動かないところがあって、結局、FileMaker のサーバーに入っている curl コマンドで送る方式に切り替えました。組んだ翌日のことです。
curl なら、送る内容がそのままコマンドとして見えるので、「このコマンドを打ってみてください」「こう返ってきました」でやり取りできる。古い環境ほど、仕組みが単純な方が強いです。仕様書も、受け口ごとにコマンド例をそのまま貼る形にしました。
上書きしないもの
商品情報は FileMaker が正で、同期のたびに新サイト側を上書きします。ただ、一つだけ例外を作りました。
新サイトには、商品名と説明文を AI で読みやすく整える機能があります。これを使った商品が、次の同期で FileMaker の元の文章に戻ってしまうと困る。なので「AI で編集した」という印が付いている商品は、商品名と説明文だけ上書きしないようにしています。価格や在庫はいつも通り FileMaker の値が入ります。
「どっちが正か」を最初に決めて、例外は数えられる数にしておく。ここが曖昧だと、後で「直したはずなのに戻ってる」が起きます。
旧ショップの番号
旧ショップの商品番号と注文番号は、新しいデータにも残してあります。
- 旧ショップの商品 URL に来たアクセスは、その番号で照合して新しい商品ページに転送
- 店頭の QR コードも同じ仕組みで新しいページに飛ぶので、印刷し直さなくていい
- 注文の内容を FileMaker 側から取得する API は、新サイトの注文番号でも、旧ショップ時代の注文番号でも引ける
古いシステムの番号は、移行が終わったら要らなくなるように見えるんですが、だいたい後で使います。捨てない方がいいです。
公開してから
公開後に一つやらかしています。管理画面で商品を保存すると、写真の番号が消える不具合がありました。番号が消えると、FileMaker から「3番の写真を差し替え」と送られてきても、どれが3番か分からない。保存しても番号が残るように直して、消えてしまった分は復元するスクリプトを書いて戻しました。
FileMaker から CSV を書き出してショップに取り込む、という手作業はなくなって、今は FileMaker から送ればサイトに反映されます。ドメインを一つにまとめた効果が検索にどう出るかは、数ヶ月経たないと分からないので、分かったらまた書きます。
相談の入口
「この古いシステムは変えられないんだけど」という前提があっても、つなぎ方はだいたい何かあります。何が使えて何が使えないかを調べるところから一緒にやっているので、お問い合わせからどうぞ。都城・宮崎の事業者の方はこちらのご案内もあります。