簡単に結論
同じ作業で手戻りが続くときは、普段その作業を見ていない人に手順を一度見てもらいます。「何でも指摘してください」より、「夜間の担当者が、この手順だけで失敗を判断できますか」のように、場面を一つ渡すと答えをもらいやすくなります。
はじめに
久しぶりに地元の友人と話したとき、共有している話題が昔の出来事に偏ると感じました。仕事でも、同じ担当の中だけで会話を続けると、普段の説明を共有できる一方、引き継ぐ側が何を知らないか見落とすことがあります。
前提
ここで扱うのは、新しい見方を仕事の成果物に取り込む方法です。たとえば、普段は開発だけを担当する人が、運用担当の観点で手順を点検します。
親しい相手と共有している前提
慣れた仲間には「いつもの監視を見てください」で通じます。引き継ぐ人は、監視画面の名前、正常の値、何分間待つかを知らないかもしれません。話が早く通じるチームほど、外から読んだときに欠ける前提を明文化すると引き継ぎやすくなります。
立場が違うと、先に確認することも変わる
例として、夜間バッチの手順書を考えます。開発担当はログが終了しているかを見ます。運用担当は「前日分の結果が残っていないか」「再実行して二重登録にならないか」も確認します。同じ作業を別の立場から見ると、見落とした条件が具体的になります。
いつものメンバーだけでは見落とすことがある
別部署へレビューを頼むときは、手順書1ページと、実際に起きる失敗の例1件を渡します。「前日分のファイルしかないとき、ここからどこを見ますか」と聞けば、どの説明が足りないかを指摘してもらえます。
もらった指摘を次の作業で1つ試す
「ファイル名だけでは日付を判断できない」と言われたら、手順に「ファイル内の処理日が対象日と一致すること」を追記します。翌日の引き継ぎで別の人に同じ例を渡し、途中で質問せず対象日を確認できるか見ます。
レビューを依頼した相手には「処理日の確認を手順2に足しました。昨日分が残る例で迷わなくなったか、もう一度見てもらえますか」と返します。指摘を作業にどう反映したかが伝わります。
まとめ
まずは今週の作業から、説明しにくかった手順を一つ選びます。受け取る人にどこで迷うかを聞き、指摘された箇所を直し、同じ例で伝わるかを確かめます。
