ITシステムに「ポカよけ」はどこまで必要だろうか。

ITシステムに「ポカよけ」はどこまで必要だろうか。

「ポカよけ」という言葉を耳にされたことがある方は多いのではないか、と思う。一応、簡単に解説しておくと、要は「人間はミスを犯すことがある」ことを前提にして、「単純ミス」を防止するための機構のことを指す。フェイルセーフ機構の一種と言ってもいいだろう。どうやら、国際用語化しているらしく、英語版のWikipediaにも掲載されている。

[参考情報]Poka-Yoke
http://en.wikipedia.org/wiki/Poka-yoke

さて、ITシステムにおける「ポカよけ」とは様々なものが考えられるだろう。マシンルームで誤ってサーバーのコンセントを抜いてしまわないように、そのコンセントが何の機械であるかをきちんとタグに書いて付けておくのも一つの「ポカよけ」だろうし、アプリケーション上においてJava ScriptでAlertやConfirmでユーザーにメッセージを促すのも「ポカよけ」の一種と言えるだろう。

ここでは業務アプリケーション上の話で触れてみたい。

あらためて確認すると、「ポカよけ」はあくまで「単純ミス」の予防策である。したがって、業務アプリケーションにおけるそれは、通常正常に運用することができる・運用しているユーザーの”万が一”の気の緩みや別のことを考えてしまっていた時の支援をすることが前提であり、元々業務知識が不足している、や、悪意を持った・・・とまではいかなくとも、システムが前提とする運用条件を”わざと外してそうする”ユーザーからシステムを守るものではない。

そういう意味では、極めてクリティカルな部分にだけ適用されるのが”正”だろう。

ところが、そのユーザー数が極めて多い時、その正常に運用できるであろうユーザーの想定、ユーザーの持つ業務知識の前提、は非常に不透明になってしまうため、なかなかどこからどこまでが単純ミスの領域なのかの言い切りが難しくなる。

一番単純なのは、
１）全てのケースに対応できるよう、思いっきり「単純ミス」のレベルを下げ、全てのパターンにコンフィギュレーションを掛け、「ポカよけ」を作ってしまう
か、
２）それぞれのユーザーの役割・業務を単純化する
か、
のどちらかだろう。

でも２）は、システム供給側とユーザーの所属する企業の位置関係や、業務アプリケーション自身のポジショニング、そのユーザーの業務環境（場所、人の数、組織形態等）に依存するので一括りにできるものでもなければ強制できるものとも限らない。

とすると、１）という選択肢になってしまうのだが、それは結果として、本来のあるべき利用者の想定である、通常正常に運用することができる・運用しているユーザーに対しては極めて冗長的なものとなり、また、一方で、「どうせシステムが守ってくれるんだから」と、業務知識の習得意識の欠如を加速させかねない、もしくは、「システムが警告しない」＝「やっていいこと」、と悪意無き良識欠如の行動を促しかねないものとなってしまう。

今、自分の周りでは、そのような業務アプリケーションを多々見掛ける。

以前、きょこさんも書かれていたが、結局のところ、「ポカよけ」とはシステムで行うものでは無いのだろう。やはり業務アプリケーションなら、それを使う人の意識に依存する問題であって、「システムなんだからそんなの守れるはずだ」的な意識で使われることを前提にして組み込むものでは無い、とずっと前から思ってはいるのだが・・・。

まだちょっと昨日にも書いた「シンプルにして下さい」を引きずってるな・・・。