品質の関所を設計する: 通すべき条件と、戻す条件

「もっとレビューを丁寧にしよう」は、実務では機能しない。丁寧さは疲れると崩れるからだ。品質を安定させるのは、丁寧さの掛け声ではなく、通す条件と戻す条件が明文化された関所である。

関所の三つの型

• 自動関所: リンター、テスト、ビジュアル回帰。人が疲れても働く。
• チェックリスト関所: 人が短時間で通す。「文字化けチェック」「代替テキストの有無」など、判断に迷わないもの。
• 主観関所: 「トーンがブランドに合うか」「レイアウトが破綻していないか」。ここは判定者を固定する。

関所を増やしすぎない

関所は3から5、多くて7に絞る。10を超えると、通す側も判定する側も、飛ばし読みを始める。関所は装飾品ではなく、実際に判定される道具として設計する。デザインレビューを短く回す考え方は別記事で書いた。

戻す条件を書く

通す条件だけを書いた関所は、判断が甘い方向に流れる。「戻す条件」を明示するほうが、判定の一貫性が上がる。「文字が本文外にはみ出している場合、戻す」「ブランドカラーから2段階以上外れている場合、戻す」——このように具体的に書く。

「良ければ通す」より「悪ければ戻す」のほうが、判定は速く、ばらつきが少ない。

主観関所は判定者を固定

「ブランドに合うかどうか」のような主観の判断は、必ず必要になる。この関所は、判定者を人ではなく「役割」で固定する。編集長・アートディレクター・プロダクトオーナー——役割が明確なら、担当者が変わっても関所は同じ動きをする。

関所は育てる

関所は、最初から完璧である必要はない。稼働させて、通り抜けた不具合が見つかったら、次からその条件を追加する。関所は静的な文書ではなく、失敗の履歴を吸収して育つ道具として扱う。コンポーネントライブラリの逸脱を吸収する話とも通底する（コンポーネントライブラリの現場運用）。

スケジュールが厳しいときの関所

「今回は関所を飛ばして急いで出す」は、たまには必要だ。ただし、その決定は担当者が個人で下すのではなく、明示的な例外として記録する。記録が残ると、事故が起きたときの原因追跡ができる。恒久的な省略ではなく、明示的な例外として扱う。公開までのリードタイムを短くする段取りは編集パイプラインを組み直すで扱った。

反論: 関所は制作のスピードを落とす

厳密に測ると、多くの場合そうならない。手戻りの回数が減る効果が、関所を通す時間よりも大きい。ただし、初回導入時は明らかにスピードが落ちる——ここを乗り越えられずに撤収してしまうチームは少なくない。導入は、案件のクリティカルパスに関わらない時期に行うのが現実的だ。

参照

• Humble, Jez & Farley, David. “Continuous Delivery.” Addison-Wesley, 2010.
• ISO/IEC 25010:2011. “Systems and software engineering — Systems and software Quality Requirements and Evaluation.”

品質の関所は、厳しくすることが目的ではない。「厳しくなくても、ばらつかない」を目的に置くと、設計は自然に軽くなる。