既にあるウェブサイトの実装を、今後を意識してモダンにしようとすると、どうしても既存のクラシックな何かしらの置き換えが必要になる。多くの人が作り始めているであろうスタイル・ガイドはそういった時に役に立つ。現状での保証された結果を提示してくれるからだ。
クラシックな何かしらの置き換えが必要になった場合、その目的をきちんと知る必要がある。そうでないと正しくモダンに置き換えることができない。すべてをフルスクラッチで書き直すといった場合でも、少なくともクラシックな何かしらによる結果を知る必要があるだろう。
スタイル・ガイドは良くも悪くも結果に過ぎないが、ちゃんとした結果であることは保証されている。それをきちんと作っておけばとあるコンポーネント(とでもいうようなもの)がどのような意図を持ったものかを具体的な実装を知ることなく理解できるはずだ。
ちゃんと作られたスタイル・ガイド、というとかなり大げさだが、適切なタイトルとプレビュー、そして具体的な利用例くらいあれば十分だろう。作るに際して注意点は少ないが、あまり意識されていないようにも思う。
ひとつは想定環境を設定しないことだ。想定環境を決めてしまうと、スタイル・ガイドはうまく機能しない。僕はそう考えている、というくらいにしておこう。もはや一般的であるとかメジャーであるとかいう環境は設定することはできないこともあるが、もっと本質的な問題を抱えている。
ウェブサイトの実装は常に何らかの闇との戦いであるため、想定環境を作ることは安全地帯を作ることに等しい。安全地帯があれば人は安易にそこへ逃げ込む。そしてそこから出てくることはまずないだろう。しかし、その安全地帯は絶対的なものではなく、想定環境が崩れれば容易に崩壊するはずだ。
スタイル・ガイドでこのような安全地帯を作りそこへ逃げ込んでしまうと、問題を発見した環境への対応はかなりおおがかりなものになりやすい。その複雑怪奇な実装を知ること自体は必要ないが、一見しただけでは把握できないような大きな環境差をはらむことになる。これではとりあえずなんとかなっている程度にしかスタイル・ガイドの結果は保証されないだろう。
もうひとつはスタイル・ガイドの構成だ。具体的にはコンポーネントの粒度ということになる。あいまいな言い方だと大きすぎず、かといって小さすぎずというところだ。
大きすぎることはコンポーネントの意図を見えづらくする。そのコンポーネントがどのようなものかはわかりやすくなるが、何を目的としているかはわからなくなるという意味だ。何度もじっくり見ることで「あぁそうだったのか」と突然開眼することはあるだろうが、そういうヒラメキに期待して書くべきではないだろう。
小さすぎることはコンポーネントのユースケースを想像しづらくする。機能や見た目ごとに作っていくとそれぞれは把握しやすくなるが、あくまでもコード・レベルでの話だ(つまりコード・レベルでは細かい方が良いということでもある)。実際にそれらを組み合わせるとどのような効果を生むのかを推量する必要があるので、さらにそれを利用する意味を想像するまで行きつくのは難しい。
またなんらかのウィジェットという単位で簡単に決めるわけにもいかない。複雑なインタラクションを含むグローバル・ヘッダーならうまく分割してやる必要もでてくるはずだ。分割したもの同士で相互に依存する場合には、それらをまとめたコンポーネントという形でもうひとつ用意してやる方が良い。
この2つの点に気をつけたスタイル・ガイドだとクラシックからモダンへの架け橋となりうる。それそのものがデザインの意図を定義したものに過ぎないため、テスト・ケースとして機能する。しかも実現可能なテスト・ケースとして確かに存在しているからだ。
スタイル・ガイド・ドリブン・デベロップメントという形は多少行き過ぎのきらいがあるので、あまり真に受けない方が良い。しかし、このようなデザインの意図を簡潔に現実のプレビューとして表現しておくという形でスタイル・ガイドを作っておいてやると、モダンとクラシックをとりもつものとして、そしてそれだけでなく去る者や来る者と我々との間をもとりもってくれることだろう。