日々いろんな問題に直面しながらそれをどうにか解決に導こうと奮闘しているのは誰しもが変わらずに考える事かなと思います。その中でたまにどうも迷走してしまうことがあるな、ということへの自戒も含めて一度整理してみました。迷走しているときのあるある原因ではなく対策に走ってしまう起こってしまった問題に対してとにかく早く解決しようと、原因を探る前に対策を考えてしまいます。スピード優先でそれでよい時もあると思います。原因を見極める前に目先の対策に走った結果、より大きな問題になってしまった。いう経験ないでしょうか。原因が限定的になってしまうソフトウェア開発を例にしてみると、「〇〇APIが△△なため□□という不具合が発生」というのは直接的な原因であり、問題解決には欠かせない要素ではあります。「なぜ、〇〇APIが△△」だったのでしょうか?という疑問が残ります。そこを見逃してしまうと、また同じような問題が発生しないでしょうか。原因が曖昧になってしまう発生した問題に対して「確認不足でした」というのが原因になってしまうパターンです。確認不足なこともあるとは思いますが、それでは「なぜ、確認が不足したのか」もしくは「確認しようがなかったのか」ということを掘り下げる必要があるかもしれません。他にも無数に存在しそうですが、一旦このあたりにしておきます。原因の切り分けが大切まず最初に原因を見定めるということをすると思いますが、少なくとも原因は2つ以上存在すると思います。(3つ、4つともっと多くの原因が複雑に絡まりあっていることもあると思います。)1直接的な原因2真因(根本的な原因)ソフトウェア開発を例に考えてみると、1直接的な原因:〇〇APIが△△なため□□という不具合が発生2真因:API活用箇所を示した設計書が無いことによる影響調査漏れ例示で考えてみた場合に、1についてはすぐさま検討するでしょうし、対策も講じると思います。それで起こった事象に関してはもしかすると、解決するかもしれません。2の真因を考慮してみると、1に対する対策でさらなる問題が発生する可能性すらある状態とも考えられます。いうループに陥るかもしれません。それを防ぐ(もしくは理解した上で冷静に対処する)ため、原因の切り分けが大切だなと思います。対策は原因に直結することにする先ほどの同じ例示で想定した場合に、1の対策は「〇〇APIの改修」ということは一つ考えられることとして出てくると思います。その時に、「なぜ防げなかったのか」というような文脈でこのような対策が出てくるかもしれません。対策:検証観点を追加する、ダブルチェックをする。2の真因を考慮してみると「設計書が無いことによる影響調査漏れ」とあります。設計や企画時に想像だにしていなかった事象に対して、どのように検証観点を追加したり、ダブルチェックができるのでしょうか。この場合は2の真因を踏まえ、「設計書を作成」したうえで、必要に応じて「必要な分の検証観点を追加」すると問題と向き合い解決に進めるのではないでしょうか。自戒を込めて書き記してみました。若者は夢を見て、老人は回想する。福岡県生まれ東京在住。Netflix、ゲーム、漫画、寝ることが好き。詳細なプロフィール、旅した世界の写真たちまとめ。湯浅哲徳:海外旅行、Netflix、ゲーム、漫画、寝ることが好き。詳細なプロフィール、旅した世界の写真たちまとめ。YUATETSU.IN。