webディレクターの仕事内容。対クライアントアウトプットで紹介。

webディレクターという仕事は、やることが多岐に渡ります。

また求められる能力としても、コミュニケーション能力、企画提案力、進行管理能力などこれもまた多いです。

今回はwebディレクターになると、具体的にどういうことをするのか。

webサイトリニューアルを行う際に作るアウトプットベースで紹介しようと思います。

アウトプットとは、一言で言えば、お客さんや制作関係者に提示する資料のことと考えてもらえれば大丈夫です。

近年は、Backlog等のプロジェクト管理ツール、Googleのスプレッドシートなどオンラインで管理できるものも含まれていますが、内容としてこういうものが必要、という観点で見てもらえればです。

webディレクターが「アウトプット」を把握しておく理由

その前に。

「何を成果物として作るのか？」ということはプロジェクトの最初に定義をしておいた方がいいです。

なぜなら、それはそのままプロジェクト計画や要件定義に直結するからです。

プロジェクトによっては、作る必要がないものもあります。

クライアント側も、制作会社からどういうものが提示されるのか、提示されたものをどういう観点で見ればよいのか、ということを結構気にされます。

これ本当によくある話です。

都度都度状況により、あれも出てきた、これも出てきたってなると、クライアント側も、各資料の関係性を追っかけられず、「この資料はなんのためにあるのか？」「以前作った資料は何のために必要だったのか？」というあらぬ心配をかけることになりかねません。

以下のものは、webサイトリニューアルを行うときに、案件規模かかわらず、例外なく作っておいた方が良いものです。それぞれについて簡単に内容を説明をします。

※ものによっては、追って詳細説明を別記事で作成しようと思います。

1. 要件定義

1-1. プロジェクト計画書

このプロジェクトが全体として何を目的としてどのように進むのかを定義したものです。

• 体制図
• スケジュール概要
• ターゲットユーザー
• 制作スコープ概要
• 目指すゴール

1-2. サイト基本仕様書

webサイト仕様の基本対応項目として想定している内容です。 予め制作側から提示をし、もし齟齬があれば、修正します。 内容によっては、見積にも影響します。

あくまで基本対応項目であって、サイト個別で変わってくるコンテンツや、サイト設計、デザイン等の内容は含まれません。例えば下記のようなものです。（全部ではありません。）

• 対象OS
• 対象ブラウザ
• テスト検証端末
• 印刷対応
• アクセシビリティ対応
• SEO対応
• スマホやタブレット対応方針

1-3. コンテンツマップ

今回のリニューアルで、どのくらいのページをどう作るのか、ということを一覧で定義したものです。

• デザイン制作有無
• 画面設計書作成有無
• CMSによる機能化有無
• バックエンドシステム実装有無
• コンテンツ提供有無
• 画像パーツ作成有無・点数

といったことを整理しておきます。こちらを元に、最終的な見積にして調整し、クライアントとすり合わせます。

1-4. WBS（作業工程表）

Work Breakdown Structureの略で、作業工程表とも言われます。

「スケジュール」とは違う意味合いのもので、今回のwebサイトリニューアルプロジェクトで、どういうタスクが発生するのか。そのタスクをすべて洗い出したものになります。

タスクの粒度としては、「ページ単位」というよりは「やること単位」のイメージです。

WBSでは、制作側のタスクだけではなく、クライアント側のタスクも洗い出すことが大事です。

こちらをプロジェクトの最初の段階で提示し、こちらでやること、クライアント側にしてもらうことのイメージを持ってもらうことが大事です。

1-5. 詳細スケジュール

WBSで洗い出したタスクを元に詳細スケジュールを作成します。

WBSからタスクを分解していくことがポイントです。

どのページの画面設計書をいつ提示するのか。どのページをいつデザインするのか。

そういうことを定義します。WBSから具体的な制作側のやることに分解されていればフォーマットは何でもいいです。お勧めは、Backlogのタスクにし、ガントチャートにするやり方です。

そうしておけば制作スタッフとのタスク管理、フィードバック、進捗管理をまとめて行えます。

Excelファイルで細かい単位の超大作スケジュール表を作ってもいいのですが、経験上、ちょっとずれたらもう更新できない、放置される、というケースがとても多いように感じます。

実行する制作タスクを明確化し、放置されないようにする。

これが詳細スケジュールを作る上ではとても重要なポイントです。

ちなみにこの詳細スケジュールは、制作側内部では持っておくが、クライアントには提示しない、ということもあります。あまり詳細スケジュールをクライアントに提示しても詳しくは見てもらえないものです。そのあたりは、都度直近のタスクの締め切りを伝えるなど制作側での工夫が必要なところです。

1-6. インフラ環境定義書

サーバ環境についても、定義しておきましょう。

レンタルサーバ、VPS、クラウドサーバ、いろんなタイプのサーバがありますが、

• 利用サービス名
• 接続アカウント
• セキュリティ
• バックアップ
• 冗長性
• 不測の事態が起きたときの一時対応

などの定義を含みます。サーバ保守に関する責任をweb制作会社側で負う、VPS、クラウドなどの場合は、特にここはきちんと定義をしておいた方が良いです。制作会社側で対応が難しければ、webサイトの保守を専門に行っている会社がありますので、そういう会社に相談をすることも1つです。

いずれにせよ、サーバ要件として何があるかは、把握をし、その対応がどうなっているか、そこはwebディレクターが主導してまとめておく必要があります。

ここは、あまり積極的に対応したがらないwebディレクター多いです。よくわからないときは、社内のシステムエンジニア、協力会社、などのサポートを求めるのが手っ取り早いです。

