WEBディレクションは何から始める？事業会社の担当者が押さえるべき全工程と実践ポイント

「社内のWEBサイト、誰がどう進めるべきなんだろう」「制作会社に丸投げしがちで、社内で何を決めておけばいいかわからない。制作スケジュール管理だけじゃないの？」という声を事業会社の現場からよく聞きます。

私もそのような疑問にお答えする形でこれまで研修や講義を複数社に対して行ってきました。今回はその研修の一部を皆さんにもお届けできればと考えております。

本記事では、事業会社の社内WEBディレクションに必要な基礎知識を、業務フローに沿って体系的に解説します。

本記事のターゲット

• 事業会社で初めてWEB関連業務を担当することになった方
• 社内WEBディレクターとしての役割・業務範囲を体系的に理解したい方
• 制作会社とのやり取りで「何を決めておくべきか」を知りたい方

事業会社の社内WEBディレクターとは

一般的なWEBディレクションとの違い

WEBディレクションとは、WEBサイトの制作・運営において指揮監督業務を行うことです。具体的には以下の業務を担当することが多いです。

• 制作スケジュールの管理

• 各工程の指揮

• プロジェクト全体の品質管理

しかし、これはあくまでWEBディレクションの一般的な定義になります。

事業会社の社内WEBディレクターには、上記に加えてさらに3つの役割が求められます。

• 社内の関係部門や経営層との調整・合意
• 外部パートナーやお客様との連携
• 課題の可視化と解決策の提案・推進

つまり、社内WEBディレクターは一般定義に加えて「事業課題を発見・解決するリーダー」として社内外を巻き込む役割を担います。

社内WEBディレクターが担う6つのマネジメント

社内WEBディレクターは業務において以下の6つを主に扱います。

1. スコープ：プロジェクトの範囲を定義し、何を作り何を作らないかを明確にする
2. コスト：費用対効果を最大化する予算の把握と配分を行う
3. ヒューマン：社内外のメンバーの能力発揮・モチベーション・負荷管理を行う
4. リソース：人・物・時間などのリソースを最適に配置・活用する
5. コミュニケーション：社内の関係部門・経営層をはじめ外部関係者との情報伝達を円滑にし、認識のズレを防ぐ
6. クオリティ：潜在的なリスクを事前に洗い出し、対策を講じる

施策の企画・開発・実行をする方々の数には限りがありますし、契約時間内・費用内で収める必要があります。

つまり、プロジェクトには制約が必ず伴い、その制約内で収まるスコープを見定め、高いクオリティの施策を関係者と協力しながら作り上げることが求められます。

WEBディレクションの業務フロー

WEBディレクションの業務フローは、「企画・要件定義」「社内決裁」「構成・デザイン」「コーディング」「テスト・本番化」「運用・改善」の大きく6つのフェーズで構成されます。各フェーズで押さえるべきポイントと成果物を順に見ていきましょう。

フェーズ1：企画・要件定義

最初のフェーズでは、解決すべき事業課題の定義をしっかり行います。課題を解決する戦術を5W1Hで定義し、費用対効果・スケジュール・実現性が明確に言語化された状態を目指します。

進め方のポイント

• 解決すべき課題は事業戦略テーマと接続させる
• 社内有識者やお客様へヒアリングし、戦術を具体化する
• 制作するWEBサイトのパターンを確定し、スケジュールに手戻りのバッファを織り込む

WEBサイトの6つのパターン

制作するWEBサイトは、解決したい課題によって大きく6つに分類され、それぞれに求められるゴール・工数・影響範囲が異なります。

例えばランディングページ(LP)であれば、お客様の問い合わせを増やす上での課題を解決することがゴールであり、1枚で完結することが多いため工数は少ない、一方で一般のお客様の目に触れるリスクがあるため影響範囲が広めであるWEBサイトという特性があります。

課題ごとに作るべきサイトの仕様が大きく異なるため、企画段階でサイトパターンを見極めることが重要です。

