チームで何かに取り組んでいる時には、執筆物や製作物を他の誰かに確認・指摘をしてもらう場面があると思います。
その際に何か指摘を受けた際には、指摘された箇所だけでなく同成果物の中で同様に変更が必要な箇所がないかどうかについて「作成者が網羅的に確認する責務を負うフローが良い」と私は考えています。
文章確認の場合
こんな文章をクライアントに送るから内容を見て欲しいと言われたら、
いつもお世話になっております。
1/5の打ち合わせにて議題に挙がっておりました〇〇に関しまして、
社内で確認しましたところ、2/5に△△の対応を予定しております。
よろしくお願いいたします。
下記のようなコメントを送ります。
①「1/5」という表現だと読者に日付と伝わりにくい恐れがある為、「1/3(水)」や「1月3日」の方が良いでしょう。
②「2/5」という表現だと読者に日付と伝わりにくい恐れがある為、「2/5(土)」や「2月5日」の方が良いでしょう。←
同じ内容の指摘になるので②は言及しません。
コードレビューの場合（サンプルコードは割愛）
①sendThanksMailFunction関数の関数名にFunctionは不要です
②putInformation関数の処理内容に変更を加えているので、関数Docのコメントも変更してください
③getCoupons関数で取得期間を指定する際にUTCと日本時間の9時間ズレを考慮してください
④sendPromotionMailFunction関数の関数名にFunctionは不要です。←
⑤getUsers関数の処理内容に変更を加えているので、関数Docのコメントも変更してください←
⑥createUser関数の登録日がUTC基準になっているので、9時間ズレを修正してください。←
同じ内容の指摘になるので④⑤⑥は言及しません。
「ここも同様」とか「ここも修正して」みたいなことも敢えて言及しません。
心を鬼にして「水平調査をしてください」という抽象的なメッセージを伝えます。
作成者に水平調査を求める理由
作成者に確認者の意図が定着する
嫌でも確認者から聞いた意図を頭に置きながら成果物を網羅的に見直す作業が発生する為です。作成者に水平調査の意識が根付く
「言われたところだけ直せばいい」という考え方から、「他にも同様の問題が起こっていないか」と一考する習慣が身に付きます。指摘事項がコンパクトになる
ただ指摘事項は少なくなりますが、再提出内容に対応漏れが出てくることも多々あります。
水平調査が習慣化するまで作成者、確認者とも時間が掛かると思います。
補足
敢えてコメントしないとは言うものの、本当に急いでいる時やお客様に迷惑をかけられない時はスピード感を求めて細かく指摘を送ることもあります。