日経コンピュータ 2019 年 9 月 5 日号を読んだ
以下の内容だけ読んだけど多分すぐに忘れるので思ったことをメモ。
特集 みずほ３度目の正直
・みずほ３度目の正直 ついに崖越え、勘定系再構築の全貌（026p）
・スカイツリー７本分 ３０年ぶりの全面刷新（028p）
・バッチ処理を解体 みずほＳＯＡの全貌（032p）
・最大８０００人が連携 品質確保に悪戦苦闘（038p）
・緊張と重圧の１年間 ２０年の悲願ようやく（046p）
・みずほフィナンシャルグループ 社長 坂井 辰史 氏（052p）
緊急版 動かないコンピュータ
・米アマゾン ・ ウェブ ・ サービス
ＡＷＳが６時間停止、３０社超に影響 バグで空調が止まりオーバーヒート招く（006p）
きっかけはツイッター。
— がるがべさん (@garbagetown) September 7, 2019
緊急版 動かないコンピュータ
米アマゾン ・ ウェブ ・ サービス
- ＡＷＳが６時間停止、３０社超に影響 バグで空調が止まりオーバーヒート招く（006p）
ネットで入手できる以上の情報はなく、冊子としてまとまっていることに価値があるという印象。
以下に引用した通り RDS が PaaS と表記されており、ちょっと違うかなと思った。
PaaS (プラットフォーム・アズ・ア・サービス) であるリレーショナルデータベース (RDB) サービスの「Amazon RDS」
自分が調べた限りネットの情報ではこのあたりが詳しい。
特集 みずほ３度目の正直
以下のサイトでも会員登録していれば同じ内容を見られるようだけど、自分は会員ではないので分からない。
３０年ぶりの全面刷新
- Q01 結局いくらかかった?
- Q02 そもそも何をやっていた?
- Q03 完成まで何年かかった?
景気が良かった頃は 10 年程度でシステム刷新をくり返してきたが 1990 年頃にぱたりと止まり、また合併の際にシステムを片寄せし続けたためにブラックボックスとなっていた。
このままシステムを使い続けることはできず、2025 年までになんとかしなければならないとする "2025 年の崖" という課題があった。構想 20 年、東日本大震災義援金振り込み障害など二度の大規模障害を経て三度目の正直。
総コストは 35 万人月、4000 億円台半ばとのこと。
振り返ってみればコストを削減できたところは多々あるだろうけど、もし仮に半分で済んだとしても、前職では高々数億円規模の案件にしか関わっていない自分には想像もできない規模。
みずほＳＯＡの全貌
- Q04 「老朽化」問題は解決した?
- Q05 二重引き落としは再発しない?
- Q06 メインフレームはなくなった?
ハブ & スポーク型の SOA を採用。
取引メイン、流動性預金、内国為替取引はメインフレーム、SAIL なるミドルウェア、COBOL で構築しており、その他は Linux と Java で構築。メインフレームは 19 台から 4 台に集約とのこと。
メインフレーム、COBOL と聞くと真っ先にレガシーという言葉を思い浮かべてしまい、脊髄反射的に関わりたくないと思ってしまうが実際のところはどうなんだろう。
ざっと調べた限りではメインフレームと COBOL には二進化十進法による誤差のない計算と、高速/高並列処理に利点があるらしい。
海外の金融システムがどのような事情になっているのか気になって調べてみたけど、日本語で検索したためか有用な情報は得られなかった。
最大８０００人が連携
- Q07 参加ベンダーは何社?
- Q08 本当に新規開発した?
- Q09 プロジェクトはどう管理した?
- Q10 稼働を 2 度延期、本当の理由は?
- Q11 開発拠点はいくつあった?
主要 4 ベンダーは富士通、日立製作所、日本 IBM および NTT データで、トップマネジメント定例メンバー 16 社のうちアプリケーション開発ベンダー 5 社として前職の社名が掲載されていた。
1 次委託先 70~80 社、2/3 次委託先として 900 社強とのこと。
いわゆる多重下請け構造であり、幸か不幸か金融案件に関わったことがないものの前職に身を置いていたものとして、どのように工程管理されていたか想像がつく。
As-is, いわゆる現行踏襲の要件定義を禁止し、Xupper なるツールで業務フローを描き起こしたという点は興味深かった。自分たちが使うシステムをベンダ任せにせず取り組む良い前例になってほしい。
超高速開発ツールを全面活用して手動コーディングを禁止したという点も興味深かった。当然のことながら不満も出たものの品質確保に貢献し、パフォーマンスにも問題はなかったとのこと。私情を挟むと揺れるところもあるが超大規模開発であれば妥当な判断なのかもしれない。
緊張と重圧の１年間
- Q12 なぜ 9 回も ATM を止めた?
- Q13 移行失敗をなぜ回避できた?
- Q14 1 万 7000 人の操作訓練はどうした?
- Q15 目に見える成果はあった?
- Q16 投資回収の見込みは?
- Q17 経費率はどこまで下がる?
- Q18 開発力は上がった?
入念に計画した段階リリースと運用訓練によりトラブルなくシステムを移行。
5 年間で 720 億円の費用削減を見込んでおり、SOA 化などにより実際に新規開発コストを削減。
また、社内で益荒男 (ますらお) が育ち、海外の大規模開発などで一騎当千の活躍をしているとのこと。
プロジェクトマネジメントなど抽象度の高いタスクに取り組んでいたエンジニアには得難い経験になったことと思う。ぜひ超大規模案件における知見を活用して活躍してほしい。
設計や実装など具体的なタスクに取り組んでいたエンジニアも、もし赤や緑の類似案件があった際には引っ張りだこになるといいなと思う。
進退かけて指揮した
- Q19 インタビュー「経営責任」果たせたか?
- Q20 「3 度目」は起こらない?
2018-01-15 にみずほ証券社長からみずほフィナンシャルグループ社長に抜擢された坂井辰史氏のインタビュー。
社長になるのは自分の首を洗っておくこと、という言葉が印象深かった。
IT 人材のビジネスリテラシーが高くないとも仰っており気になったが、インタビュー記事では深掘りされておらず具体的にどのような課題なのか分からなかった。
感想
大変な規模の案件を、従来の多重下請け構造と一部にレガシーなメインフレームと COBOL を残した SOA で実現したと理解した。
他に類を見ない事例であることは間違いなく、関わったエンジニアのみなさんにはお疲れさまでしたという気持ちと共に、貴重な経験を活かして今後も活躍してほしいと思う一方、この事例がエンジニアにとって未来の希望や発奮材料になり得るかと言うと、ちょっと厳しいかなーという印象。
とにかくレガシーというイメージがよくない。
古くからあるものが再評価されて名前を変えてエンジニアに受け入れられた事例は多いし、マイクロサービスも SOA の再発見と言えないこともないと思うので、メインフレームと COBOL も少しいじって名前を変えるだけでずいぶん状況が変わるのではないだろうか。
メインフレームはなんかすごい速いすごいマシンということにすればよいし、そもそも開発終盤まで意識することは少ないと思うので影響は小さいはず。
COBOL の採用理由が二進化十進法による誤差のない計算にあるのであれば、その機能を持つモダンなプログラミング言語を開発してしまえばいいのではないかと思った。
きちんとコンピュータサイエンスを履修していない素人の妄想に過ぎないけど、Go や Swift などを思い返すと自分たちのシステムを支えるプログラミング言語そのものを開発するという発想は特にクレイジーではないし、4000 億円の 1% でも投入すれば意外となんとかなったりしないだろうか。
モダンなプログラミング言語で最高のパフォーマンスとセキュリティを求められる超大規模開発と聞けば、腕が鳴るというエンジニアは少なくないように思うし、そこに名乗りを上げるエンジニアにはそれなりに期待して良いように思った。