• コーポレートサイト：企業情報の発信・ブランディングの拠点。IR・採用・ニュースなど信頼性ある情報を一貫したトンマナで表現
• サービスサイト：商品・サービスの紹介・販促が目的。機能・料金・導入事例などCV獲得を意識した設計
• オウンドメディア：SEO対策した記事を複数本投稿し、認知・リード獲得を目指す
• ランディングページ（LP）：特定のCV獲得に特化した1ページ構成。キャンペーン・資料DL等を設置
• 外部サービス利用サイト：EC、SNS、SaaS等のプラットフォーム活用。運用効率と拡張性が高いが要件の柔軟性は低い
• イントラ/エクストラネット：社内・取引先向けの情報共有サイト。法規や勤怠、システム規定等を集約

主な成果物

• 企画書：課題、目的・KGI/KPI、ターゲット・5W1H、戦術、費用対効果を記載した、決裁・すり合わせのたたき台にする

• 要件定義書：システム・技術・品質・運用・セキュリティなどの要件を定義し、開発の方向性を固定する。変更は手戻りのもとになるため、合意のうえで確定版を管理する

• プロジェクト概要：背景・目的、スコープ、体制、成果物・納期、コミュニケーション方法を記載し、「何のプロジェクトか」「誰が何をするか」を共有する

フェーズ2：社内決裁

作成した企画書・要件定義書を踏まえて、経営層はじめ決裁者へプレゼンテーションを実施し、費用投資を合意するフェーズになります。

経営層はじめ決裁者は本案件以外でも多くの決裁を行なっています。ゆえに難しい内容は忘れやすく、フィードバックした内容も細かく覚えていられません。これは人間である限り当然のことです。

ぬけ漏れなく分かりやすいプレゼンテーションを行い、受けたフィードバックを必ず議事録に残すことが大切です。

進め方のポイント

• 決裁者視点でわかりやすい資料・プレゼンテーションにする。内容は事前に会議参加者に共有する
• 参加者間の認識を揃えるため、決定事項・宿題事項を漏れなく議事録に残す

主な成果物

• 決裁稟議書：予算・スケジュール・範囲などの承認を依頼する稟議・申請文書。承認後にプロジェクトを正式開始する根拠となる
• キックオフ資料：ミッション・ゴール、体制・役割、確定・未確定事項、リスク・前提をまとめ、関係者内で認識を揃える

• 会議議事録：日時・参加者、議題、議論・決定事項、アクション（担当・期限）を記録し、「何が決まったか」を後から参照できるようにする

フェーズ3：構成・デザイン

要件定義を基に、情報設計（IA）とワイヤーフレームで構成を固め、デザインを作成するフェーズです。構成の骨組みを作ってからデザインに進む順序が重要です。

特にこのタイミングで注意したいのは「実装工数を超えて、納品物の理想を高く求め過ぎてしまうこと」です。時には会社のデザインガイドラインから逸脱してしまうことや、次工程に控えるコーディングコスト・既存基盤環境での実現可能性を軽視してしまうことがあります。

担当者自らが必ずチェックするとともに、必ず違和感を持った誰かが発言しやすい場づくりを意識し、コーディング担当の声も取り入れていきましょう。

進め方のポイント

• スコープ内の装飾・機能・品質で収まっているか確認する

• 会社のデザインガイドラインやコーポレートカラーを踏まえて作業する

• 違和感をすぐに発言・相談できる心理的安全性を担保し、コーディング担当者の意見も取り入れる

主な成果物

• ワイヤーフレーム：ページのレイアウト・構成を線やブロックで示した設計図。見出し・本文・画像・ボタン・ナビの配置を装飾を抑えて表現する。Figma・Sketch・XD・PPT・紙などで作成
• モックアップデザイン：ワイヤーで決めた構成に色・フォント・画像・余白・トンマナをのせ、本番に近い見た目で仕上げたデザイン（デザインカンプとも呼ばれる）
• 画面遷移図：ページ間のつながり・遷移の流れを図にしたもの。リンク・ボタン・フォーム送信などのトリガーと遷移先を矢印で示す

フェーズ4：コーディング

要件定義・モックアップデザイン・画面遷移図に合わせて、実際にWEBサイトで動作する実装を行うフェーズです。コンポーネントの仕様書をはじめ、問題発生時に追跡しやすいドキュメントも併せて整備します。

