2011年9月17日土曜日

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

本書は、
日経コンピュータ誌の大和田尚孝副編集長が
中心になって書かれたものです。

マスメディアは、その時の流行りものを追いかけたり
煽ったりすることが多い中で、
この本は出色の傑作です。

本稿は少し長く
以下の構成となっています。
【日経コンピュータ誌のお手柄】

【本書の主張の根幹】

【CIOの人材】上野意見

【情報システムの重要度
システム依存ビジネス=モータボート】上野意見

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

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


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

みずほ銀行は、2002年
3行合併で誕生した際にシステム障害を起こしました。

時の前田頭取が、
「(お客様に)迷惑をかけているわけじゃない」
と開き直って物議を醸しました。

その後発刊された
「システム障害はなぜ起きたか」
という本書の前作の内容を今でも覚えています。

障害発生の前に、こういうことがありました。
3行の頭取が顔を揃えて
新会社の役員体制を発表した時のことです。

新役員を
「CEO誰々,COO誰々,CFO誰々、――――」
と、紹介しました。

その時にCIOが入っていないのを不審に思った
日経の記者が、
「CIOはどなたですか?」と質問しました。

そうしたら、頭取たちは「えっ?」という顔をして
後ろに控えているスタッフと相談して
「CIOとは言っておりませんが、
システム担当役員はおりますから問題はありません」
と答えたのだそうです。

それなら、
「『社長』でいいのになぜCEOと言うのか」です。
筋が通りません。

これで記者は、
「この人たちはシステムを重視していない。
これは危ない」
とウォッチしていたようです。
そうしたら、「案の定!」ということになったのです。

私は、このブログでも再々
マスコミの定見の無さを批判していますが、
このときは感心しました。

その追求をした記者の中心が、
まだ若い大和田さんだったのでしょう。

日経コンピュータ誌は、
その後も、みずほをウォッチしていました。
そうしたら9年後「(予想どおり)またやってしまった」
ということになったのです。

【本書の主張の根幹】

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

マスコミはスポンサーのことを考慮して
本質に切り込まない、のが普通です。
それに対して、
これだけ切り込んでいくのは素晴らしいことです。
―――――――――――――――――――――――――
今回のシステム障害の原因は30項目にわたるが
これらの原因の根っこは
「経営陣のIT軽視」だ。

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

「失敗を恐れ、システム刷新を先送りした」
 問題を起こした勘定系システムは
開発から23年間経ったものである・

「必要なIT投資を見送ってきた」
 システム統合・システム刷新には、
  2~3千億円かかる。

「システム部門の強化を怠った」
 その結果、障害対応能力が落ちた。

「システム障害のダメージを想定できなかった」
  これだけの大ごとになると分かっていたら
  適切な対応策をとっていただろう。

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

5月23日の記者会見で発表された
「システム障害の再発防止策」には4つの問題点がある。

1.35項目に及ぶ再発防止策のうち、
  経営陣自らの意識・行動の改善に向けた取り組みが
ほとんどない

2.「今回の事故の原因は、
9年前の統合の時の原因と異なるので
  防ぐことができなかった」
と言っていて原因を表層的にしかとらえていない。

3.事故から2か月経っているのに、
  新任のシステム担当役員を決められなかった。

4.「推進中のみずほ銀行、みずほコーポレート銀行、
みずほ信託銀行のシステム統合費用が、
この事故によって大きく増えることはない」
と言っているが認識が甘い。

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

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

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

などが重要である。
―――――――――――――――――――――――――
以下は上野の意見です。

【CIOの人材】

先の前田頭取の失言も
システムに対する無知の表れと言えます。

ご承知のように
同じメガバンクでも三菱東京UFJ銀行は,
畔柳信雄CIOが社長・会長になりました。
畔柳CIOが指揮したシステム統合のプロジェクトは
IT Japan Award 2009の経済産業大臣賞(グランプリ)
をとるほどの成功でした。

CIOの人材という点では、
野村証券の田中浩CIOは、代表取締役専務ですが
この方の意見は素晴らしいものです。

