リスクは細部に宿りたもう

「リスクの集中管理」と言った場合に、リスクを集中的に管理するというのは、リスク管理作業を集中化するということを意味するのではないと思っている。
そのように集中化できることを否定はしないが、そのようにするには、リスク管理のスーパーマンを想定しなければならない。

すべての企業にそんなスーパーマンはいるのだろうか？
いたら頼めばよいが、いなかったら育成するのだろうか？
育成できないならあきらめるしかないのだろうか？

そんなことについての考えを、翔泳社の IT Compliance Web が取材でまとめてくださったので、よかったらどうぞ。
もとは雑誌の記事だったけれど、Ｗｅｂにも掲載されたのでお読みください。

IT Compliance Web

　「リスクは集中管理できるのか～企業における法対応とITのバランス」

みずほ証券発注ミス

まるちゃんの情報セキュリティ気まぐれ日記にも出てますが、小さな事故をこまめに対処しない組織では大きな事故が発生するというＨＲＯ対策の基本そのままの事例ですね。

推察ですが・・・

・株価と株数の取り違い

入力画面でそれぞれを区別する工夫が、画面設計上足りなかったのではないかと推察します。
東証での同じ、株価、株数取り違えによる億単位のミスは、今回で３件目のようですから。
そう考えれば、より少額のミスは常態化していたかもしれません。
その他には、ＩＴではなく業務処理手続きに落とし穴があったかもしれませんね。
たとえば、ほとんどの指示が、「１０万円で１０株を売り」というように、「金額、株数」という順番の様式なのに、その中に、「１０株を１０万円で売り」という指示が混在すれば、それを「１０円で１０万株を売り」と入力してしまうでしょう。

・警告画面を無視した

警告画面の出現頻度が高い設計だったのではないかと推察します。
しょうもないことまで、常に警告画面を表示させるようなシステムでは、人は、それを無視しはじめるでしょう。
極めて稀にしか表示されないような、警告画面を、即座に無視するとは思えません。
あるいは、グローバライズ気取りで、意味もなく警告文を英語で作っていたり。
日本人には、「WARN や ALERT」と表示するより「警告」と表示した方が直感的なはずです。でも、かっこつけて英語で表示するものが意外に多いですよね。
少なくとも、警告画面の頻度が少なくなるように、警告条件を考慮するのは、設計上の問題です。そして、警告条件が取り引き条件に依存するなら、警告条件を変更できるような設計がなければ、「人」はそれを正しく使えません。
最後は「人」なんだという配慮に欠けた設計のシステムが最近多い気がしています。

などと勝手に推察してみましたが、そんなことは揚げ足取りの邪推でしかありません。
まぁ、いろいろな事情があったのでしょう。
しかし・・・

・再発防止のためには

一般的に考えて、これまで株数と株価を入れ間違えるミスがまったくなかったところに、いきなり数百億円のミスが発生したとは思えません。
日々の小さなミスを軽視して、設計変更をしなかった責任は重いはずです。

まさに、ＨＲＯ対策を怠ったということですね。

ＨＲＯとは、 高信頼組織（High Reliability Organization）の略で以下の書籍で解説されています。

　不確実性のマネジメント（Managing Unexpected）
　出版：ダイヤモンド社

良書なので、amazon に書評を書いたことがありますし、佐藤の講演では、ちょくちょく紹介してます。

「バカな行政、バカな報道、バカな国民では再発は防げない」で書いたとおり、今回のような事件を他山の石として失敗から教訓を学び、自身についても同種の潜在的な問題点を改善をしないといけませんね。

PDCA 本家の陥落

NASA はアポロ月面着陸プロジェクトのときにプロジェクト管理手法を確立させた。その後、その手法は「プロジェクト」と呼ばれるものすべてに採用された。いわば、NASA はプロジェクト管理手法のご本家だ。しかし、いまやその本家の威厳は地に落ちてしまった。

いまや工程管理の常識である、PDCA, WBS, PERT図などのプロジェクト管理手法やツールのほとんどは、米国 NASA がアポロ計画の中で生み出したものだ。
情報公開制度により、アポロ計画における当時の手書きの議事メモなども含めて見れるようになっている。
それらを目の当たりにすると、アメリカの先進性に驚かずにはいられない。

そんな NASA が今やプロジェクト計画本家の見る影もない。

毎日新聞　2005年7月14日　3時26分　（最終更新時間　7月14日　10時56分）を参照

発射直前の TBS ニュース23 で取材が放映されていたが、プロジェクト指揮官が長官に品質改善のためにプロジェクトの見直しを要請するも、当初計画日程遵守を偏重し却下されたため、指揮官が辞任している。
指揮官は取材の中で、「いまや現場は悪いことは上に報告できない環境にある。上も良い報告しか受付けない。」と言っていた。

HRO としてあってはならない環境だ。

いくら WBS と PERT 図を厳密に準備しても、PDCA がちゃんと機能しなければ意味がない。

最近ときどき、PDCA を PDC としているのを見かける。
Plan, Do, Check したら、Action を適切に取らなければならない。
Check しっぱなしでは意味がない。
Plan, Do, Check が手続き的に実施できるのに対して、もっとも重要な Action は、人の判断によることになる。
PDCA を P|D|CA と分けるのは、あまりに危険だ。
本質的なところでは、PDC|A で分けてもよいくらいだと思っている。
PDCA を PDC にする人達は、C+A をまとめて C にするということがあってはならない。
A が異質だから PDC についてまずは考える・・・というのはナンセンスだろう。

PDC については、より多くの人間の意見を求め、上位までの承認プロセスを持つのがよいだろう。
しかし、A については、現場にもっとも近い少数の人間の意見を十分に尊重する必要がある。
fail safe の観点からすれば、Go サインについては、現場全員の同意を必須とする必要があるだろう。
ひとりでも、No Go がいるならば、No Go をまずは決定すべきだ。

現場指揮官が No Go を要請し職を辞してまで訴えたものを、その長たる者が、Go を強行するような NASA には、もはや、アポロ計画の頃のようなプロジェクト遂行は期待できないのだろうと思った。

納期という圧力に人が負けたとき、現在のプロジェクト管理手法のすべてが機能しないことは、図らずもそれを生み出した NASA が証明したことの意味を考えるべきだろう。

アポロ計画の遺産である WBS や PM 手法を使った、昨今のＩＴ構築であるが、ちゃんと PDCA ができているのだろうか・・・
似たような話しを見聞きするのは気のせいだろうか・・・

NASA は発射延期により、最後の最後でぎりぎり No Go のブレーキが残っていたわけだが、はたしてＩＴ構築の現場はいかに？