はじめに

このシリーズでは、CSSを設計／運用していくというテーマで、どんなことに注意しているかを話してもらいます。

第1回目となる今回は、設計に入るときに確認したいことです。対応ブラウザやコーディングルールなどの技術面のほかに、デザインカンプや仕様書に「まだ」出ていない情報をどこまで汲み取るのかという「気遣い」「空気を読む」などの話題も出ています。

参加者は、ピクセルグリッドのエンジニア5名です。

• 高津戸 壮（@Takazudo）
• 小山田 晃浩（@yomotsu）
• 山田 敬美（@tacamy）
• 坂巻 翔大郎（@GeckoTang）
• 中島 直博（飛び入り：@nakajmg）

ブラウザの対応確認は必須

——一口にCSSの設計といっても、さまざまな案件があると思いますが、一般的にまずクライアントから聞くこと、聞かなくてはいけないことはどんなことでしょうか。

坂巻：最初に聞くのは対応するブラウザのバージョンとかですかね。それによって設計が変わるから。たとえば、IE 6からと言われたら、display: inline-blockとか使えなくなったりしますよね。そうすると、Polyfillを使わなきゃいけなくなるし。

山田 敬美：私はクライアントにIE 8から対応と言われて、display: table-cellとか使いまくっていたら、あとからIE 6と7でも最低限レイアウトは崩れないようにしてくださいって言われて、ハックを使って大掛かりな修正をした経験がありました。それからは非対応でいいと言われても、どこまでやるかを最初に確認しようと思いました。

小山田：つまり、IE 8対応じゃなくてIE 6対応だよね？　みたいな（笑）。

坂巻：角丸ってIE 8以下で使えないけど、そういうときに画像でやるのか、対応していないブラウザは無視して四角いボタンになっちゃっていいのかとか。そういう、プログレッシブ・エンハンスメント*的な部分をどうするかということですよね。

やるなら、こちらは「がんばって」やるということを説明しておいたほうがいい。プラグインでできるんだったら『じゃあやってよ』って言われることもありますよね。そして、がんばってやってみたものの、のちのちほかのJavaScriptとかと組み合わさると爆発する可能性もある。

Polyfillを使うのはこういうリスクがあることなんですよと説明した上で、『それでも使ってください』って言われたら、Polyfillの動きを理解して実装していかなくてはいけない。『もしがんばって対応したとしても、のちのち予期せぬことが起こる可能性があるから、僕はおすすめしません』というようなことを言っておくことも、場合によっては必要です。

聞いておくことあれこれ

——対応ブラウザの問題は大きいようですね。

小山田：僕が聞いているのは、基準となる文字のサイズ、文字の色と、リンクの色。これは、僕が「基準三姉妹」と呼んでいるんですけどね（笑）。基準がないと困るんですよ。まあ、これは、デザイナーに確認するのですが。

坂巻：あと、納品形式を相談しておくと、お互いにのちのち幸せかなあと思います。最適化して圧縮してCSSだけ納品しちゃうと、それは編集しづらい。修正があったとき、元ファイル渡してそっちを使ってもらうか、それとも逐一戻してもらうかを最初に相談しておいたほうがいい。まあ、いろんな兼ね合いがあるから、ちょっとした修正でも戻してもらうほうが安全ではあるんですけど。一度納品しちゃうとそういうことが難しいと思うので。

それから、向こうのコーディングルールがあれば聞いておく。コメントの形式とか、インデントとかもですね。『インデントはスペース1個で』とか後から言われても困るし。まあ、既存のサイトがある場合はこっちでソースを見て判断するということでもいいんですけど。

——ソースのコードを読むよりは、事前に言葉なりドキュメントなりであったほうがいいと。

坂巻：あればいいですね。なかったら、空気を読むしかないから（笑）。

ガイドラインの必要性

山田 敬美：……でも、実はガイドラインって、たいがいページ数がものすごいことになっていたりして、読むのが大変だしめんどくさい。コードから空気読んでよしなにやりたい派なので、できればもらいたくない（笑）。

坂巻：まあ、確かに（笑）。ガチガチなところはガチガチだからね。

小山田：ただ「長いだけのガイドライン」もあるし。

高津戸：コーディング専門でやっている会社は、ガイドライン持ち込むとお金取るというのを見たことある。既存のガイドラインに合わせるなら別途料金取る、みたいな。

山田 敬美：あ、ピクセルグリッドでも、相手にガイドラインあったりとか、既存のソースコード読んでということなら、何ポイントという見積もり*はやりますよね。うちで好きなように作っていいならなし、とか。

