"原因"と"対策"を特定するリテラシーについて

問題が起きたとき、私たちはよく「原因を突き止めて対策しよう」と言います。

仕事でも、組織でも、プロダクトでも、生活でも、体調でも、だいたい同じです。

売上が落ちた。

ミスが起きた。

人が辞めた。

会議が噛み合わなかった。

顧客が離れた。

業務が回らなくなった。

自分の調子が崩れた。

そうしたときに、「原因は何か」「対策は何か」と問う。

ただ、これが意外と難しい。

なぜなら、多くの場合、原因追求と反省が混ざってしまうからです。

「自分が悪かった」

「次は気をつけます」

「確認不足でした」

「もっと早くやるべきでした」

「コミュニケーションが足りませんでした」

こうした言葉は、反省としてはあり得ます。

ただし、それだけでは原因を特定したことにはならない。

原因を突き止めることと、反省することは別物です。

｜

｜

｜

｜

原因とは何か

原因とは、単なる悪者ではないです。

原因とは、その現象を再び生みうる、再現性を持った原点です。

つまり、

「何があったから、また同じことが起きうるのか」

「どの条件が揃うと、同じ方向に現実が流れるのか」

「何がその結果を生む力を持っていたのか」

を指すものです。

たとえば、人が忘れること。

これは原因になり得ます。

でも、人が忘れること自体をなくすことはできません。

疲れること。

焦ること。

都合よく解釈すること。

見落とすこと。

伝えたつもりになること。

現場ごとに事情が違うこと。

時間が経つと資料が古くなること。

言葉の意味が人によってズレること。

これらも全部、原因になり得ます。

でも、これらは基本的になくならない。

むしろ、なくならないからこそ原因です。

原因とは、消せる欠陥というより、現実の中に存在し続ける力です。

だから、原因を特定するとは、

「誰が悪かったか」を見つけることではなく、

「何があると、また起きるのか」を見つけることです。

｜

｜

｜

｜

原因追求と反省は違う

反省は、自分の態度や振る舞いを振り返る行為です。

それ自体は大事です。

ただ、反省だけで終わると、現実はあまり変わりません。

「次は気をつけます」

「もっと丁寧にやります」

「確認を徹底します」

これらは一見すると前向きですが、構造としてはかなり弱い。

なぜなら、次回の成功を人間の注意力や意志力に依存させているからです。

人間は忘れる。

人間は疲れる。

人間は慣れる。

人間は忙しいと雑になる。

人間は自分に都合よく見る。

これは怠慢というより、前提です。

この前提を無視して「気をつける」で済ませると、また同じことが起きます。

だから、原因追求とは反省ではない。

原因追求とは、再現条件の特定です。

何があると、また起きるのか。

どの順番だと、また崩れるのか。

どの情報がないと、また判断を間違えるのか。

どの状態になると、また雑になるのか。

どの関係性だと、また言えなくなるのか。

どの業務設計だと、また属人化するのか。

ここまで見に行くことが、原因を突き止めるということだと思います。

｜

｜

｜

｜

対策とは何か

では、対策とは何か。

対策とは、原因そのものを消すことではないです。

もちろん、消せる原因なら消せばいい。

壊れた機械が原因なら直す。

間違った設定が原因なら変更する。

不要な工程が原因ならなくす。

明らかなバグが原因なら修正する。

それはそれで大事です。

ただ、多くの本質的な原因は、そんなに簡単には消えません。

人は忘れる。

人は疲れる。

情報はズレる。

現場は変わる。

資料は古くなる。

判断はブレる。

責任は曖昧になる。

会議は形骸化する。

組織は部分最適に流れる。

これらを「なくす」のは無理です。

だから対策とは、

原因が存在しても、望ましくない結果まで到達しにくくするための設計変更です。

もっと言うと、

原因の影響力を弱めること。

原因の作用範囲を狭めること。

原因が悪い結果に流れ込む前に検知すること。

原因が発生しても回復できるようにすること。

原因が別の良い流れに変わるように道を作ること。

これが対策です。

｜

｜

｜

｜

「原因をなくす」は、しばしば理想論になる

原因がわかったときに、「じゃあその原因をなくそう」と考えたくなります。

ただ、これはしばしば理想論になります。

たとえば、ミスの原因が「確認不足」だったとします。

