こんな成果物は嫌だ。 コーディングディレクション編

コーディングに入るときに、こんな成果物は嫌だ！
ということでコーディングディレクションにおける成果物を洗い出そうという試み。
成果物といっても修正指示まで入れると、いただくドキュメントすべてという感じですね。
注意点１．念のため、一応書いておきますが、特定の誰か・何かを非難するものでは全くありません。
心当たりがあったからといって、うちが恨んでいるという話では全くないのですが、
勘違いされる方がいらっしゃったら先に謝ります。すみません。
注意点２．これ、制作会社の方から発注があることを前提に書いています。Web制作でエンドユーザーからだったら、こんなに虫の良いこといいません。これをそろえるのがディレクター（うちがやることもありますが）の仕事だ、というつもりで書いています。
注意点３．嫌みっぽく見えたらごめんなさい。文章のノリの都合上の問題です。
注意点４．ディレクターって大変ですよね。まじめな話。
注意点５．こういうミスをなくすために、ドキュメントのフォーマットをそろえたり、言葉の定義をそろえたりということをしましょうという前向きな記事です。

まず成果物の種類だしから。

• 仕様書／コーディングガイドライン
• サイトマップ
• デザイン
• 原稿
• 修正指示

ひとまず。

仕様書
発注条件が書いてあるもの。そもそも、きちんとお客さんから渡されることが少ないんだけど、少なくとも社内標準を作って、聞くことはまとめておいた方がいい。

こんな仕様書は嫌だ。

• 確認ブラウザ後出し　「あれ、このブラウザって言ってなかったっけ？」
• ex.  NN4.7って！フルCSSだめじゃないっすか！無理っすよ
• ex. IE5.5って！標準モードでレンダ（略）
• ex. Mac IE5.01って！（略）
• ex. WindowsME（ry
  
• バージョン後出し
• 「今回HTML4.01じゃないと、お客さんが運用できないってさ」
• 「いや、Strictがいいんだけど！」→target属性（涙）

• デザインと矛盾
• デザインが垂直真ん中あわせなのに、position:absolute禁止とか？あんまり無いか。
• すでにいただいているHTMLと矛盾
• 確認必須ブラウザで崩れている
• もらったHTMLがValidじゃない

※そもそも、「こんな仕様は嫌だ！」という話がありそうですね。対応ブラウザとか。OSまで細かく指定がくるとつらいっす。

サイトマップ
会社によって、URLリスト、ディレクトリリスト、ディレクトリマップといろいろな言われ方をします。

こんなサイトマップは嫌だ。

• そもそもサイトマップが無い
• これは簡単なものでも作るのがおすすめです！
  
• HTMLファイルの洗い出しが間違っている
• 既存サイトのリニューアルだったらls とったりgrepとったりしてファイル一覧作って差分とってください！余裕があったら、その辺の記事も書きたいなぁ。
  余談ですが、grepとかその後のExcelとかはコーディングディレクションにはあるとよいスキルですよね。
  
• まぁリダイレクトするファイルとかブラウザで確認しづらいですよね。
• 事前にFTPでファイルをもらっていればすんだりする話もあったりなかったり。
• 見づらい
• 論理的に装飾ルールが一貫していない（単なる装飾云々は最低限でいいんですけど）
• コーディングに関係ない無駄な列はできれば非表示にしていただきたい（わがままですね）
• 階層構造がぱっとわからない（これはできれば、ですが）
• お客様に確認がしっかりとれていない、ころころ変わる
• しょうがないものもありますが、単に聞いていなかっただけとか泣きたい（＞＜）。前工程の変更は、後工程になればなるほど深刻な変更になるのです！
• そのためにも、項目やHTMLの漏れは最初につぶそう！
• フォーマットが独自すぎる
  
