【Webディレクター】結局何をどこまでやるの？仕事の流れを詳細に解説！

皆さんは「Webディレクター」と言われて何を想像しますか？
おそらく大体の方が思い浮かべるのは「工程やクオリティの管理をする仕事…？」だと思います。

結論から言うと、その認識で大体は有っていますが、少し抽象的なのでこの記事では弊社のWebディレクターが行っている業務フローを例に、更に詳細に解説します。

クライアントとの打ち合わせ

まずはお問い合わせをいただく・または受注するところからWebディレクターの業務はスタートします。

クライアントからの課題や要望を打ち合わせにてヒアリングし、現状のサイト分析と照らし合わせます。

弊社ではヒアリングシートを用意しており、お打ち合わせまでに記入していただくことで初回の打ち合わせをただの顔合わせではなくより実りの多いものにしようと考えています。

– サイト分析

クライアントから提供いただいたGoogle アナリティクスのデータを基に分析します。

ここで重要なのは、前述したようにクライアントからの課題・要望と照らし合わせることです。

webサイトのデータを見ることで、課題をより詳細に深堀りしピラミッド構造 (イシューツリー) を作成し、「何が改善されれば課題をクリアできるのか」がより明確になります。

ロジックツリーとは、何らかのテーマについて議論をする上で、より具体感をもって全体像を把握する必要があるときに使われる。
コンサルティングにおいては特に論点整理 （＝解くべき問いの整理） を行う上で使われることが多く、その場合はイシューツリーとも呼ばれる。

ロジックツリー・イシューツリー （論点ツリー）

また、クライアントが抱える課題 (顕在化された課題) 以外にも、データを参照することで見えてくる課題 (潜在的課題) も見えてくるので、そういった課題の優先順位を見極めることも出来ます。

– 企画書・スケジュール案・お見積書作成、プレゼンテーション

Google アナリティクスのデータを見て改善できる点を把握したら、次は企画書作りです。

クライアントにわかりやすく課題と改善策を理解してもらえるよう、企画書はPREP法に習い作成してみましょう。

PREP法とは、「結論 （Point） →理由 （Reason） →具体例 （Example） →結論」の順番で話を展開するフレームワークのこと。
PREP法を修得すれば、要点をつかんだわかりやすい文章が書けるだけでなく、説得力のあるプレゼンテーションができるようになります。

「PREP法」なら誰でも論理的な文章が書ける！

プレゼンテーションを行う上で気をつけたいのが、専門用語をなるべく使わない様にすることです。

Web制作を行っていると当たり前に知っているような用語でも、それはあくまでIT業界の話なので、他業種のクライアントにとっては理解できない言葉のほうが多いです。
そういった言葉を多用してしまうと理解が追いつかず、十分な納得感が得られず理解しようとするのを諦めたり、お互いの間で認識違いを起こしてしまうので極力避けましょう。

また、企画書と共に概算のスケジュール案も一緒に提出します。

弊社ではクライアントと簡単に共有でき、遅延が起きた際も迅速に共有できる様Google スプレッドシートにてスケジュールを作成し共有しています。

サイト構成と制作前の整理

プレゼンテーションを行い、無事受注が確定したら、サイト構成を更に詳細なものにします。
制作に入る前に、より円滑に制作を進められる様情報整理と素材の如何を確認しておきましょう。

– サイト構成

ここでは、サイトをどの様に制作するのかを形にしていきます。

どの様なページ構成で、どのシステムを使うのか (またはスクラッチなのか) 、クライアントが簡単に運用できる様にするためにはどの様な投稿機能が必要か等、詳細に設計していきます。

ここでも弊社ではGoogle スプレッドシートを使用し、サイトマップやカスタム投稿機能の詳細などをまとめています。

– 提供素材の有無・各情報の確認

現在のサーバー情報やシステム情報の確認、各ページに表示する画像素材の有無を予めクライアントへ確認します。
クライアント側で素材を保持している場合はそのまま頂くことが出来ますが、保持していない場合、有料 (または無料) 素材のみで作成するか、弊社で撮影まで行うかを別途提案しています。

弊社で撮影となる場合はカメラマンをアサインし、工程表と絵コンテを作成しカメラマンに撮影してほしい素材のイメージを共有します。
撮影当日もディレクターとして同行します。