2011年6月9日の
日経コンピュータ誌のインタビュ記事で
このようなことを述べておられました。
―――――――――――――――――――――――――
「ITはビジネスそのもの。
証券業では、
システムの発展が業務の発展につながってきた。
営業担当者をシステム部門に積極的に異動させている。
利用者が望むシステムを素早く開発できるようになった。

(現在の野村証券のシステムは
20年以上使用している手作りシステムであるが)
システム再構築する際に、
野村総合研究所の「STAR-Ⅳ」の利用を決めた。

「STAR-Ⅳ」は共同利用型のシステムで
利用部門のすべてのニーズを満たすことはできないが、
コスト削減効果は大きい。
私の役割は、利用部門からの不満を抑えることだ」
―――――――――――――――――――――――――

情報子会社の社長も、CIO機能を担っています。
システム・ITと経営の両方が分かる方に
なっていただきたいものです。

野村証券の子会社野村総合研究所の社長は
代々、本社からの「天下り」でした。
初の生え抜き社長だった藤沼彰久さん(現会長)は
2005年から保守の改革を推進しました。

当時から事業の中核になっていた
ソフトウェア保守業務をエンハンス業務と名付け
その改善を推進する「エンハンス業務革新推進室」
を作り専任の要員を置いたのです。

これは本邦初のことです。
こういうことは天下り社長にはできません。

【情報システムの重要度
システム依存ビジネス=モータボート】

日本の経営陣一般のIT軽視については
今さら言うまでもない、という感じです。

特に、製造業は仕方がないでしょう。
ITより技術や製品が大事です。

フィルムがダメになったのに
大発展している大手企業のことですが、
過去2年間で社長が、
IT部門に声をかけてきたのは
2例しかないのだそうです。

1例は「うちのクラウドはどうなっているのかね」
もう1例は
「(ソニーの情報漏えい事件のとき)
ウチは大丈夫かね」
だったそうです。
「ITはIT部門に任せて」おけばよいのです。

しかし、金融業・流通業は
ビジネス=システムです。
システム軽視=ビジネス軽視です。

私はこれらの産業を
「システム依存ビジネス」と言っています。

「システム依存ビジネス」と
それ以外のビジネスの差は、たとえて言えば、
モータボートとヨットの違いです。
船体がビジネスで、エンジンがシステムです。

製造業はヨットです。
進むことに対して、
エンジンは補助的な役割しかありません。

風があれば、
入港・出港の時くらいしかエンジンを使いません。
帆(製品、技術)の強化の方が優先します。

これに対し
「システム依存ビジネス」の金融業・流通業は、
モータボートです。

エンジン(システム)がなければ
ニッチもサッチもいきません。
この業界でシステム軽視なんて信じられませんね。

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

このこともシステム障害発生の遠因になっている
と思われます。

金融系の企業では、
ほとんどが情報子会社を持っていて
システムの実務は子会社依存です。

企画機能は本社で留保していると主張されますが、
実務の実態から離れて
有効な企画ができるものでしょうか。

日本が得意とする製造業では、
確立した製品の生産を
EMSやOEMメーカなどに
製造委託することはあっても、
自社の工場で、
生産技術を確立できるようになっています。

委託側で委託先の作業と品質を
完全に評価・コントロールできるように
なっているのです。

さらに、
企画を自社で実施し製造を他社に依存するという方式は、
情報システムの場合は、責任があいまいになるという
欠点もあります。

企画段階で決定した開発の仕様は、
製造業の場合と違って完成度が低く、
その後変更になることが多いからです。

したがって、
きちんとしたものができない責任はどこにあるのか
ということがはっきりしなくなるのです。

まともな企画ができない、
責任の所在があいまいになる、というだけでなく、
機動性に欠ける、という欠点もあります。

ビジネス側が、「新事業を始めよう」
「新方式のサービスを始めよう」という時に
子会社は、子会社の経営成果を出すという
別の責任を負っているのですから、
本体の社長の号令ですぐ動くわけにいきません。

そういうこともあり、最近は、
本体のシステム部門強化に動いている企業も多い
のです。

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

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

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

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

