危機管理
なかなか興味深いエントリーANAのシステムトラブル。特にこの辺が興味深い
危機管理という観点だと「使っている人が仕組みが分からないシステム」は止まると何もできなくなる。だって「仕組みが分からないから、何をしたら正しいのか使ってる人が判断できない」から。結果として、現場には「人の頭数はいるが何もできずオロオロする（人件費はその時間にも発生している）」ことになる。まぁベテラン職員が昔を思い出してなんとか切り抜けようとするんだろうが、現場任せでは全員が同じ手順で同等レベルの作業をこなすのは難しい（だから、システム化されたのだろうし）システム組んでいる側からすれば、100%を目指してはいるけど、100%はありえない。99%を99.9%にするには、90%を99%にするよりも、何倍、何十倍ものコストがかかる。100%は無理だ。
100%は無理だということを前提にして、オペレーションを行わなければならないのだ。
私なんかは当たり前だと思っているこの100%は無理だということを教育すべきなんだろうね。システムは壊れるものだ。壊れたときにどう対処すべきなのか。それを末端の社員まで教えること。それが大事。
上記webより引用
中で何をやっているのか分かるシステムは、止まった場合も、人が手動でできるか否かは別として「何をすれば正しいのか」は現場で判断できる。外見上、簡単に仕組みが分かるような、見る人が見れば「えらい簡単なシステムだな」と思うかも知れない。でも、利用者全員の意識に「これは○○を受け取って××してるだけ」と普段から思わせるようなシステムが大事なのだと。改めてKISSの原則の考え方は大事だなー、と。思った
SI屋さんをやっていると、「あれもやって、これもできて、あのシステムと連携できるようにしてください」という足し算発想の客は多く、結果的に止まったときのインパクトがでかいシステムが納品されがちになっている、気がして、なかなか反省材料は多い。
一般には客の要望をかなえてあげるシステム屋が優秀とされてるのだし、システム屋にはそう言う要素が望まれているのは事実だろう。要求聞いた後に、「止まったらどうすんだ、削れ！諦めろ！」と一喝するようなシステム屋は、まぁ普通は居ない。受注金額が減るようなことを自分からは言わないだろう。（居たら冷や飯を食わされてる可能性は高い）
そう考えたとき、事故報道を通して、システム停止時の危機管理は「システム開発屋」任せにしてはならず、発注サイド（この場合だとANAだけど、別に東証とか、好きな会社名で）がどれだけ自分自身の問題として考えていたのか、がうっすらと見えてくるような気がします。
