どうも、最近残業多かった男です。
５月病を乗り越えました。
今回はズバリミスについてのお話です。
次は気をつけようではミスは減らないは科学的に正しい
参考文献[1]では、間違いを犯さないように注意を促すなど人々を変えることに重点を置いた解決策は、間違いを助長する環境がそのまま残っているため、ほとんど効果がないと結論付けています。気をつけてね！という人任せではミスは減らないんですね。このため別の戦略が必要となります。
エンジニア用のミスを減らす戦略とは？
実はミスとかエラーに関しての研究は結構認知心理学では盛んなんだそうです。このため戦略も豊富といえば豊富なんですが、認知心理学の枠組みだけだと「マルチタスクをやめよう！」とか「睡眠時間は○時間以上取ろう！」というのが大半です。私なんかはこれを逐一気をつけていますが、いまいちミスが減らないんですよねぇ。
そんなわけで結構困っていたんですが、この度ようやく「エンジニアでのミスを減らすには？」という研究論文が見つかりましたのでご紹介します。要件定義なんかでミスってしまうエンジニアの方はご参考にしてください。
この研究は2016年に10カ国で行われ、エンジニアの現場で起こるエラーを分類し、それぞれに適した戦略を調査しています。具体的な方法については詳しく説明すると長くなるため、結論を先に述べますと、
エンジニアのエラーは以下の3つに分類されます。
人的エラー
プロセスエラー
環境エラー
ここいらはある程度イメージしやすいのではないでしょうか。
また個別の戦略ですが、こちらは以下にまとめています。
1. 人的エラー
(a) 内部研修活動: 例えば（スキルやパフォーマンスの向上を目的とした）研修の企画・実施など。
(b) 内部エンカレッジ: チームを勇気づけ、指導し、何を行う必要があるかを認識させることによってチームを変える。
(c) 外部トレーニングおよびコーチング活動:トレーニング/コーチング/コンサルティングとか。
2. プロセス
(a) 調査: 何をすべきかを特定することによるプロセスの変更
たとえば、ツールの評価やプロセスのギャップの特定など。
(b) 改良と再設計: 以下によって引き起こされるプロセスの変化:
b-a) 新しいプロセス、ツール、またはアプローチの導入による環境の変化。
b-b) 必要に応じて既存のプロセスを改良または変更する。
b-c) 変更されるプロセスの一部として既存のプロセスを実装する。
(c) 役割と責任の定義: 既存の役割と責任をより明確に定義することにより、プロセスの変更を促す。
(d) リソース割り当て: 正しいイベントに正しいリソースを割り当てることによるプロセスの変更。
3. 環境
(a) 新しいプロセス、ツール、またはアプローチの追加
(b) 要員の追加: そのサブプロセスの作業に通常関与していない要員の追加による環境の変化。
(c) 構造の追加: 特定のプロセスに対応するための標準またはテンプレートを定義または作成することによる環境の変更。
例えば品質基準の定義や仕様テンプレートの作成などです。
(d) 新しい役割の追加: 既存のチームメンバー間で適切な役割と責任を定義することによる環境の変化。
例えばチームリーダーを任命したり、マネージャーを紹介したりします。
まとめ
というわけで今回はエンジニアのエラーについて紹介しました。全く関係ないんですけど、残業代は肩こり解消のマッサージで消えました。。
以上！！
www.mathlikeb.com
参考
[1]Our current approach to root cause analysis: is it contribut- ing to our failure to improve patient safety?
[2]Human Error Management in Requirements Engineering: Should We Fix the People, the Processes, or the Environment?
