今回紹介する資料「ポストモーテム」は、「みずほ銀行システム障害 事後検証報告」をキャッチフレーズにしており、「人間が判断する体制が問題」部分の以下のフレーズが印象的でした。
「他のメガバンクCIO（最高情報責任者）経験者は『障害の規模を人が判断するという体制に、そもそもの問題があったのではないか』と指摘する。
みずほ銀行はシステム障害が発生した際に、複数部署のメンバーがオフィスの会議室に集まり情報共有した上で、対応を協議するとしていた。
それに対して他のメガバンクでは『何件以上の顧客影響があったら自動的に対策本部を立ち上げる、といったルールを事前に設けている。必ず頭取にも連絡が届く』（CIO経験者）という。
みずほ銀行はここでも、体制上の不備があったわけだ。」（引用終わり）
それでは、本日もPDCAを回して行きましょう！
PDCA日記が更新されたら通知が欲しいという方がいましたので、そのような場合は Twitter をご利用ください😊。https://twitter.com/MPdca
P.S. システム障害が頻発したみずほ銀行は、元日本IBM理事だった林氏を副CIOに迎え入れています。https://xtech.nikkei.com/atcl/nxt/column/18/00001/05743/
ただ、CIOではなく副CIOになっているのが、なんとも日本の銀行らしいところであると感じています。
金融業界では有名でしたが、みずほ銀行のシステム統合は延期が繰り返され、中々完成しませんでした。
そのため、このプロジェクトは「IT業界のサグラダ・ファミリア」と揶揄されましたが、19年の時を経てようやく完了したことになります。
みずほ銀行のチャレンジングな19年は、私が金融業界で過ごした日々（2000年～2016年）と重なっています。
みずほ銀行のシステム障害の歴史について、もっと知りたい方は「みずほ銀行システム統合」を手に取るとよいでしょう。
「みずほ銀行システム統合」において、教訓になる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」とすればよいですね。
本日は、アニメ「勇しぶ。」を紹介します。
「勇しぶ。」の舞台は中々複雑で、魔王が消えた平和な世界に生きる勇者になれなかった青年ラウルが主人公です。
ラウルは勇者試験を目の前にして魔王が倒され、勇者になれなかったというチャレンジングな過去を持っています。
王都にある小さな電気店、マジックショップ・レオンにラウルは就職し、そこで電気店店員としてレジ打ちの仕事をしています。
勇者から電気店店員となったラウルは忙しい毎日を送っていましたが、バイト希望でやって来た少女との出会いをきっかけに、大きく変わってしまいます。
彼女の名はフィノで、実は倒された魔王の娘でした。
自分が望んでいた職業とは違うことをしているラウルですが、フィノの教育係をすることで、「この仕事を続けてみるか」という気持ちになっていきます。
人事部で教育関係の仕事をしている人や、「今の仕事が向いていないのではないか？」とお悩みの方は、アニメ「勇しぶ。」を鑑賞してみてください😊。
The material introduced today "Minimalist life that lives richer for 100,000 yen a month" has the catchphrase "Minimalism solves the problems of health, money, work, human relations and things" and the following phrases were impressive.
"Some people may be wondering that 'Does reducing things really change your life?'
Of course, reducing things is just a kick.
Minimalism is a way of thinking that resets your life once, and is a means of tuning your life.
Reducing things is easy and quick for anyone to get started.
And if you reduce things and make it lighter, you will have an indescribable sense of security and freedom.
When a chance pops up in front of you, you have the money and the freedom to grab it right away.
That's why you can change your life.
This is the first self-investment you should work on.
No matter how much you spend on books and seminars, it won't work unless you first prepare the environment around you." (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
