先日「まめことネコゼのどたばた会議」の収録模様がUSTREAMで配信されていました。収録も終わってまめこさんとネコゼさんがまったりとお話している中で、ネコゼさんが作っているモジュール一覧（とかコンポーネントコレクションとか言われているやつ）のお話になったときに、それっぽいのを公開しましょうか？とつぶやいてしまったのでこのエントリーを書いてます。

で、結論から書きますと、とても申し訳ないのですが、実際にクライアントさんに納品したものしかないため、なかなか公開は厳しい感じです。ただ、それではあまりにも申しわけなさ過ぎるので、弊社内でざーーーっくりと決めているコーディングのルールと、今まで他社さんが作ったものなんかも見てきた経験で、モジュール一覧ってこんな感じのことが書かれていますよねということを公開しますね。

株式会社まぼろしのちょっとした決まり

弊社ファイルサーバ内に入っている、コーディングのちょっとした決まりです。あまりにもざっくりというか、ほんのちょっとのことしか決めていません。おそらく、これを見てもほとんど何も参考にならないでしょう。

株式会社まぼろし：コーディングのちょっとした決まり（155キロバイト）

モジュール一覧に書かれている内容

モジュール一覧的なものを作るにあったってまず問題となるのは、それぞれのモジュールをどんなふうにグループ化するのか？って所だと思います。概ね以下のような感じに分ければどのモジュールもどこかに属することになるでしょう。

• レイアウトモジュール

  メインカラム内でさらに段組をするモジュールなんかがここに入ります。

• 見出しモジュール

  見出しが入ります。一口に見出しと言っても、例えば同じh2なんだけど、あるページではテキストで、あるページでは画像化文字で、あるページではキービジュアルとテキストの組み合わせで、など複数ある場合もありますね。

• 段落モジュール

  段落が入ります。単なる段落じゃないものですと、リード文の登場回数が多いですね。

• リストモジュール

  ul、ol、dlといったリストが入ります。よくある感じですと、注釈リストなんかありますね。他にもギャラリー系ページで登場するサムネイル写真一覧なんかもここに入れてます。

• 表モジュール

  表が入ります。HTMLで言えばtableでマークアップするモジュールたちですね。細かな部分ですと、tdに数値がはいるので右寄せにしたい場合には「num」ってclass付けてねとか、各列の幅を均等にする場合には「fixed」ってclass付けてねとか。

• ブロックモジュール

  メッセージエリアや、注意文言のエリア、「Adobe Readerをダウンロードしてね」などのプラグインエリア、お問い合わせ先が掲載されてるエリアなんかが入ってきます。難しいのが関連リンクをずらーっと並べるためのエリアですが、弊社の場合はだいたい「リンクモジュール」へ含めてしまいます。

• インラインモジュール

  emや、strongが入ります。もしかしたらcodeとか、supとかが入ってくるかもしれません。

• リンクモジュール

  ページ内リンクや、外部リンク、各種ファイルへのリンクなどが入ってきます。また、関連リンクや、ページの目次などのような、ナビゲーションが集まったエリアなんかも入ってきます。

• 画像モジュール

  装飾目的で文章の右や左に配置されている画像や、キャプション付き画像なんかが入ってきます。

だいたいこんな感じでしょう。例えばギャラリー系ページで登場するサムネイル写真一覧なんかは画像ではないのか？などのツッコミ所も満載なのですが、その辺は各社で暗黙のもとにルールが決まっていたりするでしょう。

さらに、それぞれのモジュールについてどのようなことが書かれているんだということですが、「実際のスクリーンショット」「サンプルソース」「適宜変更を必要とする箇所」「注意点」くらいですね。

その他にはどんなことが？

他に書かれていることとすれば、モジュール一覧を更新するときの注意点、更新情報、最終更新日、最終更新者、必要なファイルの場所など、いわゆる資料としてお決まりのものですね。

別に必要なければ作る必要ないと思います

と、いろいろ書いてきましたが、「コーディングは最初から最後、また運用になっても自分一人しかしない。」「複数で行う場合でもコミュニケーションが完璧にとれていて迷うことがない。」「クライアントにとっても資料の作成がなんのメリットにもならない。」などであれば、そもそも用意する必要はありません。

作るのであればディレクションから

資料を用意しようかとなったときなんですが、企画・設計やビジュアルデザインがすべて終わってあとはHTMLを実装するのみ、って所からいきなり作りましょうとなりますと、納期的にも、労力的にも結構キツイ思いをすることが多いですし、なんかただ作らされているだけであまり意味がないものになってしまうこともあります。

例えば、ビジュアルデザインもモジュールのカタマリごとに行うようにしておけば、デザイナーさんもマークアッパーさんもだいぶ楽になったりします。ですのでこういったこと（サイトをモジュールの集合体として考える事で制作効率あげることができるよねってこととか）は、実は現場のマークアッパーさんというよりは、ディレクション方面に携わる人にこそ、心に留めて置いて欲しいですね。

