障害発生が「当たり前」という銀行システム統合、本当にそれでいいの？

>これが鉄道の管制システムであれば

と書かれていますが、銀行システムの障害で「多くの人命を失うという事態も十分起こり得えます」のでしょうか？
こちらの記事などを読んで、再考されてはいかがでしょうか。
http://itpro.nikkeibp.co.jp/article/COLUMN/20071018/284916/

銀行のシステム障害で、何百人かは死ぬ恐れはあるでしょう。期限までに入金できなければえらいことです。銀行のせいだと相手が分かればいいですが、そうでない方もいるでしょう。自殺や脅迫、窃盗も発生する可能性が無いとはいえませんね。
ちなみに鉄道の場合は障害が発生すれば止まりますから人命は失わないことがほとんどでしょう。

自動車のエアバッグだとコンマ何秒で人命に関わる。
電車のATSだと路線により大きく異なり、数秒～数分。時には数時間でも人命には影響しない。
銀行システムだと人命に関わることはほとんどない。ただし企業経営においては「不渡り=>倒産」という可能性もなくはないので、やはりトラブルはない方が良い。
個人レベルだと前もって必要な金を引き出しておくか、他の銀行カードやクレジットカードで凌げば良いのでさしたる問題はない。

「テスト肯定のスペシャリスト」？

blogじゃ誤字脱字あっても仕方がないよね

欧米等の事例とかでは、今回の案件レベルでの事故や対応はどないないんでしょうか？
コンサルタントの豊富な経験をお持ちの方は詳しいかと思うのですが、今後のために例でも教えていただければ助かります。

[追伸]
日本のPJ管理技術の未熟さとか、開発要員の劣化とかが問題なのか、はたまはままあることなのか…
それとも投資額を倍にすれば、単純に解決するのか…

私はUFJのシステム開発に携わったことがありますが夜間動くプログラムだけで４千近くあります。
この時点で鉄道と比較するのはどうかと・・・
日中動いているプログラムもは上記以上あると思いますがそれらのプログラムをすべて把握するのは不可能に近いと思います。
ましてや開発要員６千人といってもその多くは常駐者ではないでしょうし、システム全体を把握しているのはほんの一部の人でしかないはずです。
私の時の場合は移行完了後に作業員がATMまで走って本番事前テストなども行いました。
今回の場合だと、本番稼動しているので
移行最終段階でバグが発生したと考えれると思いますが最終段階まで行っていると、ロールバックするよりプログラムを修正したほうが早いと考えたのでしょう
一言で信販といっても残高照会から入金・振込み・ショッピング・クレジット・ETCカード・他銀行との連携など多くの業務があるかと思います。

>カタカナではなく漢字だった
個人情報保護法で見れなかったんでしょう

「2万件以上の取引が成立しなかった」と書かれているが、発生条件から考えて限定的と言えるだろう。
（詳報によれば、セブン銀行ATMで取引をした、未記帳が10件を超えている口座が発生対象）
むしろ、当該時間帯の総取引件数を取材した上で、割合として何％と提示するべき。

鉄道の管制システム（恐らくATOSとかCTCとかのことを言ってるのでしょうが）と
比べていますが、それこそ「それって本当に正常な比較なのでしょうか？」

コメント欄の下部には「オルタナティブ・ブログは、専門スタッフにより、企画・構成されています。」
という注釈が書かれていますが、専門スタッフが聞いてあきれますよ。

　アメリカあたりだとATMが止まってもニュースにもならないですね。
　利用者も「あれ、使えないの？」と言って普通に諦めます。

　トラブルがないことが良いには違いないですが、99.9％ の品質を 99.99％ に上げるために何億も注ぎ込むのは馬鹿げた話。
　日本の公共事業費が極端に高いのも、そういう異常な品質要求が原因の面もあります。
　こんな品質の良い道路なんて世界的に希、汚職（官製談合系）の類はアメリカの方が惨いです。

＞鉄道の管制システム（恐らくATOSとかCTCとかのことを言ってるのでしょうが）と
比べていますが、それこそ「それって本当に正常な比較なのでしょうか？」

