出会い
主にシステム開発を行っているので、ほかの執筆者とは少し違うかたちでCSSに関わってきました。2005年ごろ、当時勤めていた会社で利用していたCMSツールが限界にきており、新たなツールを開発する業務にあたっていました。利用する社内のWebデザイナーに、どのようなCMSツールを求めているかアンケートをしたところ、「デザインの制限がない」「簡単に利用できる」という意見が圧倒的に多かったです。
すごく困りました。当時、社内ではHTMLのテーブルでレイアウトしていたため、「デザインの制限がない」ことを実現するには、テンプレートエンジンを開発しなくてはなりません。テンプレートエンジンを利用すると、そのつかい方を覚えなくてはならず、「簡単に利用できる」という要望に応えることができません。
そこで、当時流行の兆しを見せていたブログツールをヒントに、CMSが書き出すHTMLは固定してしまい、CSSでデザインできるツールの開発にこぎ着けたのでした。
苦難
要望に応えられたはずでしたが、スタッフのCSSスキルが低く、「このCMSではこういうデザインができない」といった苦情がたくさん寄せられました。わたしは自分がつくったCMSの正当性を証明するために、CSSについて深く勉強しました。そして、できないといわれたデザインを、半ば力技で実現しました。そうしているうちにCSSについてかなり詳しくなり、スタッフ全体のCSSスキルもそれなりに向上してきたのですが、そこでまた大きな問題が発生しました。
テーブルレイアウトに比べて、制作スピードが格段に落ちてしまったのです。いままでほぼなかった「コーディング」という作業プロセスが発生したためです。それまでは、Dreamweaverのデザインビューでの「切り貼り」作業が中心でした。また、制作部門と更新部門という分業制がうまく機能しなくなりました。つくった人しか修正できないサイト、解読に非常に時間がかかるサイトなどができ上がってしまったからです。
克服
これはどうにかしなくてはいけません。当時勤めていた会社は大阪にありましたが、東京からCSSデザインの第一線で活躍している方をお呼びして、すべてのスタッフにCSSの基本や効率的なCSSの書き方、そして制作ガイドラインやワークフローの見なおしを指導してもらうことになりました。その時、いろいろと指導してもらったのが、本書の共著者でもある益子貴寛さんです。
CSSでデザインするというのは、本質的なようで、そうではないことを知りました。CSSで大切なのは誰でも簡単に修正できる保守性であり、誰でも簡単に理解できる可読性です。そのように意識することで、制作だけでなく修正や更新といった業務プロセスも改善できます。CSSはガイドラインやワークフローを整えることで、非常に高い生産性を発揮できる言語であることを学びました。
いまでも、XHTML+CSSによるWebサイト制作に切り替える最大のメリットは、業務プロセスの改善だと考えています。
コメントする