2009年04月18日(土)に行われる、WCAN x CSS Nite 2009 SPRINGに出演します。

内容は、2009年2月19日に開催したCSS Nite in Ginza, Vol.31の『CSSレイアウト：IE 6対応のかんどころ』の再演です。2月19日は、若干言葉足らずで伝えきれなかった部分もありましたので、その辺を補おうと思っています。

僕以外にも、「ブランディング」「コーディングワークフロー」「CSS3／jQuery」と、幅広広い内容となっています。ご興味ある方は是非ご参加ください！

フリーランスで仕事をしていようと、会社に属していようと、日々たくさんの業務を遂行していく上で数多くのファイルが新たに生み出されます。

大雑把に管理していても、その案件がホットな時期は、○○の書類はどこだった？と聞かれた際に、即座に回答することが出来ますが、半年・1年と時が経っていくと、困難になってきます。

昨日のカンブリア宮殿において、日本電産の永守重信（ながもり・しげのぶ）氏は、工場内の自分のテリトリーをキレイに整理している社員をめっちゃ褒めて、「ああいうヤツは絶対に仕事も良い仕事をするもんだ」とおっしゃっておりました。

また、佐藤可士和の超整理術の中でも、全てのファイル名には3桁の連番をつけようといったように、ファイル管理の大切さが述べられております。

という訳で、どこに何があるのか分からないという常態にならないように、おそらく皆さんもあるルールに従ってファイルを管理していると思うのですが、まずは僕的にはこうやったらある程度うまくいくんじゃないかなーというものを公開してみますので、ドシドシ突込み等お待ちしております。

基本的なファイル管理規則です。ここではフォルダ構成のみとなっております。また、自社内よりは、クライアントのファイル管理の方が大変かと思いますので、自社の方は割愛します。

• 自社名
  • 割愛
• 取引先
  • 各種取引先名

    • document

      各取引先共通資料：請求書・見積もり・基本契約書・VIなど

      請求書・見積もりは案件それぞれで管理した方が良いケースもありますが、一括して見たい場合などもありますので、取引先毎で一括管理しています

      • bill

        請求書

        • 年別にフォルダ分け
        • IDは見積もりに依存

      • quotation

        見積もり

        • 年別にフォルダ分け
        • ID：[案件名略記/日付/アルファベット連番]
      • など書類の種類によって

    • material

      各取引先共通素材：代表写真・支給ロゴなど、取引先の複数案件で使用する素材

    • 各種案件名

      [0805-0812Web-renewal][0701-0709CompanyEc-open]など[期間/エンドクライアント名（あれば）/案件種別]な感じで

      終了していない段階であれば、開始月のみを記載しておきましょう

      • document

        各案件資料：サイトマップ・コンテンツマップ・ガイドラインなど、各案件限定での資料

        • sitemap
        • schedule
        • contents-map
        • など書類の種類によって

      • material

        各取引先共通素材：デザインモック・モジュールPSDファイル・案件限定での写真素材など

        • mock
          • 基本的にはサイトマップにおけるディレクトリ構造、もしくはページIDで管理
        • module
          • 各モジュール名（クラス名）で管理
        • text
          • 基本的にはサイトマップにおけるディレクトリ構造、もしくはページIDで管理
        • illust
        • photo
          • 基本的にはサイトマップにおけるディレクトリ構造、もしくはページIDで管理
        • など素材の種類によって

      • www

        Webファイル

最近、CSSのマルチシートネタでは、リセットCSSを使わないというケースや、必要最小限だけ使うのが良いよね、といったようにリセット回りのことが話題になってますね。
双方のケースが引用している、CSS Nite in Ginza, Vol.23において大藤さんは、マルチシートアプローチすらも使われるケースが減ってきているとおっしゃっておりました。※1
という訳で、マルチシートあたりが、また若干熱くなっているのかなということで、今回は僕が主に使用しているマルチシートアプローチに関するエントリーです。

そもそもマルチシートアプローチのメリットを考えてみると、あきらかに制作のしやすさという点があげられるでしょう。
今でこそ、Dreamwaeverなどのツールが進化したおかげで、CSSファイルのどこにどんな指定をしたのかというのは一瞬で分かるようになってきていますが、そうでないときには、2~3千行あるいはそれ以上になるCSSの指定を人間だけで管理していくというのは結構難しかったりします。
ですからファイルを分けて、それぞれに限定的な記述をすることで、どこにどんな指定があるのかが分かりやすくなり、管理のしやすさがグッと上がる訳ですね。

また、マルチシートアプローチは複数人でのマークアップ作業にも向いています。例えば1枚のCSSファイルを複数人でいじっていれば、ファイルの先祖がえりなんてのも当たり前でしょうし、CSSファイルを複数に分けることで、このファイルは誰と誰以外はさわっちゃダメみたいな権限の設定も容易に行えるようになる訳です。

