読者です 読者をやめる 読者になる 読者になる

やまろぐはてな

yamanokuの技術メモ。Qiitaは怖くて書けない。

クオリティチェックで気をつけていること

クオリティチェックしてますか

f:id:cardboarder:20160629232846p:plain

納品前に一旦問題ないかをしっかりチェックし、品質は維持しているかを確認するクオリティチェック。皆さんの会社でも行っているかと思われます。やってないのだとしたら、自社のプログラマーがよほど立派なのか、客のことどうでもよく思っているでしょうかね。

クオリティチェック、ウチではチェックリストをデザイナー・プログラマー・ディレクターでそれぞれ設けてチェック項目を埋めていき、問題があったら都度リストにあげて作業者にパス、問題がなくなったら再度連絡してチェックしてもらう、という感じで品質維持・エラー数を減らしていってます。

ちなみに弊社ではGoogleDriveのスプレッドシートを使用して独自のクオリティチェックシートを用意しています。

チェック指摘について気をつけていること

で、表題に関してなんですが結論から言うと自分が修正するくらいのことを書くというのを気をつけています。

例えば、xhtml記述でオミットタグを忘れてバリデーションエラーが出てしまった箇所があるとしましょう。その時に

  • xxx行目 エラーあり
  • xxx行目 omitted tag エラーが発生しています

の2つがあったとしたらどちらが親切かといえば間違いなく下だと思います。そしてどういったエラーが起きているかというのも一見して分かるのでその修正箇所のエラーに対してもどう直せばいいかもわかります。

ちなみに程度問題ではありますが自分は以下まで書いてます。なるべく作業者のストレスは軽減できるように。

  • xxx行目 imgタグにオミットタグがないようです。<img src="" />修正の方お願いします。

見た目の調整も限りなく数値化する

今のはマークアップ側のエラー報告ですが、デザインの観点で言えば元のデザインと相違点があったら指摘が入ると思います。その時には

  • /xxx/xxx.html h2見出しのpaddingを上下あと10px広げてください
  • グローバルナビのホバー時のカラーを #d0d0d0 にしてください
  • ロゴの大きさをwidth : xxx px、height : yyy pxに修正していただけますか

とできるかぎり数値化・コード化してくれるとその通りに入れ込むことができるので安心です。ほかにもアニメーション挙動箇所についても何秒遅らすかとか、レスポンシブさせる時にカラム幅をいくつにするか等あるかもしれません。

チェックがただの指摘になっていないか

上述したのは主にマークアップに関するチェックなんですが、他にもインフラ側のチェックとかだと「どの条件下で発生したか」などのよりバグが発生した時の具体的な説明や期待値を述べるととてもやりやすいと思います。

結局何が言わんとするのかというとクオリティチェックをする際に他人事にしていないかということで、ただやって終わりにしないというのを徹底して欲しいなということです。

もちろん業務が分かれている以上、全員が詳細的な指摘はできないとは思いますが、いわゆる赤入れして期待値になってないときにキレる人というのはかなりの確率で他人事にしていると思います。それはひどい客がやるやつじゃんとお思いの方、案外敵は身内にいるものなのです。

何にせよやり過ぎはいけませんが、ちょっとした気遣いで全体の雰囲気は良くなります。人の振り見て我が振り直せ精神でクオリティチェックやっていきましょう。こちらからは以上です

以上精神論でしたけれど

クオリティチェックで漏れが出てしまった場合の対応策とかはまた別の機会にまとめていきます。lint的なやつとか。

関連

oyamaokuto.org