本を耳で読む Amazon Audible 30日間無料体験キャンペーン実施中

けっして他人ごとではない【書評】日経コンピュータ(編)『システム障害はなぜ二度起きたか』(日経BP社)

3.11、あの大震災のわずか3日後に起こったみずほ銀行の大規模なシステム障害。
本書はその原因を究明し、問題点を明らかにし、解決策のいったんを提示したものです。

驚くべきは、その過程で浮かび上がってきた真の原因・・・。
規模やレベルの差はあっても、なんらかのシステムを利用して仕事をしている我々にとって、けっして他人事ではありません。

 

【目次】

はじめに
第1部 震災直後、「またか」の大規模障害
第2部 合併直後、「まさか」の大規模障害
第3部 とらぶるはどこにでも
第4部 システム障害と闘う
おわりに

【ポイント&レバレッジメモ】

★システム設定を23年間見直さず

みずほ銀行の勘定系システムは1988年に稼働を開始した。その後、みずほ銀行は、ATMの24時間稼働、インターネットバンキング、携帯電話からの振込といった新サービスを投入する一方、一括処理の上限値の設定を、23年間一度も見直さなかった。それどころか、現在のシステム担当者は上限値の設定があることする知らなかった。23年前の稼働当時に在籍していたシステム担当者は、上限値の存在を知っていたはずだ。だが、23年の間にシステム担当者が入れ替わる中、その存在が後任者に正しく引き継がれなかった。

★異常時のシナリオを用意していなかった

みずほ銀行は、異常時のシナリオを自動運行システムに組み込んでおかなかったどころか、紙の運用マニュアルとしても用意していなかった。そのためシステム担当者たちは、まずどの処理を進めて、それが終わったら次にどの処理を実行して、という具合に、異常時のシナリオをその場で考え組み立てながら作業する羽目になった。<中略>
みずほ銀行のシステム担当者が、異常時に使える運用マニュアルを用意していなかったのは、システム部門の責任である。だが、現場のシステム担当者に無理を強いたみずほ銀行の経営陣の責任は、それ以上に重い。<中略>システム障害の全面復旧に向けて張り切るシステム部門に「待った」をかけて、銀行全体にとって最適な判断を下すのが、経営陣の責務である。みずほ銀行の経営陣には、
それができなかった。

★費用とリスクを嫌い、システム刷新を先送り

4種類の不手際の背景にある問題をさらに整理すると、2つの経営問題にたどり着く。「システム刷新を先送りした」という点と、「組織としての基本動作を誤った」という点である。
みずほ銀行が勘定系システムの刷新を見送ってきたのは、みずほ銀行とみずほファイナンシャルグループの歴代の経営陣が、大規模システム刷新を決断できなかったからである。

理由1: 費用がネックになった
メガバンクの勘定系システムとなれば、全面刷新するには二千億~三千億はかかる。金額以上にやっかいなのは、投資効果が見えにくいことだ。

理由2:経営陣がシステム刷新のリスクを嫌った
メガバンクの勘定系システムを全面刷新するとなると、日本最大級の大規模なシステム開発プロジェクトになる。難易度は高く、失敗のリスクも膨らむ。みずほのトップは「情報システムのことはよくわからない。どれだけリスクがあるのかも、感覚的にはつかめない。自分がトップでいる間は、今の情報システムで我慢してもらって、刷新は次の世代に任せよう」と考えたのではないか。

★基幹系システムに危機迫る

 主として日本の大企業においては、情報システムの老朽化と肥大化という問題が深刻になりつつある。<中略>
 情報システムを修繕するということは、コンピューターの上で動いているプログラムを直すことである。一つの情報システムは複数のプログラムで構成されており、それぞれ関連しあって動いている。一つのプログラムを修整した結果、別のプログラムに悪影響を及ぼすといったことがしょっちゅう起こる。そこで、情報システムのプログラムの関連を整理した「辞書」のようなドキュメントをつくっておき、それを見ながら手を入れることになる。はっきり言って手作業であり、時間が案外かかる。
 しかもやっかいなのは、こうした日々の修整を、情報システムを止めずに行わなければならないことだ。<中略>
 情報システムの老朽化に対処すべく、修正作業を続けていると、今度は肥大化という問題が起きる。新しいプログラムを追加したり、古いものを修整したりしているうちに、その情報システムを構成しているプログラムの量が増えていく。なぜ量が増えるかと言うと、古いプログラムを全面的に取り換えるのではなく、そこにプログラムを追加していくやり方をとるからである。

