続き戻るサイトマップ・ページ一覧・ワイヤーフレームの役割を考え直すこれは、サイトを設計するときの「三種の神器」と言えるほど重要なものだと思っていますが、どうも形骸化しているように感じるので、もう一度これらのドキュメントについて考え直して見たいと思います。作ろうよ、という話です。何かをちゃんと考えてみるとき、5W1Hについてそれぞれ考えます。5Wではこれらのドキュメントの役割について見直し、1Hではどう作るかについて、実際にテンプレートを用意しようと考えています。ディレクタの責任においてこのドキュメントが作られるべきだと考えています。ディレクタが存在している場合には、その人の責任で作られて制作会社に提供されることがあるかもしれません。ディレクタより下流の作業担当者の責任でこのドキュメントを作ることは考えにくいです。デザイナの仕事であるとは思えません。ページ一覧についてはコーダーが制作したり、精査するとより良いものになると考えます。ディレクタが責任を持って確認する、ということになると思いますが、ディレクタが忙しい場合はコーダーに依頼をすることも検討に入れると良いと思います。このドキュメントは「いつ」作るのか?ウェブサイトの企画が決まり、仕様書が与えられ、要件定義書を同意した後に、これらのドキュメントがクライアントに提出されるものと想定しています。この3つのドキュメント自体の制作順については、1サイトマップ2ページ一覧3ワイヤーフレームと進むのが自然だと思いますが、ページ一覧を作りながらサイトマップに訂正を入れたり、ワイヤーフレームを書きながら見落としたページをページ一覧に書き入れたり、など、現実には3つそれぞれを同時に編集しながら進めることが考えられます。作り始めるタイミングは、要件定義書にはサイトマップを含むことがあることから、要件定義書と並行して進めることが考えられます。リニューアルの案件の場合、現行のサイトのページ一覧を企画の段階で入手していることも考えられます。この場合は新しいプロジェクトに合わせて新旧比べながら比較のできるページ一覧を作ることが望ましいです。これらのドキュメントを仕上げながら、同時にデザインを進める場合も考えられます。それは構わないと思いますが、デザインが全て仕上がる前には、このドキュメントについて決着がついている必要があります。デザイナ、コーダーなど、プロジェクトに関わる人全てがこのドキュメントを共有すべきと考えます。クラウドなどにおいて、編集権限を管理しつつ、いつでも最新版や過去の変更経緯が確認できるようになっているとより良いですね。このドキュメントは「なぜ」作るのか?これまでの話にちょいちょい出てきますが、最終的には、これから作るサイトについて「クライアントに承認を得るため」に作ります。承認までの過程、すなわち制作会社内での検討やクライアントとの検討のためにも利用されます。→具体的なナビゲーションや分類を把握してそれらのラベルの妥当性を検討する→原稿を揃えるために必要な情報を提示する・・・・いかがでしょうか?あったりまえじゃん、と思った方も多いことでしょう。他方で、これらのドキュメントを「なんとなく」作っていたかもと思う方もあるかもしれません。何を検討したり把握してもらって承認してもらうのかを念頭におくと、なんのためにこれらの書類が必要なのかよくわかると思います。ここからは、少し余談なので、大事なことはわかったからどう作ればいいのかを知りたい方は先に進みましょう。ディレクタなんていう声があるかもしれません。「俺が歩くドキュメントだから、これらの書類をいちいち作る必要はない、時間の無駄だ」とおっしゃる方があるかもしれません。ここまで横暴な言い方ではなくても、自分の頭にあって「よく十分に把握している」のに、わざわざ書面にして共有する必要を感じない、また、共有したり、はっきり承認を得てしまうと、かえって都合が悪い、そういう風に考える向きはあるように思います。私がこんな記事を書いているのはなぜなのか?「わざわざ書面に起こして共有して承認を得ることが必要である」と、私が考えているからです。ディレクタという立場にある人を数人思い浮かべてみると、どの方も、大抵、もっすごい忙しいと思います。それは、これらのドキュメントを作らずに、自分の頭に全てをしまってあるために、結果、忙しくなっているのではないかな、と思います。これらのドキュメントを作らずプロジェクトを進めるとき、デザイナもコーダーも、作るものについて何か不明点が見つかって確認が必要になった時に、その都度ディレクタに尋ねるしかなくなります。ディレクタは忙しい、つかまらない、返事がこない・・・・・その結果デザイナやコーダーの作業は滞ります。ディレクタ自身も「よく十分に把握している」という状況はおそらく一過性のものであって「必ず忘れます」し「必ず見落としがあります」。人間の頭なんてそんなものです。自分の頭から取り出して、ドキュメントに起こすことで固着し、かつ他の人に見てもらうことで検討が進んでより確かなものになります。その価値は、決して「時間の無駄」などではありません。ディレクタは自分の頭をよく読んでくれる有能な右腕を育てましょう。「コーダーやデザイナからこれらの書類を求められたことがない」などなどがこれらのドキュメントに対する否定的な意見として耳にしたことがあるものでしょうか。それでも、これらのドキュメントを作りましょう。人に見せる100%完璧なものでなくてもいいのです。ページ一覧だけは、ページを省くわけにはいきませんが、その他のものは手書きレベルや大事なページだけを抜き出すなど、手間を減らしてでも、作りましょう。これらのドキュメントが不要だという人の方がおかしいです。これらのドキュメントを作るための時間や費用を確保しないプロジェクトや進め方もやはり危険と考えた方が無難だと思います。いうドキュメントをきちんと作れる能力の方が、それを認めない上司やクライアントやプロジェクト自体よりも、ずっと大事ですし、あなたのキャリアにつながると私は確信します。プロジェクト全体のこのドキュメントの役割とは以上で5Wの検討を終えました。残す1Hを検討する前に、もうひとつの問題点をしておきたいと思います。ディレクタだけでなく、ウェブサイトの制作にあたって、そのプロジェクトに関わる人がそれぞれの役割を把握していないのではないか、という点です。プロジェクト全体を俯瞰する時に、やるべきタスクが、プロジェクトに関わる人(プレイヤー)に正しく振り分けられていないのではないか?ということ。引いて、ウェブサイト制作全体でどんな段階があり、これらのドキュメントが全体の中でどのような役目を担っているかを考えてみます。プロジェクトの始まりウェブサイトを作ると決まる前の話です。企業には何らかの課題があり、その課題についての解決にウェブサイトが必要、もしくはウェブサイトに新しい役割を持たせるなどの判断が下されたはずです。ここで「ユーザーの需要」や「サイトの目的」の芽が生まれているはずです。クライアントの中で、何かモヤモヤとした「なんとかしたい」の思いが渦巻き始めていることでしょう。プロジェクトの企画クライアントのモヤモヤは企画書という形になって制作会社の選定を行うかもしれません。クライアントのモヤモヤを受け取った制作会社が素敵な企画書を仕上げるでしょう。クライアントも企画書を承認してくれました。素敵な企画書をもとに、これから作るサイトの要件を定義します。ついてや、ターゲットブラウザ、機能や実装した後の運用について、細かく話し合い、定めていきます。面倒な作業ですが大事なことです。何をどこまで誰がやるのかをクライアント、制作会社の両者で同意が得られるまで、決めていきます。この段階でサイトの完成までに必要な作業全てをスコープしてそれぞれのプレイヤーに振り分けていきます。サイトの構造を考える要件定義書を手掛かりに、ウェブサイトに必要なコンテンツをピックアップし、どのような構造でサイトを練り上げていくか考えます。具体的にはサイトマップを形にし、必要なページを一覧にしていきます。コーダーがそわそわとページ一覧を眺めて自分のタスクを考え始めています。あ、今、ページ一覧に修正を依頼しました。何か足りないものがあったようです。ディレクタの頑張りどころです。サイトの骨格を考えるサイトの構造ができたところで、各情報にたどり着くように、具体的なナビゲーションを検討します。ウェブサイトの見た目や操作についての検討になってきました。この辺りからデザイナやコーダーも頻繁に会議で発言するようになるでしょう。サイトマップとページ一覧を片手に、ワイヤーフレームとにらめっこしてたどり着けないページがないように検討しなくてはいけません。サイトの原稿についても不足がないか、どんなものがある方がわかりやすいページになるか、デザイナは想像を巡らすでしょう。写真やイラスト、図説、魅力的なキャッチコピー・・・ああ、そうですね、ライターも招いて会議が必要かもしれません。ここで基本的なUIについても検討します。最終的にはデザイナのさじ加減でしょうか。コーダーはハラハラしながら自分の工数を数え始めます。手を動かしていないと不安になってきたのか、テスト環境を整え始めました。サイトのデザインを考えるワイヤーフレームとこれまでの資料を片手に、デザイナはサイトデザインをヴィジュアルとして落とし込んでいきます。UIの要件を満たし、ナビゲーションの要件を満たし、さらに盛り込むべき情報の要件を満たしていきます。魅力的な見え方をするように、頭を絞ります。あ、今、とても画期的なレイアウトを思いついたようですが、レスポンシブのスマホ画面で問題になるため、コーダーが渋い顔をしました。工数が増えすぎるようですね。デザイナからのUI上の問い合わせに対して、コーダーはテスト環境上で簡単なモックやデモを見せて答えているようです。デザイナが頑張っている間に、続々とサイトの素材が集まってきました。サイトのデータを作り込むデザイナが全てのデザイン的な課題を解き終えるのを待たずに、コーダーは決定しそうな部分からサイトのデータを作り込みます。サイトマップから構造を読み取り、CMSの構造を整え、ページの一覧を眺めながらURL構造と折り合いをつけ、すでに決定しているメタデータを組み込むでしょう。ワイヤーフレームを参考にHTMLの要素を並べ、UIを実装していきます。しているうちにデザインカンプにクライアントの承認がおり、デザイナから最終のデータを渡されました。サイトの全てのデータが仕上がりました。コーダーは力尽きて倒れているようです。サイトのテストと確認作業コーダーの作業がひと段落する頃、プロジェクトの人員を集めて、要件定義書を改めて確認しながら、サイトのテストと確認をします。ここでサイト一覧がまた活躍します。このドキュメントをもとに、全てのページをもれなく確認します。一覧があれば、作業の分担ができます。誰がどのページをチェックしたかを書き込めば重複が防げますし、責任の所在もはっきりします。ダブルチェックも容易になるでしょう。ワイヤーフレームがあることでサイトを初見するスタッフにもそのページがどのようなコンテンツを持つべきなのか、画面に表示されているページが妥当かのかを判断することができるようです。これらのテストの後、クライアントとも同じようにテストと確認を行い、サイトはめでたく納品されました。半年後のウェブサイトを修正するみんなで健闘をたたえあったプロジェクトの打ち上げから半年後、クライアントからクレームの電話がありました。ウェブサイトのページが思ったように更新できないと言うのです。ディレクタはもう次のプロジェクトを進めていて、納品してしまったプロジェクトのことは覚えていません。なんだかクライアントの言い分には違和感があります。要件定義書を確認しました。最終の要件定義にはその機能については記載がありません。次にページ一覧を確認しますが、そのページについては更新頻度は1年以上もしくは更新しないと言う記載があります。クライアントはもしかしたら、他のページと勘違いをしているのかもしれない、そう思いながらディレクタはもう一度クライアントと話をした結果、やはり勘違いだと言うことが発覚しました。気がついたら物語調になってしまいました。この後、リニュアル依頼編も用意してありますが、さすがに蛇足がすぎるのでやめておきます。いかがでしょうか?サイトマップ、ページ一覧、ワイヤーフレームが所々で利用されていることがわかったと思います。同時に、これらのドキュメントがなかった場合、スタッフ間で情報の共有が難しかったり、作業分担ができなくなったり、確認漏れが出たりなど、プロジェクトは混乱に満ちたものになるでしょう。これらのドキュメントを「どう」作るか?なぜ作るのか?で挙げた、それぞれのドキュメントでの検討や承認を得る目的を踏まえて、Googleドキュメントでテンプレートを作成してみました。ウェブサイトツール(Googleドライブ)記事の公開日の時点ではページ一覧のみテンプレートがあります。サイトマップのサンプルを掲載しました。ワイヤーフレームはUIツールをいくつか追加しました。やりたいこと富山でWeb勉強会と銘打って始めたのですが、私自身が富山を出てしまうということになり、結局勉強会は途絶えてしまっております。フロントエンドやWordPress関連で、素朴な疑問とかハウツーとか明日から使える小技とかを広めて、5分でも早く仕事を終わらせる、なんてことを念頭にやっていたのですが、続きませんで、大変申し訳なく思っております。いう質問サイトでCSSやWP周りの質問にせっせと答えいたりしましたが、これも忙しくなるとやっていられない、とかそういう感じです。https://teratail.com/users/marlboro_tataフリーランスの屋号のサイトで、要件定義の記事を書いています。私自身はコーダーですので、本来、要件定義の作成に関わることは少ないのですが、あまりにこれがないがしろにされた仕事が散見されるので、ちゃんと書こうよ、という気持ちで書いています。この記事は、「案件が来てから要件定義を書こうとするから時間がかかるのであって、得意であったり、自分ができると思うシナリオを想定して、要件定義を先に書けばいいじゃないか」ということを提案しているものです。要件定義が完成したら、それを元に、WPサイトを組んでみる、という展開を夢見ています。これも更新が滞っているのですが、要件定義ヘルパーという名で、要件定義に出てきそうな機能やツールについて解説をする記事を書いています。この記事は主に、要件定義を作る人やそれを読む立場、ウェブ担当者をターゲットに書いています。これに混ぜるか、別にするか悩んでいますが、デザイナ向けにUIの話を含めて書くかもしれません。要件定義とは別に、サイトマップ(サイトツリー)、ページ一覧、ワイヤーフレームについての記事を書こうと思っています。これらはどんなもので何を目的として作るのか、ということについてです。そんなもの、私がわざわざ書かなくてもこの仕事をやっている人ならわかるだろうと思うのですが、もう一度整理してみようか、という気持ちです。(2019-08-11追記:書きました)また、ページ一覧についてはGoogleスプレッドシートなどでテンプレートを公開しようと考えています。これも探せばすでに素晴らしいものが存在していそうですが、あえて、です。仕事は相変わらずやっておりますが、昔のように寝食削って・・・とまではやっていません。徹夜ってできなくなるものですね。食べて寝ないと身体が保たないのです。家事も昔のようにサボりにサボって、というわけにはいかなくなったので、仕事に使える時間は極端に減っています。その中で自分の稼ぎとして必要な分をとなると、時間単価高くせざるを得ません。コーダーですので、なるべくコーディングだけで済むような仕事環境にしたい、という思いが強くあります。要件定義書、サイトマップ、ページ一覧、ワイヤーフレームを一式揃えてから見積もり依頼をくださいというお願いです。今後、もっと厳しく、仕事を選ぶことになるでしょう。その一方で、稼ぎにはならなくても、勉強会としてオフラインで集まること、何かの集まりに参加することは増やしていきたいと考えています。富山でWeb勉強会についてはオンラインでもまた何かできれば、、、と思っています。アイデアがあればお聞かせください。やりたいことにコメントサイト改装中いい加減真面目にグーテンベルグと向き合おうと思って、2019テーマに変更して、カスタマイズ実行中のため、サイトの表示が派手に崩れておりますが、何卒ご容赦いただけますよう、お願い申し上げます。いつになったら勉強会が再開できるのだろうか(遠い目)ブロックの新規追加はだいぶ骨が折れるわ・・・・・とりあえず見出しを追加してみるDDで並び替えとかができるようで。見出しは(h1~6)を選択できるサイド部分に出てくるもので、1〜6の見出しを選択できる。「高度な設定」から、アンカーが設定できるのよいですね。地味に、CSSクラス名を書けるようになっているの素晴らし・・。内容テーブルは列/行の追加はできるけど、thを設定したりとかはできないのかな。テーブル要素にも「右寄せ」「全幅」とかオプションがつくっぽいけどこれはいかに?(上のは「幅広」にしておいてみた。これは、カラムこれは、カラムですけれども、どうなるんでしょうねこれ。画像とかかいるのかな?いつかのおやつカラムは最大6つまでかな?オススメの本この本はみんな読むと良いよ!普通の段落。ブロックのメディアと文章を全幅で配置するとこうなる。(6)突然のカテゴリ挿入。他にも、アーカイブとか最近の記事とか。ウィジェットの扱いみたい。要らんなあ、消せるのかなあ。管理画面の候補から消しても、一度入力したものについては影響がないようだ。キャプションを編集すると全てに反映?ボタン!!所感としては、プリセットのブロックを活用して、あとはCSSで力技、という感じだろうか。「幅広」とか「全幅」とかをなんとかしたい気もする。この子(やりたいことはわかるけど...)。見れば見るほど多機能すぎてびっくりするなあ・・・・・。引用のブロックにカスタムスタイルを追加してみた。foo();?>カスタムプレビューメッセージ?って結局一体何だったんだ・・・。怪、というか、いかに自分がCSSの定めるところについて、上っ面しか知らない、と思い知らされたので、記事にしました。この先あんまり偉そうなこと言わない、言えない・・・。そもそもの発端はteratailに上がっていた質問に答えたことからでした。https://teratail.com/questions/142990破線の両端が繋がってしまうことを避けることができないか?という質問でした。現象としてはこんな感じです。chromeでキャプチャそこで、仮説として、セルの高さが破線の高さの倍数であれば、セル内で改行が起こっても破線がつながることはないのではないか、と考え、具体的にはセルの高さを決定する要素、内包するテキストの行の高さとセルのパディングがそれぞれ破線の高さの倍数であれば、その和であるセルの高さは破線の高さの倍数になる。考えて作ったデモがこちらです。例2を参照してください。説明は端折りますが、結果できたセルを見てわかったことが以下のこと・破線はセルの中央を起点として、実線、もしくは空白の中央を起点に合わせるように実線と空白を繰り返し描画している・破線の両端が実践になるように、なんらかの調整をしているsafariでキャプチャそりゃ、破線、繋がっちゃうよね。デモの例3にもあるが、border-spacingを使ってやるしかなかった。http://www.htmq.com/style/border-spacing.shtml余談ですが、border-spacingの値を上下・左右別のものを設定することができるとは、知らなかった・・・・。やって見なければわからないことは、あるものだな、と思った次第であります。どこかで誰かのお役に立てば何よりです。あ、ちなみに、破線の高さですが、safariでは実線3ピクセル、空白は3ピクセルが基本のようです。他方、Chromeは実線3ピクセル、空白が2ピクセルでした。実を言うと、そもそもの「セルの高さを破線の高さの倍数にする」と言う解決策の過程自体が、危ういです。Chromeでも破線の両端は実線にするルールのようなので、今の所解決策は同じで、border-spacingを使う、と言う感じになりそうです。Typeキックオフ会を実施したまま活動が止まっていた「MT北陸」がようやくスタートアップのセミナーを開催しました。その中心メンバーの、ちょっぴり端っこに、もう北陸在住ではないけれど、参加しております。