Shopify構築の流れ｜要件定義〜公開の全ステップ

「Shopify構築を始めたいけど、何から決めればいいんだろう」。この段階で止まる方は少なくありません。

要件定義・設計・構築・テスト・公開。言葉としては分かっても、自分の案件がいまどこにいるか、次に何を決めればいいかは別の話です。

進行で迷うことの多くは、フェーズ間の境目で起きます。この記事では、Shopify構築を5つのフェーズに分け、各フェーズで決めること、抜けやすい論点を整理します。教科書通り順番には進まず、並行作業と後戻りが前提になる実態にも触れます。

つまずきやすい3つの落とし穴も先取りで載せているので、自分のプロジェクトを位置づけながら読み進められます。

1.全体像

1-1. 5つのフェーズと、各フェーズで決まること

Shopify構築は、要件定義・設計・構築・テスト・公開の5つのフェーズで進みます。「サイトを作る」と一言で言っても、実際は「決める→組み立てる→確かめる→公開する」と段階を踏む必要があり、それぞれが違う役割を担っています。

各フェーズが「なぜ必要か」と「具体的に何を決めるか」を順に整理します。

① 要件定義｜何ができれば運営が回るかを決める

ECサイトは見た目を整えるだけでなく、お店の運営全体を回す仕組みです。要件定義では、必要な機能だけでなく、業務フローや抜けやすい論点まで含めて言語化します。

このフェーズで曖昧にした論点は、設計・構築・テストの全フェーズに響いてきます。5つのなかで最も重い段階で、ここに時間を使うほどトータルでは早く仕上がります。

② 設計｜どう作るかを決める

要件で「何が必要か」が決まったら、次は「どう実現するか」を詰めます。

設計が甘いと、構築フェーズで「予定していた機能が実装できない」「データ構造を組み直す」といった手戻りが頻発します。

③ 構築｜設計を実物に組み上げる

テーマカスタマイズ、アプリの組み込み、外部システムとの連携を実際に手を動かして形にします。作業量は最も多い段階ですが、要件と設計がしっかりしていれば淡々と進む段階でもあります。

④ テスト｜本番運営に耐えるかを確認する

注文から出荷までの通しテスト、表示崩れや決済・速度のチェックを行います。ECサイトは決済・在庫・出荷が絡むため、公開後に不具合が出るとお客さまと取引先の両方に影響します。要件定義と並んで、軽視できないフェーズです。

⑤ 公開｜独自ドメインに切り替え、運用に乗せ始める

ドメインの切り替えと最終確認、運用フェーズへの移行までを終えます。作業量は少ないものの、切り替えタイミングや段取りを誤るとアクセスが止まることもある、段取りが命の段階です。

5つのフェーズの中で、特に時間をかけたいのは要件定義とテストの2つです。要件定義が曖昧なまま進めると、設計や構築の段階で手戻りが続きます。テストが甘いと、公開後にお客さまや業務にトラブルが出ます。後のフェーズで起きる問題の多くは、前のフェーズで詰め切れなかった部分が原因として現れます。

並行で進む場面もあります。デザインカンプを詰めながら、商品データの構造を別ラインで進める、という進行は珍しくありません。逆に、構築フェーズに入ってから業務フローの抜けに気づいて要件定義に戻ることもあります。フェーズの境目で「ここまで決まったか」を確認することが、後戻りを最小化する助けになります。

2.要件定義フェーズ

ECサイトはネット上のお店です。新しく実店舗を開くと考えてみると、「何を売るか」「どうお金を受け取るか」「商品をどう届けるか」「お客さまとどう関わるか」を決めずに開店する人はいないはずです。要件定義は、ECで言うところの「開店前の決め事」を、一つずつ言葉にしていく段階です。

この章を読み進めながら、自分のお店ならどうするかを手元のメモに書き出してください。読み終わったときに残ったメモが、次の設計フェーズに入るときの土台になります。

2-1. 機能要件で決めること｜商品・決済・配送・顧客対応