マルチシートアプローチの説明はこの位にしておきまして、最近の僕のやり方ですと、以下のようなマルチシートにすることが多いです。

• import.css
  • reset.css
  • common.css
  • module.css
  • ie.css
• category.css
• page.css

あくまでこのような感じになることが多いというだけで、全てがこうであるということではありませんが、まぁ概ねこんな感じでしょう。
ざっくりと説明しますと、サイト内のあらゆるページから「import.css」を読むことで、「reset.css」「common.css」「module.css」「ie.css」を読込みます。
さらに必要であれば、それぞれの(X)HTMLから「category.css」や「page.css」を読み込もうねという感じです。
もっと言えば、印刷用に「print.css」なんかもあるのですが、今回はスクリーン用だけということでここでは割愛します。

ここで「reset.css」「common.css」「ie.css」の3つに関してはそれほど説明するまでも無いでしょう。「reset.css」はブラウザリセット、「common.css」はサイト共通の結構大きな指定、「ie.css」はIE用のハックを記述しています。
問題は「module.css」なのですが、ここに記述している内容をちょっと工夫しています。

例えば、以下のような写真の一覧があったとしましょう。

1. 
2. 
3. 
4. 

この場合、全て写真の一覧には変わりませんので、仮に「.photo-list」というクラス名を付けたとしましょう。
その上で、多少の見た目の違いを指定しなければいけませんので、良く見るやり方としては、body要素や親要素となるdiv要素へIDやクラスを指定して、そこからの子孫セレクタで指定するというやり方があります。
これでも良いとは思いますが、最近の傾向としては全てクラス名で見た目の違いを吸収するようにしています。

ここでそれぞれの違いを考えてみると、

• 写真の枚数の違いにより、一つの写真と説明の幅と、写真間の余白が違う（CSSで言えば「width」と「margin」）
• 写真の枠線の色が違う（CSSで言えば「border-color」）

という2つの違いがあります。
では、クラス名に対して「.photo-listA01」という風にアルファベットと数字の2つの連番を加えてあげることで、この2つの違いを表現してみましょう。

共通の指定

.photo-listA01 li,
.photo-listA02 li,
.photo-listB02 li,
.photo-listB03 li {
	list-style: none;
	float: left;
	}
.photo-listA01 li img,
.photo-listA02 li img,
.photo-listB02 li img,
.photo-listB03 li img {
	border-width: 1px;
	border-style: solid;
	}

アルファベットによる写真枚数の管理（「width」と「margin」）

.photo-listA01 li,
.photo-listA02 li {
	width: 40px;
	margin-right: 10px;
	}
.photo-listB02 li,
.photo-listB03 li {
	width: 58px;
	margin-right: 8px;
	}

数字による写真の枠線の色の管理

.photo-listA01 li img {
	border-color: #f00;
	}
.photo-listA02 li img,
.photo-listB02 li img {
	border-color: #00f;
	}
.photo-listB03 li img {
	border-color: #0b1;
	}

と言う風に、クラス名だけで、見た目のり違いを表現できるようになる訳です。

また、このような考え方を行うには、各モジュール（※2）によって、サイトが構成されているような考え方が必要になってきます。
今回は、CSSのお話ではありますが、実はこのモジュールを基点とする考え方は、ビジュアルデザインにおいても重要になってきます。
よくマークアップをする人たちが何人か集まると、「出来上がるデザインモックが、各ページによって全くバラバラだと困るんでよね」というような話題になることがあります。
特に(X)HTMLのことをよく知らないデザイナーさんがデザインを行うと、そのようなバラバラが発生することも多いようですが、それは当然と言えば当然で、複数ページに渡る情報の関係性を理解していないからこそ起きる問題でしょう。

例えば、クライアントからページに入る文言をいただいた時点で、マークアップ側の人が、「このページのこの部分と、こっちのページのこの部分は、同じ写真の一覧ですね」などのように、デザイナーさんに対して、ざっくりとした情報の関係性を理解してもらうだけでもだいぶ変わってくるでしょう。

このような指示は、一見デザイナーさんに対して負荷がかかるので嫌がられそうですが、弊社の場合は全く逆でした。
デザイナーさん的には、「じゃぁ、こことここは同じような見た目にすれば良いんだな」と気づくことで、全く違う見た目を何個も作る必要もありませんので作業も楽になったということが起きました。

という訳で今回は、マルチシートアプローチとかクラス名とかに関する広義にはCSS設計などと呼ばれていることのお話しではあるのですが、そもそもCSSとは表現（見た目）を司るもの（逆に(X)HTMLは構造を司るもの）な訳で、CSS設計を考えるということは、実はビジュアルデザインも含めたワークフローまで変えることが出来るんじゃないですか？ということが言いたかったという次第です。

※1

あくまで、海外の個人blogを中心に、CSSを分析された結果ということです。

※2

各要素。サイトを構成する細かな部品のことを表しています。