またこのタイミングで注意したいのは、ユーザーが直接触れる「フロントエンド」と、裏側の処理を担う「バックエンド」の2層構成でコーディングが実施される点です。もし仕様変更が伴った際には、どこに影響が出るのか、実装内容を踏まえた指示が重要となります。

例えば「ページ上のアニメーション動作をカルーセル形式にする」などの変更はフロントエンドにおけるJavascriptで解決する事象であることが多いです。一方で、「入力フォームの項目を一つ足す」などの変更はフロントエンドも、その後のデータベース登録に関わるバックエンドにも変更が伴います。

進め方のポイント

• 手戻りを防ぐため、デザインが確定したものから着手する
• 作業が見えづらいため、実働の進捗・負荷を定期的に確認する
• 社内の命名規則・ファイル構成・コーディング規約などを実例を踏まえて共有し、技術的負債が生まれないよう意識する

主な成果物

• コンポーネント仕様：UIパーツ（ボタン・ヘッダー・カード・フォームなど）の見た目・状態（通常・ホバー・無効などの動作）・クラス名・使用ルールを定義し、実装・問題解決の効率化を図る
• フロントエンドコード：HTML（構造）・CSS（見た目）・JavaScript（動き）で、デザインに沿ってページを実現する。レスポンシブ・アクセシビリティ・表示速度も対象
• バックエンドコード：フォーム受付・メール送信、認証、DBの読み書き、外部API連携など画面に直接出てこない処理を担当。PHP・Ruby・Python・Node.jsやCMSなどで実装

フェーズ5：テスト・本番化

ついにWEB上に開発した資材を載せるフェーズです。

テスト環境にてテストする項目をあらかじめ仕様書にまとめ、表示・動作の検証等を行い、修正後に本番環境へ移行しましょう。

お客様の目に入る状態になるということは細心の注意が必要です。

バージョン管理は必ず行い問題が発生したら即時きり戻せる状態にし、リリース確認時には上長や社内関係者に協力を仰ぐなど徹底していきましょう。

進め方のポイント

• バージョン管理もしくは元ファイルのバックアップを取り、問題発生時に切り戻せる状態を担保する。切り戻し手順もまとめておく

• なるべく社内の多くの人にテスト段階でチェックを仰ぎ、精度を上げる

• 本番化はお客様影響（利用）が少ない時間帯で実施する

主な成果物

• テスト仕様書：実施するテストの種別・観点・環境・担当・合格基準をまとめた文書。表示確認（PC/SP・ブラウザ）、動作確認（リンク・フォーム・遷移）などを定義する
• チェックリスト：表示・動作・リンク・ブラウザ対応・必須文書・計測タグなど、項目ごとに結果（○/×）を記入する
• リリース手順書：デプロイの順序、バックアップ、DNS・サーバー設定、反映後の確認、ロールバック手順を記載する

フェーズ6：運用・改善

リリースしたらプロジェクト完了ではありません。

本番公開後にコンテンツ更新・保守・データ分析・改善施策を続け、企画で掲げた目標の達成を目指す本フェーズも重要な役割を持ちます。

一方でWEBサイトなどモノとして成果が見えづらく、目標数値を改善していくフェーズになります。特に決裁者・関係者は「制作物がどうなっているのか・上手くいっているのか」気になる方も多いはずです。KPIダッシュボードや進捗報告書を作成し、活動が成果につながっていることをしっかりと周知させることが大切です。

進め方のポイント

• プロジェクトメンバーの成果を定期的に可視化し、決裁者に伝える
• ダッシュボード等のツールのチェックタイミング（例：週1回）を決めておく
• 数値の定期モニタリング、「なぜか」の深掘り、PDCAサイクルが重要

運用・改善で使う主なツール

運用・改善で使う主なツールは以下の3つになります。

• Google Analytics（GA4）：アクセス解析ツール（無料）。セッション・PV・流入元・CVなどを計測し、KPI確認や改善の根拠に使う
• Google Search Console：検索向けサイト管理ツール（無料）。表示回数・クリック・順位・キーワード・インデックスを確認。GAと併用すると効果的
• Hotjar / VWO 等：クリック・スクロールなどのサイト内行動を可視化したり、A/Bテストを容易に設定できるツール