要件定義で最初に決めるのが機能要件です。「商品をどう並べるか」「どんな決済を受け付けるか」「商品をどう届けるか」「お客さまとどうやり取りするか」、この4つを一つずつ言葉にしていきます。

それぞれの軸で何を決めるかを見ていきます。

商品｜商品棚をどう作るか

取り扱う商品数、カテゴリの分け方、サイズや色のようなバリエーションの組み合わせ方を決めます。実店舗で言うと、商品棚をどう組み、何をどこに置くかを設計する作業に近いです。Shopifyではバリエーションを最大3軸まで設定でき、それぞれに在庫数・価格・商品コード・画像を別々に持たせられます。アパレルなら「色×サイズ」、食品なら「容量×フレーバー」のように、商品の特性に合わせて組みます。

決済｜会計の手段を決める

日本のECでは、クレジットカードに加えてコンビニ決済や後払い決済を使うお客さまが一定数います。クレジットカードはShopify Paymentsで手早く始められ、コンビニ決済や後払いはKOMOJUやPaidyのような決済サービスを追加して対応します。お客さまがどんな手段で会計したいかを考えて選びます。

配送｜商品をどうお届けするか

全国一律にするか、地域ごとに送料を変えるか。送料無料ラインを設けるか、設けるなら何円からか。商品の重さで送料を変えるか。これらの条件分岐は、Shopifyの管理画面で組めます。発送方法（ヤマト・佐川・ゆうパックなど）も、取扱商品と注文数の規模感から選びます。

顧客対応｜お客さまとどう関わるか

会員登録の有無、問い合わせフォームの項目、返品・交換のルール、再入荷通知メールの配信などを決めます。Shopifyではカゴ落ちメールなどの自動通知を設定できます。再入荷通知については、Shopアプリ経由の通知や外部アプリを使って実装するケースがあります。一方で、領収書や納品書を同梱したいといった日本特有の慣習に合わせる場合は、アプリの追加が必要になることもあります。

4つすべてを一度に作り込もうとすると、構築期間が伸びていきます。「公開時点で必須なもの」と「公開後に少しずつ追加していけるもの」を分けて進めるのが基本です。たとえば、決済手段は公開時点で揃えておきたい一方、ポイント制度や会員ランクのような顧客育成の仕組みは、公開後の運営状況を見ながら追加するケースが多く見られます。

2-2. 業務フローを想像する｜注文後に誰が何をするか

機能要件の次に詰めるのが、業務フローです。お客さまから注文が入ったあと、誰が・どのタイミングで・何をするか。この一連の動きを把握しておくことで、必要なアプリや人員体制が見えてきます。

実店舗に置き換えると分かりやすくなります。お店にお客さまが来て商品を選び、レジで会計をする。そのあとで在庫を補充したり、領収書を発行したり、お客さまからの問い合わせに対応したりと、目に見えない作業が連なっています。ECも同じです。注文ボタンが押されたあとに、お店の中で人が動いています。

主な流れは次の通りです。

注文数が少ないうちは、これらをすべて手作業で回せます。目安として、月の注文数が数百件規模になると、手作業のオペレーションが業務時間を圧迫し始めます。1000件前後になると、出荷自動化アプリや物流連携の検討が現実的になります。

このように一連の流れを把握しておくと「ここはアプリで自動化したほうがいい」「ここは人が見ないとダメ」といった判断ラインが整理されていきます。

2-3. 要件定義で抜けやすい論点｜会計・物流・カスタマーサポート

機能要件と業務フローを描いても、まだ抜けやすい領域が残ります。会計・物流・カスタマーサポートの3つです。後回しにすると、公開後に運営が詰まる原因になります。

会計｜売上データをどう経理処理するか

Shopifyで発生した売上を、freeeやマネーフォワードのような会計ソフトにどう連携するか。手入力で済ませるのか、連携アプリを入れて自動化するのか。月の注文数が増えるほど、手入力の負担は重くなります。領収書や納品書の発行ルールも、ここで決めておきます。

