PROCESS / EC MIGRATION
相談から、自社運営への引き継ぎまで。公開を終点にしない、
EC移行の進め方。
相談内容をそのまま制作物へ置き換えず、現在の販売と公開後の運営を確認します。必要な結果、成果物、仕事の順に範囲を定め、公開後に自社で前へ進められる状態まで引き継ぎます。
COMPLETION
完了は、公開した日ではなく、運営を始められる状態で判断します。
サイトの公開は重要な工程ですが、移行の最終結果ではありません。公開後に商品を扱い、必要な更新を行い、顧客へ案内し、自社で進める仕事と相談する仕事を判断できることを完了条件として確認します。
PROCESS OVERVIEW
六つの確認を重ねて、運営へ移行します。
案件ごとに実施内容や期間は変わりますが、判断の順番は変えません。確認できた事実に合わせて計画を更新し、未確認の内容を推測で構築しません。
相談内容と、現在の販売環境を確認します。
「Shopifyへ移したい」という希望だけで対象を確定せず、何を販売し、誰が運営し、何に困っているかを確認します。
共有していただくこと
- 現在の販売先と既存サイト
- 商品数と商品の特徴
- 現在困っていること
- 公開後に自社で行いたい業務
- 希望時期と確認体制
この段階で行うこと
- 相談背景の確認
- 確認対象の整理
- 不足情報の特定
- 依頼として成立する範囲の検討
- 次の確認方法の案内
何を作るかではなく、何を確認してから判断するかが合意できている。
移行元の情報を、運営要件へ変換します。
画面や商品情報をそのまま複製するのではなく、移行元で行われている販売業務を読み取り、Shopifyで続けるための条件へ整理します。
確認する領域
- 商品とオプション
- 価格、決済、配送
- 受注時に必要な情報
- 問い合わせと顧客接点
- 権限、更新、承認
整理する結果
- 移行するもの
- 再設計するもの
- 移行しないもの
- 公開前に決めること
- 公開後に運営で判断すること
公開後の販売と運営に必要な条件が、制作物より先に整理されている。
結果、成果物、仕事、責任の順に範囲を確定します。
将来必要になる可能性だけで作業を増やさず、現在の課題を解決するために必要な範囲を合意します。
合意する内容
- 目指す状態
- 必要な成果物
- 実施する仕事と対象外
- クライアント側の担当
- 確認方法と進行条件
開始前に必要なもの
- 対象情報へのアクセス
- 必要な権限
- 販売条件の判断者
- 確認・承認の窓口
- 作業開始の合意
誰が何を決め、誰が何を実装し、何を完了とするかが明確である。
確認できた事実に合わせて、設計と構築を進めます。
最初の計画を固定せず、商品や権限などの確認事実が変わった場合は、目的を保ったまま対応範囲と順番を更新します。
主な仕事
- 商品構造と入力基準
- 販売・決済・配送設定
- 購入・問い合わせ導線
- 既存サイトとの接続
- 運用資料と確認記録
進行中の確認
- 事業判断が必要な内容
- 仕様上の制約
- 追加情報と権限
- 変更による影響
- 範囲外となる追加要望
構築内容が、確定した運営要件と責任分担に接続している。
画面だけでなく、公開後の業務として確認します。
表示の完成度だけを確認するのではなく、商品情報、販売条件、導線、権限、更新手順が実際の運営に使えるかを確認します。
公開前の確認
- 商品と表示
- 決済・配送条件
- 注文・問い合わせ情報
- スマートフォン表示
- 担当者が行う操作
公開判断
- 未完了事項の有無
- 未確認事項と制限
- 公開日時と担当
- 告知・切り替え方法
- 公開後の確認内容
公開する条件と、公開後に確認する内容が合意されている。
公開後の行動を確認し、運営へ引き継ぎます。
資料を渡して終えるのではなく、商品追加や更新など、クライアントが実際に行う運営業務へ接続します。
引き継ぐもの
- 更新できる構造
- 運用標準と手順
- 確認すべき項目
- 社内で進める範囲
- 相談が必要な範囲
完了時に確認する状態
- 販売を始められる
- 商品を追加できる
- 必要な更新を行える
- 顧客へ案内できる
- 次の改善を判断できる
サイトが公開されたことではなく、自社で運営を始められることを確認する。
RESPONSIBILITY
事業の判断と、技術的な実現を分けて進めます。
依頼者が決めるべき販売条件を外部担当者が推測せず、技術上の判断を依頼者へ丸投げしないための分担です。
クライアント
- 商品、価格、取引条件を決める
- 必要な情報と権限を提供する
- 確認と承認を行う
- 公開後の事業判断を行う
渡邉国生
- 情報を整理し、確認事項を示す
- 運営要件を構造へ変換する
- 合意範囲を設計・構築する
- 確認と運営移行を支援する
COMMUNICATION
判断が必要な時点で、確認内容を分けて共有します。
平日は返信を中心に
確認事項、必要情報、判断内容を整理してお送りします。
土・日・月を中心に作業
設計、構築、検証などの実作業を進めます。
決定と変更を記録
確認済み、未確認、変更、対象外を混同せずに残します。
案件の規模、確認速度、外部サービスの仕様確認によって期間は変わります。固定日程を先に当てはめず、開始前に案件ごとの進行条件を確認します。
NOT FIXED IN ADVANCE
すべての案件を、同じ工程表には当てはめません。
必要な成果物は、商品、販売条件、既存環境、担当体制によって変わります。
売上、利益、受注数など、構築だけでは保証できない成果を完了条件にはしません。
開始後の追加要望は、影響と必要性を確認し、当初範囲と分けて判断します。
日常運営をすべて引き受けるのではなく、自社で進められる範囲を広げます。
PROCESS IN PRACTICE
この進め方は、実際のCASEで確認できます。
CASE 01 / KYOTO
京都御所西 小川金正堂
2026年2月10日の相談から、要件整理、権限確認、商品設計、Shopify構築、WordPress改善、公開、運用資料、公開後の自社運営までを事実として確認できます。
CASEで全工程を確認するFIRST CONSULTATION2026-02-10
INITIAL PLAN15商品
FINAL REGISTRATION55商品
OPERATION DOCUMENTS2冊
CASEには実際に起きた事実を掲載し、各工程の判断は22本のCASE STUDYで分析しています。
BEFORE REQUEST
制作物を決める前に、現在の状況をお知らせください。
現在の販売先、商品数、困っていること、実現したい状態、公開後に自社で行いたい業務が分かれば、最初に確認すべき内容を整理できます。
ご相談は受注プラットフォームから受け付けます。正式な相談先はCONTACTページで案内します。