2013年9月アーカイブ

Amazonアフィリンク

みずほ銀行で過去に2度起こったシステム障害について解説し、これと類似のシステム障害もいくか紹介しつつ、システム障害を回避するためにはどうすべきかについてを日経コンピュータの視点で論説している。特に、大規模情報システムのあるべき姿について触れていて、これらは技術の問題ではなくマネジメントの問題だと力説している点が特徴的となっている。「システムはなぜダウンするのか」のシリーズ本になる・・・のかな。

2回目の障害になる、2011年3月に起こった義援金口座の管理ミスが原因のものを受けて、この障害を受けての今後の対応方針について大いに警鐘を鳴らしているのが特徴となっている。結果的には、みずほ銀行とみずほコーポレート銀行の合併を2013年7月に行っているけど、システム統合・・・というか新規作り直しはまだ先のようだ。一部では「みずほ銀行ATM停止なんて聞いてなかった」みたいなニュースで語られてますが、舞台裏はやっぱいろいろ大変だなぁと思い知らされる例です。ちなみに、システム障害については調査報告書がみずほ銀行(旧みずほフィナンシャルグループ・・・でいいのかな？)から出たりしている模様。

1回目の障害になる、2002年4月に起こった合併(日本興業銀行・第一勧業銀行・富士銀行)に端を発するシステム統合での失敗は、Wikipedia上にあった記事が「独自研究」で証拠不足で消されたりしていたりと、実はほとんど公開情報がない模様。とりあえずまとまってるとこを3つほど張っておこう。
2002年4月、みずほ銀行に何が起こったのか
von_yosukeyanの日記： みずほ銀行システム障害とは何だったのか？
失敗事例 ＞ みずほフィナンシャルグループ大規模システム障害

「プログラム的な仕事は工数管理だとかいうマネジメントと合わないんじゃないか」の議論はよく見かけるものの、個人的には、100人を超えるような(==数名のスペシャルプログラマで片をつけることができない程度の)規模だとそういう工数管理のやり方をせざるを得ないのかなと思う。だって人多いと意思疎通取るだけで大変なんだもん。数席隣のやつの実力とかやってることとかすら把握できなくなるもん。組織だったやり方じゃないと開発すらできなくなっちゃうもん。「100人」なのか「50人」なのか「20人」なのかは意見の分かれるところだとは思うけど、少なくとも大規模開発だとマネジメントは必須かなと感じる。あとそういう規模だと「スーパープログラマ」みたいなのも不要かとも思う。不要というといいすぎだけど、そういう人は自分でコードを書く役割を果たすんじゃなくて、設計だけをひたすら請け負うような役割を果たさざるを得ないわけで、そういう意味でその人はもはや「スーパープログラマ」じゃないよねと。

あと考えさせられるのは、第9章に書かれている「全体が分かる技術者が減少」の話。本書的には、バブル崩壊に発するその後の景気低迷で企業がシステムを一新する機会を失って、その結果「やってみないと伝わらない」ような技術が後継者へと引き継がれなくなり、そのうち古くからいる現場人が引退して「全体が分かる技術者が減少」していると説明している。なんかそれってもろに、20年ごとに遷宮させることで技術伝承させてるんじゃないかという話の伊勢神宮の式年遷宮と一緒なのね。なんかこう、同じ担当者にやらせ続けた方が技術習得コストを抑えられていいよねと言い続けていたら、担当者が引退したり辞めちゃったり死んじゃったりして大混乱するトラックナンバー的な話に通じなくもない。「ジェネラリスト」「スペシャリスト」の話なのかもしれない。

もう1つ気になったのは、13章の「臨機応変に動くには高度なスキルが必要」の最後の段落。ちょっと引用すると

机や椅子が壊れている、打ち合わせしようにもホワイトボードすらない、緊急に連絡したくても携帯電話の電波が入らない、といった問題を見つけ、七十八拠点でオフィス機器を新調するなど職場環境の改善につなげた。

えぇ話やなぁー、・・・じゃなくて、、いくら忙しいからと言ってこういうとこを手を抜いてると本当に忙しい時にものすごく痛い目を見るんよねぇ。いつしかのスラドのコメントで見かけた「あまり仕事がはかどらないときはエディタの設定などのメンテをして堂々とさぼってる方がいざというときにちゃんと動けてトータルで効率よく仕事できる」という趣旨の話も理解できる。本当に忙しいときはどうしようもないけど、年がら年中忙しいのは本当に勘弁してほしい・・・目の前のバグつぶしで精一杯で開発環境整えるのすらままならないのは本当に勘弁してほしい・・・

・・・なんか最後の方はタダのグチになってしまいましたが、勘定系の情報システムでのトラブル事例を知るという意味では大いに意義のある本かと思います。ただどちらかというとマネジメントのあるべき論の話なので、そっちに全く興味ない人は読まなくてもいいかなとは思います。

普段はこの手のイベントに滅多に参加しないですが、とある友人がなぜか興味を持ってたんで、じゃということでHATSUNE Appearance 『夏祭初音鑑』に行ってきました。一言で感想を言うと、あぴリンさんがかわいくてよかったです。

・・・いや、この感想だけだとただのリン廃に間違われてしまうので、続けておくと・・・

ちょうど1年前に八景島シーパラダイスでプレビュー公演されたのをベースに、よりブラッシュアップしてまとめられたのが今回のイベントです。

で、もう少し技術屋視点的に掘り下げると、このイベントでは映像投射のシステムとしてEyelinerてのを使ってます。これはどちらかというと去年Perfumeのライブで使われたというのが有名なようで、それを考察したこんな記事が参考になります。要するに、透明な斜めスクリーンにプロジェクターから投射することで、観客席側への反射を押さえつつ、透明スクリーンに投射された映像と透明スクリーンの向こう側との共演をするわけですね。反射を押さえられるのがメリットな反面、輝度を稼ぎにくいというデメリットがあるわけです。・・・そういわれればNHKのサイエンスZEROで放送してたような、と思って調べてみたらあった。

でいざ実際に見てみると、やっぱりどうしても細かいところが気になってしまうわけで。ざっとあげると

• ミクさんのツインテの物理演算がやっぱまだまだだなぁ、MMDベースだと厳しいかもしれないけど。まぁ極めるとポニテの物理演算でイグノーベル賞が取れるくらいには難しい分野ではあるけど。
• 奥スクリーンへの明るい投射と重なるとどうして「透けている」のがわかってしまう。動きが激しい時も比較的その傾向あり。
• スクリーンの下ギリギリに投射できないのでどうしても「足が浮いている」ように見えてしまう。マジカルミライの場合は結果的に足下のスポットライトでうまく隠れてるようでした。
• 立体感が弱いので、複数人が「重なる」時の映像がどうしても不自然。
• 手前の透明スクリーンと奥のスクリーンの2つという構成なので奥行き表現にはやっぱり限界があるのかなぁ

表現の幅としては、光を使うんじゃなくて闇を使ったほうがいいんじゃないかと個人的には思うわけで。「秘密警察」の「朝から晩まで?♪」の右の方に投射しといて一瞬ブラックアウトさせて左の方の投射に切り替えるところとか、そういう「見せない」時間を作る方が動きが感じられて個人的にはおもしろいと思います。終わった後の友人との会話で「スクリーンそのものを動的に動かせばより3Dっぽくなるんじゃね？」とか冗談半分で言ってましたが、「見せない」時間を意図的に作るのならば動かすことも現実的になる・・・いやさすがにムリか。

まぁそんなむずかしいことはおいといて、あぴリンさんがかわいくてよかったです。