物流｜倉庫と配送の体制を決める

自社で在庫を管理するのか、物流倉庫に委託するのか。複数のモール（楽天・Amazonなど）も並行して運営する場合は、在庫の一元管理をどう実現するかが論点になります。物流体制が決まらないと、出荷オペレーションの設計が固まりません。

カスタマーサポート｜問い合わせ窓口の設計

問い合わせフォーム経由のメール対応、電話対応の有無、対応時間帯。誰が窓口を担うかも含めて決めておきます。お客さまからの問い合わせに迅速に対応できる体制がないと、レビューや評判に影響します。

この3領域は「サイト構築の話」と思われにくく、要件定義から漏れやすいのが共通点です。Raboに届く相談でも、公開直前になって「会計連携を考えていなかった」「倉庫が決まっていない」と慌てるケースがあります。

3.設計フェーズ

要件定義で「何が必要か」が固まったら、設計フェーズで「どう作るか」を詰めていきます。実店舗で言えば、内装の図面を引き、商品の陳列棚を設計し、レジカウンターをどこに置くかを決める段階です。

この章では、ページ構成とデザイン、商品データの構造、機能の実現手段の3つの順に、設計で決めることを整理します。

3-1. ページ構成と見た目を決める

設計フェーズでまず取り組むのが、ページ構成とデザインの方向性です。どのページを用意し、どんな順番でお客さまに見せるか。ブランドの世界観をどう表現するか。サイトの骨格を決める作業です。

Shopifyの一般的なECサイトで必要なページは次のようなものです。

ページが決まったら、お客さまがトップから商品ページまでどう辿るか、回遊導線を設計します。実店舗で言えば、入口から商品棚、レジまでの動線を決める作業に近いです。

デザインの方向性は、テーマ選びと並行して決めます。Shopifyには無料・有料あわせて多数のテーマがあり、業種や雰囲気に合わせて選べます。テーマで賄える表現と、カスタムが必要な表現を切り分けることも、この段階で見えてきます。

日本のECでは、購入の多くがスマートフォンから発生します。PC画面で美しくても、スマホで操作しにくいサイトは購入に至りません。デザインカンプもスマホ画面から作り始めるのが、最近の主流です。

ページ構成とデザインが固まると、「どんなお店になるか」のイメージが具体化します。次は、その中に置く商品をどう構造化するかを決めていきます。

3-2. 商品データを構造化する｜バリエーション・カテゴリ・属性

商品データの構造は、設計フェーズで一番慎重に決めるべき領域です。一度組んだ構造を後から大きく変えると、運用負担と修正コストの両方が膨らみます。

商品データの構造で決めることは、主に3つです。

バリエーション軸の設計

Shopifyではバリエーションを最大3軸まで設定でき、各軸に在庫・価格・SKU・画像を個別に持たせられます。アパレルなら「色×サイズ」、食品なら「容量×フレーバー」、雑貨なら「色×素材」のように、商品の特性に合わせて軸を決めます。3軸では足りない場合は、メタフィールドというShopifyの拡張領域を使うか、アプリで補う判断になります。

カテゴリ階層とコレクション設計

Shopifyにはカテゴリの代わりに「コレクション」という仕組みがあり、商品をまとめて表示できます。「新着」「セール」「ブランド別」「シーン別」など、お客さまがどう探すかを想像しながら設計します。

商品属性（メタフィールド）の使いどころ

標準のフィールドだけでは表現しきれない属性（素材・原産地・賞味期限など）を、メタフィールドとして追加できます。お客さまにとって判断材料になる情報は、メタフィールドで構造的に持たせておくと、検索やフィルタにも活かせます。

Shopifyの強みの一つが、CSV一括処理の使い勝手です。商品数が増えても、CSVで一気に登録・更新できます。ただし、バリエーション軸やコレクションの命名がブレていると、CSVの整理に時間がかかります。命名ルールは設計段階で決めておくのが基本です。

