おざなりにされがちなデザインコーディング（CSS）の今を叫ぶ
マークアップエンジニア&コーダーのアサイン緊急度が低くなっている、というのもあり
後回しの義務・最低限の作業になりがちなデザインコーディング（特にCSS）。
ソースを見て「ああ、ここに愛はなかった・・・」となることが特に多くちょっと寂しかったりします。（これ、言語問わずエンジニアあるあるだと思うのですが）
動作上は問題ない。であればOKとされがち。
工数や予算上仕方ないこともあるのですが、そもそものスタンスとしてそれで良いのでしょうか。
自分の今の考えをまとめます。
（デザインとデザインコーディングは切っても切れない関係なので、時々デザインの話も出ます）
なんでおざなりにされるのか
CSSフレームワークの台頭
便利なフレームワークが増えて、デザインコーディングをしなくても「それっぽい」ものができるように。
それもあってデザイナー及び専任担当（マークアップエンジニアorコーダー）がアサインされる率も大幅に減少。
フレームワーク自体は誰もが作りやすくなるツールとして素晴らしいと思うのですが、いくら最低限でも「CSSを1行も書かない」ということはほぼないかと。
そうすると各開発担当のエンジニアが対応しなくてはならない。そもそもフレームワーク自体の知識も必要。
また、修正したくてもフレームワークのCSSが邪魔して「時間ないし、まあいっか」となることも。
アジャイル開発の裏で
アジャイル開発では改善に改善を重ねてプロダクトを仕上げていく。多くは開発スピード重視のためその都度デザインを検討・依頼→マークアップ→開発というフローを踏むことが少ない。
感覚値ではフレームワーク利用で進めていくスタイルが多い気がします。（それ自体はなんの問題もない）
ルールが定まっていないとあとで大変に。
パーツリストが事前にある場合などは良いかもしれないけれど、完璧など存在するのか。
アジャイルは特にコミュニケーションが必要だと思う。
重ね技が有効
CSSはスタイルにスタイルを上書きして適用することができるので、対応箇所がよく分からない→修正よりも重ね技を使って対応するパターン。
「まあ!importantつければ良いでしょ」という人もまだ割といる。
それ自体は便利ではあるものの、乱用すると激重＆混乱の原因に。
度重なる改修で既にカオスと化したものたちもよくいます。
そうなると、改善するのにとても時間がかかる。
ちょっとミスっていても「一応大丈夫」になっちゃう
CSSは比較的懐が広い言語なので、なんとなくOKになっちゃったりするパターン。
でも内部的には良くないです。ブラウザ変えるとダメになったりもするかも。
古の民の「CSS書けます」によるもの
「あ、CSS書けるの？書いてよ！」となるパターン。
一番危険で信用してはならないアレ。古の時代と今は違います。
当時の書き方では通らないことや足りないこともとても増えました。考慮すべきことも。
知識としてゼロベースより圧倒的に話は早くて大変助かりますが、アップデートは必要です。
そもそもデザインが再現されると思われていない？
グラフィックのデザインはWEBだと表現できない、と思われている気が。
デザイナーの方が上げてきたデザインと、（仕様上の問題ではなく）全く違うものになってもOKとされがち。
必ずしもそうではないよ、と言いたい。
ピクセルずれや意図のないものを省くことはあっても、意図があるなら再現できた方が良い。
「"伝える"プロ」が作ったものなのだから。
（もちろん工数の関係やデザイン自体がアレ？みたいなこともあるけれど、それとこれとは別）
ワイヤーフレーム扱いにするのはそれこそコストの無駄では？
デザイン作りを大事にするメリット
SEO
（HTMLと）CSSを最新に&軽くすればその分SEOに有利に。
不要なCSSをカットすることでサイトスピード・操作性がアップ→ユーザーもハッピー→SEO的にもハッピーです。
一応数十MB以下なら影響ないとのことですが、それ以上の場合には検討を（内容による）。
（推奨は1.6MB）
メンテナンス性の向上・コスト削減
構造がルール化されていれば、改修も容易でその分工数、コストもダウンします。
改修を重ねても重くならないようにもできる。
長期的に見て何がお得か。
初期段階できちんとできる体力があるところの方が圧倒的に少ないとは思います。
が、それでもやれることはあります。
コンバージョンアップ
デザインが全てではありません。機能による部分、コンテンツによる部分もとても大きい。
ですが、デザインによって上がるコンバージョンもあります。
ユーザー導線・印象・動き・構造など包括したデザイン設計能力の必要性もありますが、
ページ表面上の静的な改善だけでも変わったりします。
例えば実際に行った「お問い合わせ」をコンバージョンとした複数の案件では、（ソースを触ったのはHTMLとCSS部分のみで）1〜3ヶ月後計測した結果、CV3〜6倍に変化しました。
（これを話すと悲しいことに「エェ〜？」と言われること、多いんですが・・・ほんとだよ！）
開発・コンテンツ制作・デザイン等々、関わる人の全ての力でサイトはより良くなります。
言い換えると、デザインの重要性は開発とコンテンツ制作他に並びます。
考えられたデザインはもちろん、それをコードで再現する力、それをより軽量でメンテ性が良いように作る力は、ないがしろにされやすくある今でもとても重要なものだと考えます。
デザインにもデザインコーディングにも光を当ててほしいのです。
だからビジュアル（HTML・CSS・デザイン周りのJS等）作りの時間も大事にしてほしい。
そして、現段階であまり目立ちはしないものの、やっているところはしっかりそれをやって結果を出しています。
どうしたらいいのか
少し目を向けるだけでも良いのです。とりあえず、今からできることから。
デザインコーディングにも決まりを定める
複数人で対応する場合、例えば
- パーツリストを作っておく
- 足りないパーツは都度リストに追加して利用する
- またはフレームワークの利用ルールを全体で確認する
- コーディングルールを共有する
- チェック担当をつける
- ルールや議事録はREADME、ドキュメントに残す
など。基本的なことをちょっとやるだけで全然変わります。
慣れないコーディングルールは無理に使わない
コーディングルールを最初に決めても守れないのでは余計な混乱を招きます。
結果、時間に追われ悲しみを背負った開発陣それぞれが部分的に守ったよく分からない何かができることも。
その場合にはシンプルなルールだけ定めて運用した方が吉になるかも。
可能なら分かる人をアサインする
可能ならもちろんその方が良い。
結局コミュニケーション
スキル感の違い・認識の違いはどの役割だとしても当然あるもの。
なので結局総じて大事なのはコミュニケーションだと思います。
スタイルを当てる際の話はできているか、もありますが、
ビジョンや世界観、目的などの共有ができているか。
改修案が出た時に、きちんとコミュニケーションを取れるか。
企画側で出たものに開発に理解あるメンバーが1人もいない状態でふわふわしたままGOが出ていないか。
またはそれを固められる人材がいるか。
GOが出たとしてもその後コミュニケーションが取れてリカバリーできる状態か。
開発陣で認識の齟齬がないか。
何につけても人対人で、こまめにやりとりをするのが寛容だと考えます。
ちゃんと話せばだいたい大丈夫。のはず。
デザインコーディング、楽しいのでやってほしい
年々コーダー、特にCSSラブな人口は減ってきている気がします。寂しい。
書き方が割と分かりやすくHTMLとあわせて片手間にされがちですが、CSSはビジュアルを作る、最近は動きも表現できたりする素敵な言語ですし、HTMLの構造もSEOに大いに関わってきます。意外と奥が深いんだぞ〜！
自分が書いたものがパッとweb上に表示されるので、制作に触れる初手としてデザインコーディングをやってみるのも楽しいと思います。
最高なビジュアルが自分の思う通りに、さらに軽量・綺麗なコードで再現できるようになったら凄くかっこよくないですか？（さらにJavaScriptも書けるようになったらもっともっと可能性が広がっちゃう！）
そう、デザインコーディング、スーパー楽しいんです。もっと興味を持ってほしい。
そしてそれがプロダクトにとって大切な1ピースであることを忘れないでほしい。
私も日々精進で頑張ります。