「システム障害はなぜ２度起きたか」

本書は、

日経コンピュータ誌の大和田尚孝副編集長が

中心になって書かれたものです。

マスメディアは、その時の流行りものを追いかけたり

煽ったりすることが多い中で、

この本は出色の傑作です。

本稿は少し長く

以下の構成となっています。

【日経コンピュータ誌のお手柄】

【本書の主張の根幹】

【ＣＩＯの人材】上野意見

【情報システムの重要度

システム依存ビジネス＝モータボート】上野意見

【システム機能の社外依存の問題】上野意見

【『動かないコンピュータ』撲滅のための１０カ条】

【日経コンピュータ誌のお手柄】

みずほ銀行は、２００２年

３行合併で誕生した際にシステム障害を起こしました。

時の前田頭取が、

「（お客様に）迷惑をかけているわけじゃない」

と開き直って物議を醸しました。

その後発刊された

「システム障害はなぜ起きたか」

という本書の前作の内容を今でも覚えています。

障害発生の前に、こういうことがありました。

３行の頭取が顔を揃えて

新会社の役員体制を発表した時のことです。

新役員を

「ＣＥＯ誰々，ＣＯＯ誰々，ＣＦＯ誰々、――――」

と、紹介しました。

その時にＣＩＯが入っていないのを不審に思った

日経の記者が、

「ＣＩＯはどなたですか？」と質問しました。

そうしたら、頭取たちは「えっ？」という顔をして

後ろに控えているスタッフと相談して

「ＣＩＯとは言っておりませんが、

システム担当役員はおりますから問題はありません」

と答えたのだそうです。

それなら、

「『社長』でいいのになぜＣＥＯと言うのか」です。

筋が通りません。

これで記者は、

「この人たちはシステムを重視していない。

これは危ない」

とウォッチしていたようです。

そうしたら、「案の定！」ということになったのです。

私は、このブログでも再々

マスコミの定見の無さを批判していますが、

このときは感心しました。

その追求をした記者の中心が、

まだ若い大和田さんだったのでしょう。

日経コンピュータ誌は、

その後も、みずほをウォッチしていました。

そうしたら９年後「（予想どおり）またやってしまった」

ということになったのです。

【本書の主張の根幹】

大和田さんたちの主張の根幹は以下のとおりです。

マスコミはスポンサーのことを考慮して

本質に切り込まない、のが普通です。

それに対して、

これだけ切り込んでいくのは素晴らしいことです。

―――――――――――――――――――――――――

今回のシステム障害の原因は３０項目にわたるが

これらの原因の根っこは

「経営陣のＩＴ軽視」だ。

その結果は、こうなった。

「失敗を恐れ、システム刷新を先送りした」

　問題を起こした勘定系システムは

開発から２３年間経ったものである・

「必要なＩＴ投資を見送ってきた」

　システム統合・システム刷新には、

　　２～３千億円かかる。

「システム部門の強化を怠った」

　その結果、障害対応能力が落ちた。

「システム障害のダメージを想定できなかった」

　　これだけの大ごとになると分かっていたら

　　適切な対応策をとっていただろう。

「経営陣のＩＴ軽視」は以下の点からも分かる。

５月２３日の記者会見で発表された

「システム障害の再発防止策」には４つの問題点がある。

１．３５項目に及ぶ再発防止策のうち、

　　経営陣自らの意識・行動の改善に向けた取り組みが

ほとんどない

２．「今回の事故の原因は、

９年前の統合の時の原因と異なるので

　　防ぐことができなかった」

と言っていて原因を表層的にしかとらえていない。

３．事故から２か月経っているのに、

　　新任のシステム担当役員を決められなかった。

４．「推進中のみずほ銀行、みずほコーポレート銀行、

みずほ信託銀行のシステム統合費用が、
この事故によって大きく増えることはない」
と言っているが認識が甘い。

システム強化の対策としては

1.ＣＩＯには将来経営トップになる人材を当てなさい。

2.ＣＩＯは取締役にして
  取締役会に出席し意見を述べられるようにしなさい。

などが重要である。

―――――――――――――――――――――――――

以下は上野の意見です。

【ＣＩＯの人材】

先の前田頭取の失言も

システムに対する無知の表れと言えます。

ご承知のように