– ワイヤーフレーム作成

サイト構成が決まったら、ワイヤーフレーム (設計図) を作成します。
ここで重要なのは、ワイヤーフレームはあくまで設計図であり、デザインしてはいけないということです。

Webディレクターはデザイナーではないので、あまりに作り込むとデザイナーにとってノイズになってしまいます。
ワイヤーフレームの段階ではUIの部分に注力し、必要なパーツ (各headlineやcommon button等) のフォーマットや、コールトゥアクション (以下CtA) の仕様、ヘッダー/フッターの仕様等に重きを置いて制作します。

ワイヤーフレームが完成したら、クライアントへサイト構成を説明しましょう。

サイトデザイン作成

ワイヤーフレームをクライアントに確認してもらい、承認を得たらいよいよデザイン作成です。
デザイナーへデザイン制作を依頼する際に、必ずページの役割や、システム上のデータの反映のされ方など、入念に打ち合わせします。

また、スマートフォンで閲覧した際のヘッダーメニュー等の仕様なども詳細に伝えましょう。
デザインする際に参考となるサイトデザイン案を用意しておくと、デザイナーとサイトデザインのイメージ共有がしやすくなります。

プロジェクトによってはデザイナーがワイヤーフレーム作成から参加することもあります。
この場合はクライアントから初期段階でラフデザインでの確認がしたいとの要望や、ECサイトなどのシステマチックなサイト制作の際に有効となります。

開発

クライアントからの修正が完了したら、Webディレクター・デザイナー・エンジニアで打ち合わせを行います。

ここではシステムで登録したコンテンツがデザインでどのように反映されるかや、パーツキットの説明、デザインルールの説明をエンジニアに伝えます。

– 静的コーディング

まずは静的にサイトを作成していきます。

Webページを適切に検索結果ページへ反映させるためにはマシーンフレンドリー (ここでは検索エンジンに取って理解しやすい、という意味で使用します) なページにするためにセマンティックに構築していきます。

Webディレクターとしての役割は、構築されたページがマシーンフレンドリーかどうかのコードレビューをエンジニアと共にします。

– システム開発

サイトに組み込むシステムを構築していきます。

WordPressやmovable TypeなどのCMSや、EC-CUBEやshopifyなどのオープンソースASPなどを使用する場合や、フレームワークを使用したスクラッチ (新規開発) など、システムと言っても多岐に渡りますが、サイト構成時に要件定義した内容で開発していきます。

各ポストタイプやクライアントの要件に有っているか・足りないデザイン要素などないかを社内テストしていきます。

本番公開・運用

クライアントへのレクチャー・テスト運用を行った後、いよいよサービスを公開します。
本番公開後は、機能改善を目的とした追加実装や、Google アナリティクス等での定月分析による改善策の提案をし、PDCAサイクル (Plan (計画) Do (実行) Check (評価) Action (改善) ) を回していきます。

-テストアップ

システム開発・社内テストを行ったら、テストアップしクライアントに運用レクチャーを行い、テスト運用してもらいます。
また、ここで出た軽微な修正を行い、本番公開に向け調整します。

– クライアントレビュー

本番公開後、運用していく中で発生した機能的改善点は、追加実装としてサービスをアップデートしていきます。

– 定月分析・PDCAサイクル

Google アナリティクス等の分析ツールによる定月分析を行います。
提案時に設定したKPI (重要業績評価指標) が達成されているか、想定通りの動きをしているかをチェックし、レポートします。

定月分析していく中で顕在化した課題は改善策を提案し、PDCAサイクルを回していくことで着実に指標を達成していきます。

まとめ

いかがだったでしょうか？

こうしてまとめてみると意外と工程が多かったので自分でも驚いています。
「こんな沢山の業務出来ねーよ！」と思った方も多いと思います。

初めてのディレクションは自分自身目が回る思いでしたが、Webディレクターの良いところは多数のツールやテンプレートを用いてスキームを効率化する事ができる点です。

また、経験してきたことがナレッジとしてストックされていき、似たようなプロジェクトに参画した場合、非常に効率よく回せるようになることもWebディレクターをやってきて成長を感じる点の一つでもあります。

効率化することで複数のプロジェクトを回す事もできるようになり、クオリティの向上に力を入れることができるようになりますので、失敗を恐れず取り組んでいきましょう。