と書いていますが、そのくらいの気概を以ってテストすべきという比喩だと理解するのは私だけでしょうか？

公共システムは、障害が発生した時点で多かれ少なかれ不便が発生します。
人命に係わらないからいい加減で良いとはならないはずです。

今回発生した様な障害は、接続相手のシステムを考慮すれば普通に防げていたと思います。

また、
夜間4千近くのプログラムが動くから比較は・・
と別の方が書かれてますが、それをチェックする技術者は一人ですか？
十分と判断するだけの人員をかけて開発してきたはずです。

多いからなどというのは言い訳でしかないし、そんな事を言う体質である（と反論を見て想定）
からこそ、間違っていないから問題ない⇒バグ内在となるのでは？

100％障害の無いシステムというのは理想でしかないことは承知していますが、
今回の様な障害はチェックする技術者の常識・甘さとそれを容認している体制の問題だと思います。

コンサル（笑）という言葉も定着しそうですね。

いやはやQuickC程度で挫折してしまうお方のご高説は非常に勉強になります！！！１１１
この業界の一番の問題はそういった方々が設計（笑）と称して開発人員を引っ掻きまわす事がそもそもの元凶な気がしますが。

>これが鉄道の管制システムであれば、

鉄道のシステムは安全のため止めてしまうわけです。
つまり、サービスを縮退させて安全を確保しているわけです。
で、今回の事例もサービスを縮退させて、
それ以上の不具合（例えば顧客のデータ破損）を発生させなかったと考えれば
十分安全を確保したといえませんか？

銀行システムにサービス停止を許さないのに
鉄道システムはサービス停止してもよいというのはアンバランスかと思います。
しかも、鉄道のほうが（人身事故、天災など外部要因を除いても）頻繁に障害を起こしてますし。
もっとも風雨に吹きさらしの設備ですからある程度はしょうがないですけどね。

他の方が言われるとおり、比較対象として不適切ですね。

>また、
>夜間4千近くのプログラムが動くから比較は・・
>と別の方が書かれてますが、それをチェックする技術者>は一人ですか？
>十分と判断するだけの人員をかけて開発してきたはずです。
あなたはウィルスにかかっていないＰＣを1時間毎に1回ウィルスチェックをしているのですか？
ウィルスバスターが反応したときだけ対応しているのではないですか？
稼動状況をチェックしているのは人ではなくサーバでしょう。
正常に稼動している(稼動実績がある)プログラムをチェックするくらいなら1から作ると思いまし、１から作れるなら新基幹で開発していると思います。

＞あなたはウィルスにかかっていないＰＣを1時間毎に1回ウィルスチェックをしているのですか？
＞ウィルスバスターが反応したときだけ対応しているのではないですか？
＞稼動状況をチェックしているのは人ではなくサーバでしょう。

通常稼働中のシステムを指しているようですが？
勘違いしてませんか？

1から作った新基幹システムに今回移行して、
稼動初日それも当初から発生した障害ですよね。

オペレータのチェックという意味なら、異論はありませんが、
システム開発時にチェックが漏れた結果障害が発生したことを、お話しているはずです。

故に、「この時点で鉄道と比較するのはどうかと・・・」というのは、論点がずれている思います。

運用規模・開発規模は違っても、
おおよそ、開発規模／工数の開発密度は変わらないでしょうから。

ＰＳ：敢えて書きますが、稼働状況をチェックしているサーバーを開発したのは人ですよ。

コップに水が80％入っているのを見て
「8割しか入ってないじゃないか！誰が飲んだんだ！こぼしたのか！誰がこぼしたんだ！」って言う人みたいですね。
端的に言うとすごい狭量。

