三菱UFJ銀行で貸金庫の中身が盗まれていた事件で、とうとう犯人が逮捕され、改めて紙面を賑わせています。

貸金庫を管理していた責任者が、銀行用の鍵と、契約書用の鍵（スペアで預かっていたもの）を用いて解錠したということです。

業務プロセス設計で考えれば、契約者用の合鍵を支店で保管するという業務プロセスの致命的な欠陥を直すだけのことですが、銀行側は信頼回復できないようなら貸金庫サービスからの撤退も視野に入れているとの報道もあります。

問題を直接解決するならそういう選択もあるのでしょう。

しかし根本的にはそのような危険な業務設計に気づかず長年放置してきたことが気がかりです。こういう大きなポカが許されているなら、必ず別の業務設計でも大きなミスをしていることでしょう。

ですので業務設計には定期的な点検が欠かせません。

業務点検の目的や方法は様々です。効率的か、やすいか、無駄がないか、といったことをチェックするの大事ですが、特に責任のある銀行などでは、脆弱性が無いかを点検するのはそれ以上に重要となります。

軍隊の演習で言うとブルーチームとレッドチーム、サイバーセキュリティで言うハッカーとホワイトハッカー、サーバで言うと負荷試験、のような視点が重要です。敵に勝てるか、不具合を防御できるか、イレギュラーなことにたいしての脆弱性を点検するのです。

ウイルスのコードを含むテキストを送信して実行させることで感染させられたような時代も有りましたが、通常想定されるものと異なるデータが投入されて不具合を起こすようではダメです。

先日もコンビニチェーン店で、紙幣をいれる挿入口に高齢者が硬貨を入れてしまって故障させた、といったことがSNSで流れていましたが、紙幣を重ねて入れられるように投入口を大きくすれば、当然硬貨も入ります。それですぐ不具合が起きるなら、トレーニングがある店員向けの端末なら別ですが、これから高齢化してどういう使われた方があるかもわからないユーザー向け端末としては失格です。