確認の一覧を作らせると、自分では気づかない項目が出る

• 手順を作ると、確認項目まで考えない
• 一緒に作らせると、抜けが見つかる
• 出てきた項目は、絞ってから使う

何かを作るとき、手順は考えても確認項目までは考えていなかった。一緒に作らせるようにしてから、見落としが減った。

頼み方

手順と一緒に、確認項目も求めている。

（作業の内容）を進めます。

手順と、各手順が終わった時点で
確認すべき項目を挙げてください。

確認項目は、できたかどうかが
はっきり判断できる形で書いてください。

最後の1行が要点だ。曖昧な項目は、確認しても判断できない。

判断できる形とは

この違いで、使えるかどうかが決まる。

• 使えない — 「正しく動くこと」「問題がないこと」
• 使える — 「エラーが表示されないこと」「3つの画面で崩れないこと」

前者は何をもって正しいか分からない。確認したつもりになるだけだ。

出てきた項目の扱い

そのまま全部使わず、絞っている。

• 自分の環境に関係ないものを外す
• 確認に時間がかかりすぎるものを外す
• 重要なものを上に並べ替える

2つ目で半分近く減ることがある。網羅的に挙げられるので、実用の範囲に絞る。

自分では気づかない項目

出てきて「そうだった」と思う項目を挙げる。

• スマホの幅での表示
• 別のブラウザでの動作
• 権限が無い状態での見え方
• データが空のときの表示

4つ目は毎回忘れる。自分の環境にはデータがあるので、空の状態を見ていない。

一覧を残す

作った確認項目は、次に使えるよう残している。

• 作業の種類ごとに保存する
• 次に同じ作業をするとき、そのまま使う
• 漏れが見つかったら、追記する

3つ目を続けると、自分の失敗が蓄積された一覧になる。

記事の公開前にも使う

同じ考え方を、記事の確認にも使っている。

• 数字をすべて確認したか
• リンクがすべて開くか
• スマホで崩れていないか

どれもはい・いいえで答えられる形にしてある。

作る側と確認する側を分ける

同じやり取りの中で確認させると、甘くなることがある。

• 作らせた会話で「問題ないか」と聞くと、肯定されやすい
• 新しい会話で、成果物だけ渡して確認させる
• 作った経緯を知らない状態のほうが、指摘が出る

3つ目を試して差を感じた。経緯を知っていると、そこに至った理由まで考慮して評価してしまう。成果物だけを見せたほうが、読む人に近い立場で判断される。確認の工程は、作った工程と切り離すのが基本だと考えるようになった。

項目を増やさない

一覧が長くなると、使われなくなる。

• 12項目程度に収める
• 追加したいときは、何かを外す
• 使っていない項目を定期的に削る

3つ目をやると、実際に効いている項目だけが残る。

作業の前に見る項目

終わった後だけでなく、始める前の確認も作った。

• 控えを取ったか
• 戻す手順を把握しているか
• 作業してよい時間帯か

3つ目は公開中のサイトを触るときに効く。利用者が多い時間に触ると、壊れたときの影響が大きい。終わった後の確認より、始める前の確認のほうが被害を防ぐ。項目は3つだけだが、これを飛ばして失敗したことが何度かある。

人に渡す場合

確認項目を人に渡すときは、形を変えている。

• 確認の方法も書く。どう見れば分かるか
• 合格の基準を書く
• 駄目だった場合の連絡先を書く

1つ目が無いと、確認の仕方が人によって違う。

確認する順番

項目の並べ方にも意味がある。

• 直すのが大変なものを上に置く
• 公開設定の確認は、最後にまとめる
• 上から順にやれば、手戻りが起きない

3つ目が狙いだ。細かい誤字を直した後に、構成から直し直すことになると二度手間になる。影響の大きいものから見るという順番にしておけば、下のほうを直す段階では上はもう確定している。並べ替えただけで、確認にかかる時間が短くなった。

自動化できるものを分ける

項目のうち、機械的に確認できるものは仕組みにした。

• リンクが開くか — まとめて確認する道具がある
• 数字の抜き出し — 機械的にできる
• 目で見る判断 — 自分でやる

3つ目を絞ると、人がやる確認は数項目で済む。

まとめ

• 手順を作るとき、確認項目まで考えていない
• 一緒に作らせると、抜けが見つかる
• 「はっきり判断できる形で」と指定する
• 出てきた項目は、実用の範囲に絞る
• 漏れを追記していくと、自分の失敗の記録になる