商品データの構造が固まると、商品を追加するときの作業が定型化します。設計の手間は最初に集中させて、運用フェーズを楽にする発想です。

3-3. 機能ごとに、標準・アプリ・カスタムを振り分ける

要件定義で挙げた機能を、Shopify標準で済むもの・アプリで足すもの・カスタム開発が必要なものに振り分けます。この振り分けを誤ると、構築フェーズで「実装できない」「コストが想定外に膨らむ」といった問題が出てきます。

Shopify標準で済む例

・在庫の自動減算と売り切れ時の非表示

・配送料の地域別・金額別・重量別の条件設定

・再入荷通知メール・カゴ落ちメール

・Shopify Paymentsによるクレジットカード決済

アプリで足すのが一般的な例

・送り状の発行（B2クラウド・e飛伝などとの連携）

・サブスクリプション機能

・ポイント制度・会員ランク

・複数モール（楽天・Amazonなど）との在庫一元管理

・会計ソフトへのデータ連携

カスタム開発が必要になる場面

既存のアプリでは要件を満たせない、独自の業務ロジックを組み込みたい、特殊な外部システムと連携したい、といった場合はカスタム開発の検討に入ります。開発費用が一気に上がるため、本当にカスタムが必要かは要件に立ち返って吟味します。

「アプリを足せばできる」と判断する前に、テーマで賄える機能かを確認するのが先です。商品レビューの表示エリア、FAQのアコーディオン、サイズガイドのモーダル表示など、テーマ側で対応できることもあります。アプリは月額が積み上がるため、テーマで済むなら運用コストを抑えられます。

機能ごとの振り分けが終わると、構築フェーズで何を作り、何を組み込むかが明確になります。次はいよいよ、実物を組み上げていく段階です。

4.構築・実装フェーズ

構築フェーズは、要件定義と設計で決めたものを、実際に動くサイトとして組み上げる段階です。実店舗で言えば、内装工事を進め、商品棚を設置し、レジを組み立てる作業に当たります。

この章では、テーマカスタマイズ・アプリの組み込み・外部システム連携の3つの順に、構築で進めることを整理します。

4-1. テーマカスタマイズ｜デザインを動く画面に

構築フェーズで最初に進めるのが、テーマのカスタマイズです。設計フェーズで作ったデザインカンプをもとに、Shopifyのテーマを編集して、ブランドに沿った画面に仕上げていきます。

Shopifyのテーマは、無料テーマと有料テーマの両方があります。Shopifyには公式の無料テーマと有料テーマがあり、業種や雰囲気に合わせて選べます。有料テーマは1点3〜5万円程度で買い切れるものが中心です。

カスタマイズの粒度には幅があります。

要件と予算に応じて、どのレベルまでカスタマイズするかを決めます。デザインカンプ通りに細かく作り込むほど、工数とコストが上がります。

構築フェーズで時間が伸びる典型パターンが、レビューの繰り返しです。「もう少し色を濃く」「ボタンの位置を変えたい」といった細かい修正が積み重なると、想定外の工数を生みます。レビュー回数の上限を事前に決めておく、フィードバックは溜めて一度に出すといった工夫で、進行を安定させます。

テーマのカスタマイズが進むと、サイトの見た目が固まってきます。次は、機能を担うアプリの組み込みに入ります。

4-2. アプリの組み込みと設定

要件定義と設計で選定したアプリを、実際に動く状態にするまでの工程です。アプリは入れただけでは機能せず、設定を一つひとつ埋めていく作業が必要になります。

アプリの組み込みは、ある程度の順序を意識して進めます。決済→出荷→マーケといった依存関係に沿って入れていくのが一般的です。先に入れたアプリの設定が、後から入れるアプリの動作に影響することがあるため、順序を考えずに入れると後戻りが発生します。

各アプリには、設定項目が多数あります。たとえば出荷自動化アプリなら、配送業者の選択、送り状の出力先プリンタ、追跡番号の自動登録ルールなど、設定項目が並びます。要件定義で描いた業務フローと突き合わせながら、一つずつ埋めていきます。