坂巻：すでにあるサイトの改新って、簡単じゃないですからね。

高津戸：そう、イチから作るほうが簡単。

坂巻：元のサイトで汎用性のある名前を使っちゃっていて、バッティングしていることがあるから。

小山田：たとえば、これまで公開したページがあってすでにコンテンツはあるけど、ページのレイアウトとかコードをリニューアルしたいという場合は、昔のコンテンツを使いたいですよね。その場合、スタイルはリニューアルしても、コンテンツ素材は過去のものを使うかもしれないんです。だから、それが新しいものと組合わさったときに壊れないようにしなくてはいけない。

坂巻：新しいものに古いものを突っ込むとスタイルシートが2つ存在するから、ちょっと大変ですよね。新しいものと古いもので二重になるんだったら、その分の見積もりはしておいたほうがいい。

やらずにいられない！？ 「気遣い」

高津戸：でもまあ、作業前の確認というのを、一般的な話として落とし込むのは難しいよね。ものすごく数をやるコーディング専門のところだったらそういうのもあると思うけど、うちみたいなところはそもそもそのコンサルも含めてひとつの案件という気もするし。

大企業ならすでに何かあるだろうから、それに則らないとダメだし。そうじゃない場合でも、既存のサイトがあるなら踏襲してうまい形でそれに追加しないとダメだし。何を決めておかないとというよりは、何を決めるか、どうすればいいのかのステップはいると思う。

そうでなければ、無難に作っておくという場合もあるよね。IE 6/7で崩れるのが困っちゃうのが想定されるなら、あらかじめIE 6/7でも対応しておく。ちょっと非効率だけど、安全な書き方として。

坂巻：気遣いですかね（笑）。簡単なのだったらいいんだけど。『IE 6/7は対応しなくていいっすよ！』って言われているのに、勝手にIE 6/7対応して、全部対応しなくちゃいけなくなると、それはそれでめんどくさいかなあと。

高津戸：プロジェクトのノリによるんじゃない？　『まったく新しい技術でやっちゃいましょう！』みたいなタイプのサイトだったら、技術もデザインもチャレンジしちゃうだろうし。たとえばGoogle Chromeの特集コンテンツで最新技術を見せつけてやる、っていうならCSSやJavaScriptの新しい技術を使いまくることもアリ。その場合は、IE 6/７/8には、「Chrome入れてね♡」みたいな表示をすることになるよね。

全員：（笑）

坂巻：僕がやった案件でIE 8からの対応があったんだけど、よもつさん（小山田）にCSS書いてもらって見ると、スタイルシートの中にIE 6/7対応に対応するためのdisplay: inline-blockのPolyfillがちょこちょこあるんです。いちいち書くのめんどくさいから、よもつさん、これのスニペットとか予め作ってあるのかな？　と思った。僕も自然に書いちゃうことがたまにある（笑）。

display: inline-block;
*display: inline; /* IE6/7対応 */
*zoom: 1; /* IE6/7対応 */

小山田：保険、保険（笑）。

坂巻：対応しなくていいのに、自然と対応しているときは僕もありますね。display: inline-blockをIE 6/7で使うためのPolyfillを自然に書いている自分がいるのがすごい悔しい（笑）。対応しなくていいのに（笑）。

そういうのはSassとか使えばMixinでまとめて書き出したりしているので、自分でやることは少なくなるかもしれないけど。まあでも自然と対応していることはありますね。

気遣いとモヤモヤの狭間で

——そこらへんはあくまでも個人の気遣い？

小山田：気遣いというか、あとで言われたときに怖いから、その保険を掛けている側面はありますね。

高津戸：それなしでやっちゃうと戻れないレベルだから。そうですねえ…‥『醤油入れないでおいしい煮物作ってよ』って言われたから、わざわざ醤油を使わないレシピを選んで作ったのに、あとから『醤油入れてよ』って言われたみたいな。

全員：いやいや（笑）

高津戸：『醤油入れないで』って言うから、オレこの作り方のしたのにさ……みたいな。

小山田：まあでも、やっぱり空気ですね。初めてのお客さんならちょっとそういう保険掛けたりしているけど、何回もやりとりしてだいたい方向がわかっている人なら、その保険は徐々に減らしていくと。

高津戸：でもその保険っていうのはレガシーな書き方で書いているわけだから、実質工数がかかるわけです。タグとかも実際増えたりする。一回こっきりのお客さんだと、あんまりメリットを発揮できないですね。

たとえば恒久的に運用し続けるWebサービスみたいなのをメンテしていくところで、IE 6/7にずっと対応していくということだと毎回時間かかっちゃう。