• エクセルの行と全く対応していない
• っていうかエクセルじゃない
• 情報設計にはいいけど、コーディングには向いていないのでは？
  っていう矢印が一杯入った、ボックスが一杯ういたPDFとか。OmniGraffle？Visio？
  とはいいつつ、二つ作るのはめんどくさいですよね。でも、漏れが無くなったりしやすいですので、うちとしてはExcelがおすすめです。
  
• 手書き　コピペできないとミスが出ます！急ぎの時以外はできるだけ。
  
• 項目の漏れ。（あとでHTMLさわりなおすはめに・・・）
• 必須：<title>、新URL、（リニューアルなら）旧URL、meta keywords、meta description
• 使うなら必須：リダイレクト先URL
• 今まであってちょっとうれしかったもの：ID、備考、システムが使うかどうか、使用するテンプレートのID、手を加えるページか加えないページかの判断
  ※新URLとか任せていただくこともあります。
• IDって書いてある項目がよく変更されている
• IDはIDです（涙）
  

デザイン
PhotoshopやFireworksでいただくテンプレートのデザインファイルです。

• アウトライン、アンチエイリアス関連
  
• アウトライン化されすぎていて、コピペできない
• アウトライン化全くされていないので、崩れが不安
• （可能であれば）テキスト化するところはアンチエイリアスオフでお願いします。あとから差し替えるの結構つらいっす。
  
• レイヤー分けがきちんとされていない
• Photoshopと見せかけて、開くとBMP貼り付けられたレイヤーが一枚
• ロールオーバーとかできればレイヤーを分けていただいた方がわかりやすいかもです。
• 作成環境が不明
  
• Windows／Mac？ 微妙にフォントのカーニングとか違いません？
  
• 作成したソフトのバージョンがわからない
  ま、上のバージョンで開けばだいたい大丈夫なのですが。
  
• というかIllustratorだ。
  ここはうちのスキル不足もあると思うんですが、色とPixelできっちりできない関係で、Illustratorは嫌なのですが、誰か解決方法を教えてください〜
• マージン／幅などが適当になっている
• むしろデザインファイルを完全に再現すると怒られる。
• 逆にデザインファイルと一緒じゃないと怒られる。。。
• 適当なら、「マージンは適当なのでルールであわせちゃってください〜」とか指示いただければCSSでやります！逆に、いつも1px違うとか判断迷います。
  
• グラデーションが微妙すぎてうちのモニターでは。。。（笑）　できればガイドあたり引いていただけると。

原稿
超絶Photoshop使いがいると、全ページPhotoshopでくる場合もあります。ただ、ふつうはテンプレートページだけPhotoshopで、あとはMicrosoft Officeの何らかのフォーマットでくる場合が多いです。あとは写真とか。

• 原稿が来ない／遅い／作った後でころころ変わる
• 「Webだからすぐ反映できるだろ」とか、明らかにダミーテキストだよ、とかちょっと寂しいです。結構二度手間になるので、できれば原稿はそろえてください（＞＜）
  でもここはいかんともしがたいですよね。。。
  変更がありそうなら、ありそうとか、柔らかいなら柔らかいと一声かけていただけると助かったりします。
  
• HTMLプレビューって、気持ちはわかりますが（法務に厳しいところとかその傾向あり）、予算・時間無いときは是非原稿段階でたたいてください。
• 表記揺れや、ミスが多い
• 数字の半角・全角
• 「問い合わせ」と「お問合わせ」など。
  ※これもルールがあればこちらで直すことも可能ですが。あとでぼろぼろ修正が入るとつらいです。
  
• なんか原稿が自由すぎる
• チラシ一枚渡されても〜　マークアップできるかしら。。。
• 手書き→手打ちになるので、勘弁してください。
• でっかい写真渡されても。「いいようにトリミングしておいて！」って、後で修正するくせにー。。。
• ふつうに印刷された写真だ。いや、全然OKなんだけど、エンドユーザーじゃないんだし、
  
