仕事のミス・作業ミスをワークフローシステムで9割減らす方法（中編）
こんにちは。
マーケティング部の木村です。
ごめんなさい！
計画が変わりました。
前回のブログ（前編）では、ミスの原因と個々の解決策について触れ、今回は後編として、ミスの原因（まだ説明していない分）の説明からワークフローシステムでの解決方法まで説明する予定でしたが、あまりにもボリュームが出てしまいましたので、今回は「中編」として以下の内容を説明していきます。
ミスの原因4つ目と5つ目
| 原因 | タイプ | 解決策 |
| 知識不足 | 訓練することで防止できるミス |
作業手順書を作成・更新する事を義務付ける・奨励する 作業手順が判らなくなった場合に、気軽に質問・相談できる担当者（メンター）をつけてあげる |
| スキル不足 |
ツールを高度に使いこなす必要が無いような簡単な作業を担当するところから始め、徐々に複雑な作業にOJTで慣れてもらう ツールに関する作業上のノウハウを勉強会や資料の形で共有する |
|
| モラル不足 |
定期的に手順の妥当性を見直す 手順が遵守されているか、定期的に内部監査する |
|
| 計画・環境不備 | 「作業環境・手順を改善する事で防止できるミス」だが、作業者に着目して言い換えると「作業者を訓練しても防止できないミス」と言える。
「人間は必ずミスをする」という前提に立った原因分析・再発防止策検討が重要。 |
発生防止観点 排除 / 代替化 / 容易化 の3つの原理で対応する 波及防止観点 |
| 手順不備 |
上記データは 中央大学 経営システム工学 中條武志教授による以下の論文中にある要素をまとめたものです。
1999年「作業管理システムが作業ミスの発生に与える影響」よりエラー分類と解決策を引用
https://ci.nii.ac.jp/naid/110003154353
「人間信頼性工学：エラー防止への工学的アプローチ」より解決策としての分類を引用
http://www.indsys.chuo-u.ac.jp/~nakajo/open-data/Healthcare_Errorproofing2.pdf
さて、前回のブログでは上記の表の中の「訓練することで防止できるミス（知識不足、スキル不足、モラル不足）の原因と解決方法に触ました（前回の記事はこちら）。
早速、残りのミス（訓練しても防止できないミス）の原因である「計画・環境不備（ミスの原因4つ目）」と「手順不備（ミスの原因5つ目）」について説明していきます。
「計画・完了不備」「手順不備」についての対応策
| 解決策【計画・環境不備（ミスの原因4つ目）と手順不備（ミスの原因5つ目）】 |
|
発生防止 代替化 容易化 波及防止 影響緩和 |
ミスの原因の4つ目は「計画・環境不備」です
物凄く厳密に考えると、「計画」と「環境」は対象とする概念・範囲が異なるのですが、ここではあくまで「計画（計画を作成した環境も含む）」として捉えます。
さてこの場合、ミスを引き起こす原因は
「作業スケジュールに無理がある」（無理、要素の考慮漏れ）
「作業者が不足している」（ディスパッチの不備、不測の事態）
などの、計画自体に難があるケースが大半を占めます。
しかし、これらの原因は起こるべくして起こっているとも言えると考えます。
なぜなら、これらの「原因」には、即時での改善が難しいと考えられる「背景」が存在するからです。
課題例）作業スケジュールに無理がある
→
・計画策定者の能力に依存（無理、要素の考慮漏れが原因と仮定）
→
【対策案】
- スキルアップ → （課題：時間がかかる）
- 人を変える → （課題：適する人材を調達できるか不明）
↓
上記の課題により、
・解決したくても踏み出せない背景がある（やりたくてもできない）
・計画策定者を含むチームにて承認されているため、客観視しての判断ができない
（なんとかしなきゃと思いつつも、チームで承認されているので良し、として進めてしまう）
上記のような「背景」は想像に易いです。
また、以下の課題例も示しましょう。
課題例）作業者が不足している
→
・コストを割当てていない / 動的人材配置の準備がない（不測の事態、計画不備）
【対策案】
- 予算追加 → （そもそもカツカツでやっていて追加予算を組めるファイナンス状況ではない）
- 多能工化 → （計画的に育てていなければ付け焼き刃。離職率にもつながる）
↓
上記の課題により、
・そもそも解決不可な状況である（環境として）
上記のように、環境の問題も背景として想定されます。
では、やりようがないのか？というとそうではなく、先の中條教授は「手順不備」の解決策と合わせて「エラープルーフ化」での対策案を出されています。
「エラープルーフ化」による対策
端的に言うと「作業システムを構成する人以外の要素＝システム、文章、手順等の「作業方法」を改善すること」です。
エラープルーフ化の考えでは、「訓練しても防止できないミス」を「発生防止」と「波及防止」の２つの項目にわけ、更にその中で対応方針を分類しています。
発生防止
さて「発生防止」についてです。
「発生防止」の策は、更に3つにわけた対応が提案されています。
- 排除
- 代替化
- 容易化
排除
発生防止は、作業自体の目的に無理がないか（計画・環境不備）確認する事からはじまり、ミスを引き起こす危険の有る手順や作業をそもそも無くしていく考えです。
手順の抜本的な見直しを行う可能性があり、業務プロセスに大きな影響を与えることが懸念点です。
また、作業担当者自身はなかなか「これをやめましょう」と発言すること自体ハードルが高いと考えられるため、先ずは発言を促す場を作り、チーム全体・組織のレイヤーで客観的に評価し判断する事が推奨されます。
代替化
人的ミスが起こりうる作業を「機械」や「システム」に任せるやり方です。導入にはコストが掛かりますが、「うっかり系のミス」を極力減らすことができます。リスクはシステムや機械のバグなどトラブルの発生リスクです。この点を踏まえると、発生防止の効果自体は「排除」よりも劣ると考えられています。
更に代替化は「自動化」と「支援システム」の2つに分けることが出来ます。
- 自動化：人の作業を「機械」「システム」に置き換える
- 支援システム：人間が該当の機能を確実に果たすことが出来るよう支援ツールを用意する（チェックリスト、ガイド、サンプル、入力フォーム化等）
容易化
人が作業する中で「記憶・知覚・判断・動作」等の機能を確実に行えるように、作業そのものを「容易」なものにすることです。
容易化も代替化と同様に、さらに3つにわけて間上げることが出来ます。
- 共通化・集中化：作業における変化・相違を少なくする
- 特別化・個別化：作業における変化・相違を明確にする
- 適合化：作業の対象・環境を人間の能力にあったものにする
共通化・集中化の例：必ず決まった時間にある行動をとれるようにしておく（タイマー、アラート、カレンダー記入など）
特別化・個別化の例：作業時に使用する道具を工程1は赤色のテープ、工程2は緑色のテープを貼るなどして、識別を容易にするための補助をしておく
適合化：ある特定の作業は有資格者にしか行わせない、視力の弱い人に極端な目視でのチェックを要する作業をさせないなど、対象と環境のマッチングを意識します。
ミスの発生自体を防止する。
この観点では実は人に依存する解決方法というよりも、環境や計画を含めて「システム化」されたプロセスにて防止を行う方法だと言えるのかもしれません。
波及防止
波及防止はその名の通り、仮にミスが発生したとしてその影響を極力少なくするための考えです。
発生を防止する考えに加え、「発生した後」を考えた策をそもそも講じておくことで、包括的にミスを減らす体制までを視野に入れた考えとなっています。
波及防止の2つの分類
異常検出
異常検出は、「異常」で有ることがすぐにわかるような措置を講じておくことです。
例として、都市ガスをつなげるホースの先の形状をある規格に準じて制作・備えておくことで、その規格以外の機器の接続ができなくなる（その時点で異常であるとわかるようにしてある）状態などが挙げられます。
更に、異常検出は3つのタイプに分けられます
- 動作の記録と確認
- 動作の制限
- 結果の確認
動作記録と確認：動作を記録し、特定の作業時点でその内容に誤りがないかを確認する
動作の制限：作業従事者が異常にきづくように、エラーに基づく動作を制限する
結果の確認：結果として得られた機器のログや報告文章、通知などを特定の作業時の時点で確認する。
さて、例として外科手術を引用しましょう。
外科手術では手術計画を元に、様々な器具の使用と術後の投薬ケアまでが一連の流れとして考えられます。
その際、手術器具の術前と術後の個数を数えるのは「動作の記録と確認（処置漏れにて、体内に機材を置きっぱなしにしていないか？）」です。
また、麻酔装置のタンクの接続先の形状を特定の形にしておくのは、接続ミスを防ぐための「動作の制限」にあたります。そして術後に定められた用法用量・時間で投薬がされているかを確認するのは「結果の確認」に当たります。
影響緩和
影響緩和は機能を冗長にしたり、制限や保護を設けたりすることで、エラーの影響をその波及仮定で緩和・吸収します。
影響緩和も更に3つに分けることが出来ます。
- 冗長化
- フェイルセーフ
- 保護
冗長化：エラーが起きても正しい結果が得られるように、同じ機能を持つ作業を並列で行うようにする
フェイルセーフ：エラーによって発生する危険な状態への移行を防ぐ機構・条件を装置や作業に組込む
保護：エラーによって危険な状態になっても損失が生じないように保護を設ける
「冗長化」は例えば、同じ作業を2名で行い、そのアウトプットが完全に一致しなければ次の工程へ作業をすすめないというような施策です。2名の作業者が同じ間違いをしない限り、致命的な結果が起こることを防止できます。
「フェイルセーフ」は装置やシステムの能力を危険の少ない範囲に制限しておくこととされています。物理的な機械であれば装置の能力を危険の少ない範囲に限定しておくこと。システムであれば、該当の工程や処理の範囲を適切な範囲で切り出して実施するようにしておくことです。（次の工程への自動移行がされないようにする点も合わせて実施）
最後となる「保護」は、エラーが発生したとしても影響度合いが少ない様に、そもそもの環境を整えておくことです。物理的な施策であれば、保護マスク、ヘルメットなども該当しますし、システムなどであれば「適切なアクセス権限」や「該当作業プロセス」にて処理されるデータをマスターデータから切り離し、加工後の数値がマスターに影響しない形で保存・利用される構成にしておくことが考えられます。
さて、これで前回より説明・紹介してきた全てのミスとそれらに対する解決策（解決方針）が出揃いました。
いよいよ本題に迫っていきます。
異なる視野からの解決策提起
さてこれまで、ミスの原因と解決策について述べてきたわけですが、ここまで読み進めて何か違和感を感じられる方もいらっしゃったのではないでしょうか。
実はこれまでの原因と策は、あくまで「工学的な視点」での整理がなされています。
実際の現場でも「システム化・自動化」はスローガンとして掲げられており、自社でもすでに取り組みでみであると思われるのではないでしょうか。
それでは何故、ミスはなくならないのか。
実はここには会社組織における技術的問題と適応課題の問題が潜んでいると、私は考えます。
「技術的問題」とは既知の技術・方法で解決できる問題です。
例えば「喉の乾き」を覚えた際、これを解決するには「水を飲む」事です。
これは「知識」に依存する問題解決の方法であり、知識が増えれば増えるほど対処できる対象と範囲は広がります。
また、社内で作成されるファイルを全て一箇所に集めたい・適切な権限を付与して閲覧に制限をかけたい。この様な場合はクラウドストレージやSaaSのサービスをもって解決策となるでしょう。
これは「知識がある」からこそ対応できると言えます。
一方で「適応課題」とはどのようなものでしょうか。
ここで埼玉大学経済学部経営系大学院の宇田川 元一 准教授の著書「他者と働く」より、一節をお借りして説明します。
”一方で、適応課題とは、例えば他の部署に協力を求めても協力をしてくれない場合のように、これと言った解決策が見つからない問題です。先程のクラウドサービスの導入にあたって、会議で提案したところ「それはこういうリスクがある」と反対を受ける、というようなケースです。そして、そのリスクは回避を出来るといくらロジカルに説明しても、何か別な理由をつけてまた反対される、というようなことがあった場合、これは「適応課題」だとわかります。なぜならば、表で語られている言葉の背後には、語られていない何か特別なことがあると考えられるからです。例えば。「共有した情報を元に勝手に仕事を進められると、問題が起きた時に対処することが面倒くさい」とか、「自分の持っているデータを共有されると、自分のアドバンテージが失われてしまう」など、相手に何らかの痛みが予想されたりする場合です。
他者と働く──「わかりあえなさ」から始める組織論
これは、単に「こうするほうが合理的だ」と主張しても解決しません。変化がもたらす恐れを相手が乗り越えることを可能にしていかなければ、物事が先に進まないからです。
これだけ知識や技術があふれている世の中ですから、技術的問題は、多少のリソースがあれば、なんとかできることがほとんどです。つまり、私達の社会が抱えたままこじらせている問題の多くは、「適応課題」であるということです。”
この文章を初めて目にした際、思い当たるフシが沢山ありました。
いくらロジカルに説明しても相手に受け入れられなかったケースや、逆に自分自身が相手を受け入れなかったケースです。
もちろん、当事者はその時時で「自分は妥当な判断をした」と感じているのでしょうが、さかのぼって考えると「問題」が解決したのか否かは記憶の闇の中です。
さて、それでは「適応課題」に対する解決方法はあるのでしょうか。
その答えは「対話」です。
「対話」と言っても、単純に「輪になって話し合う」や「飲みニケーションで本音を伺う」というものではありません。「対話」とは、「新しい関係性を構築すること」です。
さて再度、宇田川准教授の著書より対話についての一節をお借りします。
”新しい関係性とは、いきなりわかり合おうとすることではありません。
他者と働く──「わかりあえなさ」から始める組織論
先のクラウドサービス導入提案の例を考えて見るならば、提案を拒否されて腹を建てていたときは、「相手に自分の提案を受け入れさせよう」という関係性でした。しかし、相手にも相手なりに一利あって、その相手の状況の中で提案が「意味のあるものにすると考えられた時に、関係性の変化が始まっているのです。”
”組織とはそもそも「関係性」だからです。私たちは組織がモノとして存在しているように考えています。しかし、あなたが努めている会社を考えてみて下さい。そこには、人がいて建物はあっても組織はモノとしては存在せず、実は誰もそれ自体を見たことがありません。でも私達はその組織のために毎日出勤したり、会議をしたりします。
つまり組織の実質とは、実は私達を動かしている関係性そのものなのです。”
この様に文章を受け止めてみると、改めて自身の中で腹落ちする気がします。
確かに、どの様な環境でも起こる難しい問題は、決して技術的な問題だけではなく「関係性」の中で生じる問題が無数にあると。。。
まあ、このブログのゴールはワークフローで如何にミスを減らせるのかを説明する点にありますので、「技術的問題と適応課題」についての詳細は、引用元より書籍を購入いただくか図書館に走ってご確認下さいませ（笑）
さて、改めてなぜ今回「技術的問題と適応課題」を取り上げたのか。
その理由は、先の工学的アプローチの死角を補えるのではないかと考えたからです。
例えば「モラル不足」によるミスの発生。
これを単に「モラル不足」や「モチベーションが足りない」「会社に対しての帰属意識（ロイヤリティ不足）の問題」であると捉え、訓練や教育により修正しようと試みるとしましょう。
表面的にはそれなりの変化や進捗があるでしょう。
例えば、ミスした当事者の「反省」の弁や、「明るくなった」「積極的に質問するようになった」など見た目の行動変化です。
しかし、この当事者が、実は「表面だけ反省した・忠誠心があるように見せかけて対応しておこう」という腹づもりでいることは、想像に易いことです。
加えて、ミスをした当事者より何かしらの改善案の提案があったとします。
これをミスをした当事者の詭弁であると捉え、その提案を顧みない人もいるのではないでしょうか。
その背景には「こちら側は準備しているはずだ（システムとして対応しているはずだ。私はあなたよりこの仕事が長いので、そんなことは大したことではない）」などの、口には出さぬ抗弁が存在してはいないでしょうか。
この様な懸念は、実は物語の中ではなく現実の社会の中で常に孕まれていると考えます。
なぜなら、フラットなものの見方というものは、そもそも人間の意識構造上はありえないからです。（認知のバイアスは誰にでも有る）
その様な前提を踏まえず、「人間（人と人）」の理解を脇に置き、「システムだけ（仕組み。過去のプロセス）」で解決しようとすると何が起こるのでしょうか。
先に記載した「対話（新しい関係性の構築）」がなされない世界。対話をAPIでの通信よろしくINとOUTと捉える世界（聞いたことに答えよ！の世界）。
それは、人との関係性の上で何かを構築するのではなく、論理ベースでの判断が優先される世界なのでは無いでしょうか。
（要・不要で判断される世界）
実はこれは「ビジネス」の根本に大きく関係する問題でもあるんですよね。
殆どのビジネスでは「新規顧客」を必要としますが、それを「新しい関係性の構築」とみるか、技術的問題＝システム的な視点で「コンバージョン（プロセスの結果論）」として見るかでは、未来が大きく変わりそうな気がします。
ミスの原因とその解決を真摯に考える時、我々は工学的なアプローチのみならず、その根深さに向き合う意味で「関係性の中での解決」を試みるフェイズに入ってきている、その道が「真の問題解決」に対して開かれていると、私は考えます。
さてさて、長くなりましたのでまとめます。
過去の知識を借りるとして工学的アプローチによる課題概念の整理と分類、そして分類に応じた解決策は「それなりに」効果を奏すると考えます。
この効果を満足の行くものへと更に改善・昇華させていくには「適応課題」を意識し、工学的アプローチと並行して「新しい関係性の構築」を試みる必要があると考えます。
今回はここまで。
次のブログでは、いよいよまとめである「ワークフローシステムでミスを9割減」をご紹介していきます。