たとえば角丸の話でも、border-radius使わない場合は、divを8個とか9個とか重ねるとできるんです。でも、そういうのやると時間かかるし複雑になるからメンテナンスのコストも上がる。対応しなければIE 6/7/8だと角丸でなくて四角になっちゃうけど、メンテコストが削減できる。そういうところが、古いブラウザを切り捨てる意味と言うか……。

だからこそ「受託」という体系だと、なかなかモヤモヤした部分がある。だって、どのブラウザのバージョンだって見られたほうがいいし、それ対応しませんって言ったところで、クライアントへ提示する見積もりが劇的に安くなるわけじゃないしね。だってそれで安くしたら意味わかんないじゃん。最新技術使って安くやりますって、どんどん貧乏になっていく（笑）。

コーディングしている人は、そういうなんかこうモヤモヤした世界で生きているところはありますよね（笑）。うちはまだいろいろやっているから客観的に見られるのかもしれないですけど、ほんとコーティングばっかりしている人は、そういう事情があるんで、新しめの技術を使いたいのだけれど、使うに使えない。そういうのをクライアントに確認するにも手間ばかりかかる上に、目に見えるメリットもないような状況の中で「このブラウザ、切る？　切らない？」というようなことをモヤモヤ考え、交渉したりしている部分があると思う。

設計の価値とは

高津戸：特にHTML／CSSで言えば、どこに価値を見出すかって難しくないですか？　ピクセルグリッドが書いたコードがほかの会社が書いたコードの100倍の価値があるかと言えば、ないし（笑）。

——相手が何を「価値」と思ってくれるかによっても違いますしね。

高津戸：そうそう。たとえばすごくページ数があって、それを破綻させずにメンテしやすく設計していくという部分は価値だと思いますけど、そういうのはクライアントが単純には量れないし。

でも、なんでもそうなのかもしれないですね。JavaScript書くような仕事だったとしたら、コード書いている人以外は、結局、最終的なアウトプットが動作しているか、いないのかでしかわからないじゃないですか。

コード品質の判断はプログラマーしかできないし、見えない。そうであるなら、プログラマーも、自分がやっていることをちゃんとクライアントに見える形で伝えたり、コードを書く以外の部分をちゃんとヒアリングしたりといったようなコミュニケーションをしたほうがお得だ思うんですよ。それも含めて仕事かなぁということもあると思うんですよね。

——黙っていたら価値が理解してもらえない可能性も？

高津戸：いやぜんぜんわからないと思いますよ。同業者ならチェックすればわかる部分は多いですけど、そうでない場合は、うまくやってくれたとか、そうじゃなかったとかいうレベルで捉える人も多いんじゃないんですかねえ。

坂巻：たとえば、開閉する見出しで文字をクリックすると、本文が下にべろべろっと現われるいうUIがあったときに、それをどう作るのかというのは、いろんな方法があるから人によって違うわけです。

同じ要件を満たすためにいろんなコードが存在していて、それぞれどういう価値があるかというのは難しいから、ちゃんと説明する必要がある。たとえば、僕のは拡張しやすくしているとか。HTMLに所定のclassを付けるだけで実装できる、JavaScript書かなくていいですよとか。お客さんが自由に編集する機能がありますよとか。

——そこらへんのニーズがお客さんからクリアな言葉で出てくることってないでしょう？

高津戸：ないですねえ〜。結局そういうところはないよなあ。ある場合もなくはないですけど、なんだかそこまで手をかけさせてしまうのも違うかな、そこはこっちの仕事の範疇かなと思うときもありますし。……今日、午前中猫の病院行ってきたんですよ。

——え（笑）？　動物病院？

高津戸：そう。その病院は凄腕で猫の避妊手術を日帰りでできるらしいんです。でも別の病院では施術後、1週間ぐらい入院させられるというところがあったらしいんです。

結局そういうことじゃないかなあ？　コードを書いて問題なくできたんだけど、ちょっと項目増やそうとしたら超金がかかるみたいなこと言われましたみたいな。動物病院で、入院費用かかっちゃうと言われちゃったみたいなもんですよね。でも、それは頼むほうも先に言葉にすることは難しいし。

——猫の入院費用ぐらいなら思い付くかもしれないけど、コードの場合はちょっと難しいかも。

高津戸：当たり前の話なんだけど、結局最終的にはここに頼んだから満足するものを作ってくれたという、結果としてしか捉えられないかなというところはある。

先回り、それが作るということ

