サイトマップ・ページ一覧・ワイヤーフレームの役割を考え直す

これは、サイトを設計するときの「三種の神器」と言えるほど重要なものだと思っていますが、どうも形骸化しているように感じるので、もう一度これらのドキュメントについて考え直して見たいと思います。
とにかく、ちゃんと作ろうよ、という話です。

何かをちゃんと考えてみるとき、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ツールをいくつか追加しました。

今やっていること やりたいこと

富山でWeb勉強会と銘打って始めたのですが、私自身が富山を出てしまうということになり、結局勉強会は途絶えてしまっております。
フロントエンドやWordPress関連で、素朴な疑問とかハウツーとか明日から使える小技とかを広めて、5分でも早く仕事を終わらせる、なんてことを念頭にやっていたのですが、続きませんで、大変申し訳なく思っております。

代わりに、オンラインを活用して何かできないかなーというところで、時間に余裕があるときは terateil という質問サイトでCSSやWP周りの質問にせっせと答えいたりしましたが、これも忙しくなるとやっていられない、とかそういう感じです。
いつものアイコンで参加してます https://teratail.com/users/marlboro_tata

フリーランスの屋号のサイトで、要件定義の記事を書いています。私自身はコーダーですので、本来、要件定義の作成に関わることは少ないのですが、あまりにこれがないがしろにされた仕事が散見されるので、ちゃんと書こうよ、という気持ちで書いています。
この記事は、「案件が来てから要件定義を書こうとするから時間がかかるのであって、得意であったり、自分ができると思うシナリオを想定して、要件定義を先に書けばいいじゃないか」ということを提案しているものです。
さらに、要件定義が完成したら、それを元に、WPサイトを組んでみる、という展開を夢見ています。頑張って記事を書かねばね・・・。

要件定義関係では、これも更新が滞っているのですが、要件定義ヘルパーという名で、要件定義に出てきそうな機能やツールについて解説をする記事を書いています。この記事は主に、要件定義を作る人やそれを読む立場、ウェブ担当者をターゲットに書いています。これに混ぜるか、別にするか悩んでいますが、デザイナ向けにUIの話を含めて書くかもしれません。

