制作会社を変える判断は、単なる発注先の変更ではなく「事業の基盤」を移し替える意思決定です。なぜならWebサイトは、問い合わせ・採用・既存顧客対応など、売上や社内オペレーションに直結する導線だからです。乗り換えでつまずきやすいのは、デザインの良し悪し以前に、契約と引継ぎが曖昧なまま進み、権限や資産の抜け漏れが起きるケースです。

乗り換えを検討すべきサインから、現状整理、要件定義、契約・権利・アカウント確認、引継ぎ対象の全体像までを、意思決定に必要な観点（費用・体制・リスク・成果）で整理します。

乗り換えを検討すべきサインと意思決定の前提整理

「不満」ではなく「事業リスク」で見る

制作会社の変更理由は「対応が遅い」「提案がない」などの不満から始まります。ただし経営判断では、不満をそのまま理由にせず、事業リスクに翻訳して捉えるのが重要です。たとえば次のような状態は、サイト停止や機会損失につながり得ます。

• 更新が属人化していて、担当者不在で止まる
• 仕様がブラックボックスで、改修のたびに見積が膨らむ
• 解析や広告のタグ管理が不透明で、成果が説明できない
• セキュリティ対応（更新・脆弱性対策）が後手に回る

判断軸は「止めない・移せる・測れる・改善できる」

乗り換えの是非を短時間で整理するなら、経営として次の4点で棚卸しするとブレが減ります。①止めない（公開と更新が継続できるか）②移せる（資産と権限が移管できるか）③測れる（成果指標を継続して計測できるか）④改善できる（運用と意思決定が回るか）。この4点のどこで詰まっているかが、乗り換えの優先順位になります。

乗り換えのゴールは「作り替え」ではなく「成果の再現性」

みやあじよでは、デザインを「見た目」ではなく問題解決のための設計と捉えます。つまり、乗り換えのゴールも「新しく作る」ではなく、成果が出る状態を再現できる体制と仕組みをつくることです。ここを外すと、完成したのに運用できない、改善が回らない、といった“作って終わり”になりやすくなります。

まず整理するべき現状情報とゴールの言語化

最初に集めるべき「現状の事実」

乗り換え検討の初期は、まず事実を集めて「現状がどう動いているか」を把握します。ここが曖昧だと、新しい制作会社に何を引き継ぐべきか決められず、見積比較もできません。

• 現行サイトの目的（問い合わせ、採用、既存顧客対応など）
• 主要ページと導線（入口ページ、資料請求、問い合わせ、応募）
• 更新頻度と更新担当（誰が、何を、どのツールで更新しているか）
• 現行契約の範囲（保守、改修、サーバ費、追加作業の単価）
• 運用上の痛点（更新の詰まり、承認フロー、品質、スピード）

ゴールを「数字」と「意思決定基準」に落とす

KPIは目的達成の進捗を測る指標を指します。経営側は、KPIを決める際に「どの数字が動けば成功と言えるか」「いつ判断するか」をセットで置くと、乗り換え中の迷いが減ります。問い合わせ件数だけでなく、商談化率や採用の応募単価など、事業に近い指標へ寄せると判断がしやすくなります。

要件定義の進め方と「決めること／決めないこと」

要件定義で決めるのは「作るもの」より「運用の前提」

要件定義は目的を実現するための要件（機能・コンテンツ・運用・制約）を整理して合意する工程を指します。乗り換えでは、機能やページ構成より先に、運用の前提を固めるのが効果的です。

• 更新は誰が行い、承認は誰がするか
• 緊急時（障害・改ざん等）の連絡経路と初動は誰が担うか
• 月次で何を見て、どの会議で改善判断するか

「決めないこと」を決めてスコープを守る

乗り換えは、やりたいことが芋づる式に増えがちです。そこで、初期段階で「今回はやらないこと」を明文化し、優先順位を守ります。スコープはプロジェクトで対応する範囲を指します。例として、デザイン刷新は最小限にして、まずは引継ぎと計測の安定化を優先する、といった意思決定があり得ます。

契約・権利・アカウントの確認ポイント

ここが抜けると、止まる・移せない・説明できない

乗り換えトラブルの多くは、契約書そのものより「権限」と「資産」の所在が不明なことから起きます。特に、サイトを動かすための“鍵”が誰の手元にあるかは、早期に棚卸しします。契約条件の解釈が難しい場合は、社内の法務や専門家の確認を前提に進めると安全です。