高津戸：たとえば左にテキストがあって右が画像があるレイアウトの場合。イレギュラーで画像がない場合もあるんですっていう場合でも、きちんと表示できるのかどうか。画像がないのに、そこだけぽっかり空いているみたいなことだと困るわけです。

それを想定せずに、画像がない場合は、ぜんぜん別のコードじゃないと出せませんっていうのは、けっこうめんどくさい。システムで分岐してまるっきり違うの出したりとか。

……そういうイレギュラーなパターンがきた場合どうするかっていうこと、僕めっちゃ考えながらやっているんだけど（笑）。僕が頼みたいとしたらそういうの空気読んでほしいと思っちゃうから。画像のあるなしもそうだけど、見出しが1行だけ想定なのに、あとから急に『見出しが2行になりました！』とか、そういうの言われてもいいように……。

坂巻：そう。そういう場合はあらかじめ1行と2行で作っておくとか、1行もしくは複数行で作っておくと幸せになる（笑）！

高津戸：そうそう。ボタンとかのラベルテキストもさ（笑）。

坂巻：『いやー、この商品だけ2行なんですけど』……とか、よく言われる（笑）。

小山田：『これだけ名前が長くてねえ』とか（笑）。

坂巻：これは経験則でしかないんだけど、可変の可能性を気にして保険を掛けておこうみたいなことは常に考えますね。ここは2行で来ても大丈夫なようにとか。もしくは事前にクライアントに相談しようとか。できるときと、できないときがあるから。

——先回りして考えるということ？

小山田：そうそう、今の仕様では直接見えないところも考えなきゃいけないから。作るってたぶんそういうことだから。

高津戸：そういう意味では、先を見越した設計というか見積もりにする必要がある。

その設計、安い？　高い？

高津戸：まあ、あとから項目を追加するのに費用がかかるっていうのは妥当な要求だと思うけど、仮にそうしたとしてもプログラマー的にはめんどくさいから、最初から想定しておくというほうが楽。ほんとに、この分岐でこっち行ったら戻れないってときは確認したほうがいい。

坂巻：人や会社によっては、仕様書通りにしか作らない、作れないってあると思うんですよ。たとえば「うちは超高速で納品できるし、超安い」というのがセールスポイントになっている会社もあると思う。でも、それは速いなり、安いなりの理由ってありますよね。拡張できないとか。

逆に高いには高いなりの理由があって……高いっていうわけじゃなくて妥当な価格なんですけどね（笑）。たとえばデザインだって、実際のコンテンツを入れてみたら、絶対デザイン通りに行かないじゃないですか。デザイン上でのテキストは1行しか入っていないけど、実際のコンテンツは複数行になったりとか。そういう可変性に気を遣って作ると、価値が上がっていく。

高津戸：でもむしろ、その価値を認識していない人が多いのかなという気がする。サイトを作るって、基本的にカスタムオーダーじゃないですか。前の会社でもデザインパーツとかで汎用的なのも用意しておいて制作コストを低減する試みもしましたけど、結局うまくいかなかったし。

だって、コーディング頼むっていう時点で、汎用的なものでなんとかできる世界じゃなくなるんです。たとえばコーポレートサイトだとしたら、ありものを使うのではなくて、やっぱりちゃんとイチからデザインしているし。CSSとHTML、毎回同じのを使えるんで「イエーイ、この案件1日で終わっちゃったぜ☆」みたいのはほぼなくて（笑）。

そういうものができるとしたら、既存のデザインをそのまま使うという前提がないと無理なんじゃないでしょうか。たとえば、サイトおまかせパッケージみたいな商売で、安く作れるけど特にデザインにはこだわることができないとか、もしくは管理画面を手軽に作りたいからBootstrapでできる範囲でやるとか。

——CSSの設計の仕方って見えないところが多くて、そしてそこの価値が大切なのかもしれませんね。さて、それでは設計に使うツールなど、具体的なことを聞かせてもらいたいと思います。

（次回へ続く）

ここまでのまとめ

• 設計するにあたって対応ブラウザの確認は必要だが、単なるバージョンの確認だけでなく一歩踏み込む必要がある
• コーディングルールやガイドラインの確認はケースバイケース
• 相手の要求の空気を読むことも大切だが、コストとの兼ね合いを考える必要もある
• 設計の価値とは相手をどれだけ満足させられるか
• クライアントの仕様だけでは見えないところに配慮するというのが「作る」ということ
• 見えない配慮をしてあるコーディングは価値があると思うが、誰もがその価値をわかっているわけではない

（取材・文・構成：丸山 陽子）