手順書があっても任せられない理由

実践者としての結論

操作画面の説明だけでは手順書になりません。なぜ行うか、何を受け取り、どの状態なら完了か、何が起きたら止めるかを第三者が確認できる形にします。

仕組み化の成果は、人を減らすことや自動化率を上げることではありません。判断の根拠が残り、異常時に人が止められ、購入者への対応が遅れない状態です。

運営上の課題

手順書を渡したのに担当者ごとに結果が異なり、確認漏れや判断のばらつきが発生しています。

個人の経験や注意力だけへ依存せず、他の担当者が同じ記録から同じ判断へ進める状態を作ります。

仕組みに必要な確認

1. 作業の目的と対象範囲
2. 必要な権限・資料・入力
3. 手順と判断基準
4. 完了証拠と保存先
5. 例外時の連絡先・期限

確認項目には所有者、期限、証拠、保存先を付けます。未確認を正常完了として扱わない仕組みが必要です。

役割と判断を分ける

• 正常例と例外例を一件ずつ通して試す
• 担当者の質問を手順の不足として記録する
• 同じ入力で同じ結果になるか照合する
• 変更履歴と適用開始日を管理する

ツールや担当者には処理を渡しても、重大な停止・再開、販売可否、購入者対応の最終承認まで無条件で渡しません。

停止・保留・再開条件

• 口頭補足がなければ完了できない手順の移管を止める
• 秘密情報や不要な権限を渡さない
• 再開はSOP更新とテスト完了後に行う

停止は失敗ではなく影響を限定する正常な運営操作です。再開時には、停止中の差分と未処理注文も確認します。

記録と手順更新

• SOPの版・適用日・所有者
• テスト結果と質問
• 誤りが起きた手順箇所
• 改善を次版へ戻す

発生した質問、誤り、例外、復旧をSOPと役割表へ戻し、同じ問題を個人の注意で防ごうとしません。

まとめ

操作画面の説明だけでは手順書になりません。なぜ行うか、何を受け取り、どの状態なら完了か、何が起きたら止めるかを第三者が確認できる形にします。

第三者がテストできるSOP初版を作れる状態を目指します。正常時だけでなく、失敗・停止・復旧まで試して運営可能性を確認してください。