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