Webサイト制作前に社内で確認すべきこと

Webサイト制作を社外へ相談する前に社内で確認したいことは、ばらばらに洗い出すより、1. 目的・課題・対象範囲 → 2. 現状把握と課題の切り分け → 3. 関係者・役割・承認フロー → 4. 社内で最低限そろえたい相談前情報 → 5. 予算・納期・社内工数・優先順位 → 6. 公開後運用の順で整理すると進めやすくなります。最初に目的と承認ルートを固めておくと、見積もりや提案の比較条件がぶれにくくなり、手戻りも減らせます。

この記事では、この6項目を会議や社内調整に使える形で整理します。読後には、制作会社に相談する前に何を決め、何を未確定のまま持ち込んでよいかを切り分けられるようになります。

制作会社に相談する前の社内確認は、6項目を順番に整理すると判断の前提がぶれにくくなります。冒頭で全体像を押さえることで、各章の役割を理解しやすくなります。

01Sectionまず6項目の全体像をつかむ

Webサイト制作の相談前準備は、思いついた順ではなく、前の判断が次の判断の前提になる順で見ると進めやすくなります。

この順番は基本形です。すでに決まっている項目があっても、「1. 目的・課題・対象範囲」と「3. 関係者・役割・承認フロー」は先に確認しておくと、後の比較や承認がぶれにくくなります。

02Section1. 目的・課題・対象範囲を整理する

最初に整理したいのは見た目の好みではなく、目的・課題・対象範囲です。やることとやらないことを分けると、相談内容や見積もり条件がぶれにくくなります。

最初に整理したいのは、見た目の好みではなく「何を変えたい案件なのか」です。

目的は1〜3個に絞る

目的は多いほど網羅的に見えますが、実務では判断を難しくします。まずは1〜3個に絞り、「誰に、何を、どう変えたいか」を1文で言える状態を目指してください。

たとえば「今っぽいサイトにしたい」では社内合意が取りにくく、制作範囲も膨らみがちです。代わりに、「比較検討中の法人担当者にサービス内容を伝わりやすくし、問い合わせにつながる導線を整える」のように、対象と変化をセットで置くと議論しやすくなります。

背景課題も、抽象語ではなく業務上の支障に言い換えるのが有効です。たとえば「情報がわかりにくい」より、「営業が初回商談で毎回同じ補足説明をしている」のほうが、制作で改善したい理由が明確になります。

今回やることと、やらないことを分ける

対象範囲は、次の3つに分けるだけでも十分です。

• 今回やること
• 今回やらないこと
• 後続で検討すること

この切り分けがないまま相談に進むと、見積もり条件と社内承認条件がずれやすくなります。新規制作でもリニューアルでも部分改修でも、まずは「今回どこまでやるのか」を暫定で決めることが重要です。

目的に合わせて成果確認の軸を置く

目的が違えば、公開後に見るべき成果も変わります。検索面の変化は Search Console の Performance レポート でクリック数・表示回数・CTR・平均掲載順位を確認できます。問い合わせや資料請求などの重要行動は、GA4 の key event の考え方で継続確認しやすくなります。

数値目標まで厳密に決め切れなくても、どの指標を主に見るかは相談前に置いておくと、提案の方向性がそろいやすくなります。

03Section2. 現状把握と課題の切り分けをする

現状把握では、課題の有無だけでなく、Web制作で対応しやすいか、別施策も必要かを分けて考えることが重要です。先に切り分けると、対象範囲の見立てがしやすくなります。

次に必要なのは、「今のサイトの何が問題か」を事実ベースで整理することです。ここが主観だけだと、全面リニューアルが必要なのか、部分改修で足りるのかも判断しにくくなります。会議では、課題の説明と同時に「Web制作で対処しやすいか」「別施策も必要か」まで分けて話せる状態を目指してください。

見る観点は4つに絞る

現状把握は、少なくとも次の4観点で見ると整理しやすくなります。

検索流入の変化は Search Console、問い合わせや資料請求などの重要行動は GA4 で見やすくなります。表示体験を確認する場合は、PageSpeed Insights で実ユーザーデータと検証用データが分かれている点を押さえておくと、体感の遅さと技術診断を混同しにくくなります。

解析が弱い場合の最低限の確認材料を集める

アクセス解析が十分でないと、現状把握ができないと思われがちです。ただ、相談前の段階で必要なのは、完璧な分析よりも課題仮説を置けるだけの材料です。

部分改修か全面見直しかを見立てる

判断のポイントは、ページ単体の問題か、サイト全体の構造や運用まで影響しているかです。特定ページの説明不足やCTAの弱さが中心なら部分改修で足りる場合があります。一方、複数部門から継続的に不満が出ている、情報分類が古い、更新運用が全体で重い、といった状態なら全面見直し寄りです。

先に「全面リニューアルありき」で進めないことが大切です。問題の広がり方を見て、どこまでを今回の対象にするかを絞るほうが、相談の精度は上がります。

04Section3. 関係者・役割・承認フローを整理する

社内調整で止まりやすい案件は、関係者が多いことより、役割の違いが曖昧なことが原因になりやすいです。誰が決めるのか、誰に確認するのか、誰が実務を持つのかを分けて整理しておくと、差し戻しを減らしやすくなります。

役職名ではなく、役割で整理する

部門名の列挙だけでは不十分です。実務では、RACI の考え方 のように、実行する人、最終責任を持つ人、相談先、共有先を分けて見ると整理しやすくなります。