同じメガバンクでも三菱東京ＵＦＪ銀行は，

畔柳信雄ＣＩＯが社長・会長になりました。

畔柳ＣＩＯが指揮したシステム統合のプロジェクトは

IT Japan Award 2009の経済産業大臣賞（グランプリ）

をとるほどの成功でした。

ＣＩＯの人材という点では、

野村証券の田中浩ＣＩＯは、代表取締役専務ですが

この方の意見は素晴らしいものです。

２０１１年６月９日の
日経コンピュータ誌のインタビュ記事で

このようなことを述べておられました。

―――――――――――――――――――――――――

「ＩＴはビジネスそのもの。

証券業では、

システムの発展が業務の発展につながってきた。

営業担当者をシステム部門に積極的に異動させている。

利用者が望むシステムを素早く開発できるようになった。

（現在の野村証券のシステムは

２０年以上使用している手作りシステムであるが）

システム再構築する際に、

野村総合研究所の「ＳＴＡＲ-Ⅳ」の利用を決めた。

「ＳＴＡＲ-Ⅳ」は共同利用型のシステムで

利用部門のすべてのニーズを満たすことはできないが、

コスト削減効果は大きい。

私の役割は、利用部門からの不満を抑えることだ」

―――――――――――――――――――――――――

情報子会社の社長も、ＣＩＯ機能を担っています。

システム・ＩＴと経営の両方が分かる方に

なっていただきたいものです。

野村証券の子会社野村総合研究所の社長は

代々、本社からの「天下り」でした。

初の生え抜き社長だった藤沼彰久さん（現会長）は

２００５年から保守の改革を推進しました。

当時から事業の中核になっていた

ソフトウェア保守業務をエンハンス業務と名付け

その改善を推進する「エンハンス業務革新推進室」
を作り専任の要員を置いたのです。

これは本邦初のことです。

こういうことは天下り社長にはできません。

【情報システムの重要度

システム依存ビジネス＝モータボート】

日本の経営陣一般のＩＴ軽視については

今さら言うまでもない、という感じです。

特に、製造業は仕方がないでしょう。

ＩＴより技術や製品が大事です。

フィルムがダメになったのに

大発展している大手企業のことですが、

過去２年間で社長が、

ＩＴ部門に声をかけてきたのは

２例しかないのだそうです。

１例は「うちのクラウドはどうなっているのかね」

もう１例は

「（ソニーの情報漏えい事件のとき）

ウチは大丈夫かね」

だったそうです。

「ＩＴはＩＴ部門に任せて」おけばよいのです。

しかし、金融業・流通業は

ビジネス＝システムです。

システム軽視＝ビジネス軽視です。

私はこれらの産業を

「システム依存ビジネス」と言っています。

「システム依存ビジネス」と

それ以外のビジネスの差は、たとえて言えば、

モータボートとヨットの違いです。

船体がビジネスで、エンジンがシステムです。

製造業はヨットです。

進むことに対して、

エンジンは補助的な役割しかありません。

風があれば、

入港・出港の時くらいしかエンジンを使いません。

帆（製品、技術）の強化の方が優先します。

これに対し

「システム依存ビジネス」の金融業・流通業は、

モータボートです。

エンジン（システム）がなければ

ニッチもサッチもいきません。

この業界でシステム軽視なんて信じられませんね。

【システム機能の社外依存の問題】

このこともシステム障害発生の遠因になっている

と思われます。

金融系の企業では、

ほとんどが情報子会社を持っていて

システムの実務は子会社依存です。

企画機能は本社で留保していると主張されますが、

実務の実態から離れて

有効な企画ができるものでしょうか。

日本が得意とする製造業では、

確立した製品の生産を

ＥＭＳやＯＥＭメーカなどに
製造委託することはあっても、

自社の工場で、
生産技術を確立できるようになっています。

委託側で委託先の作業と品質を

完全に評価・コントロールできるように
なっているのです。

さらに、
企画を自社で実施し製造を他社に依存するという方式は、

情報システムの場合は、責任があいまいになるという

欠点もあります。

企画段階で決定した開発の仕様は、

製造業の場合と違って完成度が低く、

その後変更になることが多いからです。

したがって、

きちんとしたものができない責任はどこにあるのか

ということがはっきりしなくなるのです。

まともな企画ができない、
責任の所在があいまいになる、というだけでなく、

