スタイルシート・レイアウトについて

河本孝之(Takayuki Kawamoto)

Contact: https://plus.google.com/112326853631114362590/about

First appeared: 2006-06-02 00:56; 2006-06-12 20:58;
Last modified: .

はじめに

この記事は、2006年6月に公開した「スタイルシートによるデザインは過渡期なのかも」という記事と、これに対するはてなブックマークでのコメントに応答した「スタイルシート・レイアウト、再び」という記事をまとめたものです。再掲載するにあたり、当時の意見は(2015年の現在から振り返ると間違っていた理解や見通しも含めて)そのまま掲載してあります。なお、2006年の当時は別のウェブ制作会社に在籍していましたし、既に記事の初出から10年近くが経過しているため、具体的な個人(当時の同僚)について論評した内容も再掲載して問題ないとは思いますが、僕自身の推測にすぎない箇所は削除しました。また、これら二本の記事について、(1) 不正確な表現を改め(例えば「代理店」を「広告代理店」に修正しました)、(2) 2015年の時点で追加できるコメントを最後に加え、(3) 再掲載した記事の中にも注釈を追加してあります。

スタイルシートによるデザインは過渡期なのかも

さきごろ /.J で紹介されていたレポート [注釈(2015): 現在は「スラド」というサイトになったので、URLも修正しました] にもあったように、大企業の約7割はまだテーブル主体でレイアウトを組んでいます。これは、企業というよりもスタイルシートでのレイアウトに躊躇する制作会社や広告代理店が多いということでもあり、その最も大きな理由としては、恐らく相変わらずの互換性(ブラウザどうし、また同ブラウザのバージョンどうし)が挙げられるでしょう。もちろん対応すること自体は可能ですが、Netscape Navigator 4.7.x と Opera 9 Beta で全く同じ見栄えを実現しようとすれば、レイアウトにスタイルシートを導入することが、他の修飾的なプロパティの使用を諦めることにつながるというジレンマを引き起こすでしょう。また、一部の有能な方から見れば信じられないことかもしれませんが、ざっと他の制作会社のサイトを見たり、あるいは実際に制作会社で働いてきた経験から言うと、日本で何らかの制作会社に所属している「ウェブデザイナー」のうち、フルでスタイルシートのレイアウトが組める人は多くて 3 割くらいだと見ています。そして、この数はもちろん上記のレポートの結果と関係があります。

実際のところ、フルでスタイルシートのレイアウトが組めるウェブデザイナーは、実はそれほどいないと思っています。その感覚だけでも「3割以下しかいない」と推定して構わないのですが、もう少し考えてみましょう。上記の記事で挙げられていたのは、確かに一部上場の大企業ですが、そこのサイトを制作しているスタッフは、たとえ制作会社の名前が大きくてもそれに見合ったスキルがあるとは限りません。ふつう、こうした大企業のサイト制作を請け負ってくるのは広告代理店さんです。そこが、予算やスキルを考慮して制作会社に依頼します。規模が大きくなると、広告代理店から実制作を請け負った制作会社が、また他の制作会社とかフリーランサーに実制作を依頼することもあります。そうすると、実制作するスタッフがスタイルシートのレイアウトに対応してコーディングできなければなりません。また、実制作のスタッフから返ってきた(外注の場合は納品された)ファイルを開いて、広告代理店へ納品するまでに少なくとも内校と最終校の計2回はチェックする必要があるでしょう。では、誰が? 広告代理店から受けた制作会社にスタイルシートを理解できる人間がいなければ、およそスタイルシートの運用について内校などできる筈がありません。したがって、一人でもスタイルシートを理解していないスタッフがいれば、そのレベルに合わせてレギュレーションを立てなければならないでしょう。そして、特に大阪の制作会社を色々と見ていて思うのですが、スタイルでレイアウトを組める人の方が多い制作会社というのは、実は数えるほどしかないと言えます。

スタイルシートでレイアウトを組めるスタッフがどれだけいても、そのスタッフだけでは仕事を処理しきれない場合は、レギュレーションをテーブルレイアウトに変更(敢えて「落とす」とは言いません)しなくてはなりません。したがって、一つの制作会社としてはテーブルレイアウトしか対応できない「見做し判定」を食らっても仕方がありません。もっと案件の規模が小さくなって、スタイルシートを理解している一部のコーダーとデザイナーの組み合わせだけで処理できるなら、フルでスタイルシートのレイアウトにも対応できると言うでしょう。しかし、見做し判定としては「できないも同然」となります。上記のレポートにでてきた数字も、大企業のサイトだけを分析して国内の動向をそのまま一直線に語っているものではなく、「見做し判定」をしているにすぎません。僕がここで述べている推定も、同じく見做し判定です。