複数のアプリを入れると、お互いに干渉して動作が不安定になることがあります。たとえばカスタマイズ系のアプリ同士で、同じCSS要素を取り合うようなケースです。組み込みの段階で動作確認を細かく取り、問題が出たら早めに対処します。

アプリの組み込みが終わると、業務フローの自動化部分が動き始めます。次は、Shopify外のシステムとつなぐ外部連携です。

4-3. 外部システム連携｜決済・物流・会計

Shopify外のシステムとつなぐ作業が、外部連携です。決済・物流・会計の3領域が代表的で、ここがつながって初めて、お店としての運営が回ります。

決済システムとの連携

Shopify Paymentsをメインに、コンビニ決済（KOMOJUなど）や後払い決済（Paidyなど）を組み合わせます。各決済サービスの管理画面で設定を行い、Shopify側と疎通確認を取ります。

物流システムとの連携

出荷自動化アプリ（シッピーノ、OPENLOGI、ロジレスなど）を介して、倉庫システムと連携します。注文情報を倉庫に流し、出荷完了の情報を受け取る、双方向のデータのやり取りが発生します。

会計システムとの連携

freeeやマネーフォワードのような会計ソフトに、Shopifyの売上データを連携します。専用のアプリを使う方法と、CSVを定期的に書き出して取り込む方法があります。

外部連携は、Shopify単体のテストでは見つからない不具合が出やすい領域です。連携先の仕様変更、データ形式の食い違い、タイミングのズレなど、想定外の動きが出ることがあります。連携が完了したら、本番に近い形で必ずテストを行います。

外部連携が動くと、サイトとしての形がほぼ整います。次のテストフェーズで、本番運営に耐えるかを確認していきます。

5.テストフェーズ

テストフェーズは、要件定義で描いた業務フローと、構築で組み上げたサイトを突き合わせる段階です。実店舗で言えば、開店前のリハーサルに当たります。お客さまが入ってきて、商品を選び、会計をして、商品を持ち帰るまでの一連の動作を、実際に流して確認します。

この章では、通しテスト・画面と決済の動作確認・表示速度の3つの順に、テストで見ていく内容を整理します。

5-1. 注文〜出荷の通しテスト｜業務フローを実際に流す

テストフェーズの中心が、注文から出荷までの通しテストです。お客さまが注文してから、商品が手元に届くまでの一連の流れを、本番に近い形で実際に流して確認します。

通しテストでは、次のような項目を順に確認します。

Shopifyにはテストモードという機能があり、実際のお金を動かさずに決済の動作確認ができます。テストモードでひと通り確認したあと、最後に少額の実決済テストを行うのが安全な進め方です。

通しテストは、運用マニュアルの動作確認も兼ねます。マニュアルに書かれた手順通りに操作して、迷う箇所や説明不足がないかを確認します。テストフェーズで見つかった改善点をマニュアルに反映させると、公開後の運用が楽になります。

通しテストで業務フローが回ることを確認できたら、次は画面と決済の動作を細かく見ていきます。

5-2. 画面と決済の動作確認｜表示崩れ・金額・税送料

見た目と金額計算が想定通りに動くかを、複数の環境で確認します。お客さまの環境はバラバラなので、自分の手元の環境だけで確認を済ませると、公開後にトラブルが見つかります。

表示崩れのチェック

PC・スマートフォン・タブレットの主要なサイズで、画面が崩れていないかを確認します。ブラウザもChrome、Safari、Edgeなど主要なものでチェックします。スマホはiPhoneとAndroidで挙動が違うこともあるため、両方で見るのが基本です。

決済手段ごとの動作

Shopify Payments、コンビニ決済、後払いなど、用意したすべての決済手段で実際に注文を入れます。決済画面の表示、決済完了後の遷移、メールの送信タイミングまで、一つひとつ確認します。

税・送料の計算ロジック

