【初心者向け】WEBサイト立ち上げを制作会社に依頼する前に決めておきたいこと

BtoB SaaS のマーケを 1〜数人で回していると、サイトを新しく立ち上げる、あるいは作り直す場面に何度か遭遇します。制作会社に相談する前に何を決めておけば後工程で困らないのか、見えにくいまま見積もり依頼に進んでしまう感覚があります。

結論から書きます。Web 制作を依頼する前に決めておくことは「目的・要件・計測」の 3 点で、特に計測設計を最初から要件に組み込んでおくのが、公開後の手戻りを防ぐ現実解だと感じています。本記事ではこの 3 点を、発注前チェックリストとして要件定義から公開後計測まで時系列で整理します。

この記事は、事業会社で BtoB SaaS のマーケを担当し、GA4 / BigQuery / Looker Studio / AB testing で実務を回してきた立場から書きます。発注側として制作会社とやり取りしてきた経験も踏まえた整理です（BtoB SaaS マーケ業務委託の経験）。

私自身、サイトを立ち上げる前にスコープを詰め切れず、公開後に「この数字はどう取るのか」を後付けで考え始めて手戻りした経験があります。発注側として目的だけ伝えて要件を制作会社任せにすると、認識のズレが後工程で表面化する、と感じています。

※本記事には、A8.net を通じたアフィリエイトリンクが含まれます。読者の支払額は変わりません。

---

サイトを作る前に決める3つの判断軸（目的・要件・計測）

サイト立ち上げの相談に入る前に、発注側が手元で決めておく判断軸は 3 つに束ねられると考えています。目的、要件、計測の 3 点です。

目的・予算・ターゲット・サイト構成といった項目は、検索すれば多くのチェックリストが出てきます。ここでは飽和した論点として簡潔に束ね、本記事では 3 軸目の「計測」に字数を寄せていきます。

• 目的：何のためにサイトを作るのか、KGI / KPI に翻訳できる形まで落とす
• 要件：掲載コンテンツ・ページ構成・依頼範囲を発注側が握る
• 計測：公開後に何を測るかを、要件定義の段階で決めておく

多くの発注は「作ってから計測を考える」順序で進みます。これが後工程の手戻りを生む典型的な構造で、計測を後段の判断軸として独立させる必要があると考えています。

なお、サイト全体の立ち上げ判断が固まった後は、LP 単位の設計・外注へ話が移ります。LP の外注先選びは 事業会社マーケが選ぶLP外注先 で別途整理しているので、本記事を読み終えた後の次の一歩として参照してください。

目的とKGI/KPIを「計測できる形」で決める

「サイトの目的を決めましょう」という助言は多くの記事にありますが、目的が計測できる形まで落ちていないと、公開後に何を改善すればよいかが決まりません。ここでは曖昧な目的を測定可能な指標に翻訳する手順を整理します。

目的を KGI に翻訳する

「ブランディングを強化したい」「問い合わせを増やしたい」といった目的は、そのままでは計測できません。最初にやるのは、目的を一つの最終ゴール（KGI）に翻訳することです。コーポレートサイトなら問い合わせ数、プロダクトサイトなら資料請求数など、数えられる単位に置き換えます。

KGI を一つに絞ると、後段の要件定義で「どのページにどの導線を置くか」の判断基準が定まります。目的が複数あるとサイト構成が発散するため、優先順位を発注側で先に決めておくのが現実的です。

KGI を KPI と計測イベントに分解する

KGI が決まったら、そこに至る中間指標（KPI）と、計測すべきイベントに分解します。KGI が問い合わせ数なら、KPI は流入数・フォーム到達率・フォーム完了率に分解でき、それぞれが GA4 のイベントに対応します。

この分解を発注前にやっておくと、フォーム計測やボタンクリックのイベントを「要件」として制作会社に渡せます。分解しないまま発注すると、計測は公開後の宿題として残り、初期の数字が取れない期間が発生します。

目的が曖昧なまま発注した時の手戻り

目的が計測に落ちていない状態で発注すると、公開後に「数字が追えない」という形で問題が表面化します。どのボタンが押されたか、どのフォームで離脱したかが取れず、改善の打ち手が決められません。

