HTML/CSSのコーディング品質についておもうこと

コーディング
コミュニケーション

2016-06-08T11:00:31

デザインフローシリーズをいっかい休みにして、最近おもったことをかいていきます。

タイトルからして、なんか意識高い系の話になりそうでいやなのですが。。
とはいえ、じぶんが普段思っていることと照らしあわせてなにか考察できればいいなと思います。

keyvisual

HTML/CSSのデザインコーディングについて

通常わたしたちは、デザイン業務をメインでしていますが、HTML/CSSへのコーディングもやっています。
コーディングって意外とデザインの視点が入りづらいところと思われがちなのですが、実際にはそうでもないな、と最近改めて思いました。

そこで、わたしたちが考えているコーディングへの思いを挙げていってみたいと思います。

デザインを受け取って、それをコーディングするだけではうまくいかない

ほんとに、いわゆるコーディングの「作業」という業務ですね。
psdとjpgなどを受け取って、画像を書き出して、HTML/CSSで組んでいく作業。
この作業だと、いかにデザインに忠実に再現できるかがポイントになってきます。

おそらく、受け取ったデザイン案をひととおり見て、共通化できるところはしたり、モジュールを設計したりしていくと思います。

もしこれが、今後も修正や拡張をまったくしないようなLPとかWebサイトであれば、それでもいいと思うのですが、今後も運用が続いていくものであれば、これだけだとむずかしいんじゃないかなーというのが正直なところ。
特にWebアプリに関しては、修正・拡張・改修は必ずあるのが前提でしょう。

デザイン案ができるまでにも、クライアントといろいろ話して、紆余曲折があってできるものです。
たいがいは、話しているうちに夢がふくらんできますので、予算と期間をみて、できることに第一フェーズはしぼる。そうなると、サービスがうまくつづけば必ず第二フェーズ、第三フェーズも発生します。

で、実はこの「第二フェーズもありますので」というのがあるのとないのとでコーディングに期待されることがだいぶ変わってくると思うのです。

コーディングのときに渡される資料からは実はこのあたりの背景については触れられていないことが多いので、このあたりの背景のないようないわゆる「作業」だけではうまくいかないのではないか、という結論ですね。

なんのためのサイトなのか？の理解

これも、上のものと同じような趣旨にはなります。

なんのためのサイトかという背景を知っておくと、「今はないけど今後追加されそうなページ、もしくはモジュール」が想定しやすいのではないでしょうか。

cssの設計の話になってきますが、「これは共通のもの」「これはページ固有のもの」などの判断材料になるかと思います。

モチベーションの維持

あともうひとつは、モチベーションの問題ですね。
「作業」になった場合、コーディングを「きれいに」するのって自己満足になってしまいがち。
きれいなコードを書くためにはそれももちろん必要なのですが、このプロジェクトに関わるいろんな人の顔を思い浮かべながらコードを書く、というのがわたしは重要だと思っています。

プロジェクトにはたくさんの登場人物が出てくると思います。
PM、ディレクター、デザイナー、などなど制作チームの人や、クライアントチームの人。
あと、ほんとうはわたしたちには見えない「ユーザー」もいます。

全員に喜んでもらうことができるかどうか、いつも考えてデザインしています。
やはりその気持ちは制作チームでも共有しておきたい。
よりクライアントの顔が見えづらいコーディングという仕事でも、そこは同じ気持ちで臨みたいですね。

CSSの設計と命名規則も品質のひとつ、そしてそれが可読性にもつながる

CSSの設計や命名規則はいろいろとあり、わたしもすべてをおさえられているわけではありませんが、今Webアプリ界隈で主要なのはやはりOOCSSやBEMでしょうか。

この考え方自体は3年ほど前からありますのでそんなに目新しいわけではないですが、汎用性、メンテナンス性、可読性を考えるといまのとこいちばんいいなと思います。

ムダなクラスをつけたくない（できれば要素のタグをそのまま利用してスタイルをつける）、という時期はわたしもありましたが、システムを組み込むWebアプリでこれをやると、早々に破綻してしまいました。

自分が1ヶ月後に見て解読できるコードかどうか

1ヶ月後といわず、忙しい人は3日後とかでもいいのですが、あとで自分が見たくないようなコードは書かないようにしましょう（笑）。

これってでもそのためにはルールを決めることが重要で、それが先ほどのOOCSSだったりBEMだったり。

コーディングルールは、受注・発注側で最初にすり合わせるのが大事です。