機動性に欠ける、という欠点もあります。

ビジネス側が、「新事業を始めよう」

「新方式のサービスを始めよう」という時に

子会社は、子会社の経営成果を出すという

別の責任を負っているのですから、

本体の社長の号令ですぐ動くわけにいきません。

そういうこともあり、最近は、

本体のシステム部門強化に動いている企業も多い
のです。

我が「母校」帝人の大八木成夫社長は、ＣＩＯ経験者です。

日経コンピュータ誌２０１１年９月１５日号の
インタビュー記事「構造改革にＩＴは不可欠、
グローバル化へ変革は続く」　の中で、
以下のような発言をされていました。

「一つの試みとして、
ＣＩＯの下にＩＴ企画室を設けて、
そこに２０人くらいを配置しています。
各事業からの選出チームです、

一時期はＩＴシステム子会社のインフォコムに
全部切り出したのですが、
その反省のうえでの取り組みです」

金融業はほとんどすべての企業が

情報子会社を持っています。

情報子会社を作った時代は、

非常に多くの開発業務があったのに対して、

本業とは全く異質の開発業務要員を

社内で育成・処遇することが困難だったからです。

当時は企画機能は重要ではなく、

製造機能があればよかったことも

分離の要因となりました。

これに対して、

同じく「システム依存ビジネス」でありながら、

流通業は情報子会社を持っていない方が主流です。

ダイエー凋落の原因はいろいろありますが、

原因の一つは、

早くから情報子会社を作ったことだと言われています。

現在トップの総合流通業になったイオンは

情報子会社を持っていませんでした。

（最近、グループ全体をホールディングカンパニ方式に

切り換えた際に、システム部門も独立会社にしました）

イオンのＭ＆Ａ・新ビジネスの続出には

目を見張るものがあります。

ビジネスの企画とシステム企画・運営が一体でなければ

そんな早業はできません。

【『動かないコンピュータ』撲滅のための１０カ条】

最後に「システム障害はなぜ２度起きたか」で

あげられている

「『動かないコンピュータ』撲滅のための１０カ条」

（システム障害を起こさないための１０カ条）

をご紹介しましょう。

「動かないコンピュータ」は、日経コンピュータ誌が

永年に亘って継続している

情報システムの失敗を紹介する連載型人気記事です。

その１

　経営トップが先頭に立ってシステム導入の指揮を執り

　全社の理解を得ながら社員をプロジェクトに巻き込む

　（この中には「システム部門を強化再生せよ」

という主張も含まれています）

その２

　複数のシステム開発会社を比較し

　最も自社の業務に精通している業者を選ぶ

その３

　システム開発会社を下請け扱いしたり、

　開発費をむやみに値切ったりしない

その４

　自社のシステム構築に関する力を見極め、

　無理のない計画を立てる

その５

　社内の責任体制を明確に決める

その６

　要件定義や設計など上流工程に時間をかけ、

　要件の確定後はみだりに変更しない

その７

　進捗は自社で把握、

　テストと検収に時間をかける

　（上野注：そのように計画を立てるのですが、

　要件の変更等で時間がなくなり「テストと検収に」

　時間をかけられなくなっているのです。

　したがって、「その６」が重要です）

その８

　システムが稼働するまであきらめず、

　あらゆる手段を講ずる

　（「プロジェクトマネジメントを企業に定着させる」

　という主張も含まれています）

その９

　システム開発会社と

有償のアフター・サービス契約を結び、

　保守体制を整える

　（「この１０カ条は、

あくまでもシステム構築に重点をおいて作ったもので、

保守に関する条項は一つしかない。

だが、保守はそれだけで

それぞれ１０くらいポイントが列挙できる分野である」

というコメントが述べられています。

そのとおりです。

今や開発と保守にかかる工数比は１対４ですし、

障害やトラブルの大半は保守が原因なのです）

その１０

　「うっかり」ミスを軽視せず、

　抜本的な対策を取る

　（上野注：このことは飛行機事故等でも

　指摘されていることで、不注意だ、うっかりミスだ

　で片付けると事故は再発する、

といういわば「真理」です）

大和田さんたちの予想は

「このままだと３度目が起きる」です。

みずほグループは、この本の提言のように動いて、

そうならないようにしていただきたいものです。