ワテの場合、メインバンクはみずほ銀行ではない。
なので、みずほ銀行のオンラインシステムにトラブルが起こっても大して影響はない。
と言うよりも、そもそも銀行にそんなに大金を預けている訳ではないので、どこの銀行ともあまり縁が無い。
時々ジャパンネット銀行をインターネット経由で利用する程度だ。
図１． ラーメンを食べながらインターネットバンキングを利用するワテ
さて、こんなニュースを見た。
「みずほ銀、システム統合再延期 動作テスト延長 運用18年以降」
当記事では、システム開発に失敗する理由を自称システム開発の達人、いや変人のワテが解説したい。
では、本題に入ろう。
みずほ銀、システム統合再延期 動作テスト延長 運用18年以降
2016/11/12 2:00 日本経済新聞 電子版
みずほ銀行は2016年12月に予定していた新たな勘定系システムの完成時期を遅らせる検討に入った。システムの一部で実施中の動作確認テストを延長する必要があると判断した。遅らせれば２度目の延期となり、新システムの運用開始は18年夏以降になるとみられる。みずほは過去に２回の大規模なシステム障害を起こしており、今回も万全を期すことにした。
勘定系システムは、口座の入出金や資金決済、口座管理などを担うシステム。みずほは02年と11年の２度にわたり、ＡＴＭの停止や口座振替の遅延などの大規模なシステム障害を起こし大きな混乱を招いた。
今も残る旧みずほ銀、旧みずほコーポレート銀、みずほ信託銀の３つのシステムを障害に強い１つの新システムに統合。全面刷新することで再発防止につなげる方針だった。
新システムの完成時期は、14年にも16年３月の予定を９カ月間遅らせた経緯がある。今回は12月から完成時期を数カ月程度遅らせる見通し。システム完成後の移行作業には１年半程度かかるという。
引用元 日本経済新聞 電子版
あかんがな。
みずほ銀行と言うと、何かとシステムトラブルが多い銀行と言うイメージがワテには有る。
第一勧業、富士、日本興業の３銀行が再編されて「みずほ銀行」になった訳だが、2002年4月1日の営業初日に現金自動預入払出機（ATM）の障害が発生した。
さらに公共料金の自動引き落としなどの口座振替にも遅延が発生して、日本全国を巻き込む大事件になったのを覚えている。連日のようにニュース報道されていた気がするが詳細は忘れた。
兎に角、それ以来、ワテの場合にはみずほさんには悪いが何となくシステムが不安定な銀行と言うイメージを持っている。
以下では、なぜ巨大システム開発は失敗しやすいのか考察してみたい。
図２． ATMを使っている人
現金自動預け払い機（げんきんじどうあずけばらいき）
ATM（エーティーエム）、
英: cash machine、automated/automatic teller machine
teller
名詞可算名詞
1. 話し手.
2. (銀行の)金銭出納係，窓口(係).
a deposit teller 預金係.
3. 投票計算係.
ATMのTはtellerと言う英単語の略らしい。
今日まで知らなんだ。
みずほのシステム開発には総費用3000億円
ネット情報によると、みずほのシステム開発には総費用として3000億円が投入されているようだ。
3000円置くんちゃうで!!なんて冗談言っている場合ではない。
3000億円だ。
今話題の
- 豊洲市場（約3,926億円、東京都HP情報）とか
- 新国立競技場（約1490億円を予定、Wikipedia情報）
の建設費と同じレベルの数千億円の規模だ。
システム開発は良く失敗する
巨大なシステム開発では、往々にしてトラブルが起こりやすい。
銀行のオンラインシステムとか証券取引所の株式売買システムとか。
あるいは先日はANAシステム障害がニュースになった。
開発作業中のトラブルならまだ良いが、本番稼働した後のトラブル発生は全国ニュース規模の大事件となる。場合によっては経営陣の謝罪とか頭取の引責辞任なんて言う場合もある。
具体的にはどんなトラブルだろうか。
- 設計した通りに本番で動かない。
- 動かしたとたんにトラブル続出（みずほ銀行の2002年4月システム障害の例）
- 開発スケジュールが大幅に遅れる（数か月程度ではなくて何年も遅れるなど）
- 2000年問題、閏秒など普段と違う状況でトラブルが出る（2038年問題はどうなる？）
などなど。これら以外にもあるだろう。
恐らく世間一般の人は、何でそんな事態になるの？
失敗しないように出来ないの？（コンピュータ界のドクターＸのような人はいないの？）
と思っているだろう。
3000億円も掛けて失敗するなんて、一体全体どう言う事よ？
と疑問を持っているに違いない。
以下では、ワテがその疑問に対する理由を考察してみたい。
システム開発の難しさは何か？
「システム開発の難しさは何か？」その答えは簡単だ。
作っているところが見えないのがシステム開発の最大の問題なのだ。
3000億円かけて新国立競技場を建設するのなら、
- 設計図を作って、
- スケジュールを決めて、
- 業者さんに発注して、
- 現場監督さんがそのスケジュールに従って作業を管理する。
そう言う流れになるだろう。
で、計画通り進んでいるかどうかは、その建物が日々建築されて行く様子を見ていれば、スケジュール通り進んでいるかどうか分る。
100階立てのビルを建てる場合でも、2016年〇月〇日の時点で50階まで鉄骨を組むという計画になっていたとして、その日に確認したらまだ30階までしか鉄骨が組んでいなかったら、20階分遅れている事は素人が見ても分る。
図３． 高層ビルを建設する例
ところが、システム開発では、物が作られて行く過程が見えない。
プログラマーとかシステムエンジニアの人が、コンピュータに向かってプログラムを書いたり、ワープロで仕様書を作成したりと言う作業が殆どだ。
3000億円掛けて作っても、出来上がるものはプログラムなどのデジタルデータでしかない。
その場合には、2016年〇月〇日の時点で計画通りに出来上がっているのかどうか？なんて、外からコンピュータを眺めても見ても全く分からない。
図４． プログラムは他人が見ても何を作っているのかも完成度も分からない
あるいは、そのシステム開発に携わっている人達ですら分からないだろう。
外から見えないからだ。
作っているプログラマー本人にしか分からない。
目的とするプログラムが完成したかどうかを判定する方法
プログラムのソースコードを目で見たくらいでは何も分からない。
目的とするプログラムが完成したかどうかを判定する為には、
元になった仕様書に基づいて全部テストして仕様書の通りの機能を持っているかどうか確認して初めてそのプログラムが完成しているのかどうかが分かるのだ。
なので、極端な話、作っている本人ですらその日の時点で、計画通りに進んでいるかどうかなどは分からない。
まあ経験的に大体はスケジュール通りに進んでいるかなと言う程度の予測は出来るが、その場合でも、本人が気づいていない重大な欠陥がプログラムの中にあるかも分からない。そう言う事態になったらその欠陥を修正するための追加作業が必要になるので益々遅れる。かつ、そんな欠陥は、作った本人しか修正出来ない場合が殆どだ。
一方、建設現場ならそんな問題は起こりにくい。
- この柱には直径3cmの鉄筋を50本使う、
- この床は20センチの厚みにコンクリートを流し込む
- この部屋の天井は5メートルの高さ
など設計図通りに出来ているかどかなどは、必要に応じて調べれば大体把握できる。
もし、設計図と違っていたらすぐに修正すれば良いし、その作業は建設の知識がある人なら誰でも可能だ。設計図と違う施工をしてしまった本人が修正する必要は無い。
で、完成した部屋を素人が見ても良い材質の床材を使っているかどうかとか、柱の太さは何センチあるかとか、床をドンドン蹴っても下の部屋に響かないかどうかとか、天井の高さは何メートルあるかとか、そう言うのは簡単に分るので、出来上がった時点で完成度も分る。
作っている物が誰にも見えないのが最大の問題
と言う事で、システム開発の最大の問題点は、作っているものが見えないと言う事だ。
かつ、作ったとしても動かしてみない事には設計通り出来たのかどうかが分からないと言う事だ。
だから、開発がスケジュールよりも遅れたとしても、単純に人員を増やしたところで問題は解決しない。
一方、建設現場なら、何が遅れているのかは目で見て分るので、遅れている現場の人員を増やすなどで対策が立てやすい。
もちろん建設現場でも専門知識を必要とする部分も多いと思うので、いきなり素人作業員を大量に投入するだけでは問題が解決しない場合もあるとは思うが、でも中には人海戦術で対処できる部分も多いだろう。
100階建てのマンションの鉄筋が組み上がって、各階の内装工事を始めたとする。
でもスケジュールが遅れている。
そういう場合は、大量に人員を投入して各階の内装作業を並行して行えばよい。
資材を運搬するエレベータがボトルネックになるなどの恐れもあるが、その場合は追加でクレーンを設置するなど、兎に角どうにでもなるだろう。
部屋の内装工事などは、並列処理で実施できる作業の典型だろうから、兎に角大勢で一気にやればスケジュールの遅れを取り戻せるだろう。
しかし、プログラミング作業にいきなり助っ人が100人来たとしても、100倍の効率で作業が捗るか？
そんな事は滅多にない。いや、殆ど無い。
システム開発の問題点はこう言うところにあるだろう。
まとめ
システム開発の進捗度合とか完成度を何らかの方法で可視化して管理する仕組みとか研究などは無いのかな？
ワテの場合、そう言うのにはあまり縁は無いので詳しくは知らないが、もし何らかの方法でシステム開発を可視化して管理する手法が確立出来れば、よくありがちな開発スケジュールの大幅な遅れとか、本番状況でのトラブル続発などの問題は減ると思う。
ただし、開発段階のソフトウェアの完成度とか品質を定量化して管理する事は難しいだろうなあ。つまり出来上がったとしても、実際に動かしてみないと分からないと思う。
もし開発段階でソフトの完成度を評価するなら、部分的に完成したソフトウェアに対して想定される入力データを与えて出力結果が正しいかどうかを調べれば良い訳だが、結局のところ、入力データの作成とか出力データの検証は人力でやるしかないんじゃないかな？
テスト作業自体は自動化出来ると思うが、要件定義段階で想定した各種のパターンを利用して、全自動で入力データを生成して、全自動テストを行い、全自動で出力を検証するシステムなどあるのかな？
そういう分野は疎いので良く分からない。
でも、多分無いだろうなあ。もしあったら、システム開発で失敗する事件がニュースになるはずが無いし。
と言う事で、みずほ銀行さん、ご健闘を祈ります。
コメント