物理的欠陥による不具合ならば、欠陥をもたらす物理現象を追及すればその欠陥を防ぐか、その影響を軽減することが出来る。しかし、最近のシステム(ここではコンピュータシステムを念頭においていているが、もっと一般的なシステムについても以下の論議は成り立つ)は巨大化したことで完璧な知恵が隅々までまわりかねるからであろう、人智(具体的な例としては、ソフトウエアやシステムの運用)のミスによる重大な不具合が目立つ。不注意を責めることは簡単だが、注意深くすればミスがなくなるといったレベルを超えてシステムが複雑になっているところに、問題の深刻さがある。
人間は無知による誤りを犯す。これは低次元の話で、論外である。たとえ知っていたとしても、状況を見落としたり、理解や認識が正しくなかったり、論理的思考を組み立てる時に正しい演繹を踏み外す、といったこと等で誤りを犯す。人間はこのような知的ミスを絶対に犯さないと想定するのはナンセンスである。人間は必ず誤りを犯す。
脳の営みも生理化学的な物理現象であるから、その物理現象を調べることで、人智の誤りを防ぐことが出来る、と言えなくもない。しかし、残念ながら、脳の生理化学的研究はそれほど進んでいない。現在のところ、物理的アプローチで人智の誤りを防ぐことは絶望的である。やはり、人智の誤りは防ぐことが出来ないのであろうか。
ハードウエアの誤り対策を考える場合、色々調べて物理的な故障(フォールト)のモデルを定め、そのモデルに基づいて方策を考える。そうであるなら、人智の誤りについても、そのモデルを定め、それに応じた方策が考えられるのではないか。したがって、人智の誤りのモデル化についてもう少し力をいれて研究すべきである。
これまでも、大事故(たとえば、航空機事故)につながったかもしれない小さなミスを報告させ、それを参考にして再発防止策を定める、と言うようなことがいわれている(最近、JR西日本もそのような対応をするといっているが、何をいま頃、という感は否めない)。しかし、個々の誤りの事例を単に集積するだけでは、そこでの経験が他の状況に必ずしも活かせない。大切なのは、個々の事例から人智の誤りを類型化し、その相対的な頻度を定めることである。、人智の誤りの類型としては、周囲との適合条件(たとえば、着目するプログラムモジュールと他のモジュールとのインタフェース条件や、適用範囲)を見落とす、早合点する、理解できていない、論理を踏み外す、などのパターンが考えられる。あるいは、これらのパターンの階層的な位置づけも必要であろう。人智の誤りのtaxonomyがあってよい。そうすれば、個々の場で、それぞれの誤りパターンとその相対的頻度に基づいて、具体的なチェックポイントを定めることができる。そのチェックポイントについて逐一確認することで、人智の誤りを完全に無くすことは出来ないにしても、減らすことが出来ると思われる。システムの開発者からユーザにシステムが引き渡されるとき、それぞれのチェックポイントの確認を文書化して示すことも重要であろう(その後の新しい不具合を検討する際に役立つ)。
誤りは恥と言う意味合いもあるから、誤りを報告する(一歩進めて、公表する)ことには抵抗感がある。銀行システムの不具合、東証システムの不具合などの詳細は知られていない。過去の人智の誤りを集積し、パターン化して、それを広く世に知らしめなければ、過去の教訓は得られない。
私はこれまで、同じことを重ねて言わない(古くなったことを二番煎じに繰り返さないという意味合いをこめて)ようにしてきた。しかし、最近、同じことを何度も繰り返し言ううことの重要性を改めて認識し始めている。そう、同じことを言おう。航空機事故調査委員会だけではなく、影響が大きい公共的な情報システムについいぇは、第三者による事故調査委員会を設けるべきである。(青)
人間は無知による誤りを犯す。これは低次元の話で、論外である。たとえ知っていたとしても、状況を見落としたり、理解や認識が正しくなかったり、論理的思考を組み立てる時に正しい演繹を踏み外す、といったこと等で誤りを犯す。人間はこのような知的ミスを絶対に犯さないと想定するのはナンセンスである。人間は必ず誤りを犯す。
脳の営みも生理化学的な物理現象であるから、その物理現象を調べることで、人智の誤りを防ぐことが出来る、と言えなくもない。しかし、残念ながら、脳の生理化学的研究はそれほど進んでいない。現在のところ、物理的アプローチで人智の誤りを防ぐことは絶望的である。やはり、人智の誤りは防ぐことが出来ないのであろうか。
ハードウエアの誤り対策を考える場合、色々調べて物理的な故障(フォールト)のモデルを定め、そのモデルに基づいて方策を考える。そうであるなら、人智の誤りについても、そのモデルを定め、それに応じた方策が考えられるのではないか。したがって、人智の誤りのモデル化についてもう少し力をいれて研究すべきである。
これまでも、大事故(たとえば、航空機事故)につながったかもしれない小さなミスを報告させ、それを参考にして再発防止策を定める、と言うようなことがいわれている(最近、JR西日本もそのような対応をするといっているが、何をいま頃、という感は否めない)。しかし、個々の誤りの事例を単に集積するだけでは、そこでの経験が他の状況に必ずしも活かせない。大切なのは、個々の事例から人智の誤りを類型化し、その相対的な頻度を定めることである。、人智の誤りの類型としては、周囲との適合条件(たとえば、着目するプログラムモジュールと他のモジュールとのインタフェース条件や、適用範囲)を見落とす、早合点する、理解できていない、論理を踏み外す、などのパターンが考えられる。あるいは、これらのパターンの階層的な位置づけも必要であろう。人智の誤りのtaxonomyがあってよい。そうすれば、個々の場で、それぞれの誤りパターンとその相対的頻度に基づいて、具体的なチェックポイントを定めることができる。そのチェックポイントについて逐一確認することで、人智の誤りを完全に無くすことは出来ないにしても、減らすことが出来ると思われる。システムの開発者からユーザにシステムが引き渡されるとき、それぞれのチェックポイントの確認を文書化して示すことも重要であろう(その後の新しい不具合を検討する際に役立つ)。
誤りは恥と言う意味合いもあるから、誤りを報告する(一歩進めて、公表する)ことには抵抗感がある。銀行システムの不具合、東証システムの不具合などの詳細は知られていない。過去の人智の誤りを集積し、パターン化して、それを広く世に知らしめなければ、過去の教訓は得られない。
私はこれまで、同じことを重ねて言わない(古くなったことを二番煎じに繰り返さないという意味合いをこめて)ようにしてきた。しかし、最近、同じことを何度も繰り返し言ううことの重要性を改めて認識し始めている。そう、同じことを言おう。航空機事故調査委員会だけではなく、影響が大きい公共的な情報システムについいぇは、第三者による事故調査委員会を設けるべきである。(青)