★日本はプロジェクトマネジメント後進国

 日本の情報システムの世界を見渡すと、プロジェクトマネジメントの導入に関して驚くほど世界諸国から遅れている。<中略>
 なぜ世界の孤児といえるほど遅れてしまったのか。その理由は逆説的だが、日本が世界の中でもっともプロジェクトマネジメントに適した国民性を持っていたからである。汎用的な知識体系や各種団体を通じてノウハウを共有しなくても、自己流ではあったが立派にプロジェクトをこなしてきた。<中略>
 自己流の最大に欠点は、できる人しかできないこと。そして、徒弟制度でしかノウハウを伝承できない。本来なら、ノウハウを誰でも使えるような仕組みにする必要がある。その時に汎用的な知識体系が役立つ。だが、日本はプロジェクトマネジメントのノウハウを系統立てて整理してこなかったため、先ほど述べたように現場のプロジェクトが減り、徒弟制度が維持できなくなると、とたんにノウハウの伝承が難しくなる。我が国は、自己流だが世界有数のプロジェクトマネジメント力を持つ国から、自己流で実力すらない国に転落しつつある。

★「動かないコンピュータ」撲滅のための10カ条(抜粋)
◇経営トップが先頭に立ってシステム導入の指揮を執り、全社の理解を得ながら社員をプロジェクトに巻き込む

 残念ながら、経営と情報システムの位置付けがしっかり頭に入っている経営者はまだそう多くない。経営トップがまずすべきことは、会社や事業をどう変えていくかという大方針を固めることである。方針があって初めて、必要な戦略が決まり、必要な情報を定義でき、そして情報システムの機能を決められる。情報システムを先に決めることは理論的に不可能である。方針があやふやのまま、「とにかくITだ」と号令をかけて、情報システムの開発プロジェクトを恥得ると、「動かないコンピュータ」が出現する可能性が極めて大きい。

◇システム開発会社を下請け扱いしたり、開発費をむやみに値切ったりしない

21世紀にはいっても、システム開発会社を対等なパートナー企業とはみなさず、「命令は何でも聞く出入り業者」と錯覚している企業が存在する。はっきりいうと、金融機関や公益企業に多い。
 システム開発会社はこうしたダメな顧客企業を次第に敬遠するようになる。大手コンピューター・メーカーは、コンピューターを売り込みたい一心で、顧客のわがままを聞いているが、プログラムを開発するシステム開発会社は、さっさと逃げ出すことができる。
 システム開発会社の間で、「あの企業と仕事をするといつもトラブルが起きる。敬遠したほうがいい」と言う評判が立ったりしたら、その企業の未来はないと言わざるをえない。

◇「うっかり」ミスを軽視せず、抜本的な対策を取る

 システム運用業務は、たった一つのミスが大規模なシステム障害につながりかねない、極めて重要な仕事である。ミス一つでトップのクビが飛ぶ時代、どこの企業も、システム運用をおろそかにすることはできない。
 日経コンピュータは1980年の創刊以来、コラム「動かないコンピュータ」を仲春に、500件以上のシステム障害を取り上げてきた。これらの原因を分析すると、運用操作の誤りなどを人為ミスによるシステム障害が年々増えていることがわかった。2000年以降に限ってみると、実に3件に1件が、人為用ミスによるものであった。

【感想など】
普段、都市銀を全く使わないワタクシにとっても、3月14日からのみずほ銀行のシステム障害は記憶に残っております。

システム自体や銀行のシステムを利用した業務については、全くの門外漢ですが、正直今回のシステム障害の原因については驚きました。

というか、こんなことがあっていいのか?と。

システムダウンの直接の原因は、東日本大震災に対する義援金の振り込みが処理上限値をオーバーしたことから始まり、異常終了時事のマニュアルが用意されていなかったなど、システム部門の不手際が二重三重に重なっていったことで、この対応のまずさも驚くに値するのですが、根本的な原因を突き詰めていくと、もっと根深いものに行きあたります。

それは、経営陣のITへの軽視・不理解。

なんとみずほ銀行では23年間システムを刷新していなかったというではありませんか!

ありえないですよね。

