- Coding Methodology
- 第12回 JD（Job Description）シート
第12回 JD（Job Description）シート
一口に「コーディング」という言葉で表現されるコーディングファクトリーの業務範囲ですが、内部的には、たくさんの工程に分けられます。たとえば、コーディングに入る前準備の工程であれば、「デザインデータの整理」「サイトマップの整理」「コーディングガイドラインの確認」「画像スライス」・・・といったことが挙げられます。これらの工程で、具体的にそれぞれ何を行うのかを、分解して明文化（＝Job Description）することで、各担当者が、無駄なことに悩む時間を減らしたり、戻り作業の発生を抑えたりすることが可能になります。
「なんとなくいつも通りにできる」と「整理された手順通りに行える」との大きな違い
コーディングを多少でもかじったことのある方なら分かると思いますが、デザインデータからコーディングをある程度できるようになることは、それほど難しいことではありません。
なんとなく左上のほうからデザインを見ながら組んでいき、ブラウザで見て、崩れていたら他のコーディング方法を試してみる・・・そんな繰り返しをしていくと、1ページがコーディングできてしまいます。
しかし、常に一定の品質を一定のペースで作り続けるには、それでは限界があります。それを「仕組み」化して、いつでも・誰でも、同じレベルのことができるようにするため、ドキュメントとして明文化しておく必要があります。
明文化（Description）のメリット ムリ・ムダ・ムラを徹底的に排除する
コーディングファクトリーでは、業務を分解して明文化したものを「JDシート」と呼んで共有しています。
これは、実際にいちばんその業務にかかわっている人が、1つ1つの手順を文章や絵に記述したドキュメントを作成し、それをもとに、ミーティングで発表し共有します。
書いたドキュメントによる無駄の削減効果と同時に、現場の担当者自身が、どんな手順で何をするのが一番効率的なのかを考え直すこと自体も、ひとつの大きな意義になっています。
JDシート（例：制作とチェックのやりとりについて）
これは、コーダーがコーディングしたファイルを、社内チェックに回す際のJD(Job Description)シートの例です。それを補足する図と文章で、わかりやすくまとめています。
このJDシートを全員が共有することで、「どんな順番で」「誰が」「何をするのか」が明確になり、漏れや誤解をなくし、各工程を確実に進めることができます。
「ルール」自体がナマモノだと心得る
このようにして明文化してきた「JDシート」ですが、決まった後も、けっして「決められた手順通りに作業するだけ」を推奨しているわけではありません。ベストな方法というのは、技術的な進歩や、社内の生産力に応じて常に変化するものだし、また、進化させていかなくてはならないものでもあると考えています。
「決められた事は確実に実行する」ことと、「決められたことが今の私たちに本当にベストなやり方なのかを常に見直して、改善していく」の2つがあって、はじめて、生きたルールとして活用されるのだと考えています。
