問題が発生した場合の対処法

仕事

問題が発生した場合の対処法

日々いろんな問題に直面しながらそれをどうにか解決に導こうと奮闘しているのは誰しもが変わらずに考える事かなと思います。その中でたまにどうも迷走してしまうことがあるな、ということへの自戒も含めて一度整理してみました。

迷走しているときのあるある


原因ではなく対策に走ってしまう

起こってしまった問題に対してとにかく早く解決しようと、原因を探る前に対策を考えてしまいます。もちろん、スピード優先でそれでよい時もあると思います。しかし、原因を見極める前に目先の対策に走った結果、より大きな問題になってしまった。という経験ないでしょうか。

原因が限定的になってしまう

ソフトウェア開発を例にしてみると、「〇〇APIが△△なため□□という不具合が発生」というのは直接的な原因であり、問題解決には欠かせない要素ではあります。ただ、「なぜ、〇〇APIが△△」だったのでしょうか?という疑問が残ります。

そこを見逃してしまうと、また同じような問題が発生しないでしょうか。

原因が曖昧になってしまう

発生した問題に対して「確認不足でした」というのが原因になってしまうパターンです。もちろん、確認不足なこともあるとは思いますが、それでは「なぜ、確認が不足したのか」もしくは「確認しようがなかったのか」ということを掘り下げる必要があるかもしれません。

他にも無数に存在しそうですが、一旦このあたりにしておきます。

問題が発生した場合の対処法


原因の切り分けが大切

まず最初に原因を見定めるということをすると思いますが、少なくとも原因は2つ以上存在すると思います。(3つ、4つともっと多くの原因が複雑に絡まりあっていることもあると思います。)

①直接的な原因
②真因(根本的な原因)

ソフトウェア開発を例に考えてみると、

①直接的な原因:
〇〇APIが△△なため□□という不具合が発生
②真因:
API活用箇所を示した設計書が無いことによる影響調査漏れ

例示で考えてみた場合に、①についてはすぐさま検討するでしょうし、対策も講じると思います。それで起こった事象に関してはもしかすると、解決するかもしれません。

しかし、②の真因を考慮してみると、①に対する対策でさらなる問題が発生する可能性すらある状態とも考えられます。その場合は非常につらいですが、問題発生→対策→対策を原因とする問題発生。というループに陥るかもしれません。

それを防ぐ(もしくは理解した上で冷静に対処する)ため、原因の切り分けが大切だなと思います。

対策は原因に直結することにする

先ほどの同じ例示で想定した場合に、①の対策は「〇〇APIの改修」ということは一つ考えられることとして出てくると思います。

その時に、「なぜ防げなかったのか」というような文脈でこのような対策が出てくるかもしれません。

対策:検証観点を追加する、ダブルチェックをする。

しかし、②の真因を考慮してみると「設計書が無いことによる影響調査漏れ」とあります。設計や企画時に想像だにしていなかった事象に対して、どのように検証観点を追加したり、ダブルチェックができるのでしょうか。

この場合は②の真因を踏まえ、「設計書を作成」したうえで、必要に応じて「必要な分の検証観点を追加」すると問題と向き合い解決に進めるのではないでしょうか。

と、自戒を込めて書き記してみました。


記事が気に入ったらサポートしてもらえると喜びます。いただいたお気持ちは大好きな海外旅行グッズの足しにさせて頂きます。

Amazonギフト券でサポートする



この記事が気に入ったら
いいね ! しよう

Twitter で
Tetsunori Yuasa

Tetsunori Yuasa

1983年9月8日 福岡県生まれ東京在住。住んだことがあるのは福岡・大阪・東京・ハノイ・名古屋。海外旅行、Netflix、漫画、寝ることが好き。詳細なプロフィール、旅した世界の写真たちまとめ、ご質問は質問箱まで。連絡先 tetsunori.yuasa@gmail.com

コメントを残す