私自身、立ち上げ時に CV 定義を詰め切らないまま公開し、数週間分のデータを後から取り直す形になった経験があります。計測は後でも設定できますが、過去に遡ってデータは取れない、というのが実務感覚として痛感した点です。

要件定義で発注側が詰めておくこと（事業会社マーケ目線）

要件定義は制作会社が主導すると思われがちですが、発注した事業会社マーケが手元で握っておく範囲があります。ここを制作会社任せにすると、後から認識のズレが手戻りとして返ってきます。

発注側が決めておく要件定義の項目

発注側が握っておく要件は、掲載コンテンツ・ページ構成・依頼範囲の分担・素材と原稿の責任分界の 4 つだと考えています。掲載コンテンツは「どのページに何を載せるか」、ページ構成はサイトマップの粒度、依頼範囲はサーバー・ドメイン・CMS のどこまでを制作会社に任せるか、素材と原稿は「誰がいつまでに用意するか」です。

このうち発注側が見落としやすいのが、素材と原稿の責任分界です。原稿は発注側が用意する前提で見積もられているのに、その認識が共有されておらず、公開直前に原稿が揃わない、という事態が起きやすいと感じています。

要件定義を発注書に落とす

要件が固まったら、それを発注書の形に落とします。口頭やメールの断片で伝えると認識ズレが残るため、書面で項目を揃えるのが安全です。発注書の具体的な項目は LP制作の発注書テンプレート（発注書14項目） で整理しているので、サイト制作の発注書を組む際の下敷きとして使えます。

スコープ未定義が生む手戻りと発注側の握り方

要件定義で最も後を引くのが、スコープの線引きです。ここが曖昧なまま進むと、制作の途中で金額と納期の交渉が繰り返し発生します。発注側が初回にどこまで握るかで、後工程の安定度が変わります。

スコープ未定義が生む手戻りの具体例

スコープが曖昧なまま進むと、典型的な手戻りパターンに入ります。後から「このページも追加したい」という要望が出て、見積もりの再算定が発生し、納期が後ろにずれる、という流れです。

追加要望そのものは悪くありませんが、要件定義の段階で「どこまでが初回スコープか」を線引きしておかないと、追加のたびに金額と納期の交渉が発生します。発注側が初回スコープを明文化しておくと、この交渉コストが下がりやすくなります。

マーケ実務目線でのコメント

事業会社マーケとしての本音を書きます。要件定義で発注側が本当に握るべきは、デザインの細部ではなく「目的・KGI・計測の初期合意」だと考えています。デザインは制作会社の専門領域に委ねられますが、何のために作り何を測るかは発注側にしか決められないからです。

私自身、ある BtoB SaaS 企業の業務委託で要件定義に関わった際、最初の打ち合わせで KGI と「公開後に何を計測するか」を発注側と擦り合わせたことが、後工程をスムーズにしたと感じています。業務委託先として中立的に申し添えるに留めますが、目的と計測の初期合意を先に取るだけで、制作途中の仕様変更が目に見えて減る、という手応えがありました。固有名詞や数値は守秘の範囲なので一般化して記しています（BtoB SaaSマーケ業務委託の経験）。

制作会社の選定と発注プロセス

要件定義が固まったら、制作会社の選定フェーズに入ります。発注側の意思決定としては、ここで「誰に頼むか」と「何を基準に選ぶか」を決めます。選定軸を持たないまま相見積もりに入ると、金額の比較だけで判断しがちです。

制作会社を選ぶ判断軸

制作会社を選ぶ判断軸は、実績・計測対応力・コミュニケーションの 3 点で見ると整理しやすいと考えています。実績は自社の業種・サイト種別に近い制作経験があるか、コミュニケーションは要件の認識合わせのレスポンスが噛み合うかです。

ここで見落とされやすいのが計測対応力です。GA4 の設定や GTM の実装まで対応できる制作会社かどうかは、見積もり段階で確認しておかないと、計測は別途自社か別ベンダーで、という分担になり、責任の所在が曖昧になります。「計測まで対応できるか」を選定軸に入れるのが、後段の手戻りを減らす現実解だと感じています。

相見積もりと発注前の確認事項

相見積もりでは、金額だけでなく、見積もりに含まれる範囲を揃えて比較します。同じ「サイト制作一式」でも、原稿作成・素材手配・計測設定が含まれるかで金額の意味が変わります。

