本日の「記者の眼」は，4月11日付で掲載した記事の続編である。前回同様，本記事には宣伝文が含まれている。読み進まれる場合，その旨をご了承いただきたい。
「みずほ銀行」と「動かないコンピュータ」，そして「根本原因」という単語が入っていたせいか，前回の記事は「記者の眼」として過去最高のアクセスを記録した。読者の方々からの書き込みも非常に多かった。読まれた方々，ご意見を寄せられた方々にお礼を申し上げる。
今回は，前回の記事について寄せられた読者からの批判および質問，提言についてまとめてお答えしたい。続編を書くにあたって，すべての書き込みに返事を書くという，筆者恒例の手法をとろうと当初は考えた。だが，「掲示板のようで何が言いたいのか分からない」という批判を以前受けたので，別なやり方にする。
前回，記事の中で，「興奮して原稿を書くと体に悪いので，そのほかの教訓はまたの機会に触れたい」と書いた。これは一種の修辞であった。本当に興奮していては原稿は書けない。
もっとも執筆の動機は，メディアの一連の報道に頭にきたことだったので，書くと決めたときに興奮していた。ちなみに怒った理由は，テレビや新聞がトラブルの復旧に徹夜で取り組んでいる現場の担当者の状況をまったく無視した報道を続けていたからである。
動機が動機だったためか，読み直すとそれなりの迫力があるものの，話の展開はかなり荒っぽく，わかりにくい下りや誤解を招く表現があったのは事実である。そこで読者の批判にこたえつつ，前回言いたかったことを補強してみたい。読者の書き込みを引用するにあたっては，一部表現を変えたり，圧縮したりしていることをお断りしておく。
「谷島さん，あれは俺たちじゃなくて社長に言ってよ」
[2002/05/07]
銀行の頭取は謝罪すべきだし，もっとシステムに関わるべきだし，現場の苦労も知ってほしいとのこと，大変同感ですが，最大の問題であり非常に残念なことは，トップはこういう記事を読まないということです。個人的には，そこまで踏み込んだ記事を期待しております。[2002/04/11]
この記事が銀行関係者だけでなく全ての企業経営者に読まれることを切望いたします。日経本紙に掲載するのもよいと思います。
まったくその通りである。前回の記事を読んだ，旧知のシステム責任者の方から電話をもらった。彼は開口一番，「谷島さん，悪いけどあれは俺たちではなくて，社長に言ってよ」と言った。
しかし，これを書くのは悲しいが，IT Proも日経コンピュータも経営トップへの影響力はほとんどないに等しい。みずほフィナンシャルグループのシステム統合プロジェクトの問題について，日経コンピュータは1999年9月以来，数度にわたって取り上げた。だが，みずほフィナンシャルグループの経営トップへの影響はゼロであった。
どうすべきか。思いついたのが，書籍の緊急出版であった。正確に言うと，前回の記者の眼を読んだ日経ソフトウエアの編集長から，「あの論旨で本を書いてはどうか」というメールが来た。これが発端だった。
読者の方々は，今回の記者の眼でなにを宣伝しようとしているか，おわかりになったと思う。本日5月30日，日経コンピュータ編集部は，「システム障害はなぜ起きたか みずほの教訓」という書籍を出版した。これは一般の書店で販売される。
経営者は，IT Proや日経コンピュータを読まなくても，本屋へは行くだろう。一人でも多くの経営者が本書を読むことを期待している。本屋に行かない経営者の場合はどうするか。たいへんお手数であるが，ITプロフェッショナルの皆さんが購入し，社長室へ投げ込んでいただきたい。
すべてが失敗ではない，成功した部分は正当に評価すべきだ
前回の記者の眼の掲載が4月11日，本の制作が終わったのは5月16日。どこかの情報システム構築プロジェクトを思わせるデスマーチであった。あらかじめお伝えしておくと，この本は，日経コンピュータがこれまで2年以上取材を続け，掲載してきた一連の記事を再録し，一般の方や社長が読めるように改稿したものだ。これが短期間で完成できた理由である。
本の目的はさきほど書いたように，経営者に情報システムの開発・運用の実態や，システム統合プロジェクトとはどんな仕事なのかを伝えることである。もう一つの狙いは，みずほフィナンシャルグループのシステム統合にかかわった現場の方々になんとか元気を出してもらうことである。
本の前半は，みずほフィナンシャルグループの経営陣がいかにダメかが延々と書いてあるので，読むと暗くなる。だが，どのメディアもまだ書いていない新事実も載っている。それは，みずほフィナンシャルグループのシステム統合プロジェクトの中には，「成功したものもあった」ということである。この下りは本書の白眉と自負している。次に全文引用する。
実際，今回のトラブルに埋もれてしまったが，システム担当者たちの頑張りによって，厳しいスケジュールを克服し，統合に成功したシステムがいくつもある。ここでは，3事例だけを紹介する。
前述した通り，第一勧銀と富士通は勘定系システムのセンター移転という困難な大仕事を2001年11月に，パーフェクトにやり遂げた。
富士銀は店番変更に伴う元帳ファイルの再編成作業のリハーサルを2002年の正月休みを利用して実施した。1月2日には，全営業店に行員が出勤して，データを入力し，最終確認をした。こうしてシステム統合の3カ月前に，店番変更については万全の準備を整えた。
興銀を中心とする市場国際系システム統合のプロジェクトチームも奮闘した。2001年9月の同時多発テロにより，このプロジェクトは激震に見舞われた。富士銀と第一勧銀のオフィスが消滅したため，一時はプロジェクトを中断，米国拠点の復旧を優先した。米国拠点のシステム統合は延期したものの，欧州とアジアについては新統合システムを先行導入し，新旧システムを並行稼動させた。こうして，4月1日のシステム統合を成し遂げた。
この事実はニュースであると確信する。「あれだけのシステム障害を起こした企業の一部の成功を指摘して何の意味があるか」という意見には同意しかねる。4月1日のシステム障害の問題は追究すべきであるし，成功例は成功例として評価すべきものである。みずほフィナンシャルグループの関係者が全員無能であるかのような見方は間違っている。
「いったいどこが“根本原因”なのか」
読者からの意見と批判に戻る。いったいどこが根本原因なのか，という意見が寄せられた。
[2002/04/26]
記事の内容が理解できない。 なぜ，「動かないコンピュータ」の根本原因が，「本来はトップがすぐに謝罪すべきだった」，「現場の声に耳を傾け，彼ら彼女らをねぎらうべきだ」なんでしょうか。トップが謝罪してねぎらっててもシステムは動かなかったと思いますが。記者として致命的に文章を書く能力が不足しているように感じられます。[2002/04/17]
記事タイトルと中身が一致していないように見受けられます。当方で推定する根本原因は次のようなものです。●3銀行が一度に統合することには無理があった。とりあえず第一勧銀と富士銀を統合し，興銀は後でも良かったのではないか。●第一勧銀と富士銀の場合でも対等に近く調整が難しかった。●銀行内部の情報システム部門だけの自主開発に無理があった。●リレーコンピュータの発想は良かったが，システムの見極めが出来なかった。[2002/04/12]
表題から技術面が記述されていると期待したが，残念の一言。 表題の根本原因につられて全部読んで期待した自分が情けない。
ご批判の通り，根本原因がなにか，今一つ明示的に書かれていない。改めて書くと，「頭取が情報システムに積極的にかかわっていなかった」ことが根本原因である。ここで根本原因とは，直接の原因を生み出したものと考えている。
システム障害の直接の原因は，開発の失敗，テスト不足といったプロジェクトマネジメントの失敗である。では，なぜプロジェクトをうまく進められなかったのか。あるいは，なぜトラブルを防止できなかったのか。
答えの一端は，旧第一勧銀とシステム子会社だけの閉じた世界で開発をしたことである。なぜ旧富士銀は協力したり，進捗を監視しなかったのか。答えは旧第一勧銀のシステム幹部と旧富士銀のシステム幹部が反目していたからである。なぜ反目していたのか。経営トップが現場任せにした上に，対立を激化させるようなことをしたからである。
経営トップが本当にやるべきことは？
次に頭取がシステムに関与すべき，という主張に対して意見があった。
[2002/04/11]
谷島さんへ。「本来はトップがすぐに謝罪すべきだった」。違います。答えは現状を速やかに顧客に伝えることが必要で謝罪することではありません。顧客にとっては頭を下げてもらうことが目的でありません。「頭取はもっともっともっと情報システムにコミットしなければならない」。 間違い。答えはシステムを正常に稼働させるのは部署の仕事です。システムが正常に稼働することを前提に頭取が動くのです。谷島さん，あなたは本質を見ていない。それぞれの人たちが部署の役割を認識していないから問題が起こるのです。危機意識の欠如。簡単に言えば，「たぶん」，「だろう」が思考の中にあふれているからです。今の日本は危機意識が無さすぎます。危機意識の判断は日常生活のあらゆる場所で 必要とされます。仕事に際し，「もし」の気持ちがあれば今回の問題は起きなかったのです。「たぶん」，「だろう」を除く気持ちが大切なのです。[2002/04/11]
「トップがすぐに謝罪すべき」について。「すぐに」は理解できるとしても，「トップ（頭取）が謝罪」は絶対必要とは思いません。頭取の果たすべき責任とは何ぞや。謝ることか。否。誰が謝るかは適宜判断すること。「頭取が情報システムに積極的にかかわっていなかった」について。頭取の仕事は適切に業務が遂行されているか監視する体制を構築することであって，業務内容自体をチェックすることではありません。それは執行役員の仕事です。つまり，プロセスレビューとコンテンツレビューの違いと言えば良いでしょうか。この違いを分かっていないマネージャーは多いと思います。だからプロジェクト管理が拙いと考えます。頭取に対するコメントに推測が多すぎます。今後，実際に取材して疑問をぶつけて明らかにしてください。
トップの謝罪に関する下りはかなりの誤解を招いた。この点は後述する。「情報システムにコミットしなければならない」。これも確かに曖昧であった。普段はコミットなどという言葉は使わないようにしているのだが，やはり興奮していたのか，間違って使ってしまった。
経営トップがやるべきことについて，前回の記事から再掲する。「情報システムに何をさせたいのか，宣言することである。システムの仕様を巡って意見対立がおきたら，それをさばいて，決めることである。ある新商品を出すとしたら，どのくらいのシステム開発期間とコストがかかるのか。開発プロジェクトのどの辺に落とし穴があるのか。トラブルが起きたらいかなる事態が起き，どう対処するのか。こうした動かないコンピュータ対策を知っておかなければならない」
もちろん，実際のやり方はいろいろある。しかるべきリーダーをトップが選んで実務は任せる場合もあろう。みずほフィナンシャルグループの場合，CIOの人選についても失敗している。また，企業によっては，頭取が「業務内容自体をチェック」することもある。実際，その実例があり，今回の本に掲載した。
先の意見の中の「頭取に対するコメントに推測が多すぎます」について回答する。頭取に関するコメントとは，前回の記事の中で以下の部分である。
「本音は，『コンピュータのことなどよく分からない。現場の責任者に任せる。よきにはからってくれ』というところだろう。各行の前頭取たちは，『システムのことは任せていたのに，うちの情報システム部門はなにをやっているんだ』と思っているのではないか。残念ながら，この問題は両行に限ったことではない。悲しいかな，たいていの頭取は情報システムなんぞに興味はないのである」
2回開かれたみずほフィナンシャルグループの記者会見で，筆者は旧3銀行の頭取に直接質問をした。そのやり取りは日経コンピュータや今回の本に書いた。このやり取りから前回の記事で書いた上記の部分は，間違っていないと思っている。
記者失格と言われそうだが，もはや「実際に取材して疑問をぶつけて明らかに」することはできないだろう。「システム部門をけしからんと思っていますか」と質問したとしても，「いやトップだった私の責任」と答えるだろうからだ。
「今の日本は危機意識が無さすぎます」と書かれた読者の意見には，危機意識については賛成である。ただし，「システムを正常に稼働させるのは部署の仕事です。システムが正常に稼働することを前提に頭取が動くのです」という指摘には同意できない。この点について，次の読者が筆者の考えを代弁してくださっているので，それを引用する。
[2002/04/11]
「経営トップの責任ではなく，現場の責任感の問題だ」という読者意見に反対。あらゆる仕事に対し，担当する現場の人間に強い危機意識と責任感が必要とさせるのは当然のこと。この読者はそのことを指摘したかったのでしょう。それは勿論正しい。しかし，ことみずほとUFJの件に限って言うなら，経営トップの責任は免れないでしょう。経営者なら，システムの重要性と自社のシステム部門の力量とをはかりにかけ，適切なプロジェクトマネジメントを遂行する責任があります。銀行にとって勘定系システムは大動脈です。雑多仕事ではありません。システム部門に任せっきりで良い訳はないでしょう。もしもシステム部門に「強い危機意識と責任感」が欠如していたとするなら，それを放置していた事自体，経営者の怠慢と言えます。結局，両行の経営者に「強い危機意識と責任感」が欠如していたのが元凶なのです。
経営トップの「謝罪」を考える
経営トップ問題については，「謝罪」と「現場担当者をねぎらえ」という点が誤解を与えてしまった。
[2002/04/12]
企業トップの役割に関してはちょっと違和感があります。「すぐ謝罪」，「現場でねぎらい」はいかにも表層的なパフォーマンスのように思えるからです。本来トップがなすべきは「会社としていかにアカウンタビリティを果たすか」を考え・実行すること，現場が復旧作業をしやすい環境を作ること，そのためのリソースを投入すること，といったことだと思います。殺人的に忙しい時に訳のわからんトップが現場に来ても邪魔なだけだと思いますよ。[2002/04/16]
現場をねぎらう方法はいくらでもあるはずだ。TOPが直接現場に行ってねぎらう方法もあるが，はっきり言って邪魔です。食事の差し入れや，医師，看護[婦士]やマッサージ士の手配などする方法はいくらでもあります。要は手段の問題かと。[2002/04/14]
記事の中で気になったのは頭取がコンピュータセンターに行って部員をねぎらうべきと言っている事です。この段階で情報処理関係者は寝る間も惜しんでトラブル対策をしているのに，頭取にのこのこ来られても,何もわからない人間に説明しなければなら無いのは大変な苦痛です。また,そのために復旧作業が遅れてしまいます。その意味で記事を書いた人も余り現場を知らないのかなと思った次第です。いらぬお節介が記事を色あせさせてしまいました。
確かに単に謝ればいいというものではない。あれだけのトラブルが起きた以上，謝るかどうかは別として，経営トップが会見すべき案件だということを言いたかったが，言葉足らずであった。理想をいえば会見では，「当行の現場は不眠不休で作業にあたっております。必ず復旧させますから，もうすこし時間をいただきたい」くらいは言ってほしかった。
一方，コンピュータセンターへ行ってねぎらう件については正直言って，読者の方々の誤読に驚いた。筆者は実務経験がないので，「あまり現場を知らない」どころか，現場をまったく知らない。しかし，修羅場にトップが現れても迷惑だ，という常識は持っている。4月のトラブルを乗り切った段階で，センターを訪問し，労をねぎらってはどうかと書いたつもりだったのである。
読者の書き込みを見て，「インターネットの記事を読者はざっと読んで，すぐ書き込みをするからこうなる。もっとちゃんと読んでほしい」とつぶやいてしまった。
ところが念のためと思って自分の記事をみてびっくり。確かに読者の指摘が正しい。「トラブルを乗り切った段階で」という下りを書いたつもりだったが，ない。苦しい言い訳をすると，記事には，「徹夜の連続をどう切り抜けたのか。現場の担当者の声を聞いた上で，彼ら彼女らをねぎらうべきである」とあり，「切り抜けた」と過去型にはなっている。ただし，「トラブル収束後」と明記しない以上，「今すぐ現場に行け」と読めてしまう。
[2002/04/11]
視点として加えて頂きたかったのは，「自行のシステムを資産としてしか見ずに，合併の際の政争の具にしてしまった」点です。多くの経営トップが自社の情報システムを本音の部分でどの様に見ているのかに迫ってくださることを期待しています。単なるバランスシートや管理費としての数字に化けて理解されていたのであるならば，情報システム構築に必要な時間や顧客に与える利便性としての効果を議論できなくなっていても不思議はありません。残念なことに経営トップにとって「ＩＴ」はこんな程度の認識しかされていないのかなぁと，今回のみずほの社長答弁やその他のドタバタを見て，再度がっかりした次第です。
この方の意見に賛成である。ただし，細かいことを言うと，みずほの経営トップは，「システムを政争の具」にはしていない。むしろ合併をうまく進めるために，「富士銀が第一勧銀にシステムの主導権を譲った」と言える。政争というより，政治の具にしたわけだ。この経緯はしつこく本に書いた。
安易なアウトソーシングは問題解決にならない
[2002/04/11]
「ITベンダーにアウトソーシングしても何の解決にもならない」との意見には反対です。経営の意思決定を含めて，コンサルタント集団であるITベンダーに任せるべきです。[2002/04/18]
記事には同感できる部分も多いが，「ITベンダーにアウトソーシングしても何の解決にもならない」は偏見で，システム開発・維持・運用はアウトソーシングこそすべきで，企業本体は顧客第一で本業に徹すべきでしょう。
これまた言葉足らずであった。「システムは難しくてよくわからない。アウトソーシングしてしまえ」というように，「安易に」アウトソーシングしても解決にならないというつもりであった。
ただし，アウトソーシングについては稿を改めて書きたいが，筆者は「基幹系システムのフルアウトソーシング」については反対の立場である。システム開発・維持・運用は本業ではないが，本業を支える必要不可欠な業務である。それと「経営の意思決定」は外部に任せてはまずいのではなかろうか。
最後に，日経コンピュータのWebサイト「日経コンピュータExpress」の中にある「動かないコンピュータ・フォーラム」の宣伝を再びさせていただく。本日30日から，みずほのトラブルについての意見を掲載している（記事へ）。6月13日からは日経コンピュータ購読者専用ページとさせていただく予定だが，それまではどなたでもご覧になれる。お時間のあるかたはこちらも覗いていただきたい。
（谷島 宣之＝日経コンピュータ副編集長）
■2002年4月1日以降の「みずほ銀行システム障害」関連の一連の報道は，特集ページ「みずほ銀行システム障害」にまとめております。どうぞご利用ください。
