既存のECパッケージからShopifyへ移行する案件では、見積もり金額の大半をカスタムアプリ開発が占めます。そしてその金額を左右するのは、技術的な難易度よりも「どの機能をShopifyに移し、どの機能を既存の外部システムに残すか」という分界の引き方です。これは開発上の選択に見えて、実際には事業者側の業務変更を伴う意思決定です。本記事は、基幹システムや会員基盤を持ったままShopifyへリプレイスを検討している事業者と、その要件整理を担う技術者に向けた内容です。
機能一覧を「標準／既存アプリ／カスタム」の三分類で棚卸しする
リプレイス案件の出発点は、既存システムの機能一覧です。当社ではこれを受け取ったら、まず全項目をShopify標準機能で賄えるもの、既存アプリで賄えるもの、カスタムアプリ開発が必要なものの三つに仕分けます。
このとき重要なのは、「カスタムアプリ開発」と明記されている項目よりも、実装方法が未確定のまま残っている項目のほうが金額への影響が大きいという点です。確定している項目は見積もれますが、未確定の項目は、確認結果次第で開発範囲が丸ごと動きます。したがって仕分けの成果物は見積書ではなく、まず「確認事項リスト」であるべきです。ここを飛ばして概算を出すと、前提の異なる金額が独り歩きします。
外部システムに残る機能が、そのままカスタム開発になる
会員認証、ポイント、クーポン、注文データの同期。これらを外部のID基盤や基幹システムが持ち続ける構成では、それぞれがそのままカスタムアプリの開発項目になります。Shopify標準機能や既存アプリは、外部システムを正とする前提で作られていないためです。
特に工数を読み違えやすいのがポイントです。「残高と履歴を表示するだけ」なら軽い機能ですが、本丸は付与と利用です。チェックアウトでポイントを値引きとして適用し、外部の残高を減算し、注文確定時に付与を連携し、キャンセルや返品時に取り消しを連携する。Shopifyのチェックアウトはポイント値引きをネイティブに持たないため、ここは相応の難度になります。見積もりの初期段階で「ポイント連携」と一行だけ書いてある場合、それが表示だけを指しているのか、付与・利用まで含むのかを必ず確認する必要があります。
「外部に残すか、Shopifyへ移すか」は業務変更の判断
クーポンを例に取ります。Shopifyの標準ディスカウント機能を使えば開発は不要です。しかしこれは、クーポンの発行と管理を外部システムからShopifyへ移すという業務上の変更を意味します。外部の会員基盤側からキャンペーンでクーポンを配布し続けたいのであれば、外部で発行したクーポンをShopifyのディスカウントへ同期する開発が必要になります。
つまり「開発不要」という結論は、事業者が業務の持ち方を変えることに合意して初めて成立します。開発側が勝手に「標準機能で足ります」と判断すると、後から「これまでのキャンペーン運用ができない」という話になり、追加開発として跳ね返ってきます。当社では、この種の項目については見積書の特記事項に前提を明記した上で、事業者側に業務移管の可否を確認するようにしています。
Shopifyの制約上そもそも実現できない機能を早期に特定する
機能一覧の中には、Shopifyの制約により実現不可能な項目が必ず紛れ込んでいます。代表例がカード情報の自社保持です。EC側でカード情報を直接管理することはPCI DSSの制約から原則できないため、決済代行側のカード保存機能へ寄せる方針に切り替える必要があります。
こうした項目は、工数を積むのではなく「対応不可」として見積書に特記し、代替手段を提示するのが正しい扱いです。実現不可能なものを曖昧に残したまま金額だけ積むと、後で必ず破綻します。
バッチ処理は個別に積まず、共通基盤として切り出す
外部システム連携が絡むリプレイスでは、日次の注文データ同期、商品情報の同期、各種CSVの入出力といったバッチ処理が大量に発生します。これらを機能ごとに個別に見積もると、実装時に定時実行の仕組みを何度も作ることになります。
当社では、定時実行の基盤を独立した項目として先に切り出し、その上に個別のバッチを載せる構成で見積もります。この構成にしておくと、後から特定のバッチがスコープから外れても土台が崩れず、逆にバッチが追加された場合の追加費用も説明しやすくなります。
資料に書かれていない仕様が、最大のリスク
リプレイス案件で最も怖いのは、複雑な機能ではなく、資料のどこにも書かれていない機能です。機能一覧に行が存在しない機能について、それが意図的なスコープ外なのか、単なる洗い出し漏れなのかは、資料を眺めていても判別できません。
当社では、既存資料を横断的に読み込んだ上で、断片的な言及しか見つからない機能を「仕様の空白」としてリスト化します。たとえば商品分類の説明に一行だけ出てくる名称、ポイントAPIの定数一覧にだけ存在するステータス値、管理画面のメニューには存在するが運用上は未使用とされている機能。これらは、既存パッケージの標準機能が使われずに残っているだけなのか、実際に稼働している業務があるのかで、対応要否がまったく変わります。
見つけた空白は、そのまま推測で見積もりに織り込むのではなく、確認事項として事業者に返します。「維持不要」という回答が得られればまとめてクローズでき、必要と分かればその時点で項目を追加すればよい。この扱いにしておくことで、確認が終わるまで見積もりへの影響を遮断できます。
まとめ
Shopifyリプレイスの見積もりは、機能の数を数える作業ではなく、Shopifyと既存システムの分界線をどこに引くかという設計作業です。当社では、機能一覧を三分類で棚卸しし、外部に残す機能をカスタム開発項目として明示し、実現不可能な項目は早期に特定し、バッチは共通基盤として切り出し、資料の空白は確認事項として遮断する。この手順を踏むことで、金額の根拠を事業者に説明できる見積もりになります。逆に言えば、分界線が決まっていない状態で出した金額は、必ず後から動きます。