先に確認したい論点をそろえる

部門ごとに見たい論点も、相談前に簡単に整理しておくと進みやすくなります。たとえば、経営層・決裁者には投資目的と優先順位、営業にはよくある質問や商談前に必要な情報、情シスにはドメインやサーバー、権限や連携、法務にはフォームや表記ルール、更新担当にはCMS運用や公開後の更新フローを確認します。

確認者と承認者を同じだと思い込まないことも重要です。公開直前に差し戻しが起きる案件は、この区別が曖昧なまま進んでいることが少なくありません。

承認フローは短くても先に置く

承認フローは複雑である必要はありません。最低限、次の流れが決まっていれば、相談先にも前提を伝えやすくなります。

1. 1起案者が目的・背景課題・対象範囲のたたき台を作る
2. 2関係部門へヒアリングして論点を補う
3. 3進行責任者が優先順位案をまとめる
4. 4決裁者が予算・納期・進め方を承認する

この4段階が見えているだけでも、「誰待ちで止まるか」を把握しやすくなります。

05Section4. 社内で最低限そろえたい相談前情報

複数社比較では、金額だけでなく前提条件を揃えることが重要です。対象範囲や原稿準備、CMS対象などを同じ軸で見ると、提案差の理由を把握しやすくなります。

制作会社に相談する前に必要なのは、詳細仕様の完成ではなく、比較しやすい条件をそろえるための最低限の情報です。特に、目的・対象範囲・体制・比較条件が揃っていないと、提案や見積もりの差が「会社の違い」なのか「前提条件の違い」なのかが見えにくくなります。

先に決めることと、相談しながら詰めることを分ける

先に決めたいのは、目的、背景課題、対象範囲、優先順位、承認ルート、比較条件です。一方、詳細なワイヤー、具体的なデザイン、細かなCMS運用方法、実装手段は、相談しながら詰めやすい領域です。

この切り分けがあると、準備不足の不安で止まらずに済みます。逆に、先に決めるべき項目が曖昧なままだと、見積もり条件が揃わず比較しにくくなります。

複数社比較でそろえたい前提条件

比較のときは、金額だけを見るのではなく、何が含まれているかを揃えることが大切です。

フォームで個人情報を直接取得する場合は、利用目的を送信前に確認しやすい形で示す配慮が求められます。詳細は 個人情報保護委員会のFAQ で確認できます。セキュリティ要件も後回しにせず、フォームや外部連携がある場合は OWASP ASVS のような参照先をもとに、相談前の確認項目へ入れておくと比較しやすくなります。

そのまま使える相談前1枚シート

以下の表は、社内会議と初回相談の両方に使える簡易版です。埋め切らなくても構いませんが、空欄が多い項目ほど、相談時に「まず社内で決めるべき論点」として扱いやすくなります。

06Section5. 予算・納期・社内工数・優先順位を整理する

予算やスケジュールは、固定の相場で考えるより、何が変動要因になるかを先に整理したほうが社内説明しやすくなります。対象範囲、素材の準備状況、承認者の数、CMSや連携の有無、法務・情シス確認の重さで、必要な費用と期間は変わります。

計画段階で予算やリソース、レビュー、関係者連携を見込む考え方は、W3C の Plan でも整理されています。Web制作でも、制作費だけでなく社内側の準備と確認にどれだけ時間がかかるかを含めて見ることが重要です。

先に見るべきは、費用と期間を動かす要因

外部発注費だけでなく、社内工数と公開後の運用費も分けて考えてください。特に、原稿を誰が書くか、写真や事例を誰が集めるか、レビュー窓口を誰が一本化するかが決まっていないと、社内側がボトルネックになりやすくなります。

社内工数が膨らみやすい作業を先に押さえる

Must / Should / Not now で優先順位を決める

機能やページを「やりたい順」で並べるだけでは、現実的な計画になりません。公開に必須か、後から分離できるか、確認に時間がかかるかで分けると判断しやすくなります。

公開に直結し、後から分離しにくく、担当者も決まっているものは Mustです。効果は高いが後追い可能なものは Should。目的との関係が薄い、または前提条件が未整理なものは Not now に置くと進めやすくなります。

最後に、「予算・納期・要件のどれを最優先にするか」を1つ決めると、社内期待値を合わせやすくなります。たとえば公開時期が最優先なら範囲を絞る、要件が最優先なら時期を見直す、といった調整がしやすくなります。

07Section6. 公開後運用を制作前に考える

制作前の段階で公開後運用まで考える理由は、作って終わる状態を防ぐためです。公開後に細かい改善案まで決め切る必要はありませんが、最低限の運用責任が曖昧だと、更新停止や問い合わせ対応漏れにつながりやすくなります。

W3C の Planning and Managing でも、責任分担、監視、進捗確認、継続的見直しを回す考え方が整理されています。BtoBサイトでも、担当者と確認サイクルを置いておくと止まりにくくなります。

制作前に最低限決めること

公開後に調整しやすいこと

一方で、詳細なレポート形式、細かな会議体、追加コンテンツ案、改善テーマの優先順は、公開後に実データを見ながら調整しやすい項目です。相談前にすべてを決め切ろうとせず、止まりやすい箇所だけ先に押さえる考え方が現実的です。

兼任運用でも止まりにくい最小ライン

兼任運用のケースでは、更新対象を絞る、権限を明確にする、月次で見る指標を増やしすぎない、改善要望の窓口を1つに寄せる、という4点だけでも運用はかなり安定します。