地域別の送料、購入金額別の送料無料ライン、消費税の計算など、金額に関わるロジックを複数のパターンで確認します。地域・金額・商品の組み合わせを変えながら、想定通りの金額が出るかをチェックします。

割引・クーポンの組み合わせ

複数の割引を併用したとき、想定通りに計算されるか。クーポンと送料無料が同時に適用されたとき、優先順位はどうなるか。割引のロジックは複雑になりやすいため、組み合わせを変えながら確認します。

画面と決済が想定通りに動くことが確認できたら、最後に表示速度のチェックに入ります。

5-3. 表示速度のチェック｜体感とSEOへの影響

表示速度が遅いサイトは、購入率もSEO評価も下がります。公開前に主要ページの速度を計測し、改善できる部分は最適化を済ませます。

表示速度の確認には、Googleが提供するPageSpeed Insightsや、Lighthouseが使われます。Core Web Vitalsと呼ばれる指標（LCP、CLS、INP）が、SEO評価にも反映されます。

表示速度に影響する主な要素は次の通りです。

表示速度の改善は、突き詰めればきりがありません。スコアを100点に近づけることに時間を使うより、お客さまの体感として「待たされない」レベルを確保するほうが現実的です。明らかに遅いページから優先的に手を入れるのが基本です。

表示速度のチェックが終わると、テストフェーズは完了です。次はいよいよ、独自ドメインに切り替えて公開する段階に入ります。

6.公開フェーズ

公開フェーズは、これまで準備してきたサイトを、独自ドメインで本番として動かし始める段階です。実店舗で言えば、開店日の朝、看板を掲げてシャッターを開ける瞬間に当たります。

この章では、公開当日の作業と、運用フェーズへの引き継ぎの2つの順に、公開で進めることを整理します。

6-1. 公開当日の作業｜独自ドメイン・DNS切り替え・動作確認

公開当日の作業は、独自ドメインの設定とDNSの切り替えが中心です。切り替えた直後に、想定通りに動いているかを確認し、トラブルが起きたときの備えも整えておきます。

独自ドメインの設定では、ドメインのDNSレコードをShopify側に向ける作業を行います。設定そのものは管理画面から進められますが、DNSの反映には数時間から最大48時間かかることがあります。切り替えのタイミングは、この反映時間も考慮して決めます。

既存サイトからの移行案件では、切り替えのタイミングがさらに繊細です。旧サイトを停止するタイミング、新サイトに切り替わるタイミングのズレで、お客さまから見てサイトが繋がらない瞬間が出ないように調整します。

切り替え直後にチェックする主な項目は次の通りです。

公開直後に重大な問題が見つかった場合、一旦旧サイトに戻すか、応急処置で凌ぐかの判断が必要になります。事前に「こうなったら切り戻す」という基準を決めておくと、当日の判断がぶれません。

公開当日の作業を無事に終えると、サイトは本番として動き始めます。ただし、公開はゴールではありません。次は運用フェーズへの引き継ぎが待っています。

6-2. 運用フェーズへの引き継ぎ｜マニュアルと体制

公開はスタートラインで、ここから運用が始まります。運用が止まらず回るための体制とマニュアルを整えることまでが、構築プロジェクトの範囲です。

運用フェーズに入って必要になるのは、主に次の要素です。

運用マニュアルは、構築フェーズの後半から少しずつ作っておくと、公開時にスムーズに引き継げます。テストフェーズで動作確認をした手順が、そのままマニュアルの素材になります。

公開後によく出るのが、「商品の追加方法が分からない」「在庫の更新でミスが出る」といった運用面のつまずきです。マニュアルが整っていれば多くは防げますが、それでも不明点は出てきます。制作会社との保守契約や、運用サポートのアプリを活用するのも手です。

運用への引き継ぎが終われば、構築プロジェクトは完了です。ここから先は、実際の注文や問い合わせを通じて改善を重ねながら、ECサイトを運用していく段階です。

7.つまずきやすいポイント

ここまで5つのフェーズを順に見てきました。最後に、フェーズ解説とは別の角度から、構築プロジェクトでつまずきやすい3つのパターンを取り上げます。事前に知っておくだけで、避けられる落とし穴です。