引継ぎで確認すべき権限・権利・資産一覧

資産カテゴリ	具体例	確認ポイント	現管理者
ドメイン	example.jp	名義、管理会社、移管可否、更新期限	社内／制作会社
サーバ	本番・検証環境	契約者、管理画面権限、バックアップ方針	社内／制作会社
CMS	管理画面ID	管理者権限、編集権限、二要素認証	社内／制作会社
メール	info@ など	DNS設定、転送、送信ドメイン認証	社内／制作会社
解析	GA4 等	管理者権限、イベント定義、タグ管理	社内／制作会社
広告	広告管理画面	アカウント所有者、支払設定、権限	社内／代理店
素材	画像・文章	利用許諾、ライセンス、元データ所在	社内／制作会社
ソース	テーマ・拡張機能	改修履歴、保管場所、第三者製の条件	社内／制作会社

GA4はGoogleのアクセス解析サービスを指します。DNSはドメインとサーバを結びつける設定情報を指します。CMSはWebサイトを更新するための管理システムを指します。

引継ぎ対象の全体像（ドメイン／サーバ／更新環境／計測）

乗り換えは「4つの引越し」を同時に扱う

引継ぎを漏れなく進めるコツは、対象を「ドメイン」「サーバ」「更新環境」「計測」の4つに分けて考えることです。どれか一つでも欠けると、公開できない、更新できない、成果が測れない、という状態になります。

• ドメイン：名義・更新期限・移管手続き
• サーバ：本番／検証、バックアップ、セキュリティ更新
• 更新環境：CMSの権限、編集ルール、マニュアル
• 計測：解析・広告・問い合わせ計測の設計と動作確認

「引継ぎ資料」がない前提で、再現できる形に落とす

旧制作会社側に資料が揃っていない場合もあります。そのときは、現状サイトの構造と運用を観察し、再現できる形に落とすことが現実的です。「やりたいけど分からないことの言語化」を重視し、関係者の頭の中にある前提を、誰が見ても同じ判断ができる状態まで整理することが重要です。

体制とスケジュール設計（社内外の役割分担と進行管理）

乗り換えで一番詰まりやすいのは「誰が決めるか」

乗り換えの停滞は、技術より意思決定の渋滞で起きます。経営・事業責任者は優先順位と予算枠を決め、情シスとWeb担当は現状把握と運用要件を固め、制作会社は実現手段と段取りを提示する。この役割が混ざると、議論が発散し、見積もりもスケジュールも固まりません。

RACIは作業ごとの責任分担を「実行」「最終責任」「相談」「共有」に分けて整理する考え方を指します。RACIのような形で、決裁者と実務責任者を明確にしておくと、引継ぎ中の判断が止まりにくくなります。

乗り換えプロジェクトの役割分担表

作業	経営・事業責任者	情シス・Web担当	制作会社（新）
目的・優先順位の確定	最終決定	材料提示	整理支援
現状棚卸し（権限・資産）	支援	主担当	確認観点提示
要件定義（運用含む）	承認	主担当	作成・合意形成
スケジュール策定	判断	制約提示	案作成・調整
移行計画（切替手順）	判断	主担当	設計・実施
品質確認（受入テスト）	重要観点確認	主担当	試験・改修
公開後の運用体制	決裁	主担当	運用設計・引継ぎ

スケジュールは「切替日」から逆算する

カットオーバーは旧環境から新環境へ切り替える本番移行日を指します。カットオーバーが決まると、そこから逆算して、移行の準備・検証・周知の期限が決まります。目安としては、①現状把握と要件定義 ②設計・制作 ③移行・テスト ④切替と安定化 の4ブロックに分け、各ブロックの完了条件を文章で決めると管理が楽になります。

WBSは作業を細分化して期限と担当を一覧化する計画表を指します。WBSがあると、社内確認が必要なタイミングが見え、承認待ちで制作が止まる事態を避けやすくなります。加えて、週次の定例で「決める事項」と「持ち帰り事項」を固定し、議事メモを残すだけでも手戻りは減ります。

ロールバックは切替後に問題が出た場合に旧環境へ戻す手順を指します。ロールバックの可否と判断基準を事前に決めておくと、公開日の心理的負担が下がります。

費用の考え方（見積の内訳、追加費用、運用コスト）

見積比較は「作る費用」より「抜けの有無」を見る