ここからマーケティング屋さんのように「先進的な企業はみんなスタイルでレイアウトを組んでいますっ!」などと言っておいた方がよいのかもしれませんが、残念ながら僕はウェブデザイン業界はぜんぜん淘汰が進んでいないと思っているので、スキルのない人にはそのままいてもらう方が助かるという邪悪な戦略を採りたい(笑)。特に、DTP 業界からウェブ制作に参入してくる会社をどうやって早い段階で淘汰するかが鍵になるでしょう。断言しますが、DTP しか知らない人はそのままのスキルでウェブデザインなどできません。というか、してほしくないのだけれど、「コンピューターでデザインできます」という大づかみな感覚で参入してくる会社は後を絶たないため、スタイルシートのスキルだけを問題にすると、再び IA やユーザビリティなどが置き去りにされかねないという危惧があります。

で、ふだんからスタイルシートを使っている方はおおよそ分かっていることでしょうが、現行の CSS 2.1 をフルで使う機会などめったにありません。特に音声出力関係のプロパティや印刷出力用のプロパティは、仕事で使ったことのない人が大半だと思います。そしてこれもまたおおよそお分かりかもしれませんが、フルで使ったところでスタイルシートの装飾プロパティは一枚の画像や FLASH にはかないません。それに、絶対位置でも使わない限りレイアウトにそれほど自由度はなく、海外のスタイルシート系のショーケース・サイトを見ても分かるように、オリジナリティの大半はスタイルの使い方ではなく貼り付けている画像もしくはスタイルを使うための DHTML の組み方だったりします。スタイルシートの有効性は、おおざっぱに言えば (X)HTML でマークアップされたデータの言語構造において syntax と pragmatics の分別にあるのだから、分別した後の pragmatics 的なレベルでボーダーを何ピクセルにするかとか、あるいはフォントサイズを固定すべきかどうかといった話題は、ユーザビリティの観点から色々と考えられることは多いけれど、スタイルシートの本質的な有効性は既に満たしているという点から言えば、まさしく枝葉末節のどうでもいい話でしかありません。

また、このことから分かるように、スタイルシートをスキルとして修得するということは、まさしく pragmatic なものを syntactical なものから切り離したときに、本体をきちんと理解してマークアップできるかどうかにかかってきます。それゆえ、(X)HTML を理解していない人が「これからはスタイルシートのレイアウトです」などと口にするのは笑止もいいところで、それこそ <font> タグをべたべた貼り付ける感覚で「デザイン」をやっていた前時代的なオペレーターの方々と同じ次元でしかありません。ということで、いろいろな意味でスタイルシートを使ったデザインというものは、まだまだ過渡期なのかもなぁと考えさせられます。

冒頭に戻る

スタイルシート・レイアウト、再び

えーと、Google Analysis を使い出したのですが、先日のスタイルシート・レイアウトについて書いた記事へ 1,500 件くらいのユニークアクセスが来ていたので、いただきましたコメントにお返事してみたいと思います。hatena あんてなからアクセスが多いのは XE の方でも知っていましたが、個別の記事へブックマークしていただいてる方が予想外に多かったのですね。ちなみに、コメントをいただいている方のお名前とか URL とかは特に公開しませんのでご安心下さい。検索したら分かるのかもしれませんが・・・ではでは。

[注釈:2015] 上記、当サイトでは Google Analytics は既に使っていません。また、"XE" とあるのは、過去に運営していた "crossedge.net" という互換シェルのサイトのことです。

HTMLでごちゃごちゃレイアウトを調整しなくて良いようにするためのCSSなんだけど。本来はCSS技術者が一人いれば、あとはHTMLコーダーだけで作業できる。そうでないのは未だに紙ベースとWebベースの区別がついてないから。

制作会社によって、「コーダー」の役割は異なりますね。大きなところだと HTML コーダーと CSS 専門のコーダーさんがいるのかもしれませんが、たぶん日本で CSS のコーディングだけを専門に担当している人が常駐している会社は殆どないと思います。事実上、多くの制作会社で「コーダー」さんと言えば、HTML, CSS, JavaScript を全て担当している人という意味になるでしょう。つまり、フロントエンド側の実装を全て担当する人ということです [注釈(2015): もともと「クライアント・サイド」と書いていましたが、現代の用語法では「フロントエンド」と書く方が適切ですね] 。で、DTP からいきなりウェブに鞍替えする会社は、こういうコーダーさんがいれば、あとのデザイナーはページの「見栄え」を作ればよいだけだと考える傾向が強く、そういう環境でデザインしているデザイナーさんは、結局のところ広告代理店のディレクターに情報デザインやユーザビリティの点で、何年かは叩き上げられないといけなくなるわけです。まぁうちのチーフ・デザイナーにしてもイラストレーターからの転身らしく、ウェブの標準的なレイアウトを組むのは数年かかったようです。でもそれは IA を勉強したからではないみたいだし、広告代理店に鍛えられたからだけでもないようです。なんたって、既に公開されている「よいデザインのサイト」をパクってないと仕事が間に合わないので、自然と標準的なレイアウトは嫌でも身につくのでしょう。皮肉なことです。