見積もり時に聞いておくべき質問は、LP 制作の文脈で LP制作の見積もりで聞くべき質問 に整理しています。サイト制作でも、保守範囲・修正回数・計測対応の確認は共通して効くので、相見積もりのチェックリストとして流用できます。

サイト立ち上げから LP 設計への接続

サイト全体の立ち上げが固まると、次は集客導線としての LP 設計に話が移ります。広告やキャンペーン用の LP を外注する場面が出てくるからです。LP の外注先選びは LP制作の外注先選び で整理しています。

私自身、発注プロセスで要件の伝え方が曖昧だったために、制作会社側の解釈と自分の想定がずれた経験があります。ある BtoB SaaS 企業の業務委託で、要件を口頭中心で伝えた結果、初稿で認識のズレが表面化し、書面で揃え直したことがあります。

なぜ計測を「作る前」に決めるのか

ここから本記事の中心に入ります。発注前チェックリストの多くは、計測設計を「立ち上げ前」に決める発想をほとんど扱わず、計測は公開後に考える前提で書かれています。私は、計測を要件定義の一項目として最初から組み込むのが、公開後の改善サイクルを早める現実解だと考えています。

計測を後付けにすると、手戻りコストが発生します。公開後に「このボタンのクリックを取りたい」となっても、HTML の構造によってはイベントタグを仕込み直す必要があり、制作会社への追加依頼と再見積もりが発生します。

さらに問題なのは、データの欠損です。計測は後からでも設定できますが、設定した日より前のデータは取れません。公開直後の流入が最も多い時期のデータが欠けると、初期の仮説検証ができなくなります。だからこそ計測は「作る前」に要件として決めておく必要があると感じています。

GA4のCV定義とフォーム計測を発注前に要件化する

計測を要件に含めると言っても、立ち上げ前に決めるのは細部ではなく骨格です。KGI に直結する数点をまず固めるのが現実的だと考えています。

CV 定義とキーイベントを先に決める

具体的に要件へ含めるのは、まず GA4 の CV（コンバージョン）定義です。問い合わせ送信、資料請求完了、トライアル登録など、KGI に対応するイベントを「キーイベント」として定義し、どのページのどのアクションで発火させるかを発注前に決めます。

次にフォーム計測と主要導線のイベント設計です。フォームの表示・入力開始・送信完了をステップで取れるようにしておくと、公開後にフォーム到達率と完了率を分解できます。主要な CTA ボタンのクリックも、イベント名の命名規則ごと要件に書いておくと、制作会社の実装がぶれにくくなります。

タグの実装責任を発注前に決める

ここで「誰がタグを実装するか」も発注前に決めておきます。GTM の設定を制作会社に任せるのか自社で持つのかを曖昧にすると、公開時にタグが入っていない、という事態が起きやすいからです。実装責任を発注書に書いておくと、公開判定のときに計測の動作確認が抜けにくくなります。

BigQuery・Looker Studioの土台と公開後計測の逆算

CV 定義とイベントが決まったら、それを蓄積・可視化する土台を立ち上げ前に繋いでおきます。ここを後回しにすると、せっかく取ったデータが分析に使いにくい形で溜まります。

BigQuery / Looker Studio のレポート土台を最初に繋ぐ

GA4 だけで完結させず、立ち上げ時点で BigQuery エクスポートを有効にしておくのが、後段の分析自由度を上げる現実解だと考えています。BigQuery への蓄積は設定した時点からしか始まらないため、公開前に繋いでおくと初期データから SQL で分析できます。

レポートの土台は Looker Studio で組みます。KGI / KPI を可視化するダッシュボードの骨格を立ち上げ前に決めておくと、公開後すぐに数字を見られます。ヒートマップなど定性的な行動観察を併用する場合のツール選定は、Microsoft Clarity の使い方 で整理しているので、計測設計の具体ツール例として参照してください。

公開後30日の計測から逆算する

立ち上げ前に決める計測の最低限は、「公開後 30 日で何を見るか」から逆算すると決めやすいと考えています。公開後 30 日でフォーム完了率と主要導線の離脱を見ると決めれば、そのために必要なイベントが逆算で出てきます。

公開後 30 日で具体的に何を設定し何を見るかは、LP公開後30日の計測設定 で整理しています。立ち上げ前の計測設計と公開後の計測運用は地続きなので、発注前にこの逆算をしておくと、公開後の初動がスムーズになります。