海外で同様の障害が起きてもここまで騒がない。
逆にこれまでの規模の統合を、障害発生から数時間で復旧させた点を考えると、前回のみずほ統合より前進したと思うが。
外から言う人はアナリスト気分でテスト不足だとかいろいろご自由に意見をいっているが、ミスを指摘することぐらい誰にもできること。テスト不足を防ぐ方法については精神論で言ってしまって・・・。「不具合は絶対にある、という感覚でテストをすること」なんて、当たり前です。
相変わらずですね、日本人のアナリスト風情の方は。

＞この件に関するmixiや世の中のブログを見回してみると、多くの人が「銀行のシステム統合だから仕方ないよね」という論調で語っているように思えました。しかし、それって本当に正常な感覚なのでしょうか？

別に「システム利用者」だったらかまわない感覚なんじゃないでしょうか。逆に、「大規模システム統合の直後は信用ならない」という警戒感を利用者側がもつことによって、リスクを回避することもできるはずです。

fさん、コメントありがとうございます。

記述が十分ではなく誤解を招き申し訳ありません。そもそも私が意図していたのは、トラブルが人命に関わるレベルの世界（医療、鉄道・航空管制、自動車制御系など）ではバグの発生を極限にまで減らすことに相当努力しているということは、こういった巨大システム統合においてもなし得る事ができるのではないか、という点でした。

もちろんバグをゼロにすることが現実的な選択肢ではないことも理解していますし、そのためにBCPが重要であることも強く認識しています。だから、三菱東京UFJさんの場合、どれだけしっかりとしたBCPが立てられていたか、これが重要だと考えています。

今回のトラブルは対外インターフェースにおける疎通確認テストに含まれる内容だと思いますが、インターフェースの仕様が誤っていたために起きた事件を想定したBCPが非常に事後対応的だったので、もう少し事前にリスクを世間（一般消費者）に示すアプローチをとった方が良かったのではないかと思っておりました。

例えば、メガバンクのシステム統合規模であれば、全国の金融機関に接続失敗時のオペレーションを何パターンか伝えておき、それを店頭や各種提携コンビニ、駅などに周知させるなど、それだけでも世間から見た障害時の影響というのは変わってくるのではないでしょうか。

話を戻します。

fさんのご指摘されている点につきましては、そういった社会影響の大きなシステムの比較対照に鉄道管制システムを挙げただけであったのですが、その文脈で「多くの人命を失う～」という表記は不適切であったと思います。失礼致しました。

aさん、コメントありがとうございます。

前述のfさんコメントにも述べさせて頂きましたが、たしかに人命を失うという類の表現は適切ではありませんでした。謹んでお詫びいたします。

とおりすがりさん、コメントありがとうございます。

前述のfさんへのコメントの通り、社会的な影響のあるシステム同士でのシステム運用の品質について問題提起することを意図しており、人命を失うという意味を挙げることは文脈上不適切でした。誤解を招き、申し訳ありません。誤字ご指摘箇所も速やかに修正致します。

ただ、ご指摘の通り、前もって利用者が対応できるようなアクションを促すことについては、三菱東京UFJさんはまだ余地があったのではないかなというのが私の見解でした。

ケンさん、コメントありがとうございます。

別の方が述べていらっしゃる通り、欧米では銀行のATMが予告無く止まることもしばしばあるため、ハッキリ言えば日本の銀行のサービスレベルの方が断然高いと認識しています。個別には挙げませんが、ATMの利用が一時的にできなくなったとしても、直近の営業時間帯に支店に出向き、そこで用を済ませるという行動が一般的に世間に根付いているので、日本ほど大きく騒がれることはさほどありません。これは、多くの銀行、それこそ上位行であれば暫定対応手順が整備されているので、大事には至っていないという話です。

プロジェクト管理技術の未熟さという点であれば、今回のような規模のプロジェクトであれば、憶測ですが、まずないと考えています。しかし、開発要員の劣化については否定できないかもしれません。そもそも優秀な技術者だけをのべ6000人もピックアップして投入するというのは、複数の巨大ベンダーが元請で対応しているとしても、物理的にムリに思えます。重要なのは、品質を高めることと並行してBCPを立てることだと考えます。

一言さん、コメントありがとうございます。