今や、ITの世界では「三年一昔」いや、「一年一昔」ぐらいのテンポで技術が進んでいます。
5年前のパソコンなんて化石扱いですからね。

それでも、今まで一度も障害を起こしていないのなら納得できますが、みずほ銀行は“初犯”ではない。
2002年のみずほ銀行統合の際にも勘定系のシステム障害を起こしています。

つまり、自社のシステムを大規模刷新する機会はあったなのにそれを先送りしてしまった。
3月14日のシステム障害は、長年の経営陣の経営判断ミス、つまり経営陣の“人的ミス”が引き起こした障害だったんですね。

これに関して本書ではいくつか経営陣が先送りしてきた理由を挙げていますが、これを読んでいてワタクシも思い当たる点がありました。

多くの場合、どの職種でも共通だと思うのですが、経営陣は50歳代後半ですよね。
この世代の人たちは、極端にIT知識弱くないですか?

うちの職場がまさしくそうで、悲しくなるぐらいITに対して理解がない。

先日来、ワタクシの職場では、朝一にサーバーの調子が悪く、サーバーにアクセスできないため朝は事務仕事ができないという状態がしばしば起こっていました。
でも10時くらいになると正常に動き出す。

おかしいなぁと思って、「そもそもサーバーってどこにあるんだろう?」と確かめたところビックリ。
なんと備品倉庫ですよ。
それも空調のない、蒸し風呂のような倉庫でストックしてある備品にうずもれるようにサーバー君頑張ってました(笑)。

サーバー不調の原因は“熱”だったんです。

いま節電で、9:30くらいに冷房をいれてます。
そのため、朝一の暑い時はサーバーが不調になる。
その後、冷房が効いてくる10:00頃には冷えてサーバー君の元気復活、というのを毎朝繰り返していたんですね。

いったい誰がこんなところにサーバーを設置したのか?
熱で不調になるという初歩的なこともわかっていない。

まぁ、先日も、「もっと仕事がしやすいようにWi-Fi飛ばしてください」と頼みに行ったら、「なんか飛ばすの?」と怪訝な顔されましたから(笑)。
きっと何かモノを飛ばすんだと思ったんでしょう。

世代的に、小中学生時にPCもファミコンもなかった世代ですから、IT機器に取っ付きにくいのはわかりますし、それを批判するのはかわいそうな気もしますが、組織のトップであるならば勉強してしかるべき。

ましてや大きな社会的責任もかかえている大企業ともなれば、不具合が出たときには損失だけでなく、どれほどの迷惑を生み出すかわかると思うのですが・・・、人間は自分の見たくないモノには見ようとしないのでしょうね。

さて、本書を読んでもうひつ気になったのは、システム障害はどこでも発生するという点。
本書では東証や東工取といった金融機関だけでなく、東京消防庁や羽田空港の航空管制システムといった人命にかかわるシステムのダウンについてもとりあげています。

特に消防庁の原因は「LANケーブルのつなぎ間違い」という非常に些細で初歩的なミス。
たったそれだけのことで、消防車や救急車の出動ができなくなるとは。

思えば、先日の中国高速鉄道の事故も、列車が停止しているのに信号が青のままだったというシステムの不具合が原因。
私たちは普段意識しないだけで、システムに命を預けているんですね。

最後に、本書巻末にはシステム障害をなくすための 「動かないコンピュータ」撲滅のための十カ条 提案されています。
何らかのシステムを使っている組織トップのみなさん。
ぜひお読みください。

システム障害の原因の多くは人為的ミス。
としたらあなたの職場でもいつ起きてもおかしくないのですよ。 

そしてその前に、IT機器に関して常識的なことは知る努力をしましょうね。

うちの管理職のように
「サーバーのためにエアコンつけなあかんの?ファンがついとるから冷えるんちゃうの?」
と真顔で答えられた日には、「この人のもとで働きたくない」と思われますから。

本書は日経BP社、東城様より献本していただきました。
ありがとうございました。

【関連書籍】

2 COMMENTS

マグロ船 齊藤 正明

失敗から学ぶこと、多いですね!
追伸
明石家さんまさんが司会の
「ホンマでっかTV」、次回
は8月10日に出る予定です。
すべての都合がよろしければ、
ご覧ください m(__)m

返信する
一龍

齊藤様
失敗から何を学ぶかが、行動につなげるかが大切なところですよね。

返信する

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA