2024年が始まって早々様々なことが起きている。
その中で起きたとある事件について考えてみたいと感じ、一般論としてnoteを書いていこうと思う。

失敗は悪か？

本記事を書くにあたり、とある本を読んだ。失敗の科学という本だ。

内容を簡単にまとめると、失敗を題材に人がどのような考えを持ち、行動するのかについての細かな分析結果が記載してある。
要約記事を見つけたので、詳細は以下を参照してもらえれば分かるかと思う。

本書において重要なのは失敗は悪か、善か、どちらに捉えるか、だと思う。
結論から言えば、失敗を善と捉えて、その失敗から学ぶべきである。
しかし、人間の心理上、失敗は概ね悪と捉えられやすい。特に、その失敗が人命に関わるものであればなおさらである。

近年のSNSの発展と、その匿名性という特徴によって、この心理は加速しているように思える。
悪は正さねばならぬ。太宰治の描くメロスのように、人は無意識に正義心を発揮してしまい、人の失敗を批判してしまう。

失敗に目を留めて、それを問題視すること自体は間違っていない。ただ、失敗から学ばず、それを当事者の責任問題のみに収束してしまう事は本当に恐ろしい。

システム開発における失敗

システム開発という業務においても似た問題が起こる。

システムの納品間近、試験段階で重大なバグが見つかる。
よく見ると、思ったより初歩的なミスによって発生していることも多い。
そんな時、開発チームの面々が取る行動は二つある。

一つ目は、担当者への批判である。
誰がこのバグを埋め込んだのか、犯人捜しをはじめる。

二つ目は、そのバグの改善案の検討である。
バグの根本原因が何かを突き止め、対策を打つ。
どのような手順でバグフィックスを行い、後段のスケジュールへの影響を算出して、スケジュール上問題がないかを考える。

チーム内部で二つの行動で割れる上、個々人単位でも3割程批判したい気持ちを持ちつつ改善案を考える事もある。
個人的な感覚では、成熟している組織ほど、後者の割合が増える印象だ。

ただ、システム開発をしている以上、開発チームは当事者なので問題をクローズさせるしかない。批判していても、結局は改善案を考えることになる。

システム運用における失敗

システムを開発する、というのは記述問題を解くのに近い。
無数にある選択肢の中から、要望に応じた機能を実現する方法を揃え、連携させて、正しく動くことを証明する結合試験を行う。
それらを出題者であるクライアントへ提出して、正解と判断されれば納品となる。

ただ、システム運用においては異なる。
運用時には、ほぼ間違いなく想定外の事態が起こる。試験では確認していない動作が発生して、大小はあるが問題が起こる。

問題ないと運用開始したシステムにおいて、想定と異なる使い方をされた。
結果として、大きな事故につながる。さて、これは失敗か。
結論から言うと、やはり失敗である。

さらに言えば、システムを運用し始めるとステークホルダーが増える。
開発者・発注者に閉じず、システムのユーザや、それ以外の人にも目につくようになる。

この時、設計時と同様に、二択の選択を迫られる。
多くの場合、当事者(開発者)以外の人は批判を行う。失敗を悪だと思うのだ。

人は間違える

本題に戻り、失敗の原因は何かを追究してみる。

システムの用法に問題がある場合はないだろうか。

例えば、本来は禁じられている操作を実行してしまう。
二つの異なるシステムを操作する際に、同時に動かすと問題が起こることがある。システム単体では働く安全機能も、システムを超えてしまったら働かない。
人の間違いによる想定しない運用によって、問題が起こるのだ。

ただし、ユーザ側にも限界がある。
注意不足や体調などの要因も存在するし、そもそもシステムの動作を把握して適切に運用できる人員は限られる。
ユーザのミスは少なくすることはできても、無くすことはできない。

フールプルーフという考え方

システムを作る上でフールプルーフという言葉が存在する。
この言葉は、人がミスをしようとしてもできないようにする工夫、を指す。
主にユーザ側の操作ミスへの対策となる考え方である。

例えば、先述の二つのシステムの同時操作によって問題が起こる場合は、そもそも片方のシステムしか動かない仕組みをシステムに導入する、などである。
基本的にユーザを信用せず、至る所に安全装置を仕込むのである。

しかし、これにも限界がある。

システム開発の限界

設計段階で想定できない使用法への対処(フールプルーフ)は実装できない。

そもそも、フールプルーフを実装するには、失敗に習い対策を入れる必要がある。
例えば、他システムとの連携に問題が発生した過去の事例を参照して、安全装置となるシステムが同時に動かない仕組みを導入するなどである。

ここで話が循環し始める。

ユーザの誤操作対策にはフールプルーフが必要だが、フールプルーフには過去の事例(失敗)が必要となる。
両者は両輪で回っていて、新しい誤りが見つかれば新しいフールプルーフが実装される。

すなわち、新たな失敗は次の失敗に向けて学ぶべき事例と言える。
誰かが失敗するまで、その失敗への対策は実装できない。

結論

やはり、以下に収束する

失敗を善と捉えて、その失敗から学ぶべきである。
失敗に目を留めて、それを問題視すること自体は間違っていない。ただ、失敗から学ばず、それを当事者の責任問題のみに収束してしまう事は本当に恐ろしい。

ここから先は、個人的に今後気を付けたいこと。

もちろん程度は存在するが、誰かの失敗は改善策を検討する機会として受け止めたい。誰かを批判するより、前向きに捉えたい。
さらに言えば、自身の失敗についても素直に認め、改善策を皆にも考えてもらう機会にしたい。

人の失敗には寛容に、自分の失敗には厳しく。

ただし、第三者の目が入らない組織・体制は腐りやすい。
当事者以外の目が入り、適度な緊張を生みつつ、失敗を改善する力が働く方が良い。

このため、私もSNSの1ユーザとして、自分の業界に近い問題については、あるべきシステムの形を見据えながら建設的な意見が出せるように勉強を続けたい。

※結局、失敗の科学と同じことを言っているような気がする。