メガバンク規模の銀行システムが膨大なプログラムの上に成り立っていることはよく理解しております。前述fさんのコメントに書きましたが、確かに鉄道管制システムという比較対象は意図を伝えるには不適切であったと反省しております。

稼動しているシステム上で何が動いているかを把握することは不可能に近いというご指摘、確かに一人で全てを把握するのは不可能に近いですよね。一方で、領域ごとに担当を割り当て、彼らの持つ情報を一箇所に集約して把握するというのは、不可能とは言えないのではないかと考えます。こういうときに重要なのは、現場のトップチームがどれだけシステム状況を把握しているかでしょう。それによって迅速に障害箇所を特定し、暫定対応を立案するものだと思います。

今回のケース、例えば昨年のANAシステム障害事件のように複雑な要因によって生じたトラブルであれば、ここまで品質についてとやかく言うつもりはありませんでした。しかし、フタをあけてみると電文仕様が異なっていたことによるエラーという基本的な仕様にまつわるものであったこと、加えてインターフェース周りのトラブルが起こる確率が高いのは、過去の銀行系システム移行事例で分かっていたことなのに、そこに対するBCPに改善の余地を感じたこと、これらから銀行システムの運用品質としてどうなんだろう、というのがエントリーを書いた動機です。

追加さん、コメントありがとうございます。

個人情報保護法が広まってから、確かに顧客情報にまつわるテストデータは扱いが厳しくなりましたね。一方で、今回のケースでは、電文に使われている文字の種類を仕様として確認できていれば、もしかしたら防げたかもしれないなと考えます。

反論さん、コメントありがとうございます。

発生した事象によって直接的に影響を受ける人はご指摘の通りそれほど多くなかったかもしれません。ただ、三菱東京UFJさんが万難を排して取り組んだプロジェクトであったからこそ、些細な使用確認ミスから生じた障害に残念な気持ちを持った人は多かったのではないでしょうか。

鉄道管制システムを比較対象に用いた点につきましては、fさんのコメントに示した通り、適切ではなかったと反省しております。

KBさん、コメントありがとうございます。

おっしゃる通り、コストを度外視して品質を極限にまで高める必要はないと私も考えますし、どう頑張っても100％のレベルに達することは相当の困難であると認識しています。だからこそ世界規模でBCPに対するニーズが高まっているのでしょう。

とはいえ、安全神話とまで言われた日本、その品質の高さを維持しようという努力や気持ちをIT業界の人間はもう少し持っても良いのではないかとも思います。外資系に勤める私が述べるのは僭越ですが、世界的に見ても日本のシステムサービスレベルは高く、それを維持するために様々な努力が開発・運用現場でなされていることを知っています。この高いレベルを維持するために、高い品質管理の目で考えることは望ましいことだと考える次第です。

不見不知さん、コメントありがとうございます。

意を汲み取って下さりありがとうございます。まさにそういった気概の話を含めてお伝えしていました。100％障害の無いシステムが理想でしかないからこそBCPが必要になってくるという話でありますが、そもそも今回の障害はかなり基本的な（仕様確認レベルの）テストでチェックするものだとニュースソースから判断したので、このような厳しいとも取れる意見をした次第です。

いつどこななしさん、コメントありがとうございます。

不十分な説明、適切でない比較対象のために様々な疑問・誤解、恥ずかしい限りです。QuickCは当時小学生だった私にはかなり難しいツールでした。著名なプログラマの方も述べていましたが、今にして思えば、作りたい対象もなかったのにプログラミングの教科書をめくっていたことで、興味を失ってしまったのだと後悔しています。

設計と開発の担当者が異なるゆえに正しく仕様が伝えられていないということは、今回の件ではまさに当てはまるのかもしれないと考えています。情報システムの担当者レベルで打ち合わせた内容が正しく開発ベンダーに伝わっていない、開発ベンダーから挙げられた確認項目が正しく相手先の担当者に伝わっていない。いずれも障害原因の上位に位置するものです。ただし、これも突き詰めれば、個々人が自分に与えら得た役割をどれだけ果たせるかという点に帰結するため、そこでの不十分さを吸収できる体制をどこまで築き上げることができていたか、ということが最大の問題なのではないかと考えます。

