はじめに
前回の記事の続きで、今回は再発防止の仕方について紹介したいと思います。
何か問題が発生し解決したら、今後同様の問題が起こらないように防止策を考える必要があります。ここでは、なぜなぜ分析を使用して再発防止策を考えるテクニックについてプロが紹介します。
なぜなぜ分析を行って再発防止を行う
なぜなぜ分析とは発生した問題に対して、なぜ問題が発生したのかという要因を導き、その要因に対して再びなぜ問題が発生したのかを繰り返すことで根本的な原因を導く手法となります。色々とテクニックがあるかと思いますが、私が行っている不具合の再発防止向けのなぜなぜ分析のテクニックを紹介します。
マインドマップ作成用のツールを準備する
なぜなぜ分析を行う際は、頭の中の考えていることを整理するためにマインドマップを使用します。そのため、マインドマップを作るためのツールを準備します。
何でもいいですが、FreeMindやFreeplaneというツールがお勧めです。これらのマインドマップのツールには、クエスチョン❓や電球💡を入力することができるので、このアイコンをノードの頭に設定することで「質問」なのか、「回答」なのかが分かるようにできます。
最初に発生事象を書く
一番最初の出発点として問題の事象を記載します。最初に書く事象によって、話の広がり方が変わり、再発防止策を打つ観点が変わってきてしまうため慎重に設定する必要があります。
例がないと分かりにくいため、ここでは最近あった「うるう年で免許証発行が行えなかった」という話を例に想像して考えていきます。
再発防止策は不具合を修正後に行うためプログラム上のバグが発見できたという時点で行います。逆に言えば不具合の真の原因が分からないと、正しい再発防止は行えません。どうしても応急的に再発防止策を考えるなら時限式とかにする必要があります。話が少し脱線しましたが、この再発防止を行うタイミングの都合上、なぜなぜ分析で発生事象を、「うるう年の計算方法が誤っていた」と書いてしまいがちです。しかしこのように設定してしまうと場合、なぜなぜ分析の話の広がりが限定的になってしまい、発生要因の見落としが発生します。
よって発生事象の記載内容はより上位の問題を記載する方がよく、不具合に遭遇した当事者目線で記載することがベストとなります。ただし当事者と言っても、運転免許を取得しに来た住民、あるいは免許証を発行しているオペレータなど色々な視点があり、あまりにかけ離れた事象を設定したとしても再発防止策との関係は薄くなります。そこで、ここでは「オペレータが免許証を発行できなかった」で進めていきます。
項目に対して対となる質問を作り回答を考えることを繰り返す
「オペレータが免許証を発行できなかった」という質問に対してなぜなぜをしていきます。ここでは、対となる質問を作るため、「なぜ免許書を発行できなかったのか」という質問になります。
- オペレータが免許証を発行できなかった
- ❓なぜ免許書を発行できなかったのか
そしてこの質問に対して回答を作り、また質問を行うことを繰り返します。
- オペレータが免許証を発行できなかった
- ❓なぜ免許書を発行できなかったのか
- 💡ソフトウェアが使用できなかったため
1つの問題に対して、Qが複数あってもかまいませんし、Qに対して複数のAがあってもかまいません。
以下はコツや注意事項となります。
近道をしないこと
ありがちミスとして項目を飛ばして「なぜソフトウェアが使用できなかったのか」のように項目を作ってしまうことです。
- オペレータが免許証を発行できなかった
- ❓なぜソフトウェアが使用できなかったのか
できる限り分かる範囲で一歩一歩進めていくことが肝心です。ここの抜けの中に、実は本来の問題が抜けている可能性があるかもしれません。例えば、「ソフトウェアが使用できなかったため」という1つを入れることで、なぜそのソフトウェアが必要なのか見直す機会になります。
- オペレータが免許証を発行できなかった
- ❓なぜ免許書を発行できなかったのか
- 💡 ソフトウェアが使用できなかったため
- ❓なぜソフトウェア使用できなかったのか
- ❓なぜソフトウェアが使用できないと免許証が発行できないのか
とはいえ、気が付かずに近道してしまうことがあるかもしれないため、ここでは近道をしないあるいは近道していないかチェックする方法をいくつか挙げます。
- ツリーの下位から上位へ向かって、「～だったらか～である。～だったから～である」と文章を声に出していき読んでいき不自然ではないかを調べます。話の飛躍があったりした場合は、間に何か隠れていることになります。
- 1つのノードの文章が長すぎると要注意です。できる限り短く簡潔にすることで近道が発生しないようになります。
- 結論ありきで考えないことが大事です。
- 例えば上からの圧力で再発防止がこうだと言われた場合に、どうしても仕事上そこに向かうようななぜなぜ分析をする必要が出てくるかもしれないですが、本当はよくないのです。
事実を書くこと
当時の担当者がいないとか資料が残っておらず覚えていないというのはよくある話だとは思います。その場合は、想像で書く場合もありますが、その場合は分からないと明記したうえで想像で記載するということを書くことが必要だと考えます。
再発防止策の中で、なぜなぜ分析の結果を第３者に見せる場合がありますが、想像で書いてある部分については、なぜなぜ分析の作成者があくまで考えていることであるため、こういった可能性もあるという展開も進めることが可能となるのです。
- 💡関数の戻り値をチェックしていなかったため
- ❓なぜ関数の戻り値をチェックしていなかったのか
- 💭不明なため想像で記載
- 💡エラーが起こると思っていなかった
- 💭不明なため想像で記載
- ❓なぜ関数の戻り値をチェックしていなかったのか
流出の観点を加えること
不具合の要因は、大まかに流入要因と流出要因という２つの観点に分類されます。
例えば、流入がAPIリファレンスを確認していなかったことで異常な戻り値に対するエラー処理を考慮できていなかった。流出は単体試験レベルで見つけるべき問題であり、発生頻度が低くその後の試験では発生しなかったため流出につながった。など不具合を入れてしまった要因と、なぜ入れてしまった不具合に気が付かずにリリースしてしまったという流出の2つの観点です。
不具合の再発防止策を考えるには、上記の流入の観点と流出の観点の2つから考える必要があるため、その再発防止策を考えられるようになぜなぜ分析の適当なタイミングで「❓なぜ不具合が見つからなかったのか」のような質問を枝として追加することで流出の観点からでも洗い出しが行えるようにしておきます。
- ❓なぜ不具合が見つからなかったのか
- 💡 試験で発生しなかったため
- ❓なぜ試験で発生しなかったのか
- 💡試験工数が足りなかったため
- ❓なぜ試験工数が足りないのか
- ❓なぜ試験工数が足りていなくてもリリースできたのか
- 💡試験書に試験項目として記載していなかったため
- ❓なぜ記載していなかったのか
- 💡そのような観点がなかったため
- ❓なぜ観点がなかったのか
再発防止策も考えつつ作ること
この次の章でなぜなぜ分析の結果から、要因と再発防止策を考えていきます。
なぜなぜ分析は観点を広げることで、永遠に続けることも可能です。ただ結局のところ目的としては再発防止策があるわけなので、現実的に難しい内容などを進めても意味がありません。そういった場合は💡を記載せずに止めてしまってもいいかと思います。そういった枝は🚫のマークでもつけておきましょう。
再発防止の観点から、個人の問題にするというのは難しいです。この理由は再発防止がそのあとに繋がりにくいためです。例えば教育するといった方法もとれますが、教育したら100%防げますか、それはこれから先問題は本当に起こらないんですか、という形になります。とはいえ手順に落とし込んだとしても守れない手順なら意味がないですし、工数が増えることに繋がるので、一長一短があります。
このあたりは会社の方針にもよるかと思います。再発防止策は手順書に落とし込むか、教育にとどめるかという方向性があるかと思います。上司が強い現場なら必ず先に確認しておきましょう。
流入当時の状況を考えること
流入というのは不具合を作り込んだ時期のことを言うのですが、この当時の状況を踏まえた分析が必要です。「❓なぜ防げなかったのか」「💡当時の手順では〜ルールだったため」のように現在と過去を区別して考えます。
これを考慮しておかないと後の再発防止を決定する際に、なぜ再発防止策が既にあるのにまた発生してるのか、もっとチェックリストを強化しようと過剰な再発防止策が増える要因になります。
要因と再発防止策を決定する
上記で作成したなぜなぜ分析のツリーが完成していると思います。以下は適当に作ったサンプルですが、こんなイメージです。実際はもっと大きく深くなります。
この中で、再発防止が現実的に行えそうな流入要因と流出要因を最低1つずつ決めれば、要因分析と再発防止策が完成します。
再発防止策の種類
再発防止策の種類と落とし込んだ時のメリットとデメリットをまとめます。
チェックリスト
- メリット
- 確認すべき項目が明確化されるため、作業者が漏れやミスを防げる
- 簡単に作成・更新でき、使いやすいため、すぐに現場での実践できる
- 作業の標準化が促進され、一貫性と再現性のある作業が可能になる
- デメリット
- チェックリストが網羅的でない場合、重要な項目を見落とす可能性がある
- 過度に依存すると、チェックリストにない問題への対応力が低下する
- 定期的な見直しや更新が行う必要がある
手順書
- メリット
- 詳細な作業手順が文書化されることで、作業者のスキルレベルに依存しない一貫した品質が保証できる
- 新しい作業者の教育や研修が容易になり、短時間で作業を習得できる
- 不具合が発生した際の対応手順が明確になるため、迅速な対応が可能になる
- デメリット
- 詳細な手順書の作成と維持管理には多大な労力と時間が必要となる
- 過度に詳細な手順書は作業者の柔軟性を制限し、創造性を奪う可能性がある
- 定期的な見直しや更新が行う必要がある
教育
- メリット
- 作業者のスキルや知識が向上し、問題解決能力や自主的な改善活動が促進される
- チーム全体の意識が高まり、組織全体としての品質向上が期待できる
- デメリット
- 継続的な教育が必要になる
- 教育の効果を測定することが困難である
人の移り変わりが多い場合は教育のコストが高くなると思います。とはいえ、チェックリストや手順書や作業工数が増えるという問題があります。一長一短がありますし、部の方針もあるため上司と相談しながら考えてみるといいと思います。
ちなみに個人的な私の考えとしては次のようなものを選択します。
- QCDを考えた現実的な再発防止を考える
- 現実的に可能な再発防止だがコストに見合っていないものはやめる
- できる限り人に依存させない
- 教育もいいのだが、人の移り変わりが多いと現実的ではなくなる。とはいえ手順書にすべて落とし込むと現実的ではない工数が発生しうる可能性がある。そこで、チェックリストに落とし込み、不具合の発生例も記載しておくことで、読んだ人に想像の余地を与える
- チェックリストが増えないように、どうようの問題であれば１つのチェックリストにまとめる。ただし不具合事例の記載のみ増やしていく
その他注意点
再発について
過去に流入したものであれば既に再発防止策が練られているかもしれません。そういった場合は事例展開のみで留めるのもいいと思います。なぜまだ問題が発生するのかという話になる場合は水平展開という別の話になるかと思います。
真の不具合原因が分かっていない場合について
真の問題が分かっていないのに再発防止策を求められることはあると思います。そういった状況でも再発防止策を考えることは可能です。ただ真の原因が分かった時点でその再発防止策は検討し直すことが必ず必要です。
背景の記録について
再発防止策を作る際に背景も記録として残すことが大切です。再発防止策は増やすのは簡単ですが増えれば工数が増えることに繋がりますし見直しが必要となります。その際に、背景が記載されていれば今の手順なら関係がないとして消すことができます。
おわりに
お疲れ様です。再発防止の作り方としてなぜなぜ分析の方法を紹介しました。次は、障害に強い設計編についても記事にできたらいいなと思います。
コメント