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

GitHub Edit Page
この記事は公開から1年以上が経過しています。内容が一部古い箇所があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上精神論でしたけれど

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

アーカイブ記事のため、内容に関する更新依頼は受け付けておりませんが、誤字や脱字などありましたらご連絡ください。

この記事に関する修正依頼
アーカイブ一覧へ戻る