制作アプリ側の環境は徐々に整ってきたけど、ブラウザ毎のあまりにもいい加減な実装でデザイナーにもユーザーにも余計な負担が……。理念は素晴らしいのになあ。

解釈の仕方で主導権を握りたがっている、各方面どうしの綱引きもあるのでしょう。で、制作会社としてはここ 2 年くらいの間で出そろった IE / Firefox / Safari くらいに対応していればよいというところが多いです。極端な話、芸能人の公式サイトや金融系や風俗などの業界だと IE 6 だけでいいという会社も多いです。だって、カモは素人の一般ユーザーで、ここ数年の間にパソコンを買ったばかりで目の色を変えてアダルトサイトを見てる人、ということですから(笑。そんな人がマックだったとしても切り捨てて構わないくらいの数しかいないし、Firefox や Opera を使ってる初心者も切り捨てて構わないくらいの数しかいないはずです。アクセスログを見ても、IE 以外のブラウザは殆どは海外のユーザーですからね。国内ユーザーは、圧倒的に Windows XP + IE 6 という組み合わせが多いです(一部、UA の詐称はあると思いますが)。

一般企業のサイトを制作する会社ですら互換性を打ち切り出しているのは、幾つか理由はあると思いますが、一つの大きな理由は CSS のプロパティを知っているコーダーやデザイナーはそこそこいても、ブラウザごとのバグやハックを熟知しているコーダーやデザイナーはそれほど多くないし、どうしてもハックしなきゃいけないほど元々のデザインにこだわりがあるのかという問題もある。最初からブラウザのバグが分かっていれば、互換性を保ちつつコーディングができるので、わざわざ「互換性を維持するための調整」という作業を後からする必要などありません。が、それだけのスキルをもっているコーダーさんはまだまだ少ないと言えるでしょう。

で、もう一つの大きな理由は、たとえスタイルシートのプロパティを一通り知っているくらいのコーダーさんやデザイナーさんしかいないとしても、調べたり試行錯誤すれば何とかなるのに、特定のブラウザに対応するためのハックを見つけたり調整しなおす時間がないという現実があります。ふつうの制作会社では、デザイナーであれコーダーであれたくさんの案件を同時に抱えています。そして、各案件の工数が決まっているため、ハックが必要になっても調べたり再調整している時間なんかありません。

とにかく大阪の制作会社を見ていると、試行錯誤したり再調整する時間など見積もらないで早く納品するというのが 「顧客に対するサービス」だと言っていたりするところが多いように見受けます。金額の話にしてもそうですが、もう既に、テストとか調整の時間を入れた見積もり工期など言っても通用しないのです。それどころか、実作業だけの工数を提案しても、更にそこから(自宅作業とか休日勤務でしか事実上は補えない)「サービス」を要求されるのが実情です。これはSOHOだろうと会社員だろうと変わりません(そういうのから守るために会社ってあるんじゃねーのか?)。まぁそれでも、学生のサークル感覚でやってるような会社だったら、試行錯誤する時間を残業してがんばろうとするのかもしれませんが、少なくともうちの会社みたいなところだと、試行錯誤と言っても 23:30 からそれをしないといけません(笑。試行錯誤したいなら自動的に徹夜となります。つまり、顧客のためにがんばればがんばるほど、貧乏になるか(外食ばかりしているのですから、当然ですね)不健康になってゆくというのがよくあります。それを、たかだか月給 18 万とかのアシスタントがやってたりするわけで、そらすぐにやめるわな~と思います。工場とかで人事担当者が「定着率」を毎年のテーマにしますが、ウェブ制作や DTP の会社でも本当はテーマになるんですよ。でも、「デザイン」とか言っててみんな気取ってるから言わないのですが・・・で、そういうおしゃれな言葉に釣られて専門学校とかから「アシスタント」という名前の無邪気な代用品がどんどん補填されるから人不足に悩む心配はない、と。どんどん「『デザイン』とか『ビジネスモデル』とか『マッシュアップ』とか『クリエイティブ』の奴隷にしてください」って向こうからやってくるし、デジハ○とか W○O とか、原価計算や労働法規は教えないけれど、小手先の制作テクニックをそこそこ教えてくれる養成所もたくさんあります(しかし、そこそこ有能な奴隷にしてくれたらもっとありがたいのですが)。

・・・といった嫌みはともかく、これを「社益」の観点から見ればモチベーションのの低下につながると考えないのが、大阪にありがちな中小企業の実態です。大阪が「商いの街」だったとかいう都市伝説をいまだに信じてる人が、地方から大阪に出てきて起業してる人には多いですからね。自分から喜んで滅私奉公したがっている人たちがいるのだというおかしな思い込みを抱いているヘタレ経営者も多い。『プロジェクト X』に登場するような、つまんないプライドのためにあくせく働いてくれる、安上がりなテクノロジーヲタクこそが「ぷろふぇっしょなる」であるという。・・・おっと、また嫌みに走ってるな(笑。では次にいただいたコメントを。

3割かぁ・・・業界的にはそんなもんなのか…。

うーん。あんまり真剣にとられても困るのですが、もういちど繰り返して言うと、これは「見做し 3 割」ということです。正確な統計は取れないだろうし、どうしても僕らそれぞれの経験から推定しているだけなので、数字にこだわるよりも「半分もいない」という感じだと理解してくださればありがたいです。この辺の見做し感覚は、ウェブ制作と言っても業種別にそれぞれ違ってくると思います。

例えば、b.A. やキノトロープといった、大企業を相手に制作している会社だと、スタイルシートでデザインできる人の割合は(思い込みも含めて<笑)かなり高い。実際、コーダーを名乗っていて HTML, CSS, JavaScript を使いこなせない人が b.A. やキノトロープ(あるいは両社から請け負っている二次請けの制作会社)で働いているなんて想像できないでしょう。恐らく、こういう大手制作会社とその直請けや孫請け制作会社の中では、「コーダー」と呼ばれる人の殆どが CSS のレイアウトを単独でこなしている筈です。

しかし「制作会社」を名乗っていても、事実上は楽天とかにある自社の B2C サイトで細々と稼いでいるところも多いので、そういうところだと CSS のプロパティを一つも知らないで「デザイン」している人だってたくさんいます。当然、「コーダー」といった専門の担当者を雇う余裕などないので、デザイナーがコードも(正しく扱えるかどうかはともかく)いじります。なお、そういうところを「制作会社」と呼ぶべきかどうかに異議を唱える人もいると思いますが、条件をしぼっていけば CSS レイアウトができる人の割合は増えるでしょう。しかし、CSS を全く知らない場末の名刺屋さんみたいなところがウェブ制作を名乗ってしまっている現実がある以上、そういう人たちも頭数に入れておかないといけません。 そうでないと、淘汰すべき本当の対象を見失います。それに、ウェブデザインを専門にやっている制作会社のデザイナーにも、Dreamweaver のデザインビューだけでページを編集しているような人が驚くほど多いし(コーダーさんに渡すべき中間素材を扱っているのだという意識がほとんど無い連中ね)、所属している会社の業態や規模だけでも割り切れないところがあります。

で、規模で推測してみると、50 人以上のスタッフを抱える会社はやはり専門のコーダーさんがいるので、そういう人たちのスキルは高いでしょうし、やろうと思えばできるという人の割合は当然ながら高いです。でも、グラフを思い描いて頂くとよいのですが、会社の規模に応じて右上がりで簡単に比例するようなグラフになっているかと言うと、ある 段階で左方向へ真っ直ぐになるというのが僕の印象です。特に個人でやっている人を想像すると、もちろんフリーランサーは高いスキルをもっているがゆえにフリーでやっている人が多いので、彼らの CSS のスキルは当然高いでしょう。しかしフリーランサーと、しばしば見かける勘違い系の個人がやってる制作会社は規模で言うとどちらも「1人」なので、平均して考えると CSS レイアウトができる人の割合はそれほど高くないという統計になるでしょう。したがって、正規分布の逆の形(人数が最少と最大の場合に割合が高くなる)を想像したくなりますが、実際は少し違うだろうと思います。

最近の最大のジレンマ。代理店に技術がある人がいればと思うけど、それが最良というわけでもないだろうしなー。テーブルが何が何でも悪いというわけでもないだろうし。

やはり、生産性というキーワードで話をしてゆくと、スタイルシートが殆どわからないアシスタントに実作業をさせようとすれば、フォントサイズのレギュレーションを立てて Dreamweaver のクラスを指定させるくらいで、あとはコーダーさんがクラスや ID なしのタグについて一律のスタイルを定義するのがせいぜいではないかと思います。そういうことをふまえた上でデザイナーが動いてくれたらまだよいのですが、なかなかそうはいきません。「このデザインだとスライスはこう切らないといけないな」といった配慮をしてくれれば、まだマシな方でしょうね。そんな制約にこだわらないのが「デザイン」だと思ってる・・・本気でそう思ってる人もたくさんいます。こういう人たちは、「デザイナー」と呼んであげるから、ぜひ 「ウェブデザイナー」とは名乗らないでいただきたいですね。いや、どちらが偉いとかの話ではなく、そういう人たちはウェブに特化したスキルがありていに言って「ない」のだから、職種が違うのです。

で、上記のコメントでも言及していただいているように、CSS レイアウトを採用するかどうかを誰が決めるのかという話では、レギュレーションに沿ってチェックするスキルがあればディレクターとコーダーのチーフが協議して決めればよいと思うのです。あるいは、広告代理店のディレクターと自社のディレクターが協議する場合もあるでしょう。ただ、本人達が実制作をどこまでやれるスキルがあるかはともかく、協議する人たちには正確な知識がないといけません。ディレクターにも色々いるので、営業上がりのディレクターに多いパターンだと「WEB 2.0」だの「LPO」だのと適当な言葉でレギュレーションを振ってきます。しかし、たいていそういう連中は具体的なレギュレーションを立てるスキルが全くないので(笑、制作側のディレクターや主任コーダーが、内校段階でレギュレーションを立ててチェックしないといけないのですね。それから、社内のディレクターにしても、単なる段取り屋も多いので、そういう人たちが CSS レイアウトの採用を決めてもレギュレーションを立てるスキルはありませんから、現場の主任コーダーがレギュレーションを立てる場合も多いと思います。

さて、いまだと SEO 的な制約が加わることもあるので、ソースを軽くして、スパイダーが理解しやすい構造にまとめてくださいという要件なら、それは同時に CSS レイアウトを要望していることにもなってきます。そして、うまい広告代理店さんだと、事実上 SEO 対策を要求すれば CSS レイアウトもやってもらえると見越して要求してくるかもしれません。制作会社側に立つと、もし自社に CSS レイアウトをこなせる人材がいないなら、SEO 対策をとりつつ CSS レイアウトを安易に引き受けずに済むような、幾つかの実装パターンを提案する必要があります。相手が本当は SEO について何も分かっていない広告代理店なら、over optimized を避けるといった理由で、テーブルレイアウトで済ませられるかもしません(笑。実際、ウェブを専門としていない広告代理店さんが「ウェブはよく分からないので、やってくれませんか」と問い合わせてきた場合には、これで避けられる可能性があります。あるいは、中途半端に知ってるだけの広告代理店なら、例えばクライアントの方で更新作業をするかどうか問い合わせてから、「もしクライアントが Dreamweaver などでの作業に熟達していなければ、CSS レイアウトだと崩れる可能性がありますよ」と提案してみるとか、「クライアントに CSS レイアウトを崩さずに編集する手順をご説明願えますか?」と言ってみるとか。特に開発系出身のディレクターだと、クライアントに分かりやすく説明するといったことは苦手な人が多いので(実際に多いから困るのだが)、「では、CSS レイアウトを無理にやるよりも他のところで最適化しましょう」と言ってくるかもしれません。とにかく広告代理店のディレクターといった、とんがった話題を追いかけがちな人々と渡り合う場合には、こちらが CSS レイアウトをやりたくないとか、あるいは CSS レイアウトをするスキルがないと悟られないように交渉しなくてはなりません。まぁ個人的には何度も書いていますが、SEO の方がどうでもいいことなんですけどね。つまり、たいていの会社のサイトを見ていると、ライティングをやりなおさないといけないところが多いので、結果的に SEO 対策ともなるようなライティングを正当な見積もりに入れて要求し、リライトすればよいだけという場合が多いのです。そうして、適切にコンテンツをリライトしたり組み直していけば、SEO 対策になる筈だというのが正しい筋の通し方であって、適切であろうとなかろうと「あと 2 ワード足りない」というバカげた理由で文書に無理矢理キーワードをねじ込むなんてことを、文章を書く技術もない連中がやっているのが SEO 会社でよく見る仕事です。そういう連中が書いた文章は、たいてい Google の上位のページを見ていると分かります。くどくどと「お米が」「お米で」「お米を」などと書いている通販サイトとか、サイト名や社名などとぜんぜん関係のない「キーワード@キーワード」の形式で、スローガンじみたフレーズをやたら連呼してるサイトとか。別に、商魂たくましいとも思わないですね。見ていて反吐が出ます。

さてさて、せっかくいただいているコメントの趣旨からすぐに脇道へ逸れてしまって申し訳ありません。では次のコメントを・・・

やってみてわかるけど趣味として組めるレベルと大企業サイトのcssを設計するのは全然違う。そしてテーブルに比べて自由度が低すぎるのは確か。メリットがクライアントの目に見えない。…とか思ったけど。そんなにツン

最後の一言は意味不明なのですが、大企業のサイト(と言うよりも大規模サイトということでしょうね)になると、設計段階できちんと組み、そして実制作も下請け会社などのスタッフを含めて多人数になる可能性が高いため、ページ・デザインの段階からレギュレーションをしっかりやっていないと、後で面倒な修正や調整をたくさんしなくてはならなくなります。現在ではクライアントも制作側も Dreamweaver がデファクト・スタンダードになっているため(クライアント側はまだビルダーや FrontPage を使っている場合もあります)、CSS レイアウトとは言っても Dreamweaver のデザイン・ビューで目視可能なプロパティに制限されるという点も押さえておく必要があるでしょう。また、Dreamwever にある制限、例えばデザインビューで編集している範囲では class 属性に一つの値しか指定できないので、一つの (X)HTML 要素に対するプレゼンテーション定義は、タグそのものに対する定義と、ID 属性、それから class 属性の値を一つずつ、計 3 つの定義しか組み合わせられません。したがって、class 属性の値どうしでカスケードするという手法が使えなくなるので、最初のカスケード設計をしっかりやらないと、例外的なプレゼンテーション要素に対応するたび、定義項目がどんどん増加してゆきます。

よくスタイルシートの話題で「スタイルシートの方が簡単だ」とか「テーブルレイアウトと CSS レイアウトでは実質それほど工数に差はない」という意見を目にします。それぞれどういう作業を思い描いているのか分からないのですが、「テーブルレイアウトと工数に差はない」という人がインラインでいちいちスタイルを指定しているわけがないのは確実ですね。そして、いまどきスタイルを使わないでテキスト要素にいちいち font タグを使っている人も少ないだろうと予想できますが、いちおう HTML だけで組んでいると仮定してみましょう。すると、CSS の外部ファイルで幾つかの div 要素を定義すると、たくさんページがあっても決められた id や class の div タグを書けば、レイアウトが完成します。そして、これは HTML でやっても工数は大して変わらないでしょう。Dreamweaver で作業している限り、たくさんページがあってもファイルをコピーしてリネームすればよいだけで、これはどちらのやり方でも同じ作業です。たとえ個々のページで、仮に背景色のパターンが色々ある場合でも、CSS レイアウトはあらかじめ定義しておいたクラスを Dreamweaver のデザインビューで div 要素に指定してゆけばよいだけですし、テーブルレイアウトにしてもどこかの td タグに bgcolor を指定すればよいだけです(あれ、一行ぶんの td を全て選んでプロパティ設定すると、tr にプロパティが設定されてしまう動作、なんとかならんかな)。実質、工数は同じと言ってもよいです。ただし、これは Dreamweaver での作業を前提にした場合です。

それから上記のコメントでも言われているように、クライアントを説得する場面で「CSS レイアウト」の利点を説くとすると、せいぜい SEO 的な効用(しかしこれもすぐには効果が出ないし、見た目では分からない)か、あるいは外部スタイルシートでプレゼンテーションの更新が簡単に出来ることを力説するくらいになるでしょう。まぁ「WEB標準」といった単語を持ち出してもいいのかもしれませんが、なぜそれがいまの流れであるかとか(実際にそうなのかどうかはともかく)、そういった周辺事情を分かりやすく説明しないといけなくなり、かなり面倒なことになるかもしれません。これが「ナウいから」と言うだけで納得して、予算を追加してくれたり上層部に交渉してくれるような相手だったらどんなに楽か(笑。もちろん、みなさんの制作会社が正当な取引をしていてまっとうな人材を揃えているなら、「WEB標準にできるかどうか」を気にするクライアントには「うちではWEB標準でサイトを制作しています」と値打ちをつけて語っておきながら、社内的にはできて当たり前のスタンスを採っていてもよいでしょう。実際、これを営業的な売り文句にしていられるのはせいぜい 2 ~ 3 年がいいところです。

自分はその三割には多分入っていない。日々努力はしているけれども「使いこなせている」実感は、ない。それを自分のスキルの無さ以外の要素にすり替えているようにも思うし。

それは僕も含めて、みんな感じているのではないですか。全てのタグの組み合わせとかスタイルの掛け合わせをテストしている人などいないと思うので、まだまだ未知のトラブルは数多いです。それに対応できるだけの準備はしたいと思うのですが、僕が言っている「3 割のまともなコーダー」とは、「そもそも我々の書くコードにはいかなるトラブルも起きない」などと平気で言ってのけるホラ吹きのことではありません。そういったことを、例えば2ちゃんとかで言っている人は、「いかなるトラブルも起きない筈だ」とか、あるいは「いかなるトラブルも起きるべきではない」という願望や傲慢さを遠回しに表現しているだけのことです。だいたいが、あの Acid2 にしても全ての可能な組み合わせを網羅しているわけではないし、そもそもブラウザ側で対応できていなければコーダーがハックすればよいのかと言うと、かならずしもそうではありません。確かに職業人としてのコーダーは、もちろん対応できればそれに越したことはないし、すぐ対応できるようにあらかじめ色々なブラウザのレンダリング結果を知っておいたりバグの情報を知っておく方がよいでしょう。お目にかかったことがない状況なら、ハックするのも一つの手だと思います。が、それは決められた工数のうちで対処できればよいといったていどに考えておき、どうしても克服したいと思ったときにだけ、残業するなり自宅で考えてくるなりの努力をしたらいいと思うのですね。

で、またディレクションの話になってしまいますが、もちろん、いま述べたような理由で残業するときは実制作側の人間ではなくディレクターに相談すべきです。これはなにも、実制作側にいるチーフデザイナーとか主任コーダーにデザイナーやプログラマーを残業させるべきかどうか決める「資格がない」とか「能力がない」と言っているわけではありません。そうではなく、人材マネージメントという点でも動かなくてはならないディレクターが、そこでの「責任を負わないといけない」という意味なのです。だって、チーフデザイナーも人間ですから、部下に残業させていたら、人情として監督役の自分だって帰りにくくなるでしょう。他の人にしたってそうです。みんながみんな、さっさと帰るような会社ばかりではない筈です。そうすると、実制作側のチーフが残業させたことでみんな帰りにくくなるし、本人も帰りにくくなると、いずれは全員のモチベーションが下がってくるでしょう。すると、たとえ和気藹々とやっていても効率の悪い現場となり、結果として社益に反します。本来、そのような人材マネージメント(会社経営としての戦略)にかかわる判断は、チーフデザイナーですら一社員でしかないのですから、ディレクターが嫌われ役を買わなくてはなりません。これは偉いとか上役とかいったケチな話をしているわけではなく、ディレクションとは個々のプロジェクトのディレクションだけを指しているわけではないということを意味しています。僕が最近ディレクションの話をして、たびたびいろんな会社や自称ディレクターたちに噛みついているのは、こういう社益の観点からディレクションをしている人が少ないからです。社益の観点から適切なディレクションをするためには、ディレクターは経営者とも交渉する必要があるのです(経営者というものは、往々にして自分自身の利益を社益と混同しがちだからです)。あ~また脱線だよ(笑。

いや、1割もいないっしょ。ってか、レイアウト組めるだけでもだめだし。

では、こちらを最後のコメントとしてご紹介します。なんか高校のときにやってた放送部の番組みたいになってきたな。えーと、CSS レイアウトだけでは不十分というご意見ですね。確かに、スタイルシートを設定したり運用するスキルの話は、「スタイルシートを有効に活用する」という大きなテーマに沿った話から、「ひとまず論理構造を指定する意味づけと、プレゼンテーションを指定する意味づけを分離する」という話まで多岐に渡ります。コー ダーはスタイルシートを運用するスキルのうち、とりわけコンテンツの修飾的な意味づけ(color や background-image など)に関するプロパティの取り扱いは、デザイナーとの協議が必要になります。例えば文字列のアンカー部分について、デザイナーは a:hover のデザインと a:visited のデザインをあらかじめ指定してくるとは限りませんし、中には考えてもいないデザイナーだっています。そして、JavaScript のコーディングを担当する人が別にいれば、ブラウザごとの振り分けをしてもらうべきかどうか、それともスタイルの方でハックすべきかどうか、これはディレクターや JavaScript コーダーと協議しなくてはなりません。あるいは、スタイルの指定にあたってユーザビリティの専門スタッフに意見を仰ぐこともあるでしょう(殆どの会社には、このようなユーザビリティの専門スタッフはいませんが)。それから、古い Firefox で letter-spacing に大きな値を入れたページをレンダリングさせると、ヒープ・オーバーフロー脆弱性を突かれてしまうといったセキュリティーホールが報告されたら(実際にありました)、システム・エンジニアに問い合わせしておく必要があるかもしれません(あまり letter-spacing を動的に変えるようなページはないと思いますが)。

かようにして、コーダーと言っても CSS の勧告ドキュメントだけ読んでいればよいというものではないと言えるでしょう。更に加えて、実際に複数の OS やブラウザが入ったマシンを扱っているかどうかはともかく、各 OS ごとのさまざまな UA について、バグやレンダリングの不備を知っていなくてはなりません。とは言っても、いま書いたことを全てやっているような人は滅多にいないものです。スタイルを JavaScript とイベントハンドラで制御するくらいのテクニックを持っているレベルなら、ふつうの制作会社のコーダーとしては合格点でしょう。

ただ、コーダーさんは後々のキャリアを考えれば、ディレクターなどの管理職に就こうとしている人を除くと、デザイン系かシステム系にシフトしていかなければならないでしょうから、スタイルシート以外のスキルを嫌でも上げて行かざるを得ないという現実もあります。実際、みなさんのまわりの制作会社をご覧になれば、コーダーと呼ばれて HTML やスタイルシートや JavaScript だけをつついている人は、おおむね 20 代の人が圧倒的に多い筈です。ウェブの業界は短く見積もっても最低 10 年は歴史があるので、大学を出てからすぐにコーダーの仕事を始めた人は、ネットバブルの頃からたくさんこの業界に入ってきて、既に多くの方が 30 代になっている筈です。でも、実制作現場でスタイルシートや JavaScript を扱っている 30 代のコーダーさんは驚くほど少ない。彼らの多くは、ディレクターを除けばデザイン系にシフトして ActionScript などを兼任しているか、あるいはシステム系にシフトして PHP や Perl や DBMS を扱っている人が多いと思います。なぜか。コーダーは他のスキルを身につけない限り、そのまま同じ職場にとどまることが難しいからです。かといって、フリーランスとして独立することもできません。特別なコネクションがあってなぜかコーディングだけの仕事が入ってくるか、あるいはコーディング技術の教育や啓蒙活動を専門にしているのでない限り(つまり講師や書籍のライターさん)、HTML やスタイルシートのコーディングだけで食べていけるフリーランサーなどいないのです。ちなみに、これは俗に言う「流し込み作業」のことを言っているわけではありません。

しかし最近では、HTML やスタイルシートのコーディングという職能の範疇を大きくはみ出さずに活躍できる、新しい領域ができました。もちろん、それは SEO のことです。ただし、それは実作業としてコーディングが中心になるというだけで、SEO の担当者がタグの知識だけで業務をこなしているという意味ではありません。さきほど述べたコーダーのキャリアという話で言えば、システム系のスキルを伸ばす方へシフトしなければ、SEO を担当するのは難しいでしょう(確かに、中には Apache のログすら読めないで SEO を担っている怪しい会社もたくさんあるわけですが)。それでも、コーダーさんの重要度が高くなってきていることは確かであり、求められるスキルも多岐にわたるでしょう。実際には、多くの会社で働いているコーダーさんは、いま述べた SEO のようなシステム系のスキルだけでなく、Ajax をはじめとするバックエンドと UI を扱う技術にも深く関わるようになっていると思います("Ajax" と言っていても、その多くは単なる DynamicHTML だったりするわけですが)。したがって、これからの制作会社では、スタイルシートでレイアウトができるだけではスキルとして全く不十分なのはもちろん、HTML やスタイルのコーディングだけでも不十分と言えるでしょう(現状でも HTML/CSS のスキルだけで雇ってくれる酔狂な会社など、まずありません)。

2015年のコメント

上記の記事は、まだ XHTML 1.0 によるコーディングも普及していなかった頃のものです。前半の記事はローカルに保存していなかったので、Wayback machine で読み返してみると、WordPress 2.0.2 というバージョンで MarkupDancing を運用していた時期にあたります。もちろん僕自身も、スタイルシートによるレイアウトと、正規の XML 文書である XHTML のコーディングを2002年あたりから続けていた途中なので、色々なブラウザのレンダリングエンジンで見つかるバグや特殊な挙動に対応するバッドノウハウばかりを積み上げていて、正直なところウンザリしていました。もちろん、その当時から正しいコーディングは幾らでもできました。W3C の規格書なり DTD を正確に理解できれば、誰でも正しく文書の論理構造とプレゼンテーションを分離して、XHTML 文書と CSS を正しく書けたのです。寧ろ僕は、多くのブラウザがスタイルシートを殆どサポートしていなかった時期ですら、一部のブラウザで使えるなら使うという方針でスタイルシートを商用サイトに取り入れて、怒られるほどでした。なので、当時は「テーブルレイアウトで十分である」という現実的な選択も(ウェブサイトの構築業務がコンピュータサイエンスの実験でもなければ芸術作品の制作でもなく、およそビジネスであるからには)正しかったと思います。

前半の「スタイルシートによるデザインは過渡期なのかも」という記事では、まだスタイルシートによるレイアウトは制作業務として普及していないという意味で「過渡期」と表現したわけですが、現在までの経緯を考慮すると、別の意味でも「過渡期」だったと言えるでしょう。もちろん、HTML5 + CSS3 という技術的な推移を考慮して、XHTML + CSS2 が「過渡期」だったと言ってもいいですし、当時のターゲットであったパソコンの「標準的な」解像度という制約は失われており、家庭用のパソコンで使われるモニターの解像度が標準として WXGA (1,360 x 768) とすれば、スマートフォンの最新機種は 1,920 x 1,080 ピクセルもあり、デスクトップマシンで使うハイスペックなモニターだと 5,120 x 2,880 ピクセルの解像度があります。したがって、想定するべきビジターの最低の解像度と最高の解像度では倍以上の開きを想定して、@media のタイプ指定と media queries を使って responsive なレイアウトを組む事例が増えています。一人のビジターが(おおよそ標準的な解像度のモニタの)パソコンだけからアクセスすると想定しても良かった時代は既に終わっていると言ってよいでしょう。このようなビジターのモデルの多様化なりハイスペック化に対応するという意味でも、当時のスタイルシートの運用は「過渡期」だったと言えます。

本稿では、とりたてて「だからどうなのか」とか、「今後はどうなるのか」と断言する必要は感じていません。従来と同じく、我々の仕事がクライアントの意向なり、技術的な動向なり、ビジターの嗜好なりと無関係で自律的にどうこうなるわけではない以上、「変わるべくして変わっていくものに対応する」ための兆候を捉え続けることが、制作側の現実的な姿勢でありましょう。ただし、他の記事でも述べてきたことですが、技術的にどう移り変わるにしても、HTML なりスタイルシートの規格が一定の整合性を維持したそれぞれの体系であるからには、それらを正しく理解するための基礎となる知識をデザイナーやコーダが習得しておかなければならないという点は変わらないと思います。ウェブデザインやコーディングの専門学校や OJT で、記号論理学や公理的集合論を勉強するべきかどうかまでは明言しませんが、「コード」に関わる規格や技術の基礎として必要とされる知識があるという点は、強調しておきます。

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Google+ Twitter Facebook