マーケ実務目線でのコメント

事業会社マーケとしての本音を書きます。計測を要件化すると、公開後の改善サイクルの立ち上がりが明らかに変わると感じています。計測が後付けの現場では、公開してから「数字が取れていない」と気づき、最初の 1〜2 か月を計測の整備に使ってしまうことが多いからです。

逆に、計測を要件に組み込むことが過剰になる場面もあります。立ち上げ初期に取るべきイベントは KGI に直結する数点で十分で、最初から細かいイベントを大量に設計すると、運用しきれずに形骸化します。最低限から始めて必要に応じて足すのが現実的だと考えています。

私自身、サイト立ち上げの時点で GA4 のキーイベントと BigQuery エクスポート、Looker Studio の簡易ダッシュボードだけを先に繋ぎ込み、細かい計測は公開後に足す形にしたことがあります。最低限を立ち上げ前に決めておくだけで、公開後 30 日の数字がそのまま改善の材料になった、と感じています。

公開準備から公開後グロースまでの時系列整理

ここまでの判断軸を、要件定義から公開後グロースまでの時系列に並べ直します。発注側が「いつ何を決めるか」を 1 枚で把握しておくと、各フェーズで抜けが起きにくくなります。

公開準備フェーズのチェック項目

公開準備フェーズでは、最終確認と計測の動作チェックを行います。コンテンツの最終校正やリンク切れ確認に加えて、計測タグが正しく発火しているかを公開前に確認するのが重要だと考えています。

具体的には、GA4 のリアルタイムレポートでイベントが取れているか、フォーム送信がキーイベントとして記録されるか、BigQuery にデータが流れ始めているかを公開前にテストします。さらに、検索エンジンにインデックスさせる設定（noindex の解除、サイトマップ送信）も公開タイミングで揃えます。ここを飛ばすと、公開後にインデックスされない、計測が動いていない、という初歩的な手戻りが起きます。

公開後グロースの初動

公開後は、グロースの初動に入ります。公開後 30 日は流入が読めない時期なので、決めておいた KPI を毎日ではなく週次で見て、大きな離脱ポイントを特定します。

この初動の具体的な進め方は 公開後30日でやる計測 に整理しています。立ち上げ前に計測を要件化しておくと、この 30 日を計測の整備ではなく改善仮説の検証に使えます。

発注側の意思決定を整理した工程表

発注側が各フェーズで決めることを 1 枚に整理すると、次の通りです。

フェーズ	発注側が決めること	主な成果物	関連記事
要件定義	目的・KGI/KPI・スコープ・計測要件	要件定義書	N2
制作会社選定	選定軸・見積もり・発注範囲	発注書	N0 / N1
計測設計	GA4 CV 定義・BQ / Looker 土台	計測設計メモ	N6 / R1
公開準備	タグ動作確認・公開判定	公開チェックリスト	—
公開後グロース	30 日計測・改善サイクル	レポート土台	N6

まとめ｜発注前チェックリスト

本記事では、Web 制作を依頼する前に決めておくことを「目的・要件・計測」の 3 点で整理してきました。発注前チェックリストとして、最低限の項目を再掲します。

• 目的を一つの KGI に翻訳し、KPI と計測イベントまで分解したか
• 掲載コンテンツ・ページ構成・依頼範囲・素材の責任分界を発注側で握ったか
• GA4 の CV 定義とフォーム計測を要件に含めたか
• BigQuery エクスポートと Looker Studio の土台を立ち上げ前に決めたか
• 計測タグを誰が実装するかを発注前に決めたか

この中で発注前チェックリストの多くが触れていないのは、後半の計測まわりです。計測を最初から要件に含めることが、公開後の手戻りを減らし、改善サイクルの立ち上がりを早める独自の判断軸だと考えています。

サイト全体の立ち上げ判断が固まったら、次は集客導線としての LP 設計です。LP の外注先選びは 事業会社マーケが選ぶLP外注先 で整理しているので、本記事の次の一歩として参照してください。

私自身、計測まで含めて発注前に決めておいた案件は、公開後の改善サイクルが回しやすかったと感じています。立ち上げ前の準備が後工程を楽にする、というのが実務を通じた実感です。