デザインの意図をみんなで理解する

コーディングするときにわたしが求めていることとは、実は、寸分違わずデザインを再現してほしい、というわけではありません。
よく、「ここ1pxズレてるんだけど」というデザイナーからのフィードバックという笑い話がありますが、そこは気にしていません。
わたしのデザインはそんなに1px単位で100点満点ではないからです。

むしろ、ここ違うよ、とか、ここの余白はこういうほうがよくない？とか、そういう提案をガンガンしてほしいと思っていたりします。

「僕はデザインなんてわからないから、デザイナーさんがつくったデザインに口出しするなんて100年早いわ。。」
と思っている方、まだまだ甘い。

たしかにいろんなことを考えてデザイン案をつくっていますが、すべてにおいて理由があります。
使うときにはこのほうが見やすいから。使うときにはこの配置のほうが操作しやすいから。
適当に余白をあけているわけではないし、適当な文字の大きさにしているわけでもない。
もっというと、お客様がこの色が好きだから、といって色を選んでいるわけでもない。

でも、コーディングする人でこういった情報を汲みとってコーディングしてくれているのって、ごくごくわずかだとおもう。

口出しとかの前に、まずは疑問を持つこと

口出しというとかなりハードルがあがると思いますが、でもその前に「疑問を持つ」ことはできるかな、と。
これはなんでこの色なのか、ここはなんでこんなに余白があいているのか、それに対してここはなんで余白があいていないのか。

と、その後デザイナーさんと打ち合わせをしたときにでも、さりげなく聞いてみるのです。
「ちなみにここってなんでこの文字の大きさにしているんですか？」
と。

ちゃんと考えて丁寧につくっているデザイナーさんであれば、ちゃんと答えてくれるはずです。

そこで、真剣に答えてくれなかったり、むっとされたりしたら、今後のお付き合いを考え直してもいいのではないでしょうか。（個人の主観です）

デザイナーも、デザインファイルだけ渡すのではなくてちゃんと意図を伝えよう

とはいえ、デザイナーのほうもこういった情報、デザインの意図をきちんと伝えなければならないなと思っています。
いつも時間がなく、とりあえずデザインファイルを渡してごにょごにょっと見ればわかるような説明だけしてしまうのですが、よくないなーと。

コーディングをする人によっては、そんなの特に関係ないし、きれいに組むから説明いらんよ、という人もいるかもしれません。
まあ、それもそれで否定はしませんが。。

わたしも、今までは個人プレイ重視でやってきてそれでぜんぜん満足していたのですが、ふとした瞬間に、チームプレイもいいもんだな。。と考えるようになりました。
（そのきっかけは本題とはズレるのでまたの機会にしますが）

で、そう考えると、デザインの意図をコーダーさんと共有するほうが、確実にコーディングの質があがるなと思いました。

ここではデザイナーとコーダーの話をしていますが、もっと向こうのプログラマ、エンジニアさんと協業するときも同じで。

—
あるエンジニアさんと設計について話をしていたときのエピソードがおもしろかった。
いわゆるプログラマというのは、SEさんみたいな人から指示を出されてプログラムしていくんだけど、なんのためにこういう情報を出すのかがよくわからない場合が多いらしい。
仕様書にこう書いてあるからこのページにこの情報を出さないといけない。そのためにこれだけのAPIを準備しないといけない。

で、おもしろかったのが、SEさんが設計する仕様と、わたしたちデザイナーが入って設計する仕様っていうのは、わりとちがうんですよね。
前者の場合はほんとにシステマチックになることが多いので、開発者にとってやさしい（そしてよくある）仕様になる。
けど、後者の場合はよりユーザーが使いやすいものになることが多く、システム的にはイレギュラーなことをしないといけないことも多くなるので、開発者にとってはわりとつらい仕様になる。

前者から後者に仕様が変わるとき（つまりAPIの仕様も変更になるときだが）、これがプログラマにとって最大のモチベーションが下がるとき、ということでした（笑）。

たしかにユーザー目線で設計すると、システム的には煩雑になることが多いと思います。
それを、その意図を伝えずに「こうこうこうなりました」という事実だけを伝えてしまうと、APIの設計を大幅に変えざるを得ない。。ということになり、モチベーションだださがり。。
—

ここでも、プログラマを単なる作業者と考えずに、プロジェクトをつくっていくいちメンバーとして、設計の意図、デザインの意図を伝えられたら、もう少しモチベーションは保てるのではないでしょうか。