主な成果物

• 運用保守マニュアル：CMSの更新、問い合わせ対応、不具合時の連絡先を書き、担当が替わっても同じ手順で運用できるようにする
• KPIダッシュボード：アクセス数・CV数・離脱率などを期間別に集計しグラフ化。経営層や関係者が現状把握し、判断材料にする
• 改善進捗報告書：改善施策の内容・進捗・効果を記録し、週次・月次などで提出する

法務・コンプライアンス

これまで各業務フローにおける作業内容を解説してきました。一方で、WEBディレクションにおいてもう一つ大切なことがあり、それが「法務・コンプライアンス」です。

昨今では個人情報や著作権の取り扱いへの監視の目が厳しくなっています。さらには、サービスの料金を想定以上に割り引くなどお客様の誤認を誘発する悪徳業者を取り締まる観点も厳格化されています。

一方で最近では「カスハラ」という言葉も流行っているように、下請業者への必要以上の圧力は下請法違反に抵触することがあります。

せっかく良いものを作っても法やコンプライアンスに抵触して棒に振ることがないように、必ず以下の5つの観点を中心にチェックしながら業務フローを遂行しましょう。

1. 個人情報管理

問い合わせ・会員・メール配信・解析などで個人情報を扱うため、個人情報保護法に沿った設計が必要。取得目的の明示、プライバシーポリシーの整備・順守、同意取得、オプトイン・オプトアウトの実装が不十分だと、行政対応や信頼損害のリスクが生じます。

2. 表示義務・必須文書

利用規約・プライバシーポリシー・特定商取引法に基づく表記など、掲載が求められる文書を欠いたり内容が不十分だと、行政対応や取引リスクにつながります。サイトの種類に応じて必要な文書を洗い出し、要件・構成の段階で掲載場所と内容を確認しましょう。

3. 著作権・肖像権

写真・イラスト・フォント・文章・人物写真の無断利用や許諾範囲を超えた利用は、差止・損害賠償・刑事リスクの原因になります。使用素材の権利確認と許諾取得をデザイン・制作前にチェックし、素材リストで権利・許諾の管理を徹底しましょう。

4. 景品表示法

優良誤認・有利誤認となる表示は禁止されています。価格・割引・効果・性能などの表現が実態と合っていないと問題になります。特に企業ごとにスタンスが異なるケースがあるため、販促表現が事実に基づいているか、根拠を示せるかを確認し、必要なら法務・コンプライアンス担当とすり合わせるようにしましょう。

5. 下請法

WEB制作・運用を外注する場合は親事業者として、発注内容・代金・支払期日などを書面で交付し、支払遅延や不当な減額を避ける義務があります。特にやってしまいがちな、発注先メンバーへの直接依頼はNGです。必ず先方の管理者を通じてメンバーへの指示を行うなど依頼ルートを明確にし順守しましょう。

まとめ

事業会社の社内WEBディレクションの全体像を踏まえ、実践のポイントを整理します。

社内WEBディレクターは「事業課題を解決するリーダー」である

単なる制作スケジュール管理だけでなく、スコープ・コスト・ヒューマン・リソース・コミュニケーション・クオリティの6つのマネジメントを駆使し、社内外を巻き込みながら事業課題の解決を推進する役割です。

「企画・要件定義」→「社内決裁」→「構成・デザイン」→「コーディング」→「テスト・本番化」→「運用・改善」の各フェーズには、それぞれ押さえるべきポイントと成果物があります。とりわけ企画・要件定義の段階で5W1Hを明確に言語化することが、後工程の手戻りを最小化する鍵になります。

法務リスクを軽視しない

個人情報管理、表示義務、著作権・肖像権、景品表示法、下請法の5つの法務リスクは、プロジェクトの成否だけでなく企業イメージに直結します。制作フローの早い段階から法務・コンプライアンス担当を巻き込むことが重要です。

本記事がWEBディレクターとして、社内外を巻き込みながら課題解決をリードする第一歩を踏み出す一助になれば幸いです。

よくある質問