【PDCA日記 Vol. 199「システム障害は経営の失敗」】
私は2002年から2年間、ニューヨークに駐在したのですが、赴任早々、日本でみずほ銀行のシステム障害が発生し、金融業界で騒ぎになったことを覚えています。
また、私がフランスにいた2011年3月に、みずほ銀行で再び大規模なシステム障害が発生しました。
銀行員ではない人からすると、「どうして似たようなシステムの問題が何回も起こるのだ？」と思われるかもしれません。
皆様も利用されている銀行送金は、「全銀システム（全国銀行データ通信システム）」と言うNTTデータのネットワーク経由で行われています。
この全銀システムがかなり昔に設計されたこともあって、送金手数料などのコストが高くなっています。
他行宛振り込みの「全銀システム」はもちろんですが、自行の従業員が行う手続きやクレジットカード利用者、海外のカード利用者など、支店、ATMだけではなく、PC、スマホ経由のあらゆるプロセスを、銀行のシステムは想定する必要があります。
普段の生活ではあまり意識されませんが、ATMは非常にお金のかかる機械です（ミスができないため）。
私が普段の生活で、現金を極力使わないようにしているのは、ATM維持や現金輸送のコストが、結局自分にふりかかってくるためです。
現金を大量に流通させるために、社会全体で2兆円のコストがかかっているという試算もあるくらいです。
キャッシュレスの浸透は、色々な意味で効用が大きいため、更に推進してほしいと思っている元銀行員（元クレジットカード会社の従業員でもある :-) の私がいます。
今回紹介する資料「みずほ銀行システム統合」は、昨日（2020年2月14日）発売された新刊で、「苦闘の19年史 史上最大のITプロジェクト「3度目の正直」」をキャッチフレーズしており、以下のフレーズが印象的でした。
「大規模システム障害が起きる前に古い勘定系システムを刷新できなかったのは、みずほ銀行の情報システム部門が怠（なま）けていたわけでも、その下で作業をしていたシステム開発会社に落ち度があったわけでもない。
『このシステム障害は、経営の失敗そのものだ』。
2011年3月にみずほFGが引き起こした二度目の大規模システム障害を、企業情報システムの専門誌である『日経コンピュータ』はこう評した。
みずほFGの経営トップは勘定系システムの刷新を現場任せにして、情報システムのことを理解せず、必要な資金や人員を投入する決断ができなかった。
情報システムの開発に際して業務部門が情報システム部門に全面的に協力したり、関係各所の利害を調整したりできるようリーダーシップを発揮することも怠った。
経営陣のIT軽視、IT理解不足が、大規模システム障害の根本的な原因だった。」（引用終わり）
それでは、本日もPDCAを回して行きましょう！
PDCA日記が更新されたら通知が欲しいという方がいましたので、そのような場合は Twitter をご利用ください :-)。https://twitter.com/MPdca
P.S. 金融業界では有名でしたが、みずほ銀行のシステム統合は延期が繰り返され、中々完成しませんでした。
そのため、このプロジェクトは「IT業界のサグラダ・ファミリア」と揶揄されましたが、19年の時を経てようやく完了したことになります。
みずほ銀行のチャレンジングな19年は、私が金融業界で過ごした日々（2000年～2016年）と重なっています。
今回紹介した資料「みずほ銀行システム統合」を読みながら、昔のことを含めて色々と思い出すことがありました。
今回のPDCA日記「P.S.」部分では、特別版の形で本書の教訓になる3つの部分について、私からコメントしたいと思います（長めです :-)。
ーーー
＜教訓①結果責任の明確化＞
本書引用「金融庁はシステム障害の再発防止策やシステムリスクの総点検を命じると共に、みずほFGに対してシステム戦略を見おなすようにも命じた。
みずほFGやみずほ銀行に対して行った（金融庁の）緊急検査を通じて、『現行システムに内在する課題を踏まえたIT投資戦略』や『人材育成や適材適所の人材配置』に課題があると判断したからだ。
つまり金融庁は、みずほFGやみずほ銀行の経営トップが適切なシステム投資をせずに問題がある勘定系システムを放置し、システムを理解する人材の育成も怠っていたと断じたわけだ。」（引用終わり）
（Mr. PDCAコメント）最近では、日本郵政への業務改善命令が注目されました。
あまり知られていませんが（？）、銀行における当局対応について、私は実務経験者でもあります。
そのため、みずほ銀行が度重なる業務改善命令を金融庁から受けて、非常にチャレンジングな局面に陥ったことは容易に想像できます。
私が金融の世界を離れた理由の一つとして、「政府から遠い業界に行きたい」ということがありました。
最近は変わりつつありますが、一時期の金融庁は銀行に対して、「箸（はし）の上げ下げにまで口を出す」と言われていたものです（詳しいエピソードは、PDCAカフェで聞いてみよう！）。
現在の金融担当大臣（財務大臣でもある）が、「金融庁は昔、処分庁と呼ばれていたが、これを育成庁に変える」とコメントしていました。
このことは、以前の金融庁が金融検査マニュアルに沿って、銀行や証券会社などに対して厳格な検査を行い、処分を繰り返していた方針を変革しようとしているものと思われます。
一方、自営のコンサルタントは基本的にどこからも規制も受けておらず、取引先のベンチャーやIT企業の多くも、政府の監視からは遠いところにいます。
「経済学の父」と呼ばれるアダム・スミスは、名著「道徳感情論」や「国富論」の中で、「政府は非効率だが必要」「政府に近づくほどビジネスは非効率になる」と「小さな政府論」を唱えています。
私自身も金融業界にいた頃は、政府の非効率性を肌で感じていました（どれくらい非効率だったかは、PDCAカフェで聞いてみよう！）。
銀行を退職し、規制の少ないベンチャーやITの世界に触れて、非常に新鮮に感じたものです。
ただ、私が自営のコンサルタントとして働くうちに、政府の規制が少ない業界では、「責任があいまいになる」というチャレンジが存在することに気づきました。
2011年のみずほ銀行、今回の日本郵政もそうですが、当局から業務改善命令を受けると、1カ月後に業務改善計画を監督官庁に提出する必要があります。
業務改善計画は提出して終わりではなく、業務改善命令が解除されるまで、3ヵ月ごとに当局に報告を続けなければなりません。
通常であれば、1年程度で業務改善命令は解除されるものです。
しかしながら、計画が予定通り進まなかったり、改善が不十分であると当局が判断した場合、数年間、報告を続けなければならないケースもあります。
また、提出する業務改善計画の中に、「責任の所在の明確化」という項目があり、経営トップの交代や役職員の処分などを盛り込み、監督官庁の了承を得る必要があります。
銀行の場合、問題が発生した際は銀行法25条に基づき金融庁の検査を受け、法令違反や不適切な取引が明らかになった場合には、経営トップの辞任を含めた措置が必要になるのです。
また、銀行は取締役を選任する前に、金融庁に届け出を出す必要があります。
これはほんの一部ですが、金融業界がいかに規制だらけであるかお分かり頂けたのではないでしょうか。
一方、ベンチャー企業やIT業界では、大きな問題が発生しても、当局の検査が入ることはほとんどありません（当たり前だけれど :-)。
そのため、大規模なシステム障害などが発生しても、経営陣は結果責任を問われることなく、同じ人達がいつまでも執行部として居座ることが起こりえるわけです。
ここは経営者のバランス感覚にもなるのですが、結果責任を明確にする具体的な手法として、私は以下の3つがあると考えています。
A. 社長の任期制導入：大企業の場合、4年から6年で社長が交代する任期制を導入しているところが多いです。
経営が上手くいっている場合、再任されることもありますが、任期が明確になっていることで、「いつまで経っても問題が解決しない」リスクを軽減することができます（一定期間で、社長が交代するため）。
ベンチャー企業の場合、創業者が経営者になっていることが多く、任期制の導入はチャレンジングと思う人がいるかもしれません。
しかしながら、ソフトブレーンやライフネット生命など、創業者たちが早い段階で経営から退き、「バトンを渡す仕組み」を構築しているケースがあります。
一方で、ソフトバンク・グループやファーストリテイリング（ユニクロ）、日本電産などは、カリスマ経営者の後継者選びに苦悩しているようです。
この部分は色々な意見があるところですが、私は社長の任期制について、賛成の立場を取っています。
私が見てきた限りでは、「地位が人をつくる」という考えが正しいように感じています。
「この人が適任だろう」と決めた社長に全てを任せ、前任者は組織から離れる方が、長期的な目で見ると良いように思っています。
結果として、「この人は社長に向いていなかった」と言う場合でも、任期制によって、修正をかけることが可能になります。
B. 「うるさ型」の社外取締役選任：問題が起こった場合、結果責任を求める厳しい社外取締役を選任することで、プロジェクトの進捗を厳しく追及されることになります。
ただ、社長に結果責任を求める場合、「自分自身にも責任がある」と自らも吹っ飛ぶ（？）勇気を持った社外取締役が必要になります。
「うるさ型」の社外取締役は、社内のスタッフからすると、非常にチャレンジングな存在に映ります。
ただ、こういう人がいなければ、企業運営に適切な牽制を効かせることが難しくなるのも、事実であると私は考えています。
C. プロジェクト期限と遅延時の責任明確化：システム開発で起こりがちなのは、「いつになったら終わるか分からない」状況です。
私がプロジェクト管理の会合でよく目にするのは、「永遠の進捗率90%タスク」です。
ずっと進捗率が90%のまま変わらないため、残りの10%をどう進めればよいのか、担当者を含めて誰も分からなくなる状況があります。
これを「永遠の進捗率90%タスク」と呼ぶわけですが、遅々として進まないプロジェクトはボディブローのように、ジワジワとしかし確実に組織の体力を奪っていきます。
開発者や担当者は、チャレンジングなタスクに疲弊するのではなく、「いつまでに終わるのか分からない」未完了感で消耗するものです。
判断が遅い取引先や上司に皆さんが疲れているのも、「未完了感」があると私は思いますね :-)。
プロジェクトの期限と、それを守れない場合の結果責任を最初に明確にしておくことで、システム開発の最大の敵（？）とも言える「永遠の進捗率90%タスク」と「未完了感」を制御できます。
プロジェクト管理において、経営者やリーダーに求められるのは、進捗している状況を組織として後押しする事なのです。
「プロジェクトが進んでおり、チャレンジがあれば上伸する事で打開策を打ち出してくれる」という「完了感」をきちんと醸成できれば、担当者が何とかして進めていこうと力を振り絞ってくれます。
＜教訓②外部からのチェック＞
本書引用「（新システムの）MINORIプロジェクトで水菓子部長が手掛けたのが、外部の監査法人にプロジェクトの進捗などを評価してもらうための枠組み作りだ。
持ち株会社であるみずほFGやみずほ銀行、あるいはシステム開発の実務を担うみずほIRといった階層ごとに、プロジェクトの評価項目を整備していった。
プロジェクトの『最後のとりで』といえる重要な役回りだが、現場の反発は大きかった。
資料作りなどの手間が増えるからだ。
水菓子部長は現場から愚痴や泣き言を言われながらも『プロジェクトを前に進めていくためにアカウンタビリティー（説明責任）は欠かせない』と粘り強く説いた。
過去の大規模なシステム障害を招いた一因に、システムのブラックボックス化があった。
『自分たちの今後のためにも必要な仕事だった』（水菓子部長）。」（引用終わり）
（Mr. PDCAコメント）まず、「水菓子部長」はタイポ（誤植）ではありません（本書で確認してみてください）。
本題に戻りますが、外部の監査法人による最終チェックは、金融業界でよく行われています。
外資系企業では、外部の監査法人による最終チェックを「Validation（検証）」と呼びます。
経営陣が、プロジェクトを実行するかどうかの判断（Go or No Go Decision）で利用するのです。
私がお世話になったIT企業でも、システム開発時の「最終チェックをどうするか？」という議論になることがあります。
往々にして、ベンチャーの場合などは、内部の開発者かチェック担当部が検証を対応することになります。
しかしながら、これだけでは不十分なことが結構あるものです。
外部の監査法人によるチェックは、コストがかかりますが、長い目で見ると、結果的に「安上がりの方法」だったりします。
この辺りも経営者のバランス感覚ですが、チェック機能の重要性を理解している社長ほど、外部の目を入れようとするものです。
＜教訓③報告の遅さ＞
本書引用「（2011年3月のシステム障害発生時）システム担当役員が障害発生を知るまで、最初のトラブル発生から17時間かかった計算になる。
システム障害時の緊急連絡にしては、あまりにも時間がかかりすぎた。
システム担当者は、翌朝のオンライン処理に影響が及ぶ可能性が高まったために、『これはまずい』と考え、荻原常務に連絡を取ったのであろう。
システム担当者が『オンライン処理には影響がないかもしれないが念のため』と考え、もっと早く連絡をしていれば、この後のシステム障害の広がり方は違っていた。」（引用終わり）
（Mr. PDCAコメント）私は自分で言うのもなんですが、「報連相の達人」であると自負しています。
銀行員時代、ある上司から「お前はもう報連相に来なくていい」と冗談交じりに言われるなど、私はあらゆることを報告・連絡・相談していました。
会社組織の場合、「これは報告しなくてもいいだろう」と部下が考えていることについて、上司は「どうして報告してこないのだろう」と感じていることが多いものです。
私は自営を始めてからも、お世話になっているベンチャーやIT企業の経営者に対して、週次で報告を行い、フィードバックをもらうようにしています。
私があまりにも細かく報連相をするため、「うちの従業員も、Mr. PDCAみたいに報連相を徹底してほしいなぁ～」と話した経営者がいるくらいです。
どのような業種のどんな仕事であっても、報連相は細かいほど良いと私は考えています。
報連相のしすぎで、怒られることはめったにありません（不足で怒られることはあるけれど :-)。
2011年3月に、みずほ銀行のシステム障害が発生した際、担当者はすぐに役員に報告をすべきでした。
ビジネスにおいては、担当者が「まずい」と思った時、経営レベルの問題に発展する事象が結構あるものです。
これを避けるためには、「悪い情報ほど速やかに上申する」ことがポイントになります。
経営者や幹部側も、悪い情報を上げてきた担当者に対して、「すぐに報告してくれてありがとう」と言うくらいにしなければ、速やかに上申は行われないと思った方がよいでしょう。
ーーー
以上、史上最長のPDCA日記になりましたが、今回紹介した資料「みずほ銀行システム統合」は、IT企業に勤める開発者だけではなく、経営者やコンサルタントなど、あらゆるビジネスパーソンに参考になる情報が満載です。
本書を読んでご意見がある方は、是非PDCAカフェで語り合いましょう（かなり盛り上がると思いますね :-)。
＜ Mr. PDCAのボンジュール英語「経営の」=「managerial 」＞
今回出てきた「経営の」の英訳は、「managerial 」になります。
「システム障害は経営の失敗である」を英語にする場合、「System incident is managerial failure」とすればよいですね :-)。
I have been stayed in New York since 2002, but as soon as I was transferred, I remember that Mizuho Bank's system incident occurred in Japan, and it was causing a fuss.
Also, after the Earthquake of March 2011 in Japan, Mizuho Bank suffered a system incident again.
If you are not a bank employee, you may think, "Why do such incidents happen?"
Remittances, which are also used by everyone, are made via NTT Data's network called the "Zengin System", and due to its age, various fees are expensive.
In case of banks, it is necessary to anticipate not only the "Zengin System"' for transfer to other banks, but also the process of credit card users, overseas card users, etc.
ATMs are very expensive machines, and I try to avoid using cash as much as possible because the cost of maintaining ATMs and transporting cash eventually falls on us.
The material introduced today "Mizuho Bank System Integration (Japanese only)" has a catchphrase of "19 years of struggle, the largest IT project in history" and the following phrases were impressive.
"Because of the failure to renew the old accounting system before the major system failure occurred, it was because the information system department of Mizuho Bank was idle or the system development company working under it had a fault.
'This system incident is just a managerial failure.'
Nikkei Computer, a specialized magazine for corporate information systems, described the second major system incident caused by Mizuho Bank in March 2011.
The top management of Mizuho Bank left the renewal of the accounting system to the site, did not understand the information system, and could not make the decision to invest the necessary funds and personnel.
Neither did the business unit cooperate fully with the information system department in developing the information system, nor did it demonstrate leadership in coordinating the interests of related parties.
Management's disregard for IT and lack of IT understanding were the root causes of large-scale system incidents." (Unquote)
Let's function PDCA today!
In case you would like to receive a notice at the time of PDCA Diary post, please utilize Twitter :-). https://twitter.com/MPdca
