自社SaaSのShopifyアプリ化｜開発前に決める連携・配布・料金

自社SaaSをShopifyアプリとして提供するなら、まず「どのEC業務を助けるか」と「誰に使ってもらうか」を決めます。そのうえで、連携するデータ、初期設定、失敗時の対応、料金とサポートを整理すると、開発する範囲が見えてきます。

既存のSaaSに機能がそろっていても、ストアとの接続や日々の運用は別に設計する必要があります。この記事では、SaaSの事業・企画担当者が開発を依頼する前に決めておきたいことを説明します。

最初に解決するEC業務を一つ選ぶ

「Shopifyと連携できる」から一歩進めて、店舗担当者の作業を一つ選びます。たとえば「注文をCSVで書き出し、SaaSへ取り込み、結果を確認する作業」を対象にするなら、どの工程をアプリに任せ、どこに人の確認を残すかを決めます。

価値を確かめる基準も具体的にします。再入力が必要な箇所、処理できなかった注文を探す手間、担当者が確認する画面などです。削減時間や売上効果を先に約束せず、導入前の作業と、試行後の作業を比べられる形にします。

最初の対象業務が決まれば、SaaSのすべての機能をアプリへ持ち込む必要はありません。必要なデータを受け取り、店舗が結果を確認できる範囲から考えられます。以下の例も提供範囲を決めるための考え方であり、実装済みの事例ではありません。

既存顧客専用か、複数の事業者へ提供するか

配布方法は最初の利用社数だけでなく、今後の提供先も含めて選びます。特定の顧客向けの連携と、多くのShopify事業者が導入する製品では、必要な準備が変わります。

既存顧客が1社でも、独立した複数ストアに入れるならカスタム配布の条件を確認してください。Shopifyは、配布方法を選択した後の変更はできないと案内しています。「まずカスタムにし、後で設定だけ変えて一般提供する」という前提で進めないことが大切です。(配布方法と条件、配布方法の選択)

一方、公開アプリの通常表示と限定表示は後から切り替えられます。限定表示は審査のない別の配布方法ではありません。(App Storeの表示範囲)

必要なデータと、同期に失敗したときの扱いを決める

連携する項目は最初に選んだ業務から逆算します。注文を処理する例でも、氏名や住所まで必要な場合と、注文番号・商品・数量だけで足りる場合があります。将来使うかもしれないという理由で取得範囲を広げず、使い道を項目ごとに確認します。

同じ注文を再処理しても二重に処理しないことや、一方で更新された値を古い値で上書きしないことも検討します。店舗担当者に見せる状態は「接続済み」だけでなく、「どこまで反映できたか」「どの注文に確認が必要か」が分かるものにします。Shopifyもデータを同期するアプリには正確で一貫した連携を求めています。(App Storeの機能要件)

公開アプリで保護対象の顧客データを扱う場合は、利用申請・審査と、必要な保護措置を計画に含めます。氏名・住所・電話番号・メールアドレスには追加の要件があります。必要な範囲を絞ることは、説明する利用目的や保管範囲を明確にすることにもつながります。(保護対象顧客データの要件)

初期設定から日々の運用まで、担当を決める

初期設定ではどのストアをどのSaaS契約・拠点につなぐかを確認します。SaaSの契約者とShopifyの操作担当者が同じとは限りません。接続を許可する人、項目の対応を確認する人、実際の処理結果を確かめる人を分けて整理します。

たとえば、店舗担当者が接続先を選び、SaaS側の担当者が項目を確認し、アプリ運用担当者が同期エラーを調べる分担が考えられます。設定のどこで止まっているかを共有できれば、問い合わせを受けたときに確認先を判断できます。画面に表示する案内と、社内の対応手順をセットで用意します。

Shopify管理画面内にSaaSの画面を表示できただけで、App Storeの要件を満たすわけではありません。説明した機能が動くこと、Shopifyのデータや機能と連携すること、操作できるUIなどが求められます。既存画面をどこまで使えるかは、この利用の流れと要件に照らして判断します。(App Storeの要件)

料金・サポート・解約時の処理をまとめて考える

料金は、何に対して支払うのかを店舗が理解できる単位にします。店舗単位、処理量、利用する機能などの候補から、SaaS側の原価と店舗側の使い方に合うものを選びます。試用中に使える範囲、上限を超えた場合、プラン変更時の扱いも説明できるようにします。

App Storeで提供するアプリの利用料金は、原則としてShopifyが提供する課金の仕組みを使います。現行の公式案内では、新規公開アプリはShopify App Pricingが基本で、対応しない料金モデルなどにはBilling APIを使う方法があります。(アプリ課金の公式案内)

既存SaaSに契約や請求がある場合は、SaaS本体とShopifyアプリが提供する機能、料金に含まれる範囲を整理します。「既存契約があるからアプリ分も外部請求でよい」と決めつけず、現在の要件と個別の提供形態を確認してください。カスタム配布ではShopifyのアプリ課金を利用できないため、公開配布と同じ料金実装を前提にしません。(課金の掲載要件、配布方法ごとの制約)

サポートでは、接続できない、データが反映されない、請求が分からないといった問い合わせの窓口を決めます。一次受付、調査担当、対応時間帯を分け、店舗へ状況を伝える人も明確にします。SaaS側の障害とアプリ側の障害で、連絡先が分からなくならない案内が必要です。

解約時には、アプリのアンインストール、SaaS契約の終了、課金停止、保存データの削除がどう関係するかを説明します。連携を止める時点、処理途中の注文、残す記録、削除対象と担当を決め、再接続した場合に何が復元されるかも確認します。

App Store向けにはデータの収集・用途・保管などを説明するプライバシーポリシーと、データ開示・削除の通知への対応が必要です。通知対応は個人データを集めないアプリにも求められます。画面上の解約案内だけでなく、SaaS側の保管先やログも含めて扱いを設計します。(プライバシー要件、必須の通知対応)

小さく始める範囲と、次に広げる条件を決める

初期版は、対象業務、対象店舗、扱うデータ、同期する方向を絞ります。たとえば、新規注文をSaaSへ取り込み、結果をアプリで確認する範囲から始め、過去注文の取り込みや自動更新は必要性を見て追加する計画です。小さく始める場合も、採用した配布方法の審査・データ・課金要件は満たします。

次に広げる条件は機能数だけで決めないようにします。店舗が初期設定を終えられること、失敗した処理を見つけて復旧できること、問い合わせと解約に対応できることを、先に確かめます。一般提供を予定しているなら、最初の試行先を絞りつつ、公開配布の要件を前提に計画します。

自社で準備できるのは、解決する業務、最初の利用先、必要なデータ、既存SaaSの機能と契約、運用担当の一覧です。この材料があれば、使い回せる部分と新たに作る部分を検討できます。配布方法やデータの扱い、料金の整理から相談したい場合は、SaaSのShopifyアプリ化を相談する。