sdfさん、コメントありがとうございます。

fさんをはじめとする様々な方にご指摘頂きました通り、比較対象として不適切でした。誤解を招き申し訳ありません。エントリーを書いた際には、鉄道管制システムが誤った信号を列車に返すことで対向列車の路線に侵入し、衝突するということでもあれば人命が失われるような事態も起こりうるだろう、という考えで挙げておりました。

通りさん、コメントありがとうございます。

私の意図で解釈するのであれば、本来IDSなどで除外されるべき基本的なウイルスが除外されず、端末のウイルスアラートに検知されてしまって、そのPCがネットワークから遮断されてしまった、というシチュエーションになるのかなと思います。これって、仕様通りIDSで除外されていれば、端末は停止しなかったかったのではないかなと。

みうさん、コメントありがとうございます。

ある意味では狭量という方もいるだろうと思ってはいます。しかし、その品質を当たり前と考えるのではなく、常にもっと高い品質を作り上げることに目を向けてシステムを生み出すことを続けていると、そういった厳しい視線を持たなければ、品質を維持することは難しいと考えます。私自身は外資系企業に勤めておりますが、米国の水準が何でも優れているとはまったく思いませんし、グローバル標準と呼ばれるものにも、日本のこれまでの品質管理の目線からすればレベルの低いものもあります。だからといって、低いレベルに合わせようと楽をするよりは、世界に名だたる品質を維持するように努力する姿勢が重要ではないかと考える中、巷ではかなり基本的な電文仕様の確認レベルのバグに対して優しいコメントがほとんどであったため、敢えて苦言を呈するエントリーを書きました。

最初にこういった意図を分かり易く提示できていなかった点、申し訳ありません。

あさん、コメントありがとうございます。

最初のfさんへのコメントに記した内容や他の方へのコメントの通りですが、海外では当たり前という感覚で済ませてしまうのは、せっかく世界でも最も品質に厳しいと言われる国でシステムインテグレーションをしているのに勿体無い気がします。こういった環境で世界に名だたるIT品質管理方法論を生み出すことが出来れば、日本のITベンダーは世界での影響力をさらに強めることができると思います。

UKの政府組織のITプロジェクトから生み出されたITILが今や世界30カ国以上でITサービスマネジメントのデファクトスタンダードになっていることを考えれば、日本の超大規模SIプロジェクトから新たなスタンダードが生まれても不思議ではないですよね。

そういうイノベーションを生み出すには、品質を突き詰める姿勢を持つことは有益であり、そういう意味で「不具合は絶対にある、という感覚でテストをする」という姿勢は重要だと述べております。分かりにくい表現で申しわけありません。

megaさん、コメントありがとうございます。

おっしゃる通り、システム利用者の立場の方が好意的な目線で接してくれることにはありがたいと思いますし、複雑なシステムの統合作業がいかに困難を極めるかということが世間にも理解されてきたのだと思います。

一方で、同業者の方々が書かれているブログ等でも同じような論調が多く、その理由も「メガバンククラスの巨大システム統合ならちょっとした変更でもトラブルが出て当たり前」というものが多く見られたので、頑張れば防げるエラーならば防ぎましょうよ、という意図を込めて書いたエントリーとなっています。

利用者のリスク回避については、先週末に三菱東京UFJ銀行でシステム統合の一部が行われるということを、他行利用者は知らない状況にあるかもしれない、というケースでの事前告知がなされていなかったという点で、まだ改善の余地はあったのではないかなと思いました。

システム開発は、中から見るのと外から見るのとは大違い。具体的にどういう風になっているのを知らないでおっしゃっているんでしょうね。多分プログラムを書いたことも見たこともないんでしょう。

＞安全神話とまで言われた日本、その品質の高さを維持しようという努力や気持ちを
＞IT業界の人間はもう少し持っても良いのではないかとも思います。