要件定義とは別に、サイトマップ(サイトツリー)、ページ一覧、ワイヤーフレームについての記事を書こうと思っています。これらはどんなもので何を目的として作るのか、ということについてです。そんなもの、私がわざわざ書かなくてもこの仕事をやっている人ならわかるだろうと思うのですが、もう一度整理してみようか、という気持ちです。(2019-08-11追記:書きました
また、ページ一覧についてはGoogleスプレッドシートなどでテンプレートを公開しようと考えています。これも探せばすでに素晴らしいものが存在していそうですが、あえて、です。

仕事は相変わらずやっておりますが、昔のように寝食削って・・・とまではやっていません。徹夜ってできなくなるものですね。きちんと食べて寝ないと身体が保たないのです。
家事も昔のようにサボりにサボって、というわけにはいかなくなったので、仕事に使える時間は極端に減っています。その中で自分の稼ぎとして必要な分をとなると、時間単価高くせざるを得ません。

コーダーですので、なるべくコーディングだけで済むような仕事環境にしたい、という思いが強くあります。つまり、要件定義書、サイトマップ、ページ一覧、ワイヤーフレームを一式揃えてから見積もり依頼をくださいというお願いです。おそらく、今後、もっと厳しく、仕事を選ぶことになるでしょう。

その一方で、稼ぎにはならなくても、勉強会としてオフラインで集まること、何かの集まりに参加することは増やしていきたいと考えています。富山でWeb勉強会についてはオンラインでもまた何かできれば、、、と思っています。アイデアがあればお聞かせください。

サイト改装中

いい加減真面目にグーテンベルグと向き合おうと思って、2019テーマに変更して、カスタマイズ実行中のため、サイトの表示が派手に崩れておりますが、何卒ご容赦いただけますよう、お願い申し上げます。

いつになったら勉強会が再開できるのだろうか(遠い目)

ブロックの新規追加はだいぶ骨が折れるわ・・・・・

とりあえず見出しを追加してみる

DDで並び替えとかができるようで。

見出しは(h1~6)を選択できる

サイド部分に出てくるもので、1〜6の見出しを選択できる。「高度な設定」から、アンカーが設定できるのよいですね。
てか、地味に、CSSクラス名を書けるようになっているの素晴らし・・。

どんなレイアウトが適しているのか

  • これはリストですね
  • 自由なレイアウトがどこまでできるのか
  • 初期設定のブロックだけでも結構色々やれそうな気はする
  • 決まり切ったレイアウトというよりは、自由なレイアウト
テーブル項目項目項目項目
thとかの設定は
できなさそう?
内容内容内容内容
項目内容内容内容内容

テーブルは列/行の追加はできるけど、thを設定したりとかはできないのかな。テーブル要素にも「右寄せ」「全幅」とかオプションがつくっぽいけどこれはいかに?(上のは「幅広」にしておいてみた。


これは、カラム

これは、カラムですけれども、どうなるんでしょうねこれ。画像とかかいるのかな?

いつかのおやつ

カラムは最大6つまでかな?

オススメの本

この本はみんな読むと良いよ!

普通の段落。ブロックのメディアと文章を全幅で配置するとこうなる。「モバイルで重ねる」オプションがあるけどどうなるのか?

突然のカテゴリ挿入。他にも、アーカイブとか最近の記事とか。ウィジェットの扱いみたい。要らんなあ、消せるのかなあ。。消せた。管理画面の候補から消しても、一度入力したものについては影響がないようだ。

いつかの本棚 キャプションを編集すると全てに反映?

所感としては、プリセットのブロックを活用して、あとはCSSで力技、という感じだろうか。
「幅広」とか「全幅」とかをなんとかしたい気もする。なんですかこの子(やりたいことはわかるけど…)。
色々見れば見るほど多機能すぎてびっくりするなあ・・・・・。

引用のブロックにカスタムスタイルを追加してみた。

  • どーなったって??
  • これで・・・
<?php foo();?>

カスタムプレビューメッセージ?って結局一体何だったんだ・・・。

これが「カバー」というやつ(全幅)

border-style: dashed の怪

怪、というか、いかに自分がCSSの定めるところについて、上っ面しか知らない、と思い知らされたので、記事にしました。
もうこの先あんまり偉そうなこと言わない、言えない・・・。

そもそもの発端はteratailに上がっていた質問に答えたことからでした。
https://teratail.com/questions/142990

破線の両端が繋がってしまうことを避けることができないか?という質問でした。現象としてはこんな感じです。

Mac safariでキャプチャ
Mac 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を使う、と言う感じになりそうです。

お久しぶりのMovable Type

キックオフ会を実施したまま活動が止まっていた「MT北陸」がようやくスタートアップのセミナーを開催しました。その中心メンバーの、ちょっぴり端っこに、もう北陸在住ではないけれど、参加しております。

そう、今でこそほとんどの仕事がWP案件ですけれども、私が最初に触れて覚えたCMSはMovable Typeでした。静的生成最高。

WP案件を、今ではなんとなくこなせるようになっているものの、PHP自体はあまりちゃんと理解できておらず。また、サーバーの保守管理のようなものも苦手。さらにデータベース関連とか未知の世界で。正直、そういう部分に理解がないとWPって取り扱うのが結構しんどいです。自分の本当に頑張れる範囲はHTML+CSS、時々jQueryってところだよな、と思うと、そのほかの部分に頑張る余力が、ここしばらく本当になくなってきたなーと、思っていたのです。

つまり。WPサイトの面倒見るのが実はしんどいと気が付いてしまった。

そう思うこと、ありませんか?
例えば・・・・

  • WPのセキュリティアップデートが頻繁にあるので、その度対応がしんどい
  • アップデートは必須なのに、その費用を含めたメンテナンスや保守の費用を出し渋られる
  • 利用しているWPのプラグインなどが古いがアップデートがかからず、古いまま使っていてセキュリティが心配
  • 前任者が作ったWPサイトの中身がわからなすぎて、クライアントのオーダーで修正したいと思っても、社内でどうにもならない

WPに限らず、安いからといってオープンソースのシステムを使っていると起こりがちな問題のように思います。
社内にWPに詳しい人がいるなら、問題なく安全に取り扱える人がいるなら大丈夫だと思いますが、そう出ないなら、ちょっと立ち止まって考えてみてもいいかもしれません。

WPのアップデートに使っている時間を考えて見る

2017年7月から1年間の間に、WPは22回のアップデートをリリースしました。そのうち8回がセキュリティアップデートでした。
最低限としてセキュリティアップデートのみを対応し、年間8回アップデートの対応をしたと仮定しましょう。
その際に行われる作業を、ちょっと細かく書き出してみます。
①アップデートの通知を受け取り内容を把握
②先方にアップデートの必要ができたことを告げ、実施スケジュールを確認、その日の更新は控えてもらう
③当日、まず諸々バックアップ
④アップデート(何もなければ数分で終わる)
⑤サイトの見え方や管理画面の挙動を確認
⑥ちょっとトラブってその解決に時間が取られる
⑦仕様の変更などがあって、先方に操作の仕方を伝達、マニュアルの書き換え
⑧アップデートのレポートを先方に伝達
という感じで、平均2時間ぐらいかかったとして、年間で16時間です。
意外と少ないですか?
でも管理しているWPサイトが10個あったら10倍です、160時間。

でも、もし、アップデートが必要なくなったら。
年間で16時間、そのクライアントに対して時間を使うことができたら、何ができそうでしょうか?
お客様のサイトをささっとチェックして、コンテンツに対するアドバイスができるかもしれません。これを2月に1回ペースで行ったとして6時間ほどとしましょう。
その中でもっとうまくするアイデアを思いつくかもしれません。残りの10時間近くがあれば、もしかしたら素敵な企画が出来上がるかもしれません。
たった16時間とは、言えないのではないでしょうか?
こちらの方がずっと、ウェブサイトを役立てると言うことにおいては、意義のあることではないでしょうか?

WebサービスとしてCMSを使うという選択肢

社内にわかる人間がいないからという理由でCMSの管理を外部委託するなら、Webサービスを使うのを考えて見るのはどうでしょう。
しんどくても、なんとか知識を身につけて自前でWPの面倒をみることも多少なりとメンテ契約という費用としてお金になるのは確かなのですが、CMSのセキュリティや思ったように動き続かせるために力を取られると言うことは、本来力を注ぐべきところ、例えばコンテンツのクオリティをあげるとか、ユーザーのニーズを探るとか、UI/UXを向上すると言う方へ力が回らないと言うことです。本来、その部分がお金になる方が、コンサルを兼ねたウェブ制作をする場合、本当に成果の上がるウェブの制作を目指すと言う場合において、意味があると思います。

WebサービスとしてCMSを利用する場合、オープンソースのCMSを使う場合と比べて、ウェブサイトとして使える機能は、大抵の場合、減ります。そこがおそらく大きな違いです。
そこを補って余りあるのが、使える機能は限られるが、間違いなく「使える」と保証されていることです。無論、マニュアル通りの使い方の範囲で、と言うことになるでしょうけれど。アップデートして使えなくなった、おかしくなった、と言うことが起こるリスクは減ります。不具合があれば、必ずサポート対応してくれるでしょうし、使い方の問い合わせなどにも対応してくれる場合があるでしょう(そのための利用料金ですよね)。
MTのWebサービスの場合、サーバーにインストールする方法のものと違って、Webサービスはそこでしか使えない便利機能もあるそうです。

MovableType.net を使ってみませんか?

コミュニティに参加している時点で回し者なので(冗談です)、いや、それ以上に、使えそうだな、と思ったので、お伝えします。
Movable TypeのWebサービス版である「Movable Type.net」を検討してみませんか。一番安いライトプランの利用料は年間25,000円(年間一括払い)です。
・サーバー込み
・メールサーバーはない
・独自ドメイン使える
・無料SSLが使える、プランによっては持ち込みSSL証明書も使える
・無料で使えるテンプレートがある
・テンプレートはカスタマイズ可能なので独自のデザインもOK
・カスタムフィールド使える
・項目の編集可能なメールフォームが使える
などなど。他にも説明を聞きながら便利が機能があるなあ、と思ったのですがそれはまたいずれ。

正直なところでは、今のところ、ライトプランだと機能が限られているので、案件によってはすすめにくい可能性があると思いました。まだちょっと様々未検証なのでなんとも言えないですが。
ただし、ブログに毛が生えた程度でお問い合わせフォームがひとつあればいい、と言うぐらいの案件であれば、ライトプランでいけます。
独自ドメインで、一応独自ドメインのメールも使って、と言うぐらいでライトプランを利用したとすると。
・サービス利用料 25,000円(年間一括払い)
・レンタルメールサーバー 約1,000円(年間一括払い)
・ドメイン管理費 約3,000円(年間)
と言う感じで概ね年間30,000円(税抜)ぐらいと試算できます。
(CMSのアップデートの作業は無くなりますが、使い方の問い合わせなどをお客様から直接サービス提供会社に連絡するのはハードルが高い場合などを考え、サポートについては別途料金設定をする必要があると思います。)
ひとつのWPのアップデートに年間16時間使っていたとして、1時間5,000円のコストと考えると、年間8万円(税抜)。差額は50,000円。もし、10サイト管理しているなら10倍です。もちろんこの試算には嘘がありますが、少なくともアップデートに使っていた時間は浮くはずです。それを儲けのある仕事に割り当てることができるなら、もしくは社員の勉強の時間や、残業を減らせるなら・・・

ちょっと、心揺れませんか?

心揺れたかもしれない、と思うウェブ制作者の方はぜひ評価版を試して見てください。評価版の申し込みはこちら

WPサイトデザインのコツ(ちょっと知ろうCSS編)

前回、デザインカンプを受け取るコーダーが何を考えてWebサイトを作っているかについて、自分を参考に、お話ししました。今回はコーダーの主なお仕事である、CSSを書くこと、そのCSSについてちょっとだけ知ってみよう、というお話しです。

CSSは「Cascading Style Sheets(カスケーディングスタイルシート)」というもので、スタイルシートとも言ったりします。HTML文書に対して、人間の目に見える部分の「装飾」を一手に担っているデータです。

例えばこの見出しを実現しているCSSとは

この見出しは見出しレベル3<h3>というタグでマークアップされています。これに対しかけられているスタイルは以下のようなものです。


h3 {
font-size: 27px;
font-size: 2.7rem;
line-height: 1.1852;
margin-top: 2.3704em;
margin-bottom: 1.1852em;
}

フォントのサイズや行の高さ、上下のマージン(空白)などが設定されています。ですが、フォントの太さについての情報がありませんね。その記述を探して、CSSのファイルを上の方に遡ると、こんな記述がありました。


h1,h2,h3,h4,h5,h6 {
clear: both;
font-weight: 700;
}

見出しについて、各見出しレベルまとめて設定があります。回り込みを解除することと、フォントの太さについてです。文字の色については、ここにも書かれていませんが、さらに記述を遡ると、この文書全体を表す<body>タグについての指定で書かれています。


body {
color: #333;
font-family: "Noto Serif", serif;
font-size: 15px;
font-size: 1.5rem;
line-height: 1.6;
}

実際には、下記のような順でスタイルが記述されています。


body {
color: #333;
font-family: "Noto Serif", serif;
font-size: 15px;
font-size: 1.5rem;
line-height: 1.6;
}


h1,h2,h3,h4,h5,h6 {
clear: both;
font-weight: 700;
}


h3 {
font-size: 27px;
font-size: 2.7rem;
line-height: 1.1852;
margin-top: 2.3704em;
margin-bottom: 1.1852em;
}

<body>要素では文字の色、フォントの種類(ファミリー)の次に、フォントサイズや行の高さについての指定があります。文字色やフォントの種類についてはこのbodyに対して書かれた設定が反映されていますが、フォントサイズや行の高さについては、最後のh3について書かれた設定が反映されています。これがCSSの特徴と言えるカスケーディングの仕組みです。より詳細な指定で記載してあったり、元のものよりも後に記述することで、設定を上書きしていける一方で、特に指定がなければ親要素・先祖要素に遡って書かれているスタイルの設定が反映されます。

なので、最初の方に基本的な設定を書き、共通しているものはその設定を使い、特別な設定が必要なものを後回しに書いたり、詳細度をあげて記述することで、部分的に上書きしながら、全体のスタイルを書き上げていく、ということをしています。
つまり、レイアウトの中から共通項を見つけ出す作業をし、最初にまとめて書いてしまうということをやっています。なので、パターンを見出したり、共通できるものはまとめておきたい、というのがコーダーの頭の中には常にあるわけです。

カスケーディングの良さと難しさ

共通ものをベースにして、個別の設定をそのあとに書いていく、という基本の構造があり、効率よく書いていくというものの、ひとつのサイトに利用するCSSが3000行以上になることも珍しくありません。それらの構成を把握しながら、順序立てて書いていても、途中でスタイルが変更になったり、追加のレイアウトが増えて行ったり、などが繰り返されると、共通の部分がどこで、そのあとのどこでどう上書きされているかの関係性を見失ってしまう場合もあります。複数人で開発している場合には、ルールが必要にもなるでしょう。

全部それぞれ別々に書けばいいのでは?

身もふたもないですが、そういう風に考えることもできます。共通の部分など考えず、ひとつひとつ全て別々に書けば、思った部分だけを修正できるのではないか?しかし実際そういう風に書いたとするとCSSファイルはとても量の多いものになり、レイアウトに何か共通の修正が入った場合は、それぞれに直す必要もあり、手間がかかります。

これを避けるために、コーダーは共通部分はまとめたいと強く願うのです。

こういうのほんとありえない、、、になるわけですね。

Illustrator で文字のCSSを見てみる

CSSプロパティというウインドウパネルを出して、テキストを選択すると、そのテキストのCSSをみることができます。これらの積み重ねで、Webサイトはその形を成しています。

まとめ

CSSについてもっと詳しく知りたい方、書けるようになりたい方は、そのための教本を探していただくことにして、ここでは詳しく書きません(書ききれません)。以前、HTMLとCSSをちょっと書いてみる連載を書いたので、もっすごい基本的なマークアップやCSSの話をしているのでそちらをご覧ください。

次回からはもっと具体的な、デザインを作る時の考え方について書きます。

WPサイトデザインのコツ(コーダーの頭の中編)

Webサイトを作る時のデザイナの役割について前回書いてみました。今回は、デザインを受け取って実際に起こす作業をしているコーダーについて書きます。DTPもあとの作業である印刷の工程に知識のあることが作るものの質を変えるように、Webデザインも、デザイナのあとの工程にあるコーディングやそれを担う人が何を考えているか知ることで、デザインが変わると思っています。

デザインそれ自体も大事ですが、デザインカンプを受け取り、デザイナの思惑を読み取って、Webサイトとしての最終的な形を作る「コーダー」が何を考えて作業をしているのか、ちょっとのぞいてみたいと思います。

つまりは、私の頭の中か・・・・・。遊ぶことしかないようですけど。悪って何?

デザイナの意図を読み取ってデータにする

コーダーがデザインカンプを受け取って何をしているかというと、写真にもあるように、デザインデータから、CSSを書くためのあらゆる数値や情報を読み取ります。私はそれをデザインカンプをプリントしたものに、とにかく書き込んでおきます。あとから見返すことも結構多いので。WebサイトにするにはHTMLとCSSとでデザイン要素をデータに還元して、ブラウザが解釈して表示できるものに変換しているのです。また、画像データやアイコンなどのデータをデザインカンプから書き出す作業もします。

自動化できないの?

それができたらコーダーの仕事がなくなってしまう・・・・の、ですが、部分的に自動化することはできますし、試みられてもいます。Illustratorでは文字周りのCSSを書き出せるようになっています。それらを活用すると、コーダーの負担が減るかもしれないですね。

効率的にCSSを書きたい!コーダーの思い

Webサイトを仕上げていくとき、コーダーの頭の中には、こんな考えがあります。

  • CSSは後々でも管理しやすいように、わかりやすく簡潔に書くべき(なぜならWebサイトは繰り返し改善する=あとで修正の必要があるから)
  • HTMLに余計な要素を書くべきではない(マークアップにはルールがあり、正しく簡潔に書くことが求められている)
  • なるべく共通のパターンで整えたい、ルール化したい(そうしとかないとあとで分からなくなる)(毎回別々のレイアウトパターンのものを作るとかは手間である)

などです。
そんなコーダーをイラっとさせるのが、以下のようなこと。

こういうことがあると「デザイナーの気まぐれか?」「レイアウトはその時の気分かよ」「余白の取り方に一貫性とかルールとかないわけ?」などと、頭を抱えてしまうことになります。それでも、理由があれば、いいのです。「ここはこれまでの流れとトーンを変えて目立たせる必要があるので、フォントやレイアウトに差をもたせます」など、など。あればね。もしくは、本当に作るときに間違えてずれてしまった、とかならば、仕方ないのですが、問題は、読み取る方には「意図がある」のか「うっかり」なのかはっきりわからないことです。

話し合えばいい話。

デザインカンプだけから意図を探ろうとするのがまず、無理筋です。デザイナは、意志を持ってそのレイアウトを決めているなら、コーダーに向かって「見出しはこういうスタイル、空白は基本Xピクセルで、例外はどこのページのどの部分、本文サイズはどれぐらいで、行間はゆったりさせたいのでフォントサイズのX倍とっています」など、意図を伝えればいい。もしくはコーダーから疑問点を確認すればいい。ただし、社内ならともかく、デザインとコーディングを全く別の組織の人間が受け持つことも少なくないので、それらのコミュニケーションに手間がかかることもあって敬遠されるのかもしれません。
また、デザイナ側に経験やCSSなどの知識が乏しいと、何をどう伝えていいのかわからないこともあると思います。けれど、それを上手にするためには、まず一言伝えてみること以外に、上手くなる方法もないと思っています。

まとめ

デザインの後にあるコーディングのことに少し興味を持ってもらえたら何よりです。もしくは、効率だのパターン化だの、つまらん話だ、と思われましたかね?もちろん、デザインに素晴らしい意図が読み取れ、それがWebサイトを構成することに欠かせず、その効果を遺憾なく発揮してWebサイトの目的を達成するだろう、と信じられる場合には、こちらもやる気が出ますけど。なんとなくWFから指定された要素を組み込み、なんとなくこんなもんかで形にして、自分にだけわかるルールで整えて、それっぽくなったからOK?クライアントが気に入ればOK?で作ったものは、すぐわかります。コーダーだけじゃなくて、ユーザーも。
デザインデータをもとにせっせとそれを実現するのがコーダーの仕事ですけど、予算には上限が存在し、使える時間も限られている。しかも、一度作ってしまえば終わりではなく、何度も修正繰り返していく前提なのです。どんな細かい無茶振りな指定にも答えます!というわけにはいきませんからね。

わがままデザインにならないようにするには、何をポイントに考えればいいのか、このあとの回で書いていきたいと思います。