このとき、

「確認不足をなくす」

「確認を徹底する」

「各自が責任感を持つ」

だけだと、対策としては弱い。

なぜなら、確認不足はだいたい単体で存在していないからです。

忙しかった。

確認すべき項目が曖昧だった。

誰が見るべきか決まっていなかった。

確認しづらい画面だった。

差分がわかりにくかった。

間違ってもすぐに気づけない状態だった。

そもそもその作業が毎回変わっていた。

こうした条件が重なって、確認不足が起きている。

であれば対策は、

チェックリストを置く。

確認者を決める。

差分だけ見えるようにする。

エラーが出るようにする。

承認フローを変える。

入力欄を減らす。

作業前に必要情報が揃っているか判定する。

ミスが起きてもすぐ戻せる状態にする。

みたいな話になります。

原因を消すというより、原因が悪い結果を生むまでの流れを変える。

これが対策です。

｜

｜

｜

｜

原因と対策を四象限で見る

原因と対策の扱い方は、二つの軸で整理できると思います。

一つ目の軸は、見ているもの。

人の態度を見ているのか、再現条件を見ているのか。

二つ目の軸は、対応の仕方。

気持ちで対応するのか、構造で対応するのか。

｜

｜

｜

｜

1つ目

態度 × 気持ち

これは、反省の領域です。

「申し訳ありません」

「次は気をつけます」

「もっと頑張ります」

もちろん必要な場面はあります。

ただ、これだけでは再発可能性はあまり下がりません。

｜

｜

｜

｜

2つ目

態度 × 構造

これは、教育やマネジメントの領域です。

「この観点で確認してください」

「こういうときは相談してください」

「判断基準を共有します」

人の振る舞いを変えるために、言語化や型を置く。

かなり有効です。

ただし、まだ人間の理解や実行に依存します。

｜

｜

｜

｜

3つ目

条件 × 気持ち

これは、問題意識の領域です。

「たしかにこの状況だと起きやすい」

「忙しいと雑になる」

「情報が足りないと判断できない」

現象の構造には近づいている。

ただ、対応がまだ気持ちや注意に寄っている状態です。

｜

｜

｜

｜

4つ目

条件 × 構造

これは、原因追求と対策が接続している状態です。

「この条件が揃うと起きる」

「だから、この条件を検知する」

「この地点で止める」

「この情報を先に出す」

「この判断を自動化する」

「この時点で人に戻す」

「このログを残す」

「このズレをレビューする」

原因を再現条件として捉え、その作用を構造で変える。

この状態になってはじめて、原因と対策が仕事になります。

｜

｜

｜

｜

いい対策は、原因を否定しない

いい対策は、原因を否定しません。

人は忘れる。

だから、忘れてもいいようにする。

人は疲れる。

だから、疲れた状態で重要判断しないようにする。

情報は伝わらない。

だから、伝わったかどうかを確認できる形にする。

資料は腐る。

だから、現実とのズレを検知して更新する流れを作る。

判断はブレる。

だから、判断基準と判断履歴を残す。

現場は変わる。

だから、変化を前提に業務フローを代謝させる。

原因を「なくすべき悪」と見ると、現実を責めることになります。

でも、原因を「作用する力」と見ると、設計の対象になります。

この違いはかなり大きい。

｜

｜

｜

｜

原因は、過去の説明ではなく未来の仮説である

原因という言葉は、過去に向いているように見えます。

なぜ起きたのか。

何が悪かったのか。

どこで間違えたのか。

もちろん、それもあります。

ただ、原因の本当の価値は、未来にあります。

原因とは、

「このままだと、また起きる」

という仮説です。

だから原因が特定されると、未来の見え方が変わる。

この条件が揃うと危ない。

この順番だと崩れる。

この情報が欠けると判断がズレる。

この人にしか見えていないと属人化する。

この会議で決めても、現場には反映されない。

この資料は三ヶ月後には腐る。

原因とは、過去の犯人ではなく、未来の再発地点です。

だから原因追求は、過去を責めるためではなく、未来を操作可能にするために行うものです。

｜

｜

｜

｜

対策は、未来の現実を少し変えること

対策という言葉も、軽く扱われがちです。

「再発防止策を出してください」

「改善策をまとめてください」

「次回から注意してください」

でも、本来の対策はもっと重い。

対策とは、未来の現実を少し変えることです。

次に同じ条件が来たときに、同じ結果にならないようにする。

そのために、

入力を変える。

順番を変える。

権限を変える。

通知を変える。

画面を変える。

会議を変える。

ログを変える。

レビューを変える。

責任の置き方を変える。

人間とシステムの分担を変える。

そうやって、現実の流れを少し変える。

対策とは、反省文ではなく、設計変更です。

｜

｜

｜

｜

原因と対策のリテラシー

原因と対策を特定するリテラシーとは、結局のところ、

出来事を、責任の問題だけで終わらせず、再現性と作用範囲の問題として扱う力です。

このリテラシーが低いと、問題は毎回、人のせいになります。

あの人が悪い。

自分が悪い。

現場が悪い。

経営が悪い。

顧客が悪い。

タイミングが悪い。

もちろん、責任の話が必要な場面もあります。

ただ、それだけでは現実は変わらない。

一方で、このリテラシーがあると、問題は設計の対象になります。

どの条件で起きたのか。

どこで検知できたのか。

どこで止められたのか。

どこで弱められたのか。

どこで回復できたのか。

どこにログが残っていればよかったのか。

どこに判断基準があればよかったのか。

どこを人ではなく仕組みに任せるべきだったのか。

どこは逆に人間が見るべきだったのか。

こうした問いに変わる。

これが、原因と対策を特定するリテラシーだと思います。

｜

｜

｜

｜

仕事における原因と対策

仕事の中で起きる問題の多くは、単発の事故に見えて、実際には再現性を持っています。

営業資料が古い。

顧客理解が更新されていない。

見積もりの前提がズレている。

FAQが現実と合っていない。

KPIだけ見て顧客の温度感を見失う。

会議で決まったことが、実行の形に落ちない。

現場の工夫が、組織の資産にならない。

誰かの頭の中だけに最新事情がある。

これらは、ミスというより代謝不全です。

現実は変わっているのに、業務や資料や判断が更新されていない。

その結果として、ズレが溜まり、いつか問題として表面化する。

このときの原因は、誰か一人の怠慢ではないことが多い。

現実の変化を受け取り、業務や資料や判断に反映する流れがないこと。

これが原因になっている。

であれば対策は、

「ちゃんと更新しましょう」では足りない。

どの変化を検知するのか。

誰が受け取るのか。

どこに反映するのか。

どの資料が更新対象なのか。

何が変わったら通知されるのか。

更新されたかどうかを誰が見るのか。

古い情報が使われたときにどう気づくのか。

ここまで設計する必要があります。

｜

｜

｜

｜

原因を扱える組織

強い組織とは、問題が起きない組織ではないと思います。

問題は起きます。

人がいるし、現実が変わるし、事業が動いているからです。

むしろ、問題が一切起きない組織は、何も変化していないだけかもしれない。

大事なのは、問題が起きたときに、

反省で止まらず、

犯人探しで止まらず、

気合いで止まらず、

原因を再現性のある力として見つけ、

その力の作用を変える対策を置けることです。

原因を扱える組織は、問題が起きるたびに少し強くなります。

なぜなら、問題が起きるたびに、現実の見え方が増え、構造が更新されるからです。

逆に、原因を扱えない組織は、同じ反省を何度も繰り返します。

「次は気をつけます」

「確認を徹底します」

「連携を強化します」

この言葉が何度も出てくる組織は、原因を扱えていない可能性が高い。

｜

｜

｜

｜

あとがき

原因を突き止め、対策をする。

この言葉はとても普通に使われます。

でも、実際にはかなり高度な行為だと思います。

なぜならそれは、起きた出来事を、感情や責任や偶然の話から、再現性と設計の話へ移すことだからです。

原因とは、なくすものではなく、扱うもの。

対策とは、反省ではなく、作用設計。

起きた問題の中に、また起きる力を見つける。

その力が、望ましくない未来へ流れ込まないように、現実の流れ方を変える。

これが、原因と対策を特定するという行為だと思います。

問題はなくならない。

人も、組織も、現実も、ずっと変化し続ける。

だからこそ必要なのは、問題が起きない世界を夢見ることではなく、問題が起きたときに、それを次の設計へ変えられる視力です。

原因と対策のリテラシーとは、その視力のことだと思っています。