この記事は、ソフトウェアテストアドベントカレンダー2022の1日目です。
人はミスをする。
そう思いながら生きているので、自分や他の人がミスをしても「まぁしょうがないかぁ」とよく思います。 そもそもミスっていうのは誰かが勝手に決めたことなので、ある状況ではミスだけどある状況ではミスではないってものですし。 ミスってただの行動でしかないですよね。
でもやっぱり「この行動はしたくないなぁ」と思ったりもします。 だけど、そういうときに「次はやらないように気をつけよう！頑張ろう！」とはならなくて、「なんでこの行動をしたんだろう？*1」「この行動をしたくなった理由はなんだろう？」を想像して、そこから「どうやったらこの行動をしたくならないだろう？」を考えることが多いです。 頑張ってもたぶんできないし、気をつけられないときもあるし。その行動をしたくなくなる方が良いなぁと思っています。
そんな折「うっかりミスはなぜ起きる―ヒューマンエラーを乗り越えて―」という本をたまたま読んでいたら、ミスの分類や発生条件について書かれていることを知りました。 この本には、ミスしたくなる心理やエラーそのものについての考え方やアプローチの方法など広く紹介されていて、読んでいてかなりグッときてこのブログを書き始めました。 グッときた部分はいくつもあったのですが、その中から「判断、決心の段階でのエラーを引き起こす『心理的心構え』」として分類された6個のミスについて、思うことをつらつらと書くことにしました。
判断、決心の段階でのエラーを引き起こす「心理的心構え」
判断、決心の段階でのエラーを引き起こす「心理的心構え」
① 懸命ミス
② 確信ミス
③ 焦燥ミス
④ 放心ミス
⑤ 多忙ミス
⑥ 無知ミス
引用元：芳賀 繁（2019年）『うっかりミスはなぜ起きる―ヒューマンエラーを乗り越えて』中災防ブックス(P38~P40）
① 懸命ミス
① 懸命ミス
作業者が組織に忠実で、まじめに任務を達成しようと懸命にのめり込んで発生するエラー。
忠実でまじめ。だからこそ起きてしまう、というミス。なかなか面白いですね。 自分も、たまになってるなぁって思います(別に自分が忠実でまじめですごいでしょ！とか言いたいわけじゃない)。 だけどこの状態に陥っていることは自分ではなかなか気づけないんですよね。
自分がやるのは、自分がチームメンバーにテストするシステムの使い方を説明するときに、チームメンバーから「なんでこの操作がいるの？」とか「この機能ってなんでいるの？」って言われて説明できない、みたいなケース。 聞かれる前まで、自分の中ではわかった気でいたんだけど、いざ説明しようとすると自分の言葉で説明できなくて、理由をあれやこれや考えて説明するんだけど、チームメンバーからは「全然ピンとこない」って言われる。 そして自分も、説明しながら「あれ、これ自分も全然説明できない」って気付いて、「じゃあちゃんとこの理由を聞いてみよう」となります。
自分以外のことを考えてみると、何か質問したときに「〇〇さんが言ってるからこれでいい」とか「お客さんがこう言ってるからOKです」って返ってくる場面もこれに当てはまりそうな気がする。 あとは、チケットの修正をする人が「テストチームからのチケットは全部書かれた通りに対応しないと！」って思ってそうなときもかなぁ。
「相手が言っていることは正しい！」と疑問を持つことができずに信じ込んでいる状態。 視野が狭くなっていて、捉え方によっては何も考えずに作業しているようにもなっているので危ないですね。
この状態のまま進むと危ないので、自分たちは「〇〇が言ってるから」っていうワードが出たら「ほんとに？」とか「□□のときそれだと困るかも？」って言ったりしています。 あと「チケットは一回全部読んでみてね」って言ったり提案系のチケットに複数の期待結果を書いたり。 視野がなるべく広がるようなことをやってるんだなぁって思いました。
② 確信ミス
② 確信ミス
熟練者やベテラン作業員が、一連の流れに従って習慣化された行動を、思考や意識的チェックなしに遂行し、まったく疑いもなく間違いの方向に突き進んでしまうエラー。
これありますねぇ。 当事者は、さも当然のように堂々と振る舞っているので、間違っていることに周りも気付かなかったりするので面白いですね。
自分がよくやるのはチケットの読み間違えや、チャットの読み間違えかなぁ。 特定のワードだけ見て「あぁ。このことか」って勘違いしたまま返事を返すと会話が噛み合わない。 「いや、たぶんそれじゃなくて…」って返してくれるので、すぐに会話して自分が勘違いしていたことがわかる、っていう感じ。
①の懸命ミスとも似てるなぁって思うんだけど、②の確信ミスは「はいはい、こんなもんでしょ。大丈夫大丈夫」みたいなまじめじゃないものが混ざっている気がする。
だけど、このミスはテストにはうまく応用しているときもあるなぁとも思います。 自分がシステムに慣れている状態で、新しいメンバーにテストに入ってもらったとき「この操作すると壊れたんですけど」みたいな感じで気付いてなかった不具合が見つかる。
テスターとして「慣れてきても、慣れてないようにテストする」ってやったりもするけど、それでも自分以外のメンバーが本当に新しい感覚でテストするとその鋭さには敵わないなぁって思います。
③ 焦燥ミス
③ 焦燥ミス
就業時間までに作業を完了してしまおうと焦ったり、交通渋滞に巻き込まれながら時間に間にあうようにといらだったり、タイム・ストレスが人間の冷静さ、慎重さを崩して、判断、決心を誤らせること。
これはとてもわかる。本当にあるあるだし、この6個の中だと自分は1番嫌いなミスです。 時間に追われると時間が気になってしまって、本当に気にしたいことがおざなりになってしまう。 しかもたちが悪いのは、このミスをしてしまうと「時間があったら」とか「余裕があったら」っていうどうしようもない言い訳をしたくなるし、個人的にはとてもつらい。 そしてチームメンバーにもこのミスをしてほしくないので、このミスを生まないように特に気をつけているなぁって思いました。
気をつけ方は、時間を気にしなくていいようにタスクを調整する。 当たり前のことだけど、これに尽きるかなぁ。 そして理由もないのに「このテストを2時間で終わらせてください」っていう本当に余計な時間の管理は絶対にしないし言わない。 テストするときに下手に時間を決めると、たぶんその人の中での優先順位が「時間通りに終わること」になってしまうので、「ここ気になるけど時間通りに終わらせないといけないから、確認しなくていいや」って気持ちが生まれやすくなるなぁって思います。 それに「2時間テストしてください」って言って1時間で終わったら、残りの1時間ダラダラとテストするのも違いますもんね。
もちろん、じゃあいつまでも無限にダラダラとテストしていいか？というとそうでもないので、焦らず気になることがなくなるまでテストする、という感じ。 この塩梅はチームメンバーのテストの雰囲気から想像したり、会話して確認しています。
④ 放心ミス
④ 放心ミス
単純作業の連続、単調作業、退屈な監視業務、心配事、疲労、睡眠不足などから意識水準が低下して起こるエラー。
「単純作業の連続〜」と「心配事/疲労/睡眠不足など」で要因は違うけど、1つのミスにまとめているのが面白いですね。 前者と後者で対策が違ってくる気がするけど、「どちらも意識水準が低下してる」と言われるとなるほど！となりました。 このミスも起こしたくないですね。 起こさないようにそれぞれ気をつけてるなぁと思いました。
単純作業の連続については、一気にやらない/一気に割り振らない、ペアでやるようにしています。 例えばローレベルテストケース(手順が細かく書かれているテストケース)を自分が作ると、どうしても確認項目が多くなってしまうんですよね。 それをチームメンバーにやってもらうんですが、「はい！このケース全部やってください！」ではなくて、「一旦ここまでやってください」って感じで切り取って渡す感じ。 場合によってはその他のケースを非表示にして渡したりもします。
あと、1人ではなく2人でやる。 2人になるだけで全然単純じゃなくなるんですよね。変なミスに気づけたり、他の不具合が見つかったり、サボりたくなってもサボれないし、逆に疲れてきたら休もうって言えるし。
「心配事/疲労/睡眠不足など」については、その日はもう仕事しないで って自分にもメンバーにも言う。 「いやいや、がんばります」って言ったり言われた時期もあるんだけど、その状況って普通の状態じゃないので、本当にミスするんですよね。 なんならミスしていることにも気づけなかったりしますし。
「普通じゃない状態でテストするとどういう行動になるのか？(自分がどういうミスをするのか？)」を知るというのが目的ならいいけど、それが目的じゃない状態でテストすると結果的に全員が困ることになりやすいですし。 これも終わったあとに「体調悪かったからしょうがないね」って言い訳したくなるので、嫌なんですよね。 なのでこういうときはチームでは潔く休むことにしています。
ただ、稀に休めない状況もあるので、そのときは体調不良であることを伝えた上でお仕事するようにしています。 これが隠されるといろいろとつらくなりますよね。
⑤ 多忙ミス
⑤ 多忙ミス
緊急事態、複雑な非定常状態、自動化装置の不具合などにより、突然作業量が増加し、時間的余裕がなくなり、判断の質が落ちたり、パニックに陥るためのエラー。
外から見ているとわかりやすいミスですよね。 「あの人忙しそうだからなにか見逃しているかも」って感じで。 このミスはあるあるだよなぁて思ったけど、自分のチームは、お仕事的にこのミスが発生する状況にはなりづらいなぁって思いました。 あるとするなら「なんとか今日中に終わらせて！」と差し込みがきたとかかも。
だけど、メンバーにまでこれに陥ってほしくないので、メンバーには自分がそれぞれ割り振って、多忙じゃないように言ったりします(もちろん、ヤバさとか伝えることもあるけどケースバイケース)。 あとは、この状態は弊社だとエンジニアがなりやすいかもしれない。 なので、そうなっている人をみたときには「これって大丈夫？」って聞いたり「ひとまず落ち着こう」って言ったりもするかなぁ。
あ、意外と会議中になることはあるかもしれない。 情報や議論がありすぎて頭の中が多忙になる。こうなったときは良い結論があんまり出てない気がする。
多忙にならないようにいろいろ対策するけど、それでも多忙になるときはあるので、そうなったら「多忙である」っていう自覚があるだけでも少し対策できるかもしれない。 どうやって自覚するかは…メンバーに言ってもらうとかかなぁ。 自分でこの状態に気付くのは難しそう。
⑥ 無知ミス
⑥ 無知ミス
知識、理解が不足しているために起こるエラー。教育、訓練、経験が不足している未熟練者だけでなく、省人化で一人の作業者に幅広い知識が要求されたり、新しいハイテク機器がつぎつぎに導入されるため、ベテランでもこのタイプのミスを起こす可能性が高くなってきました。
ミスって聞いたときに多くの人が思い浮かべそうなミスだなぁって思いました。
でもこのミス、テストにうまく応用しやすいですよね。 うちのチームではこのミスは実は結構役に立っていることが多いです。 テスト対象のシステムを説明してもらってからテストに入るのですが、システムをわかってないからこそしてしまう操作があるし、そこで不具合が見つかる的なやつ。 もちろん「無知」に頼るだけじゃなくて「無知な人が触ったらどうなるだろう？」を考えながらのテストももちろんしますが、やっぱり本当に知らないことが多い状態には敵わないなぁって思います。
この無知ミス、②の確信ミスと合わせて面白いなぁって思うのは、知らなくてもミスするし、知っていてもミスするっていうところ。 知っていたら大丈夫、でもないし、知らなかったら大丈夫ともならないのが「そうだよなぁ」としみじみ思いました。
自分がテストしているとき、自分に対しても他のメンバーに対しても「今どれくらい慣れているのか？どれぐらい不慣れなのか？」は気にしている気がします。 それを考えてテストを割り振ったりしています。
おわりに
ただただ思うことをつらつらと書きました。 「どんなミスをするか、ミスが生まれない状況にするにはどうしたらいいか」という自分の行動についての考え方だけでなく「『◯◯ミスが起きそうなとき』のことを考えてテストする」と考える参考にもなっていいですね。 この本がかなり面白かったのでなんか思ったことを書きたかったんですよね。 まだまだ書きたいことはあるけど今回はこれくらいにします。 まとまりのないブログを読んでいただきありがとうございました。
他にも「エラーをおかしやすい人」「誤りに強い人と弱い人」「錯覚は正常覚」などなど個人的にとてもおもしろいことが書かれていたのでぜひ読んでください。
*1:「この行動が生まれた背景にはどういう要因があるんだろう？」っていう意。責めているわけではないし、責任には興味がない。