• サイトマップとの対応がとれていない
• 是非IDをふってください！原稿管理にサイトマップの表も使えて一石二鳥。

修正指示
納品した後で、こちらのミスや、あちらのミスや、あちらのあちらのミスを直すためのもの。

• それは修正ではなく仕様変更では？
• 料金内で対応できるものと対応できないものがありますです。
• 最初の時点で、聞いておけばつぶせたものがくると切ないです。
• 「何となく崩れているような気がします。」
• 申し訳ないです。早くなおしたいので、OSやブラウザを教えてください。
• あと、こちらの気のせいだとわかっているのですが、リロードボタンを何回か押してみてください。。。
  
• 修正がフィーリング過ぎる
• なんか違う。　→　ば、場所を。
• 修正が嫌みだ。
• （わかってて）あれー？こんな仕様でしたっけ？
• 修正の重要度がわからない。
• 「緊急」と「最優先」ってどっちを先にやれば。。。
• 修正文言が手打ち
  
• 修正を投げたばっかりなのに、進捗を聞いてくる

おもったんですが、修正のやりとりはTracを使っておけば、結構すれ違いは防げそうですね。あとは、手書きの修正をnotaとかでもらったり。

あと、うちのコーダー陣に「お客さんから何もらえたらコーディングしやすい？」って聞いてみたところ。
1位 愛
2位 お金
・・・

でも、時に成果物以上に、愛は重要ですよね。愛だけじゃご飯食べられませんけど、愛がなくてはご飯を食べたくもない。という感じが。

もしご意見などありましたら、是非コメントかはてブなどでいただければ幸いです。
単なる愚痴っぽくなりましたが、むしろこちらから積極的に情報発信して、たとえばサイトマップの標準化などを進めていきたいと思っています。上記に対して、一言、二言ある人大歓迎です。アドバイスください！

ちなみに、前に「コーディングディレクターの業務にはマネジメントスキルが必要である 」という記事を書いたのであわせてお読みくださいませ！

Comments

[投稿情報: securecat]

ディレクターのミッションはディレクションであって、こういったドキュメント類をそろえることではないんじゃないでしょうか？
ディレクションするために必要な一式ではありますけど。

[投稿情報: にゃむ]

おっしゃるとおりですね。

ただ、ドキュメントに必要な要素を洗い出すことがコーディングフェーズに必要な緻密なディレクションを考えるための一助になったりしないでしょうか？

最近ディレクションのしきりの部分と、クリエイティブな部分と、管理の部分で必要なスキルセット、マインドセットの差を感じるためです。※「しきり」って曖昧ですけどふと浮かんだんでこのままにしておきます

[投稿情報: たまみー]

う・・・・・。

う・・・う・・・うぅ・・・（；－；）

[投稿情報: にゃむ]

ちょ、たまみーさん！！というかいつもお世話になっています。。。いつも勉強させていただいてます。

やはりネガティブな書き方はおもしろくないので、もう少し前向きな書き方をしてみます。次回。

[投稿情報: Pまん]

「ディレクター」って定義、色々ですよねー
僕は、自分をCDとして、PDの方と作業分担をし、協力して進めていきたいです。
ただ「素材クレーー」って言ってても駄目だし、かといって上から指示されたことしかやらない、ってのも微妙だし。
これまでの経験上、案件の全貌を把握して作業する場合とそうでない場合では、コーディングのスピード／品質が結構違う。
導線とか理解しないと、しっかりリンクは貼れないし。
サイトの背景が分かっていれば、こちらからなにか提案できることがあるかもしれない。
もちろん「それはお前の仕事じゃねー」とか言われそうだけど、出来る事ならば足突っ込んでいきたいです。
最近そういった意味で、PDの方々は案件の全貌を把握して、性質や用途、さらにはそのサイトが扱ってる商品とかまで理解しないといけないから、大変だろうなー、って思う。

あ、あとどうでもいいですが、「マークアップエンジニア」って定義もまた謎。