CASE STUDY / RESPONSIBILITY BOUNDARIES
販売判断と、
技術実装の責任を
分ける。
外部担当者が技術的な作業を担っても、商品、価格、公開、販売条件まで決定するわけではありません。小川金正堂の取引記録から、事業者が決めたこと、外部担当者が実装したこと、双方で確認したことを分け、自社運営を成立させる責任境界を分析します。
- Theme
- Responsibility Boundaries
- Case examined
- 京都御所西 小川金正堂
- Method
- 事後的な役割分析
- Primary records
- 取引・作業・公開後確認
- Evidence status
- Audited
- Publication status
- Ready
CENTRAL QUESTION
自社運営を実現するために、外部担当者はどこまで担当するべきか。
事業者が決めること、外部担当者が実装すること、双方で確認することを、どの基準で分けるか。
外部担当者は技術的に操作できる範囲が広くても、商品、価格、販売条件、公開時期を事業者に代わって決定できるわけではありません。一方、事業者がすべての技術判断を負担すると、構築と安全な変更が進みません。
CASE CONTEXT
CASEで確認できる判断と担当
小川金正堂は、移行する商品群、予算、販売開始時期、価格改定、大口割引、送料、法人取引、公開時期など、事業と販売に関する条件を取引記録上で提示・確認しました。
渡邉は、楽天市場の商品調査、Shopifyの商品・コレクション構造、注文オプション、配送・決済設定、修正対応、WordPressの技術更新、運用資料を担当しました。
商品確認では、楽天とShopifyの確認、クライアントによる修正依頼、渡邉による修正、クライアントによる最終販売確認と運用開始という流れが記録されています。
分析対象のCASEを見る →ANALYSIS
責任境界は、肩書きではなく判断対象から確認できる。
Business Decision
何を、いくらで、どの条件で、いつ販売するかは、商品と取引条件に責任を持つ事業者の判断として現れました。
Technical Decision
事業上の条件を、どの構造、設定、アプリ、更新手順で実現するかは、外部担当者の調査と技術実装として現れました。
Joint Verification
価格、オプション、商品名、説明、表示、法規関連ページは、構築側だけで確定せず、二者確認の対象になりました。
Operational Transfer
公開後に繰り返す商品追加、デザイン変更、販促は、クライアント自身の運営行動として確認されました。
本CASEでは、事業判断をクライアントへ残し、その判断を実行可能なWeb環境へ変換することが外部担当者の役割として現れた。
DECISION FRAMEWORK
事業責任・専門性・反復頻度から担当を分ける。
- 事業者が決める条件を特定する 商品、価格、割引、送料、法人取引、公開時期、法規内容など、事業責任を伴う事項を分ける。
- 技術的な実現方法を外部側で検証する 商品構造、オプション、配送設定、権限、フォーム、PHP、セキュリティなどを調査・実装する。
- 推測で販売情報を確定しない 価格、オプション、商品名、説明、法規内容をクライアントの最終確認へ戻す。
- 確認と修正の往復を設計する 調査、登録、確認、修正依頼、修正、最終販売確認という流れを可視化する。
- 反復する運営を社内で実行できる形にする 標準機能、再現可能な商品構造、運用資料によって、公開後の追加・更新を支える。
IMPLEMENTATION
判断、実装、確認を一つの担当者へ集中させない。
2026年4月1日、小川金正堂から価格改定、大口割引、公開条件が提示され、渡邉はShopify上の実現方法を確認して設定・表示へ反映しました。登録後の44商品については、価格、オプション、商品名、商品説明をクライアントの最終確認事項として戻しました。
5月7日の商品チェックフローでは、楽天・Shopifyの確認を渡邉、修正確認と修正依頼を小川金正堂、修正対応を渡邉、最終販売確認と運用開始を小川金正堂が担う流れを明記しました。
RESULTS & FINDINGS
役割分担が、公開後の運営へ接続した。
公開後、小川金正堂自身による商品追加、デザイン変更、クーポン設定を確認しました。また、Instagramでは商品と情報の発信が継続しています。
この結果は、構築中に外部担当者が担った作業のすべてが、公開後も外部作業として残ったわけではないことを示します。一方、WordPressのPHP更新、セキュリティ整理、フォーム移行など、専門性と本番変更リスクを伴う仕事は外部担当として実施されました。
このCASEから導ける実務上の示唆
- 商品、価格、販売条件、公開時期などの事業判断は、技術実装と分けて扱う。
- 技術担当者は判断材料と実現方法を提示し、未確認の販売情報を推測で確定しない。
- 二者確認が必要な項目を、公開直前ではなく作業フローへ組み込む。
- 公開後に繰り返す操作は社内で実行できる形にし、高リスクな技術変更は外部支援として分離する。
LIMITS
この分析が証明していないこと
本CASE STUDYは、契約書に「商品・価格・販売判断はすべてクライアントの責任」と定めた条項の存在を示すものではありません。取引記録に残る発言、判断、作業、確認、公開後の行動から、実際に現れた責任境界を事後的に分析しています。
また、クライアントが事業判断を行ったことは、すべての判断が誤りなく行われたことや、売上・利益につながったことを証明しません。社内能力、法的責任、情報管理、変更リスクによって、内製と外部支援の境界は企業ごとに変わります。
EVIDENCE
一次情報との照合
本文の事業判断、技術実装、確認フロー、公開後の行動は、次の原本・確認記録と照合しました。非公開の認証情報、顧客・注文・売上・管理画面情報は掲載していません。
- ココナラ「メッセージ詳細」4ページ：商品群、予算、スケジュール
- ココナラ「楽天市場からShopifyへの移行相談」4〜9ページ：決済、法人取引、権限
- ココナラ「Shopify商品登録およびEC運用基盤整備（第1回）」3ページ：価格改定、大口割引、公開方針
- 同24ページ：価格、オプション、商品情報の最終確認
- 同31〜33ページ：社内担当者による確認・変更・今後の商品追加
- ココナラ「第2回 作業内容およびお見積り」2ページ：確認・修正・最終販売確認の担当フロー
- 同7〜8・22ページ：公開時期と法規内容の最終判断
- ココナラ「第3回 WordPress改善・運用基盤整備」7ページ：公開許可と技術作業の依頼
- 公開後の商品追加、デザイン変更、クーポン設定、情報発信に関する確認記録
Evidence Audit completed: 2026年7月25日