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

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

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

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

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

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

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

• レイアウトモジュール

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

• 見出しモジュール

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

• 段落モジュール

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

• リストモジュール

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

• 表モジュール

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

• ブロックモジュール

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

• インラインモジュール

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

• リンクモジュール

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

• 画像モジュール

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

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

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

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

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

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

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

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

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

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

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

大雑把に管理していても、その案件がホットな時期は、○○の書類はどこだった？と聞かれた際に、即座に回答することが出来ますが、半年・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ファイル

お世話になります。コバです。

弊社は土日が完全休日なのではありますが、まぁ、それはそれで、本日も見事にガッツリとマークアップしているわけです。
そんな本日は、今進めている案件（マークアップのみの案件）があまりにもヒドイのでは？ということで、「マークアップする人から見た、こんなディレクター（案件の進め方）は嫌だ！」ということを書き連ねて行きたいと思います。

1. サイトマップが見難い

   クライアント様にお見せするという理由から、とてもビジュアル豊かにされるのは良いのですが、それでいて、ファイル名・ディレクトリ構造・キーワード・ディスクリプションなど、マークアップ段階で必要になる項目がない上に、ビジュアル豊かに無意味に行をあけていたりしてとても見難いものになってしまっている状態。しかも、マークアップに入っているにも関わらず、ちょこちょこ変更が起きている。さらにしかも、その変更をリアルタイムに伝えてくれない。

2. それってWebサイトをデザインされたんですか？

   小さな案件では、ディレクター（もしくはビジュアルデザイナー）がアートディレクションを兼務することがほとんどですが、あがってきたデザインがマークアップ側からするとヒドイ状況。例えば、なんでこのページの写真の一覧と、このページの写真の一覧の見せ方がこんなにも違うの？まった同じ性質のものですけど…。とか、この2pxの差はなんなんだ！とか。平たく言ってしまえば、これ目見で作っただろ！というデザインが上がってくる。さらにサイト内のリンクテキストのデザインすら統一されておらず、「リンクテキストは全体的にこうしませんか？」と提案すると「あー、じゃそれでお願い」とか言ってくる。
   さらにさらに、全ての文字にアンチエイリアスがかかっていて、どこがテキストで、どこを画像にすれば良いのか分からない上に、こちらから確認しなければその指示も来ない。

3. スケジューリングがヒドイ上に納期の変更がきかない

   今週までに、ここまでお送りしますので！と聞いていたものが、待てど暮らせど、若干アオッても、全く来ない。プロジェクト始動段階で、デザイン提供の遅れは、納期の遅れに繋がりますということをめっちゃ説明してもまるで無関心。実際に遅れているにも関わらず納期がズレない。

4. 素材が提供されない

   マークアップに必要なテキスト素材等が用意されていない。挙句の果てには、デザインモックから抽出してよ！と言われるような状態。ファイル形式を決めて、別途管理しておいておくと良いですよね、と伝えても「あー、うんうん」とかでスルー。

5. 本当に何も決まっていない（というか決められない）のに、納期間際で変更がある

   文字コード、(X)HTMLのバージョン、印刷用CSSの適用、ターゲットブラウザ、画像や(X)HTMLファイルの命名規則、アクセシビリティへの取組み具合などなど、聞いても何もないということで、ではこれで進めますという確認のもと進めていたのに、納期間際でやっぱりこれはこうしてね、ということが発生する。

等々、ざっとあげてはみたものの、まだまだものスッゴイありますよね。
こんな進め方は嫌だー！ということが、もっともっと上がってくれば、おのずと良い（ストレスのない）進め方が逆に分かってくるので、皆さんのそんな体験ありましたら、ドシドシご応募くださいませー。

最近はあらゆるコミュニケーションがメール上でされておりますね。私自身、メールはあんまり好きではないのですが、一番の理由としては言葉の解釈というのがそれを読む人に従って凄まじい程に変わってくるということです。

「ちょっとそれはないよ～」という状況なんかでは、逆に自分が想定していたよりも受け手が思いを汲み取ってくれたりすこともあるわけで、そんなことまで考えればそこまで悪いものでは無いような気になってくることもありますが、なんたって「えっ！全くそんなつもりで書いたことでは無いのですが…」という時の脱力感の凄まじいこと。そういった記憶のインパクトが強すぎて、自分としてはあんまりメールが好きではないんですよね。

そんなこんなでメールのことを悪者にしてしまっている自分に気づいたこの頃なのですが、「ちょっと待て～！」と。それは自分の思いを、母国語を使って誰かに伝えることに難のある私が痛いのではないかとやっと気づき始めたわけですよ。