これは、サイトを設計するときの「三種の神器」と言えるほど重要なものだと思っていますが、どうも形骸化しているように感じるので、もう一度これらのドキュメントについて考え直して見たいと思います。
とにかく、ちゃんと作ろうよ、という話です。
何かをちゃんと考えてみるとき、5W1Hについてそれぞれ考えます。
すなわち「What Who When Where Why How」。
5Wではこれらのドキュメントの役割について見直し、1Hではどう作るかについて、実際にテンプレートを用意しようと考えています。
What このドキュメントは「何」なのか？
| サイトマップ | サイトの構造を示す 各コンテンツがサイト内でどのように分類されるのかを示す どのようなページに分かれるのかを示す |
| ページ一覧 | サイト内のページを一覧化したもの ページのタイトルやURLなどのページごとの固有の情報を網羅したもの |
| ワイヤーフレーム | ページにどんなコンテンツが入るのかを示すもの サイトの機能として必要なものを仮にレイアウトするもの（あくまで仮置き） |
Who このドキュメントは「誰」が作るのか？
基本的には Web ディレクタの責任においてこのドキュメントが作られるべきだと考えています。
基本的にはウェブサイトの制作会社がクライアントに提出して承認をもらうものだと思いますが、稀にはクライアント社内に Web ディレクタが存在している場合には、その人の責任で作られて制作会社に提供されることがあるかもしれません。
ディレクタより下流の作業担当者の責任でこのドキュメントを作ることは考えにくいです。Web デザイナの仕事であるとは思えません。ただし、ページ一覧についてはコーダーが制作したり、精査するとより良いものになると考えます。Web ディレクタの仕事の肩代わりではなく、あくまでコーダーが代筆したものを、Web ディレクタが責任を持って確認する、ということになると思いますが、ディレクタが忙しい場合はコーダーに依頼をすることも検討に入れると良いと思います。
When このドキュメントは「いつ」作るのか？
ウェブサイトの企画が決まり、仕様書が与えられ、要件定義書を同意した後に、これらのドキュメントがクライアントに提出されるものと想定しています。
この3つのドキュメント自体の制作順については、
①サイトマップ
②ページ一覧
③ワイヤーフレーム
と進むのが自然だと思いますが、ページ一覧を作りながらサイトマップに訂正を入れたり、ワイヤーフレームを書きながら見落としたページをページ一覧に書き入れたり、など、現実には3つそれぞれを同時に編集しながら進めることが考えられます。
作り始めるタイミングは、要件定義書にはサイトマップを含むことがあることから、要件定義書と並行して進めることが考えられます。また、リニューアルの案件の場合、現行のサイトのページ一覧を企画の段階で入手していることも考えられます。もちろん、この場合は新しいプロジェクトに合わせて新旧比べながら比較のできるページ一覧を作ることが望ましいです。
また、これらのドキュメントを仕上げながら、同時にデザインを進める場合も考えられます。それは構わないと思いますが、デザインが全て仕上がる前には、このドキュメントについて決着がついている必要があります。
Where このドキュメントは「どこ」にあるのか？
クライアントに承認されたのちは、クライアント、Web ディレクタ、Web デザイナ、コーダーなど、プロジェクトに関わる人全てがこのドキュメントを共有すべきと考えます。
クラウドなどにおいて、編集権限を管理しつつ、いつでも最新版や過去の変更経緯が確認できるようになっているとより良いですね。
Why このドキュメントは「なぜ」作るのか？
これまでの話にちょいちょい出てきますが、最終的には、これから作るサイトについて「クライアントに承認を得るため」に作ります。また、承認までの過程、すなわち制作会社内での検討やクライアントとの検討のためにも利用されます。
では、それぞれ「何を」検討したり承認してもらうものなのか？
| サイトマップ | ・サイトの構造 ・どんなコンテンツがあるか（概要） →サイトの概要をざっと把握してもらい必要なページやナビゲーションを想起する |
| ページ一覧 | ・作成するページがいくつあるか ・ページの基本情報（記事タイトル、URLなど） ・ページのメタ情報（ウインドウタイトル、SEO概要、SEOキーワードなど） ・更新する頻度 →全てのページを一覧して過不足の確認やそれぞれに必要な情報を想起する →更新頻度などページやサイトの管理運用について想起する |
| ワイヤーフレーム | ・サイトに必要なナビゲーション ・ナビゲーションのラベル ・分類などがある場合はそれの列挙とラベル ・コンテンツの具体的な内容 →具体的なナビゲーションや分類を把握してそれらのラベルの妥当性を検討する →原稿を揃えるために必要な情報を提示する |
・・・・いかがでしょうか？
あったりまえじゃん、と思った方も多いことでしょう。
他方で、これらのドキュメントを「なんとなく」作っていたかもと思う方もあるかもしれません。
何を検討したり把握してもらって承認してもらうのかを念頭におくと、なんのためにこれらの書類が必要なのかよくわかると思います。
ここからは、少し余談なので、大事なことはわかったからどう作ればいいのかを知りたい方は先に進みましょう。
俺が分かっていればいいじゃないか
by. Web ディレクタ
なんていう声があるかもしれません。
「俺が歩くドキュメントだから、これらの書類をいちいち作る必要はない、時間の無駄だ」
とおっしゃる方があるかもしれません。ここまで横暴な言い方ではなくても、自分の頭にあって「よく十分に把握している」のに、わざわざ書面にして共有する必要を感じない、また、共有したり、はっきり承認を得てしまうと、かえって都合が悪い、そういう風に考える向きはあるように思います。
ですが、わざわざ私がこんな記事を書いているのはなぜなのか？
「わざわざ書面に起こして共有して承認を得ることが必要である」
と、私が考えているからです。お、相容れないぞw
Web ディレクタって忙しいでしょ？
Web ディレクタという立場にある人を数人思い浮かべてみると、どの方も、大抵、もっすごい忙しいと思います。でも、それは、これらのドキュメントを作らずに、自分の頭に全てをしまってあるために、結果、忙しくなっているのではないかな、と思います。
これらのドキュメントを作らずプロジェクトを進めるとき、デザイナもコーダーも、作るものについて何か不明点が見つかって確認が必要になった時に、その都度ディレクタに尋ねるしかなくなります。でも、ディレクタは忙しい、つかまらない、返事がこない・・・・・その結果デザイナやコーダーの作業は滞ります。
また、ディレクタ自身も「よく十分に把握している」という状況はおそらく一過性のものであって「必ず忘れます」し「必ず見落としがあります」。人間の頭なんてそんなものです。
自分の頭から取り出して、ドキュメントに起こすことで固着し、かつ他の人に見てもらうことで検討が進んでより確かなものになります。その価値は、決して「時間の無駄」などではありません。
ディレクタは自分の頭をよく読んでくれる有能な右腕を育てましょう。
それでも「時間の無駄だ」と言われたら？
「クライアントにこのようなドキュメントを見せても理解してもらえない」
「デザインを早く見せろと言われる」
「上司にこれらの書類に時間をかけるなと言われる」
「コーダーやデザイナからこれらの書類を求められたことがない」
などなどがこれらのドキュメントに対する否定的な意見として耳にしたことがあるものでしょうか。
それでも、これらのドキュメントを作りましょう。人に見せる100％完璧なものでなくてもいいのです。
ページ一覧だけは、ページを省くわけにはいきませんが、その他のものは手書きレベルや大事なページだけを抜き出すなど、手間を減らしてでも、作りましょう。
正直、これらのドキュメントが不要だという人の方がおかしいです。また、これらのドキュメントを作るための時間や費用を確保しないプロジェクトや進め方もやはり危険と考えた方が無難だと思います。
こういうドキュメントをきちんと作れる能力の方が、それを認めない上司やクライアントやプロジェクト自体よりも、ずっと大事ですし、あなたのキャリアにつながると私は確信します。
プロジェクト全体のこのドキュメントの役割とは
以上で5Wの検討を終えました。
残す1Hを検討する前に、もうひとつの問題点をしておきたいと思います。それは、 Web ディレクタだけでなく、ウェブサイトの制作にあたって、そのプロジェクトに関わる人がそれぞれの役割を把握していないのではないか、という点です。プロジェクト全体を俯瞰する時に、やるべきタスクが、プロジェクトに関わる人（プレイヤー）に正しく振り分けられていないのではないか？ということ。
なので、少し引いて、ウェブサイト制作全体でどんな段階があり、これらのドキュメントが全体の中でどのような役目を担っているかを考えてみます。
0. プロジェクトの始まり
ウェブサイトを作ると決まる前の話です。おそらく、企業には何らかの課題があり、その課題についての解決にウェブサイトが必要、もしくはウェブサイトに新しい役割を持たせるなどの判断が下されたはずです。ここで「ユーザーの需要」や「サイトの目的」の芽が生まれているはずです。クライアントの中で、何かモヤモヤとした「なんとかしたい」の思いが渦巻き始めていることでしょう。
成果物：クライアントの要求
1. プロジェクトの企画
クライアントのモヤモヤは企画書という形になって制作会社の選定を行うかもしれません。もしくは、クライアントのモヤモヤを受け取った制作会社が素敵な企画書を仕上げるでしょう。クライアントも企画書を承認してくれました。
成果物：企画書
2. サイトの要件定義書
素敵な企画書をもとに、これから作るサイトの要件を定義します。サイトの目的、目標、納品物についてや、ターゲットブラウザ、機能や実装した後の運用について、細かく話し合い、定めていきます。なかなか面倒な作業ですが大事なことです。何をどこまで誰がやるのかをクライアント、制作会社の両者で同意が得られるまで、決めていきます。
この段階でサイトの完成までに必要な作業全てをスコープしてそれぞれのプレイヤーに振り分けていきます。
成果物：要件定義書
3. サイトの構造を考える
要件定義書を手掛かりに、ウェブサイトに必要なコンテンツをピックアップし、どのような構造でサイトを練り上げていくか考えます。具体的にはサイトマップを形にし、必要なページを一覧にしていきます。コーダーがそわそわとページ一覧を眺めて自分のタスクを考え始めています。あ、今、ページ一覧に修正を依頼しました。何か足りないものがあったようです。
そろそろ最終のスケジュールも視野に入れて、進捗管理のタスクリストも作り始めるころですね、Web ディレクタの頑張りどころです。
成果物：サイトマップ、ページ一覧
4. サイトの骨格を考える
サイトの構造ができたところで、各情報にたどり着くように、具体的なナビゲーションを検討します。ようやくウェブサイトの見た目や操作についての検討になってきました。この辺りからデザイナやコーダーも頻繁に会議で発言するようになるでしょう。サイトマップとページ一覧を片手に、ワイヤーフレームとにらめっこしてたどり着けないページがないように検討しなくてはいけません。また、サイトの原稿についても不足がないか、どんなものがある方がわかりやすいページになるか、デザイナは想像を巡らすでしょう。写真やイラスト、図説、魅力的なキャッチコピー・・・ああ、そうですね、ライターも招いて会議が必要かもしれません。
ここで基本的なUIについても検討します。最終的にはデザイナのさじ加減でしょうか。コーダーはハラハラしながら自分の工数を数え始めます。手を動かしていないと不安になってきたのか、テスト環境を整え始めました。
成果物：ワイヤーフレーム
5. サイトのデザインを考える
ワイヤーフレームとこれまでの資料を片手に、デザイナはサイトデザインをヴィジュアルとして落とし込んでいきます。UIの要件を満たし、ナビゲーションの要件を満たし、さらに盛り込むべき情報の要件を満たしていきます。なおかつ、魅力的な見え方をするように、頭を絞ります。あ、今、とても画期的なレイアウトを思いついたようですが、レスポンシブのスマホ画面で問題になるため、コーダーが渋い顔をしました。工数が増えすぎるようですね。デザイナからのUI上の問い合わせに対して、コーダーはテスト環境上で簡単なモックやデモを見せて答えているようです。
デザイナが頑張っている間に、続々とサイトの素材が集まってきました。
成果物：デザインカンプ
6. サイトのデータを作り込む
デザイナが全てのデザイン的な課題を解き終えるのを待たずに、コーダーは決定しそうな部分からサイトのデータを作り込みます。サイトマップから構造を読み取り、CMSの構造を整え、ページの一覧を眺めながらURL構造と折り合いをつけ、すでに決定しているメタデータを組み込むでしょう。またワイヤーフレームを参考にHTMLの要素を並べ、UIを実装していきます。そうこうしているうちにデザインカンプにクライアントの承認がおり、デザイナから最終のデータを渡されました。そしてついに、サイトの全てのデータが仕上がりました。コーダーは力尽きて倒れているようです。
7. サイトのテストと確認作業
コーダーの作業がひと段落する頃、プロジェクトの人員を集めて、要件定義書を改めて確認しながら、サイトのテストと確認をします。ここでサイト一覧がまた活躍します。このドキュメントをもとに、全てのページをもれなく確認します。一覧があれば、作業の分担ができます。誰がどのページをチェックしたかを書き込めば重複が防げますし、責任の所在もはっきりします。ダブルチェックも容易になるでしょう。
ワイヤーフレームがあることでサイトを初見するスタッフにもそのページがどのようなコンテンツを持つべきなのか、画面に表示されているページが妥当かのかを判断することができるようです。
そしてこれらのテストの後、クライアントとも同じようにテストと確認を行い、サイトはめでたく納品されました。
8. 半年後のウェブサイトを修正する
みんなで健闘をたたえあったプロジェクトの打ち上げから半年後、クライアントからクレームの電話がありました。ウェブサイトのページが思ったように更新できないと言うのです。連絡を受けたWeb ディレクタはもう次のプロジェクトを進めていて、納品してしまったプロジェクトのことは覚えていません。でも、なんだかクライアントの言い分には違和感があります。まず、要件定義書を確認しました。最終の要件定義にはその機能については記載がありません。次にページ一覧を確認しますが、そのページについては更新頻度は1年以上もしくは更新しないと言う記載があります。クライアントはもしかしたら、他のページと勘違いをしているのかもしれない、そう思いながらディレクタはもう一度クライアントと話をした結果、やはり勘違いだと言うことが発覚しました。ページ一覧と要件定義書を共有してあったので、何ページのなになにを確認してください、と言う話でまあるく和解ができたのです。
・・・・・・・・・などと、気がついたら物語調になってしまいました。この後、リニュアル依頼編も用意してありますが、さすがに蛇足がすぎるのでやめておきます。
いかがでしょうか？サイトマップ、ページ一覧、ワイヤーフレームが所々で利用されていることがわかったと思います。と同時に、これらのドキュメントがなかった場合、スタッフ間で情報の共有が難しかったり、作業分担ができなくなったり、確認漏れが出たりなど、プロジェクトは混乱に満ちたものになるでしょう。
How これらのドキュメントを「どう」作るか？
なぜ作るのか？で挙げた、それぞれのドキュメントでの検討や承認を得る目的を踏まえて、Googleドキュメントでテンプレートを作成してみました。
ウェブサイトツール（Googleドライブ）
記事の公開日の時点ではページ一覧のみテンプレートがあります。
そのほかは現在鋭意製作中ですm(_ _)m
2019/10/8追記 サイトマップのサンプルを掲載しました。ワイヤーフレームはUIツールをいくつか追加しました。