7-1. 要件の曖昧さが構築フェーズで爆発する

要件定義で曖昧にした論点は、構築フェーズに入ってから必ず炙り出されます。「とりあえず後で決める」は、後で決めるための時間と工数を倍増させる選択です。

要件定義の段階で「この機能、必要かどうかわからないから後回し」と判断したものが、構築フェーズに入ってから「やっぱり必要だった」と判明することがあります。このとき発生するのは、設計のやり直しと、構築済み部分の修正です。

曖昧になりやすい論点は次のようなものです。

要件定義に2週間かけるのと、構築フェーズで2週間の手戻りが出るのとでは、後者のほうが圧倒的にコストが大きくなります。要件定義の時間は、後の手戻りを防ぐための投資です。

要件定義の段階で「曖昧なまま進めようとしているもの」が一つでもあれば、立ち止まって言葉にする時間を取ります。それが結果的に、プロジェクト全体の期間を短くします。

7-2. スコープが膨らむ典型パターン

構築の途中で機能を追加すると、期間とコストが連鎖的に膨らみます。「ついでに追加してほしい」が積み重なって、当初の計画から大きくズレるのは典型的なパターンです。

スコープが膨らむきっかけは、いくつかあります。

追加要件は、一つひとつは小さく見えても、設計や構築済みの部分に影響を及ぼすことが多くあります。新しい機能を追加すると、既存機能との干渉確認、テスト範囲の拡大、ドキュメントの修正など、見えないコストが連鎖します。

追加したい機能が出てきたとき、「公開時点で必要か」「公開後に追加できないか」を必ず問います。Shopifyはアプリやテーマの追加で機能を後から拡張できる仕組みです。公開を一旦優先して、運用しながら追加する判断は、十分に現実的です。

追加要件を呑むかどうかの判断基準を、プロジェクトの早い段階で関係者と合意しておきます。基準があれば、その都度の判断が早く、ぶれにくくなります。

7-3. 運用設計の後回しリスク

運用設計を構築の最後に回すと、公開後すぐに業務が回らなくなります。サイトはできても、それを動かす人と手順が揃っていない状態です。

運用設計とは、サイト公開後に日々の業務を回すための設計です。具体的には次のような要素が含まれます。

運用設計が後回しになる理由は、構築の作業に意識が集中するからです。サイトを作ることが目的化して、それを動かすことが視野から抜け落ちます。

運用設計は、構築フェーズと並行で進めるのが基本です。構築の進捗に合わせて、「この機能の運用は誰がどう回すか」を一つずつ決めていきます。テストフェーズに入る頃には、運用マニュアルの骨格ができている状態が理想です。

「サイトを作る」と「サイトを運用する」は、別のプロジェクトです。両方を並行で進めることで、公開後の混乱を最小化できます。

8.よくある質問

8-1. 要件定義は自社でどこまで進められる？

機能要件の洗い出しは、自社主導で進められる範囲です。「商品をどう登録するか」「どんな決済を入れるか」など、運営を一番よく知っているのは自社だからです。

一方で、業務フローの可視化や外部連携の整理、抜けやすい論点のチェックは、Shopify構築の経験がある制作会社と並走したほうが確度が上がります。「自社で気づけない論点」を補ってもらう発想です。要件定義の途中段階で制作会社に相談に入ってもらう、というやり方もあります。

8-2. 既存サイトからの移行はどう進める？

既存サイトからの移行は、構造分析・データ移行・SEO引き継ぎ・公開タイミングの4軸で計画します。

まず構造分析で、既存のURL、商品データ、会員情報、注文履歴を把握します。次に、何をShopifyに移行し、何を捨てるかを決めます。SEO評価を維持するために、旧URLから新URLへのリダイレクト設計も必要です。最後に、公開タイミングと旧サイトの停止タイミングを調整します。アクセスが途切れない切り替えの段取りが、移行案件の肝です。