乗り換え見積は金額差より、含まれる範囲の差が大きく出ます。とくに引継ぎでは、移行作業や計測、運用設計が別扱いになりやすいため、内訳を揃えて比較することが重要です。

また契約形態によって費用の考え方が変わります。請負は成果物の完成に対して報酬が発生する契約形態を指し、準委任は作業時間や役務提供に対して報酬が発生する契約形態を指します。どちらが良い悪いではなく、要件の固まり具合と変更の多さに合わせて選ぶとブレにくくなります。

見積比較で見るべき内訳と追加費用の論点

費目	含まれやすい作業	追加になりやすい条件	比較のコツ
要件定義	要件整理、画面・導線の合意	社内合意が難航	成果物（要件書）の範囲を確認
設計・デザイン	ページ設計、デザイン作成	途中で方針変更	修正回数と判断者を固定
実装	CMS設定、機能実装	既存仕様の再現要求	「再現する理由」を要件に明記
移行	ページ移し替え、データ移行	量が多い、形式が混在	移行対象の一覧を先に作る
計測	解析・広告の計測設計	イベントが複雑	意思決定に必要な指標から絞る
運用	更新ルール、マニュアル	複数部署が更新	権限設計と承認フローをセットで

予算で見落としがちな「二重コスト」と「運用の人件費」

乗り換え期間は、旧保守を続けながら新構築を進めるため、二重コストが発生する場合があります。また、社内の確認・承認・素材準備の工数もコストです。経営としては、制作費のみに目を向けず、社内稼働のピークをどこに置くかまで含めて投資判断すると、途中で止まりにくくなります。

リスク管理（停止・データ欠落・検索流入低下への備え）

「止まるリスク」は権限と切替手順で下げる

乗り換えで避けたいのは、公開停止と問い合わせ機会の損失です。ドメイン・サーバ・メールの管理権限が社内で把握できているか、切替手順が文章化されているか、この2点が防波堤になります。SSLは通信を暗号化して安全性を担保する仕組みを指します。SSLの更新や設定不備は、表示エラーや信頼低下につながるため、切替前にチェック項目に入れます。

「測れないリスク」は計測の並行稼働で下げる

SEOは検索エンジンでの露出を最適化する施策を指します。検索流入を落とさないためには、URL変更の有無、リダイレクト設定、サイトマップ送信などを計画に入れます。リダイレクトは旧URLから新URLへ自動転送する設定を指します。Search ConsoleはGoogle検索での表示状況やエラーを確認できる管理ツールを指します。インデックスは検索エンジンにページが登録されることを指します。切替前後でSearch Consoleのエラーやインデックス状況を確認すると、原因特定が早くなります。

アクセス解析や広告の計測は、切替前後で並行稼働させ、主要な指標が継続して取れているかを確認します。タグマネージャーは複数の計測タグを一元管理して配信する仕組みを指します。タグマネージャーを使っている場合は、権限移管と公開フローまで含めて引き継ぐことが重要です。

成果指標の設計と運用設計（計測・改善サイクル）

本文で出てくる用語の補足

情シスは社内ITを管理する情報システム部門を指します。
アクセス解析はサイトの閲覧や行動をデータで把握することを指します。
セキュリティは情報資産を守るための対策全般を指します。
脆弱性は悪用されると不正アクセスにつながるシステム上の弱点を指します。
サイトマップは検索エンジンにページ一覧を伝えるファイルを指します。
送信ドメイン認証はメールのなりすましを減らすため送信元ドメインを検証する仕組みを指します。

成果は「指標」と「運用ルール」をセットで決める

乗り換え直後に成果が伸び悩む原因は、作り込み不足よりも「見ている数字がバラバラ」「改善の意思決定が回らない」ことにあります。運用設計は公開後に誰が何をどう更新し、どう改善するかを決める設計を指します。運用設計まで含めて合意できると、制作会社を変えても成果の再現性が上がります。

ダッシュボードはKPIを一覧で追える画面を指します。経営と現場で同じダッシュボードを見るために、指標は多くしすぎず、意思決定に必要な順でそろえます。

• 目的指標：問い合わせ件数、商談化率、採用応募数など
• プロセス指標：フォーム到達数、クリック数、資料DL数など
• 品質指標：主要ページの離脱、入力エラー、表示速度など

イベントはクリックや送信などのユーザー行動を計測する単位を指します。イベント設計は「何を成果とみなすか」をそのまま反映するため、要件定義と同じタイミングで決めておくと手戻りが減ります。

