大企業の信じられない「間抜け」はなぜ？？

【このテーマの目的・ねらい】
目的：
　みずほ銀行と東電柏崎刈羽原発の不祥事の遠因を想定いたします。
ねらい：

　「丸投げ」はすべてやめましょう。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
信じられないようなことが起きています。

９月２３日の日経新聞に二つの事件報道がありました。

１．金融庁、みずほ「強行介入」
　　障害究明遅れで実質管理

　　ご承知のように、みずほ銀行のシステムが今年になって

　　数度の障害を起こしていますが、

　　原因究明が不完全であることに対して金融庁が介入を行う、

　　というものです。

　　銀行のトップが頭を下げてもすまない状況に立ち至ったのです。

２．柏崎刈羽原発不祥事　東電が報告書

　　対テロ「リスク認識に弱さ」

　　侵入者を検知する監視の故障を３０日以上放置していた、

　　東電の社員が他人のＩＤカードを使って中央制御室に入室した、

　　配管が壁や床を貫く約8000か所のうち72か所で火災対策工事未了、

　　100個の火災報知器が設置すべき場所に取り付けられていなかった。

　　というようなことが起きているのです。

　　原子炉等規制法ではテロ対策の外部漏洩を禁止しており情報共有が

　　不十分になりやすい、こうした「秘密主義」が

　　外部からのガバナンスを及びにくくした、

　　との指摘も記述されています。

【なぜこんなことが起きるのか】

私は、以下のようにこの両社への関りがありました。

みずほ銀行創立（興銀、富士銀、第一勧銀が合併して成立した）の際に

それぞれの銀行とのお取引があり影響を受けました。

３行は、対等合併の形式的条件を守るためにお互いに遠慮して

有機的に一体化するということができませんでした。

それは情報子会社でもまったく同じことでした。

誰も本当のことは分からない無責任体制になっていました。

かたや、東京電力殿とも長年のご縁で

その風土も把握させていただいておりました。

その経験からしますと、共通して言える今回の不祥事の遠因は、

以下のとおりであると想定いたします。

１．開発時に維持運営のことを軽視している

　原発でもシステムでもメインの部分の開発者は花形で、

　副の部分の開発は重視されません。

　原子炉本体の開発が花形で、

　冷却系は副でしたのでいい加減な対応をしたことが、

　福島第一原発の事故につながっています。

　システムの開発では、

　システムの利用者から見えるアプリの部分が花形で

　それを支えるインフラ系は副の位置づけです。

　まして、維持運営のことは軽視され、

　システムの開発時には後回しになっています。

　維持運営の精通者が、システム開発の際に積極的に参画する、

　ということはなかったのではないでしょうか。

　維持運営のことをよく分からない人たちだけで

　システムを作っているのです。

　少なくとも「昔」の開発はそういう状況でした。

　原発の維持運営も同じことでしょう。

　

２．専門的機能分業に伴い責任分化が進んで、

　　お互いの情報連携が不十分になっている。

　　その結果で、日ごろから「他人のしていることは知らん」

　　「他人のしていることに口出ししない」

　　という無責任体質になっている。

　　その結果、「ブラックボックス化」や、

　　誰も分からない「つなぎ部分」が発生します。

３．専門技術的領域について、上位管理者が十分理解できないので

　　担当に丸投げとなっている。

　　丸投げとは、技術の具体的なことについては分からくても、

　　管理者として押さえるべきポイントは押さえなければならないのに

　　それをしていない、ということです。

　　みずほの場合だと、

　　銀行側の人たちは「技術のことは『情報総研』に任す」

　　となっているのです。

　　「情報総研」では上位者が専門技術を放任しています。

　　大事なことが担当者任せなのです。

　　刈羽原発の不祥事は、不備の状況を放置したとなっていますが、

　　管理者がその状況を把握していなかったのでしょう。

４．専門的領域については、外部依存を行っているが、

　　担当と外部の関係も「丸投げ」状態である。

こういうことですから、

維持運営段階でなぜそのことが起きているのか、

の究明は至難なのです。

システムの全体構成（アプリもインフラも）を

分かっている者がいれば、障害の状況を見れば、

それがどこが原因で起きているかは判断できるはずです。

刈羽原発の運営状況の全体関連図のようなものがあれば、

全体から細部までブレークダウンして把握することができるはずです。

昔、こういうことがありました。

私たちが開発し熟知して運営していた流通業の全社システムを

Ｆ社がある企業に対してオンライン化を含め再開発し移行しました。

本番に移行しているのですが、トラブルが頻発しました。

直ちに修正しないと売上請求も滞るという危機的状況でした。

Ｆ社中心の技術者たちが立ち往生していましたので、

私が助っ人に入りました。

ミスの状態を見て、多少の当りをつけますと、

どんどんそのプログラムミスを見つけることができました。

何日か、徹夜のような仕事をして修復作業が完了し、

危機を逃れることができたのです。

みずほのシステムは、

そのシステムの１００倍以上も複雑だと思われますが

原理的には同じことです。

　起きている現象の把握⇒その特徴の把握⇒発生原因の想定⇒確認

　⇒修正⇒結果の確認。

　不十分なら、発生原因の想定に戻ってやり直す。

丸投げをしていると、そういう目利きのできる人がいなくなるのです。

みずほの新システムＭＩＮＯＲＩは、

障害の切り分けなどもやりやすい

ＳＯＡ構成となっているはずなのですが、

そのＳＯＡ式の新システムの障害対応の経験不足のために

究明に手こずっている面もあるのかもしれません。

でも、本質は上記と変わりません。

【究極の対策＝全体の見える化】

結局、対策としては、維持運営段階に視点をおいて、

管理対象の全貌を見える化することです。

その全貌から順次詳細レベルにドリルダウンできる

ようになっていればいいのです。

こうなっていれば、

どんな管理者でも大事なことを見逃すことはないでしょう。

障害の原因究明も容易なはずです。