Hail2u.net

自動生成されるスタイル・ガイドはウェブ向きなのか

ウェブ制作においていわゆるスタイル・ガイドと呼ばれるものの作成をワークフローに取り入れる動きが広まりつつある。その主なものはCSSのコードから自動生成されるものだ。つまり制作の完了後に自動的に生成される。

自動生成されたスタイル・ガイドはメンテナンス等において参照するドキュメントとしては完全に機能する。その時点で使える機能や見た目がすべてサンプル付きで生成されるので、追加したいコンテンツをどのようにマークアップし、ビジュアル・デザインを反映させるべきかは一目瞭然になる。スタイル・ガイドの主要な目的はそこにあるので、これで十分ではあると言えないことはない。

本や雑誌のような場合、ビジュアル・デザインの変更や追加を行うには多大なコストがかかる。文庫本や新聞の書体が変更されるまで数年かかったなどという話はよく聞く話だ。このような世界ではスタイル・ガイドを必ず守る不可侵の基準として設定することにより、安定したクオリティーを提供することができるのだろう。一旦出したものが引っ込められないことを考えると当然と言える。

対して、ウェブにおいてはビジュアル・デザインの変更コストは低く、その変更を撤回することも容易い。規模によってはほぼゼロと言っても良い。フォントの変更など一瞬で済むし、一瞬で戻せる。こうなるとスタイル・ガイドの立ち位置というものも変わってくるのではないだろうか。

ウェブ制作においてコーディングは、簡単に編集が行え、かつ素早く結果が反映される作業だ。テスト手法が確立されていないことも相まって、どうしてもコーディングを中心に作業をしがちになる。しかしカンプ(Photoshop等で制作された仕上がり見本)をちゃんと更新して、必要ならスタイル・ガイドも更新し、それからコーディングに取りかかるという方が望ましいと思う。こういうワークフローを辿ると、カンプがテストにおける期待される結果で、スタイル・ガイドがテストそのものになる。

自動生成されるスタイル・ガイドではこういうワークフローには成りえない。

スタイル・ガイドを不可侵であり単なる実装の手引きとするのではなく、コードがきちんと反映され、機能するかのテストを行うものと捉えることもできるのではないか。


スタイル・ガイドの自動生成を否定するわけではないけれど、スタイル・ガイドはウェブ制作において貴重なテスト手段のひとつに成りうると思う。何かしら実装する時は常にカンプ→スタイル・ガイド→コーディングという作業順で行うようにすると、BDDのような形でのウェブ制作が行えるんじゃないかと考えている。