乗り換え時に成果を落としにくい運用の型

改善サイクルは「計測→仮説→実行→検証」を繰り返す流れを指します。運用を属人化させないために、最低限の型を固定します。

• 月次で見る項目（KPI・主要導線・流入別の変化）
• 改善テーマの優先順位ルール（売上影響、工数、緊急度）
• 変更管理のルール（いつ・誰が・何を変えたかの記録）

受入テストは納品物が要件を満たすかを発注側で確認する工程を指します。受入テストの観点に「計測が取れる」「主要フォームが動く」「権限が社内に戻っている」を含めると、公開後の混乱が減ります。

新しい制作会社の選び方（評価軸、提案依頼、契約の注意点）

評価軸は「作る力」より「引継ぎ耐性」

乗り換え時に重視すべきは、制作物の見た目だけでなく、引継ぎを前提にした進め方です。具体的には次の観点をそろえると、比較がしやすくなります。

• 要件定義を伴走できるか（目的と制約を整理して合意を作れるか）
• 権限と資産の棚卸しを体系立てて行えるか（表Aの観点を踏襲できるか）
• スケジュールとリスクを文章で管理できるか（切替・ロールバックまで含むか）
• 運用を含めた提案があるか（更新・計測・改善の体制まで描けるか）

二要素認証はパスワードに加えて別手段で本人確認する仕組みを指します。運用フェーズも見据える制作会社は、二要素認証や権限設計を「手間」ではなく「止めない仕組み」として扱います。

提案依頼は「比較できる条件」を先に渡す

RFPは制作会社に提案を依頼するための要件整理資料を指します。RFPに盛り込むとブレが減るのは、次の3点です。

• 目的と優先順位（最優先事項）
• 現状の制約（社内体制、既存システム、公開期限）
• 引継ぎ対象（ドメイン、サーバ、CMS、解析、素材の所在）

ここが揃うと、見積の差が「品質や体制の違い」なのか「前提の違い」なのかを切り分けやすくなります。

契約で押さえるのは「出口」と「運用の責任範囲」

乗り換えの再発を防ぐため、契約時点で出口を設計します。出口とは将来別の制作会社へ移る可能性も含めて、資産と権限を残す設計を指します。

• 成果物の取り扱い（データ・ソース・素材の納品範囲と保管）
• アカウントの所有者（ドメイン、解析、タグ管理の管理者は社内）
• 変更時の扱い（追加作業の算定方法、優先順位の付け方）
• 保守の範囲（保守は監視・更新・小改修などの継続対応を指します）

乗り換え支援を依頼する場合の進め方（相談時に揃える資料）

支援の価値は「決める順番」と「抜け漏れ防止」

乗り換え支援で最も効くのは、作業代行そのものより、決める順番を作り、引継ぎ漏れを防ぐことです。要件定義支援、PM支援、運用設計を組み合わせると、社内の判断負荷を下げながら、切替までの不確実性を減らせます。

PMはプロジェクトの進行・調整・リスク管理を担う役割を指します。PM支援が入ることで、旧制作会社との調整や、社内承認の詰まりを「見える化」して解消しやすくなります。

相談時に揃えると進行が速い資料

手元に揃うほど精度が上がるのは、次のような情報です。

• 現行契約の範囲が分かる資料（保守範囲、解約条件）
• アカウント一覧（ドメイン、サーバ、CMS、解析、広告）
• 現行サイトのページ一覧と更新ルール
• 解析の現状（KPI、主要導線、イベント設計の概要）
• 公開期限と社内体制（決裁者、窓口、定例の頻度）

資料が不足していても、現状把握から再構築できるように進めることは可能です。その場合は、把握できている事実から順に「合意できる前提」を増やしていきます。

まとめ

制作会社の乗り換えは、契約の解除や見積比較だけでなく、権限・資産・運用を移す経営プロジェクトです。止めない・移せる・測れる・改善できるの4軸で現状を整理し、要件定義で運用前提と成果指標を固め、表Aの観点で引継ぎ漏れを防ぎます。切替日から逆算したスケジュールと、計測の並行稼働、受入テストの観点設定まで揃うと、移行中のリスクと投資判断の迷いが大きく減ります。新しい制作会社は引継ぎ耐性と出口設計で評価し、RFPで比較条件を揃えた上で契約と運用範囲を明確にすると、乗り換え後も改善が回る状態を作りやすくなります。