この日本の「コンピュータは絶対止まらないもの」という思い込みによる品質至上主義により、
どれだけIT業界の現場が逼迫し、「IT業界に入ると人間らしい生活ができない」などと
世の中から揶揄されているか。

あなたは知っていますか？

好き好んで品質を落としたい人は居ません。
品質を高めるためのモチベーションさえ削られてしまう状況を作り出しているのは
日本社会（企業）の間違った考え方であると思います。

追記を読みました。大規模システム開発において「バグの発生を極限にまで減らすことに相当努力してい」ないと考えているという事ですよね。そう読まれても仕方がない文章です。バカにしすぎです。

１００万件以上のテストが行われ、ほぼ全ての機能が正常動作している事実を無視して１件の些細な漏れをあげつらって「努力してない」というのはあまりにもひどい。

そして、エラーがあった際に縮退運転する、という点では鉄道と同じアプローチを取っているわけですが、その点についてはいかがですか？
もし明日、信号機故障で電車がストップした際にも同じ事をおっしゃいますか？

＞そもそも私が意図していたのは、トラブルが人命に関わるレベルの世界（医療、鉄道・航空管制、自動車制御系など）ではバグの発生を極限にまで減らすことに相当努力しているということは、こういった巨大システム統合においてもなし得る事ができるのではないか

ここの前提に無理があるような気がします。

開発の話ではありませんが、たとえば一般的な用途に用いられるサーバの場合、必ず「ハイセイフティ用途（いわゆる医療や航空宇宙関連などです）」には使用してなならない旨の警告が付されています。

一般用途サーバに対して、ハイセイフティ用途にも利用可能なほどの品質のサーバは決して企業は導入しませんし、メーカーもまず提供することはありません。
なぜなら、コストパフォーマンスが悪すぎるからです。
システム構築も経済活動なのですから、費用対効果を考えなければ意味がありません。

小さな開発チームで使っているファイルサーバであれば、いわゆる普通のPCをサーバ代わりに使うかもしれません。
あるいは社内インフラ用サーバなら、コールドスタンバイを用意しておくかもしれません。
顧客に対し重要なサービスを提供するサーバなら、可能な限りサービス中断が起きない構成を考えるでしょう。

費用対効果を考えれば当然のことです。なんにでも最大限のコストは掛けることはできません。
障害が起こったことで予想される損失が、掛けることのできる費用を決めるのです。

人命はお金では買えない、人命を左右する用途に可能な限り最大限のコストを払う必要があるからこそ、企業はそのコストを払いますし、さらにいえばそれを価格に転換し、ユーザもそのコストを払っています。

今回の件でいえば、このシステム統合がどれだけのコストを掛けるだけの、そしてどれだけの損失が発生しうるの案件だったか。
そう考えてみると、私には、確かに社会インフラとしての機能を持つシステムではありますが、医療や鉄道などの用途と同じようなコストを払うべき案件だったとは思えません。
そして、障害が発生したのは、ユーザの利便性が損なれる程度のレベルであり、決済不能で経済に影響が出るレベルではありませんでした。

はっきりいえば、「ユーザの利便性が損なわれるレベル」のことに、「人命にかかわること」と同じだけのコストは掛けることはできません。
「経済に影響が出るレベル」のコストも掛けることはできないでしょう。

　こういう方々がマスゴミ共と連携して世間を盛り上げて、不毛な国に仕立て上げていくわけですよ
　情報システムに限らず、日本国内の全てのシステムが狂ってます。

　生活の全てが過剰品質

　100Mの光ファイバー回線が、ベストエフォート型であれば月額数千円だけど、ギャランティ型を要求すれば月額数百万円かかるわけですよ。

　公共サービス全てにギャランティ型を要求する馬鹿な国民
　その莫大な対価は自分たちが払うだけなのにね

　だから超借金大国になる。
　公務員の給与を削ったり談合を減らしたり、そんな小手先で通用する次元じゃないのに、なぜ気がつかないのか？

