ブランドEC・プロダクトシステム
ジュエリーブランドを、運営と決済が続くプロダクトシステムへ
Halo.Project は、ブランドサイト、会員機能、決済からインタラクティブなツール、日々の運営まで、私たち自身で開発し運営しています。稼働から約2年になります。
課題
商品写真を公開するのは、ジュエリーブランド運営の入り口にすぎません。お客様には素材や設計への理解が必要で、運営側にはコンテンツ、会員、決済、注文、問い合わせ、例外への対応が求められます。機能の一覧だけでつくると、発送や対話の現場に合わず、運用の負担になりかねません。
制約
- 小規模ブランドでは、成熟したEC機能をすべて作り直すより、開発と保守のコストを抑える必要があります。
- オーダーメイドには選択、相談、手作業があり、標準的なカートの仕組みだけでは対応しきれません。
- 決済、会員、業務データは、成功するデモだけでなく例外にも対応できる必要があります。
取り組んだこと
成熟した取引機能はEC基盤に任せる
商品管理、決済などの既存機能はEasyStoreに任せ、独自性のある体験の開発に時間を使います。
見送った選択肢 カートと受注をすべて自作しても、税や決済、例外対応の保守に見合うブランドの優位性は生まれないためです。
独自性を生む流れは自社でつくる
体験ツール、会員向け機能、オーダーメイドの要件を自社Webとバックエンドで実装し、今後の改善余地を残しました。
見送った選択肢 すべてをECプラグインに合わせると、データや操作が外部の項目とリリース周期に制約されるため避けました。
バックエンド基盤を共有し、責任を分ける
Goのバックエンドで認証、データアクセス、デプロイの方式を共有しつつ、会員、体験、EC連携の責任を分けています。
見送った選択肢 理解しやすく、素早く修正できるシステムが必要だったため、初めから多数のマイクロサービスに分けることはしませんでした。
運用から優先順位を決める
問い合わせ、決済の例外、制作の手順を企画に直接反映し、取引を止める問題や手作業の負担から改善します。
見送った選択肢 継続運用を左右する課題は購入後にも多いため、店舗の目立つ機能だけを優先しませんでした。
成果
- 約2年間ブランドを運営し、Web、会員、決済連携が日々の実際の取引を支えています。
- 既存のEC機能と自社の体験サービスが、継続改善できるプロダクト基盤を構成しています。
- コンテンツ、決済、サポート、システム改善が同じ運用のフィードバックにつながっています。
技術
- Go
- Astro
- EasyStore
- 決済連携
振り返り
やり直すなら、機能ごとの運用仮説を早く定め、反応のない部分は早めに削ります。ソフトウェアの完成だけでは価値は生まれず、実際の運用で使い続けられる部分に価値があると、ブランド運営から学びました。