2. 設計

2-1. サイトマップ

コンテンツマップをページ単位で落としたものです。

各ページのURL、デスクリプション、リダイレクト有無、ページタイトルなど、より詳細な情報をまとめます。

2-2. 基本設計書

基本設計は、そのサイトが目的を達成するために、どういう施策を取るのか、どういうポイントでサイトリニューアルを行うのか、を定義するものになります。

• カスタマージャーニーマップ
• コンテンツ別集客キーワード
• 回遊導線
• その他具体的な施策
• KPI、KGI

といったものを定義します。

2-3. 機能設計書

主に、CMSや、バックエンドシステムなどの機能を定義します。

• 入出力定義
• CMS機能仕様
• お問い合わせフォーム仕様

などがそれにあたります。

これをしたら、こうなるという具体を定義します。機能仕様は、そのままテスト検証項目になりうる前提で考えておくと効率的です。

2-4. 画面設計書

• 機能
• コンテンツ
• 情報の優先度
• ボタンやリンクを押した時の遷移先
• 構成要素（パーツ定義）
• 趣意

といったものをページ個別に定義します。

コンテンツは、元になるものは、クライアントから提示されるものが多いはずですが、その情報の再構成、キーワード、リード文、見出し、ページタイトルなどは、積極的にwebディレクターが提案に関与できる部分です。

基本設計書で、定義した内容に紐付け、そのページでターゲットユーザーが解決できることは何か？

そういったことを考えながら設計を進めます。

結構「それ、、もらった情報をそのまま流し込んだだけじゃない？」って画面設計書を見ることが少なくないです。

3. デザイン

3-1. デザインプレビュー

デザインフェーズにおいてwebディレクターは正解になるものを定義している状態なので、作業の主体は、デザイナーになります。

webディレクターは、デザイナーの意見も取り入れつつ、作成対象のデザインをデザイナーに進めてもらいます。

クライアントが、それらを一覧で確認しやすいようにデザインプレビュー用のサイトを作成し、提示します。

その際、デザインに対してどのようにフィードバックをもらうのか、決めておいた方が良いです。

3-2. デザインガイドライン

デザインを作成後は、そのデザインで定義したものをガイドラインとして定めておくことをお勧めします。

• フォント種類
• フォントサイズ
• マージン定義
• カラー定義
• 写真の使い方
• 画像の解像度・圧縮率・フォーマット
• カラム定義（カラム幅、コンテンツ幅、ページ幅、カラムガター幅等）

4. 開発

4-1. タスク管理シート

コーディングやCMS実装が完了すると、最終的なコンテンツを反映しつつ、クライアントに掲載コンテンツの誤りがないかチェックしてもらいます。その際、細かい修正タスクがポロポロ出てきてしまうものですが、それをBacklogやメールでやりとりするのは骨が折れます。

できればGoogleのスプレッドシートなど、残タスクが明確にわかるオンラインで関係者全員と共有できるものが望ましいとです。

4-2. テスト結果報告書

制作が一通り完了したら、定義したものがすべて実装されているが、動作不備がないか、表示対象環境において表示崩れなどがないか確認を行います。

確認結果は、テスト結果報告書という形でまとめます。

ただ、テスト結果報告書という新しいフォーマットを作るのではなく、これまでに作成した機能設計書、サイト基本仕様書などで代用する形でも問題ありません。

テストをどのように行うか、例えば機能設計書による実装確認幅は広いです。 表示保証対象ブラウザすべてにおいて、CMSの実装機能を確認したり、表示確認を行うというのは現実的ではありません。表示確認は対象ページを絞って行うこともありますし、CMSの実装機能確認は、使用率の高いブラウザに限るなどクライアントと最初に握っておく必要があります。

5. 導入

5-1. サイト運用マニュアル

サイト運用を行う上で、守るべきことを定義しておきます。

• 緊急時連絡先
• アカウント管理
• インフラ・外部サービス等の管理スコープ

5-2. CMS利用ガイド

CMSをクライアントに利用いただくにあたり、CMSへのログインからコンテンツの公開までの一連の流れを定義したドキュメントを準備します。ここで作成したドキュメントを元に、CMSの使い方説明会を行うこともあります。

あくまでクライアントが更新する際に使う機能に絞ったドキュメントであり、網羅的なCMSのマニュアルのようなものを作る必要はありません。

5-3. 納品確認記録

公開し、納品が完了したら、クライアントから問題なく納品を受け付けたという記録をもらっておくことをお勧めします。正式な文書ではなくても構いません。

そこの区切りをつけておかないと、公開後に制作側の問題でない、コンテンツの修正相談が継続する可能性があります。納品確認記録をもらうべき、ということはISO9001でも定義されているものです。

まとめ

概ねここに記載のドキュメントがあれば、webサイトのリニューアルを行う上でのアウトプットは問題なく進められます。

「たくさんあるなぁ」と思われた方もいるかもしれませんが・・・

やっているのは、

• webサイトのあるべき形を定義する。
• それを実現できる進め方を定義する。

ということです。 webディレクターがクライアントをリードして正解を作り、それで進められるように誘導します。 正解を予め作っておく、という考えが重要です。 プロジェクトの道筋を作っておくとも言えますが、道筋は最初に作っておく必要があります。 制作を進めながら、あれが出てきた、これが出てきた、みたいな状態は理想的なプロジェクトの形ではありません。最初に正解を定義してしまえば、極論あとはそれに沿って出来上がるのを待っていればいいとも言えます。

繰り返しになりますが、最初に正解を定義する、というのが大事です。