最初は興味深かったけど「運用手順書の設計思想」あたりから方向性が怪しくなってきて、ついぞ「ミスを許さない手順書」が出てくることはなかった
手順書は絶対に間違える。みんな、よく手順書通りにできるもんだと感心している。自分でもポンコツだと思うがテスト手順書もまともに手順通りに操作できない。というわけで弊社はそういうの全廃してる。
タイトルはともかく「矛盾がなく目的がわかるようになってて読みやすい」が大事なのと、ヘッダで目的や概略理解させてシナリオとタスク書くってのはいい手順書作れたと/見たとき、まあそうなってるなとは思った。
ミスを許さないのであれば手順書を使った運用自体をやめるべきだと思う
ミスを防ぐ手順書ではなく、ミスしたときの責任追及について書かれた手順書に読める
システム
「ミスを許さない」がそもそも間違ってて、「ミスが出てもリカバリできる体制」を作らなきゃいけない
何に対してミスを許さないのかが書かれてないのでやり直しです。
この資料はレベル3を満たしてるの？
思想としてはそうだけど、実際に作ってみると机上の空論に過ぎないのは手順書作成者なら誰もが通って来た道。
人的ミスは必ず起きるので最終的には指差確認＋ダブルチェックに落ち着いた。
ハハハこやつめ。このくらいの手順書でミスしないのは十分に作業者がまともなんだよ。
ミスしたやつは切腹、みたいな手順書かな？
人間だから間違いは必ず起きるんだよ。この人が作っているものはね、間違いが起きた時に「何で間違えたの？ここにこう書いてあるでしょう。間違えようがないのに何で？」って担当者を詰めるためのシステムなんだよ。
そもそも読まれないのだ！
どんなに手順書で「これを選択しろ」って強調して書いてても、作業者は上から何番目くらいにしか手順書を読んでないです。そして事故る
手順で済ませたい系戦略の限界が露呈しているヤバ目な主張。低コンテキスト手順は業務表層で仕様の一部に過ぎない。業務意図といった高い抽象層をたかがフローチャートに混ぜたらダメ。典型的エンジニアリングの錯誤
中身見てないけどゲルショッカーの掟みたいなもんだろ？ミセスは許される？
にんげんだもの
手順書は書いた時点が完成ではなく、間違えられた箇所を足していくもの。更新の担当と頻度まで決めないと読まれない一枚になる。
「ミスを許さない手順書」を作ってみた 〜 個人的にはこれ以上できることはあまりなさそう/20260827-ssmjp-operation-procedure-update
最初は興味深かったけど「運用手順書の設計思想」あたりから方向性が怪しくなってきて、ついぞ「ミスを許さない手順書」が出てくることはなかった
手順書は絶対に間違える。みんな、よく手順書通りにできるもんだと感心している。自分でもポンコツだと思うがテスト手順書もまともに手順通りに操作できない。というわけで弊社はそういうの全廃してる。
タイトルはともかく「矛盾がなく目的がわかるようになってて読みやすい」が大事なのと、ヘッダで目的や概略理解させてシナリオとタスク書くってのはいい手順書作れたと/見たとき、まあそうなってるなとは思った。
ミスを許さないのであれば手順書を使った運用自体をやめるべきだと思う
ミスを防ぐ手順書ではなく、ミスしたときの責任追及について書かれた手順書に読める
システム
「ミスを許さない」がそもそも間違ってて、「ミスが出てもリカバリできる体制」を作らなきゃいけない
何に対してミスを許さないのかが書かれてないのでやり直しです。
この資料はレベル3を満たしてるの？
思想としてはそうだけど、実際に作ってみると机上の空論に過ぎないのは手順書作成者なら誰もが通って来た道。
人的ミスは必ず起きるので最終的には指差確認＋ダブルチェックに落ち着いた。
ハハハこやつめ。このくらいの手順書でミスしないのは十分に作業者がまともなんだよ。
ミスしたやつは切腹、みたいな手順書かな？
人間だから間違いは必ず起きるんだよ。この人が作っているものはね、間違いが起きた時に「何で間違えたの？ここにこう書いてあるでしょう。間違えようがないのに何で？」って担当者を詰めるためのシステムなんだよ。
そもそも読まれないのだ！
どんなに手順書で「これを選択しろ」って強調して書いてても、作業者は上から何番目くらいにしか手順書を読んでないです。そして事故る
手順で済ませたい系戦略の限界が露呈しているヤバ目な主張。低コンテキスト手順は業務表層で仕様の一部に過ぎない。業務意図といった高い抽象層をたかがフローチャートに混ぜたらダメ。典型的エンジニアリングの錯誤
中身見てないけどゲルショッカーの掟みたいなもんだろ？ミセスは許される？
にんげんだもの
手順書は書いた時点が完成ではなく、間違えられた箇所を足していくもの。更新の担当と頻度まで決めないと読まれない一枚になる。