3 posts tagged “direction”

コーディングに入るときに、こんな成果物は嫌だ！
ということでコーディングディレクションにおける成果物を洗い出そうという試み。
成果物といっても修正指示まで入れると、いただくドキュメントすべてという感じですね。
注意点１．念のため、一応書いておきますが、特定の誰か・何かを非難するものでは全くありません。
心当たりがあったからといって、うちが恨んでいるという話では全くないのですが、
勘違いされる方がいらっしゃったら先に謝ります。すみません。
注意点２．これ、制作会社の方から発注があることを前提に書いています。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位 お金
・・・

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

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

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

おかげさまで、HTMLコーディングのサービスはいろいろなお客様にご愛顧いただている。
1月から3月まで扱うHTMLのページ数が3000ページほどに迫るというのも、何度も繰り返し発注していただけているお客様がいるからだ。（実際にコーディングするページだけではないのでそんなに意味のある数字ではありませんが）

様々なWeb制作会社の方から発注をいただくので、その先のお客様のことも考えると、結構なパターンの仕事をこなしてきた。その中で凄腕ディレクターというか、すごく仕事がしやすいディレクターの方ともかなり出会ってきた（ように思う）。ただ、その条件としてはどうしても
コーダー出身なので、コーディングで何が必要か、どういう修正が辛いか、どれくらい実現に時間がかかるか直感的に分かっている。そのため、やりとりがスムーズになり、二度手間なことも少ない。
というケースが多いように思う。でも、これをいろいろなお客様のディレクターに望むのは難しい。そもそもコーディングに詳しくないから外注したい、というケースが多い。

ということで、うちが凄腕ディレクターから吸収した技＋コーディングの視点からえたものを、お客様のディレクターのアシストとして、サービスしていけばもっとスムーズに発注ができるのでは、という考えに至った。
多分、やらなくてはいけないのは下記の三点

• コーディングを進める上で必要な情報や、コーディング時の情報のやりとりがスムーズになるようなフローの定義、ツールの導入、啓蒙（理想のサイトマップ、理想の仕様書）
• サイトマップの整理や、画像パーツの発注などの、コーディングディレクション業務のサービス化
• HTMLコーディング＋αとして、システム制作、画像パーツ製作、文章校正、サーバー管理などのサービス化

即効性があるのは1点目だろう。3点目なんかはHTMLコーディングサービスの域を超え、隣接事業分野に展開することになるので、お客様の声を聞きながら慎重に進めたいと思っている。

少なくとも4月頃には下記の問いに答えられるようになっていたい。

• 理想のサイトマップとは？
• Trac＋Subversionが今のところはベストなのか？
• サイトマップ作成や、ファイルのステータス管理に、grep+正規表現やExcelのツールがあれば生産性が格段に上がるのでは?そのときの標準のフローは？
• 隣接事業分野のニーズはそれぞれどれくらいか?スタッフのキャリアパスとしては適当か？

（お客様の予算の関係で）3月まで忙しい分、4，5月はある程度暇になるので、そこでもう一段階成長するための準備ができればと思う。