>トラブルが人命に関わるレベルの世界ではバグの発生を極限にまで減らすことに相当努力している

こちらの書き方がまずかったのか、まだ理解されてないようで…

鉄道システムで人命に関わるレベルのトラブルは確かに起きていません。（福知山線の件は防ぐシステム自体が備わってなかった）
一方で信号トラブルによる運転見合わせという、軽度のトラブルは頻繁に起きています。

今回の件は鉄道システムにおける信号トラブルレベルの障害でしょう。
これを問題視するのなら、今日起きた上野駅の信号トラブルも問題視すべきかと思います。
そういう考えであるのならそれもありかと思いますが。

鉄道の信号障害や今回の件のような
「軽度の障害」も関係者は100%防ぐという「気概」を持て、
という点は私もそう思いますが、あくまで「気概」だけです。
現実に100%防げるとは思いませんし期待もしていません。

PG2年、社内インフラ設計/運用4年程度やって最後の最後で体壊した若輩者です

>品質至上主義により、どれだけIT業界の現場が逼迫し、「IT業界に入ると人間らしい生活ができない」
NAKAさんがBCPだの品質をもっと向上すべきでしょというのは理解できますが
現場のヒトとしては雑誌やネットで無意味にBCPだとかを連呼してほしくないです。
運用する上で”念頭において”設計する必要がありますがこれは”稼働中のすべてのシステム”を
対象とすべきではなくシステムのランク分けの上で対応すべきです。
全てのシステムでそういうことをしなければならないとわかっていない上層部は思い込んでしまいます。

品質至上主義に踊らされた会社役員のせいで、ある業務の障害で一度障害を起こしたシステムの監視を
（勿論１次対処が完了し安定していました）
2週間以上一人でしかも殆ど徹夜でサーバを監視する羽目になって私は体を壊して仕事を辞めました。
こういったカッコいい言葉を並びたてる事が逆に現場に無駄な負荷を
掛けるということも知ってほしいです。

情報メディアの曖昧な説明や正論が古い体質の会社でシステムを背負わされる者を
このような事態に追い込むこともあるということをご理解ください。

日本語がおかしいので訂正します。
>全てのシステムでそういうことをしなければならないとわかっていない上層部は思い込んでしまいます。
わかっていない上層部は全てのシステムでそういうことをしなければならないと思い込んでしまいます。

追記＞
品質が低くてもいいと言っているつもりはありません
私も仕事をする上で利用者に対して極力高品質になるように
努めていましたので。
ただ、正論だけが全てじゃないと言いたいだけです。

大陸浪人さん、コメントありがとうございます。

おっしゃる通り、外から見るのと内から見るのでは大違いであることに私も同意します。それを認識しておりますので、起きてしまったことについて部外者が責任を追及するようなことを述べるつもりはありません。私が気になったのは、初歩的に思えるインターフェース周りの障害が起きてしまった原因であり、負荷がプロジェクトに生じていたために、テストに不慣れな人材をテスト工程に登用せざるを得なかったということはなかったのかという点でした。これほど大規模ではありませんが、私も多段階サービスリリースを伴う基幹系システムでテストやプログラミングをしており、過去の経験から状況を推察した次第です。

kensさん、コメントありがとうございます。

品質至上主義によってムリなサービスレベル要求を突きつけられているシステム運用の現場は私も存じておりますし、そういった状況を改善することにこれまでも積極的に取り組んできておりました。kensさんが述べていらっしゃる、「品質を高めるためのモチベーションさえ削られてしまう状況を作り出しているのは日本社会（企業）の間違った考え方である」という言葉、まったくその通りだと思います。その状況を改善するアプローチとして私が考えているのは、ITサービスの提供側がイニシアチブをとってサービスレベル要求の再考を促す組織の構築です。決して労働時間を増やして無理やり品質を上げることだとは考えていない点をご理解頂けると嬉しいです。

みうさん、コメントありがとうございます。