金融業はほとんどすべての企業が
情報子会社を持っています。
情報子会社を作った時代は、
非常に多くの開発業務があったのに対して、
本業とは全く異質の開発業務要員を
社内で育成・処遇することが困難だったからです。

当時は企画機能は重要ではなく、
製造機能があればよかったことも
分離の要因となりました。

これに対して、
同じく「システム依存ビジネス」でありながら、
流通業は情報子会社を持っていない方が主流です。

ダイエー凋落の原因はいろいろありますが、
原因の一つは、
早くから情報子会社を作ったことだと言われています。

現在トップの総合流通業になったイオンは
情報子会社を持っていませんでした。
(最近、グループ全体をホールディングカンパニ方式に
切り換えた際に、システム部門も独立会社にしました)

イオンのM&A・新ビジネスの続出には
目を見張るものがあります。
ビジネスの企画とシステム企画・運営が一体でなければ
そんな早業はできません。

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

最後に「システム障害はなぜ2度起きたか」で
あげられている
「『動かないコンピュータ』撲滅のための10カ条」
(システム障害を起こさないための10カ条)
をご紹介しましょう。

「動かないコンピュータ」は、日経コンピュータ誌が
永年に亘って継続している
情報システムの失敗を紹介する連載型人気記事です。

その1
 経営トップが先頭に立ってシステム導入の指揮を執り
 全社の理解を得ながら社員をプロジェクトに巻き込む
 (この中には「システム部門を強化再生せよ」
という主張も含まれています)

その2
 複数のシステム開発会社を比較し
 最も自社の業務に精通している業者を選ぶ

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

その4
 自社のシステム構築に関する力を見極め、
 無理のない計画を立てる

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

その6
 要件定義や設計など上流工程に時間をかけ、
 要件の確定後はみだりに変更しない

その7
 進捗は自社で把握、
 テストと検収に時間をかける
 (上野注:そのように計画を立てるのですが、
 要件の変更等で時間がなくなり「テストと検収に」
 時間をかけられなくなっているのです。
 したがって、「その6」が重要です)

その8
 システムが稼働するまであきらめず、
 あらゆる手段を講ずる
 (「プロジェクトマネジメントを企業に定着させる」
 という主張も含まれています)

その9
 システム開発会社と
有償のアフター・サービス契約を結び、
 保守体制を整える

 (「この10カ条は、
あくまでもシステム構築に重点をおいて作ったもので、
保守に関する条項は一つしかない。
だが、保守はそれだけで
それぞれ10くらいポイントが列挙できる分野である」
というコメントが述べられています。

そのとおりです。
今や開発と保守にかかる工数比は1対4ですし、
障害やトラブルの大半は保守が原因なのです)

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

 (上野注:このことは飛行機事故等でも
 指摘されていることで、不注意だ、うっかりミスだ
 で片付けると事故は再発する、
といういわば「真理」です)

大和田さんたちの予想は
「このままだと3度目が起きる」です。
みずほグループは、この本の提言のように動いて、
そうならないようにしていただきたいものです。

2 件のコメント:

  1. 拝見しました。私もまた障害が起きると予想します。
    金融産業が情報産業というのは業界内では常識なのですが、実態としてはレガシーシステムが多く、まだ紙が幅をきかせています。
    IT戦略が無いため(一応は作成されるが)、投資プライオリティが明確ではなく、声の大きい部門が予算をとるためだと思います。
    システム投資予算はシステム部門が持って主体となり、関連部門と協力して企画・開発を実施する方が全体最適が達成できる可能性が高いと思います。
    システム予算は営業部門に持たせてはいけません。

    返信削除
  2. 貴重なご意見ありがとうございます。

    システム予算は、どこで持った方が良いかは議論の余地があると思いますが、基本はシステム部門がどれだけ力を持っているかだと思います。
    力があれば、各部門が予算を持っていても、調整が効くでしょうし、力がなければ、予算を持ってもおかしなことになるだけでしょう。
    システム部門の強化が望まれます。 上野則男

    返信削除