アプリケーションの世界ではセマンティック・バージョニングが広く受け入れられた……かどうかはわからないが、採用例はすごく増えている印象だ。ウェブデザインではどうかというと、ウェブ・アプリケーションのバージョニングに追随しているだけであったり、そもそもバージョニングされていなかったりするような気がする。ウェブデザイン、主にCSS(とCSSプリプロセッサー)においてセマンティック・バージョニングを導入するとすると、どのようなタイミングでメジャー、マイナーそしてパッチ番号を増やせば良いのだろうか。
セマンティック・バージョニングの中心となる概念は後方互換性だ。後方互換性が:
数語でまとめるとこのようになるだろう。ウェブデザインにもこれを当てはめるとすると、ウェブデザインにおける後方互換性とは何なのかということをまず考える必要がある。
単純に考えるとマークアップを基準にするとうまくいきそうだ。しかしそれはウェブデザインの後方互換性ではなく、単にマークアップ及び場合によるとコンテンツの後方互換性に過ぎないと思う。マークアップの変更によりCSSの大幅な変更を余儀なくされることはあるが、違うマークアップでも同じような見た目と振る舞いにすることはそれほど難しいことではない。とすると、ウェブデザインにおける後方互換性はコードそのものではなく、その見た目と振る舞いの変化に集約される言えそうだ。
ウェブデザインは、ウェブサイトの、そしてコンテンツの見せ方を定義する作業だ。そしてそれはユーザーの見方に影響を与えるものなので、その後方互換性とはつまりそのユーザーの見方であるだろう。
ということはウェブデザインにおいて後方互換性が失われる変更とは、ユーザーの見方に変化を強いる変更ということになる。
ユーザーの見方の変化を強いる変更としては以下の様なものが挙げられる。
これらを変更した場合に後方互換性が失われるとして、メジャー番号を増やすべきではないだろうか。漠然としたイメージとして「大きなデザインの変更」となるような作業を行う場合は、上記のいずれかは変更になるだろうし、それほど難しく考えることもないかもしれない。
ロゴの変更も含めても良いかもしれないが、これはこれで別にバージョニングするべきだと思う。
特定のブラウザーで起こる問題の修正などは新機能の追加ではないので、パッチ番号の増加で良いというのはすぐにわかる。ではマイナー番号を増加するような新機能の追加とはどういうものだろうか。
新しいウィジェットの追加などは機能の追加としてわかりやすいが、それだけではない。フォントの変更や色の微妙な更新、カラム幅の変更など、ユーザーに影響を与えるものの既存のデザインのアップデートに留まる(後方互換性が維持される)ような変更も含まれると思う。それらは新たな見せ方という機能面での追加だからだ。
これらを行った場合はマイナー番号を増加するべきだろう。
先述の特定のブラウザーでの問題への対応を始め、記述ミスの書き直しなど、修正という言葉で表現できるものが主だが、その修正とは主にそのデザインの意図が正しく反映されていないことへの修正である。
例えば、新しく作り直したナビゲーションが小さい画面でうまく収まりきらず、このままではまずいので、横並びだったのを縦並びにする変更を加えたとしよう。レイアウトを大きくいじることになり、見た目に大きな変更が加わる。このような場合でも、そもそもうまく機能していないものを修正したということなので、パッチ番号の増加で良いだろう。
修正にはマークアップの変更が必要になるケースの場合でも、マークアップの変更を受けてのスタイルの更新ではないので、パッチ番号の増加にする方が良い。スタイルが機能していなかったのをマークアップの変更を加えて修正しようという作業だからだ。
メジャーとマイナーの境界はともかく、マイナーとパッチの境界をもうちょっと明確に定義できれば実践しやすくなると思う。セマンティック・バージョニングとStyle Guideから始めるウェブデザインを組み合わせることを前提とすると、スタイル・ガイドを変更してから書くような作業はマイナー番号の増加になるのではないかと明確に定義できそうだが、開発手法として認知すらされていないので微妙なところだ。
いずれにしてもバージョニングをきちんと行おうとすることによって、masterブランチでやって良い程度の作業なのか、それともトピック・ブランチを切って実装する必要があるのかを意識できるようになると思う。ウェブデザインでは簡単に実装と確認が行えるため、そういった所は軽視されがちだ。セマンティック・バージョニングをウェブデザインにも導入することにより、わかりやすい開発ログだけではなく、開発フローの改善にもつながるのではないだろうか。