
Shopifyのメタフィールドを活用したカスタムアプリで受注生産専用のOMSを構築した話
目次
はじめに
Shopifyサイト構築支援という仕事をやってみて意外だったことの一つに、アパレル、ジュエリーブランドさんといった業態で、お客さんから注文を受けてから何ヶ月か時間をいただいて商品を作りお届けする、受注生産でビジネスを成り立たせている事業者さんが多いことがあります。
確かに量産して在庫を抱えた方が、商品一個あたりの製造コストは安くなるし、お客様の今すぐ商品が欲しいというニーズに応えることができます。
しかしながら、
・ブランド立ち上げの時点ではどれくらい売れるかよめないのでリスクを背負いたくない
・少人数で、ものづくりに集中したいので在庫リスクを背負いたくない
などの理由で、そういった事業者さんは受注生産という選択をしています。
もちろん受注生産ビジネスを成り立たせるためには、お客さんが「多少待ってでもあなたから買いたい」と思える商品力とブランド力が必要ですが、一定の利益率を保ちながら健やかにビジネスしていくことが可能です。
また、EUではアパレルの廃棄が禁止されることもあり、サステイナブルな社会を作るという意味ではとても好ましいものだと思います。
ユーザーペイン:受注生産に適したOMSがない
そういった事業者さんが抱えるペインの一つが、受注生産に適したOMS(Order Management System=受注管理システム)がないことです。
OMSとは、注文を受注してから発送までの業務を管理するシステムのことで、通常、在庫販売している商品はOMSで以下のような業務管理をしています。
- 注文に対する入金確認
- 注文に対して在庫を割り当てる
- 発送伝票の発行
- 発送済み通知の送付
受注生産の場合、上記とは異なり、以下のプロセスになります。
- 注文に対する入金確認
- 一定期間の受注を取りまとめ、商品を製造先に発注
- お客様が受注生産品を待っている間の不安を解消するためお客さんに製造を開始したことを連絡
- 製造先からの検収
- お客さんにそろそろ発送する旨を連絡(+配送日時指定などの確認)
- 発送伝票の発行
- 発送済み通知の送付
つまり、受注から発送の間に「生産管理」という工程が入るわけですが、世にあるOMSは基本的に在庫があるビジネスを前提にしているため、あるプロジェクトで受注生産専用のOMSをShopifyのカスタムアプリ(Shopifyに独自の機能を追加できる枠組み)で独自に構築する決断をしました。
運用しやすいアプリにするために 〜カスタムアプリ構築の方針〜
わたしたちの会社ではカスタムアプリ構築に際し、以下のような方針を持っています。
・開発工数を抑えるため既存のアプリでできることは既存のアプリにまかせ、構築した方が長期的に費用対効果が高い機能のみを構築する。
・データは原則としてアプリ側に持たず、Shopifyのメタオブジェクト、メタフィールド、注文タグなどShopify側に持たせることで、開発コストを節約すると同時に、高速で低コストなサーバーインフラ運用を可能にする。またそうすることで万が一アプリが止まったりした際でも、クライアント様のEC業務が止まらないようにする。
技術スタック
以下のような技術スタックで構築をしました。
サーバー:fly.io
選定理由:
- アプリのデプロイの容易さ
- 東京リージョンがあることにより、日本国内から利用した際の動作の高速さ
- Shopifyと通信するために必須である遅延処理のためのシステム(Redis)が無料でついてくるなどコストパフォーマンスが高い
ご参考:fly.ioの料金体系
リソース | 無料枠 | 有料枠 | 料金体系 |
---|---|---|---|
CPU | 3台の共有vCPUまで無料 | 専用vCPU | $0.0025/vCPU/時間 (約$1.80/月) |
メモリ | 3台で合計256MB | 追加メモリ | $0.0000005/MB/秒 (約$1.30/GB/月) |
ストレージ | 3GB | 追加ストレージ | $0.15/GB/月 |
帯域幅 | 160GB/月 | 追加帯域幅 | $0.10/GB |
IPv4アドレス | 共有IP | 専用IP | $2/月/IP |
PostgreSQL (Fly Postgres) | 無料枠なし | 小規模DB | 最小$5/月〜 |
Redis (Upstash) | 無料枠あり | 追加容量 | 使用量に応じて変動 |
主な特徴:
- Hobby Plan: 無料で3つのアプリ(各256MBまで)をホスティング可能
- スケールアップ/アウト: 必要に応じてリソースを増やせる従量課金制
- リージョン: 世界中の30以上のリージョンから選択可能
- 最低利用料金なし: 使った分だけ支払う
Rails特有の考慮点:
- Webアプリには最低512MB-1GBのメモリが推奨
- ワーカープロセス用に追加の小さなVMをデプロイすると効率的
- データベースは別のVMまたはマネージドサービスとして実行するのが一般的
フレームワーク:Ruby on Rails
選定理由:
- シンプルに慣れているから
- ちなみにShopifyの創業者のトビ氏はRailsのコアコミッターとしても有名。僕の中ではコードの書ける経営者ではなくスーパーエンジニアが経営もやっているイメージです。
メール送信:Sendgrid
選定理由:
- APIを通じて容易にメールを送ることが可能
システム概念図
大きくは以下のような機能を持つシステムを実装しました。
- メタオブジェクトをアプリで自動で作成し、生産委託先情報を管理する機能

メタオブジェクトを通じて生産委託先情報を登録することが可能。
- 商品データにその商品が受託生産かどうかの情報をメタフィールドを通じて登録し、かつ1で登録した委託先を紐づける機能

その商品が受託生産かどうかtrue/falseで登録し、1で登録した生産委託先と商品情報を紐づけることが可能です。
- お客様から受託生産の商品の注文があった際タグ付けする機能。それにより、Shopify上で受託生産品を含む注文を絞り込む機能

1と2で入力した内容をもとに受注生産の商品を含む注文があった際、注文にタグをつけることで、絞り込みを可能にしました。
- 注文に対して委託先に発注済みか、委託先から納品があったかtrue/falseで管理する機能。それがtrueになった際お客様に自動でメールで通知し、お客様の受託生産の注文を待っている間の不安を軽減する。

注文情報に対して、それぞれ生産委託先に発注したか、生産委託先から納品があったかを管理するフラグを立て、それぞれがYESになった際にお客様にメールを送る仕組みを構築しました。
- アプリの画面から特定の期間の委託生産の注文を品番別にまとめる機能を実装し、生産委託先への発注業務を効率的に行うことを可能にした。

アプリのダッシュボードから特定の期間の受注情報をCSVデータでダウンロードできるようにし、生産委託先への発注業務が楽になるようにした。
効果
ECビジネスで大事なのは売上ではなく、売上から費用を引いた利益です。
売上を上げることは他人を変えないといけませんが、費用を下げることは自分たちの行動でできます。
特にAIの発達により、お金よりも時間というリソースをどう使うかがビジネスの成否を分ける時代、このような効率化によりミスが減るだけでなく、ECに関わるスタッフの業務が楽になることでお客様との対話のための時間を生み出すことができると思います。
non-standard worldではこういったシステム構築をはじめとしたバックヤードの効率化のためのコンサル、カスタムアプリ構築も承っておりますので、こちらよりお問い合わせください。