誤解を招く表現を用いてしまったことをお詫びします。決して関係者の方々を誹謗する意図はありません。みずほ銀行の前例もあり、金融庁からは「バグの発生を極限まで減らす」プレッシャーが今回のシステム統合に向けられていたような情報を過去の記事で見知っていたため、今回はどのような品質保持体制を敷いていたのかが気になっておりました。他の方のコメントにも書きましたが、その些細過ぎるエラー内容ゆえに、どうしてそのような見落としがあったのだろうと疑問に感じたことがエントリーの発端でもあります。鉄道の縮退運転との比較ですが、例えばJR東日本では中央線の大規模工事（それによって信号機がストップすることもあるでしょう）を実施する前には利用を控えるような告知がなされるのに対し、今回も同じように事前に利用を控えるような代替利用の提案がなされていれば、もっとスムーズであったのではないかと述べております。

kentさん、コメントありがとうございます。

おっしゃる通り、ビジネスの効用とコストのバランスを考えれば、何が何でもバグを減らすというのは理想論であり、それをカバーするための事業継続性計画が重要だと私も認識しております。最初のエントリーで少々過激な表現を用いてしまったのは、タイトルに書いたとおり、「当たり前」という表現の多用が品質改善の意識を希薄にしてはいまいか、という私なりの懸念でした（杞憂であれば幸いです）。一方で、今回のシステム統合における障害発生を残念に思っているのは、これが11万人月という銀行・金融庁・SIerの威信を賭けたといっても過言ではない状況でもサービスに影響のあるバグが発生したという点です。これでより一層、ITILで述べるとろこの復旧計画が重要であることが再認識されたと感じております。

KBさん、コメントありがとうございます。

過剰品質に関するお考え、ごもっともです。私もコストに見合わないサービスレベル要求は棄却すべきだと考えます。ご提示下さったネットワーク回線の価格の通り、ベストエフォートではなくギャランティを強めれば指数関数的にコストもかかりますね。私が今回のシステム統合で感じたのは、ベストエフォートではなくギャランティを求めている金融庁の存在を意識して、莫大な対価（11万人月）を費やしてでも限りなくバグを減らしたいという特殊背景があったのではないかと推察しており、それでもやはりバグが生じたことについて一連のコメントを書いておりました。

sdfさん、コメントありがとうございます。

他の方のコメントにも書きましたが、sdfさんが仰っていることは十分に理解しております。そもそもは「気概」の話でした。私の表現が誤解を招くものであり、お詫びいたします。鉄道自体もご指摘された信号トラブルのような軽度障害は頻発しており、今回のトラブルがこれと同レベルの障害であるというご指摘は私も同意致します。一方で、関係者・特に金融庁などが投げかけた期待は並々ならぬものがあり、これが11万人月という途方も無い工数をかけた結果の障害であることについて、疑問を投げかけておりました。鉄道に例えるなら、「超大規模な駅舎を通常の倍以上の人員で工事した結果、旧線路・ホームから新線路・ホームへの切替は完了していたのに、ささいな不備があって一部信号が赤信号のままのため、始発車両がホームに進入できなかった」というケースで、なぜそんなにたくさん人がいたのに気付かなかったのかと疑問に思っているのと同じです。いくら手間をかけたところで障害は無くならないんだ、という結論を再確認したと思っております。

Chiさん、コメントありがとうございます。

大変過酷な状況をご経験されたことと推察します。私自身、Chiさんと同様の憂き目を経験しており、お気持ちは理解しております。同様の経験後、私はビジネスの重要性に応じてITサービスのサービスレベルを考えるべきであり、そこには内部・外部コストを考慮した上で、現場に非人間的な生活を強いることのない（つまりある程度の余裕がある）体制を築き上げることを提言・実行して参りました。正論だけが全てではないことも十分理解しております。このエントリーで述べていることは、11万人月という途方も無いプロジェクトの結果に対する疑問点ではあり、それがそのまま全てのシステム運用現場に適用されるものではないことをご理解頂けると嬉しく思います。その点につき、Chiさんのおっしゃるような誤解を多くの経営者に与えかねないという指摘、真摯に受け止めております。