2008-06-29
「設計の問題であるのは自明」
要求仕様の問題であるのが原因の大部分を占めるのに、こんな風に客に言われたら泣いちゃうよ僕。
日本の社会に蔓延る「暗黙的にわかるだろ！常識で考えろ！」な発想がSI業界をダメにするんだよ。これはSI業界を改善したって無理。だって客はSIじゃないんだもの。
Martin Ellerby / Malcolm Arnold Variations
最近はコンテストの映像がストリーミングで流れたりして、マイナー音楽ファンとしてはとても嬉しく思ったりしているのですが、いつも見逃すんですよね。
http://www.themusicpage.com/showVideos.php?v=843
今年のAll England Mastersの課題曲はエレビーの「マルコム・アーノルド変奏曲」でした。去年のヨーロピアンの課題曲、「エルガー変奏曲」も良かったけど、今回のもなかなか。コミカルな感じが随所に出てきて、アーノルドへの愛を感じます。
エレビーは最近円熟してきた感じですね。
ロスト・エコー / ジョー・ランズデール
超能力探偵者できっちりとしたミステリといえば日本では西澤保彦ですかね。ちょっとパズラーよりでフェアに徹している感がありますが、鬼才、ランズデールのミステリはちょっと青春小説っぽい、甘酸っぱい(といってもランズデールですから簡単に人が死んじゃいますが)。
- 作者: ジョー R.ランズデール,北野寿美枝
- 出版社/メーカー: 早川書房
- 発売日: 2008/05/09
- メディア: 文庫
- 購入: 2人 クリック: 15回
- この商品を含むブログ (12件) を見る
ふとしたことで、片耳の、失った聴力を回復すると共に、その「場」に音として記憶された過去の負の感情を伴う出来事を再生できる能力を身に付けた主人公。その能力にとって、未知なる場所はいかなる負の感情が記録されているかわからない危険地帯。主人公は長ずると、その能力から逃避するかのように、酒びたり。
父親が自殺したことにされたことが納得いかず、警官になった幼馴染に再開して、その過去の事件を追うことになった主人公の、いわば成長物語なんだけど…主人公を成長させるには人が死にすぎですｗ
飲んだくれな護身術の師匠と共に酒を断ちながら、事件に立ち向かう主人公。しかし、出てくる悪役がまたいかにもって感じでいい味出してます。映画っぽい。
登場人物のセリフもこれがなかなか味わい深いです。ちょっとグロい感じのアクション描写とSF的な設定に抵抗がなければ楽しめるだろう極上のエンターテイメントミステリです。
グレイズ・アナトミーのCMがなんかアレ
昨日の晩からどうも体調不良なのでずっとねっころがって久々にテレビを見ていたんだけど、結構な頻度で流れる「グレイズ・アナトミー」のCMがなんだかムカつくのね。
かなり高いテンションで「これを見ると元気が出る」的なことを力説する女性。でもカットインする「グレイズ・アナトミー」の映像はかなり凄惨っぽい医療現場。どうやら青春医療ドラマらしいんだけどね。
確かに、医療ドラマということを強調したいからそういうシーンになっちゃうんだろうけど、普通そういうの見たら「ER緊急救命室」とかを想像するわけだ。そんな映像見せながら、笑って「見たら元気になっちゃう！」とか力説するCMって逆効果だったりしないのかなあ。
ウェブ時代の週刊誌記事
発言を意図しない方向に捻じ曲げられて記事になってしまうようなことは古来からよくあることではあります。中には美味く伝えられなかったことが原因のこともあるでしょうけど、念押ししても恣意的な方向で書かれちゃったりして。
でも、既存メディアの人はウェブページを持つ人を取材するときは気をつけなきゃならない。何しろ自由に反論できる場があったりするし、それこそ取材テープの公開みたいなことも出来ちゃう。
しんどいことだと思いますけど、事実を捻じ曲げて書くことは難しくなりましたね。もっとも、相手のウェブページにホントのことが書いているとは限りません。読者に期待するしかない。けど、人は信じたいものを信じるからなあ。
これは全くの嘘です。ちなみにこの質問、実際のインタビューでは「夜中にアシスタントに大量のファックスを送りつけ・・・」でした。自分が「何のために夜中アシスタントに大量のファックスをするのですか？」と聞くと、新潮さん「なんの・・・ため・・でしょうねぇ・・・」と、答えていました。そして、記事になってみたら上記のように『アシスタントのファックスに』が『編集のファックスに』に変わっていました・・・もちろんこのインタビューの会話は録音してあります。ちなみにいえば、新潮さんのレコーダーでもちゃんとこの様子は録音してあります。
おい・・・これは・・・ （旧）雷句誠の今日このごろ。/ウェブリブログ
いつまでもこういうことやっていると時代に取り残されてしまいそうです。憶測はいくらでも書けばいいとおもうけど、事実関係まで脚色するとこうなっちゃう。もちろん、どっちが正しいかは録音テープが公開されないと判断できませんけれど。
なんかさ、こう、何かの不正を糾弾する！！みたいな記事なら正義に燃えるあまりちょっとアレな記事になっちゃうってのも理解可能なんだけど、揉め事おもすれーｗｗみたいな記事だから余計にそう感じちゃうのかもね。
銀行の言語事情
といってもグローバルに活躍するためのマルチリンガルな話ではありませんよ。
今やメガバンクになってしまいましたが、僕がIT業界に入ったときはまだ都銀と呼ばれていた某銀行でのお話。用語について一切説明せずに行ってみる。世代チェッカーかも。
ホスト系
今やメインフレームだからといってホストでもない時代ではありますが、都銀のシステムはトランザクション量やダウンタイムの問題からやっぱりメインフレーム、で、過去の遺産がありすぎてホスト型。
言語はCOBOLが中心ですが、コア部分に近づくとPL/Iだったりアセンブラだったりする。大事なスキルはJCLを書けること。まあ、JCL自体はシェルプログラミングと変わりません。VOL-=SELの指定とか面倒だけど。基本的に端末のI/Fを想定しているから、SNAとかFNAとかで通信しなきゃいけなくて手続きはめんどくさい。メモリとかディスクの容量が少なかったときの設計を引きずっていて、色々と余裕のないフォーマットになっていて、あの手この手で情報量を減らしているせいで非常にわかりにくいことも。
まあ、バッチ処理はメインフレームは早かったりします。
最近はコア部分もJavaにしようぜって騒いでる。多分上の人はJavaの何が良いか良くわかってない気がするけど、技術者の確保がしやすいという点では有望。当然心配されているのはパフォーマンス。未だに５年位前の認識で語っている人がいる。
でもまあ、設計次第で遅くなるのはどの言語も一緒とはいえ、Javaは遅く書きやすい気もする。
ホストは色々と管理が面倒で、DASDの場所指定がめんどいとか、IMS/DBはISAMの再編成なんていう馬鹿馬鹿しい仕事も良く入るし、順編成が全件舐める逐次処理に強いのは確かだけど、そろそろRDBでもいけるよね。
システムでかいから、あんまり占有できなかったりして、いざ打鍵しようとしたらリージョン落ちてるとか、VTSを借りなきゃ返さなきゃとかあわただしい。
中継機
この辺が一番最初にオープン化されたんじゃなかろうか。僕が入ったときはもう全編UNIXな感じで。当時はLinuxなんてないも同然だったから当然商用UNIX。AIXとかHP-UXとか。Solarisはあまり見なかったけど、シェルが違うからなあ。
言語は圧倒的にC。ミドルがCのAPIしか持っていないことがほとんどだったから。Javaが活躍し始めてたけど、「Javaだとあれが使えないからなあ」という理由が多くてね。JNIなんて危険だよねってな。
この手のプログラムは電文変換をすることが多いんだけど、Cならではのありがちな「領域はみ出し」によって数々の潜在バグが作りこまれていたものです。あと、プロセスを多重化するから、処理の入り繰りでおかしくなるとかね。
フロントエンド側とはMQとかで通信できてかなり楽ちんだったけど、ホスト側はSNAとかいちいち面倒です。何が面倒かって、接続用のお手製ミドルがあるから繋ぐのは簡単と思いきや、端末の採番依頼をして定義してもらってそれを受け取って面倒な接続テストをしつつ、ホストの運用に合わせて上げたり下げたりしなきゃならない。おかしくなったからリブートしてお茶にごし、とか出来ないんだよなあ。ホスト端末イメージの場合は。
フロントエンドサーバ
相手が外部システムだったらそれに合わせて言語を選んだりするけど、WebだったらJavaですね。なんでJavaかは不明ですが、銀行がインターネットバンキングをやり始めたときに、既にJavaに注力し始めていた米IBMが作ったWebフレームワーク(と呼ぶにはちょっとアレなものだけど)を採用したからかな(多分都銀ではさくら銀行が最初だ)。それ以上の利用はあまりないけど、Java自体が商業利用にコミットしていて、IBMやSUNのサポートがかなり受けられる期待があったからかも。テレホンバンキングはCだったな。
当時のプログラムとか見ると、「オブジェクト指向ってなんだっけ」みたいなものが山ほどあるはず。だって作っている人たちもわからないもの。ちょっとAPIが多くて便利なCぐらいにしか思ってない人もいただろうし、それこそC++から来た人は「ポインタないとか言っておいてNullPointerExceptionとはなんぞ」と思っていたに違いない。
やっぱり当時のJavaは使い方が悪いと遅くて、様々なテクニックを駆使して(いる時点でJavaっぽくはならないことが多い)早くなるように頑張っていたりしました。
Javaならではの何かってのはないんだけど、とにかくスケールするWebシステムの基盤があまりなかったから、はじめから大規模システムを想定していたJ2EEは、少ない選択肢の中で独占権を得たようなものですね。
あと、なんとなくだけど、アプリケーションが別サーバーにあるとか、ソースがそのまま動作しない(コンパイル必要)とかが銀行の文化に合っているのかも知れない。リリース管理とかを考えると、ある程度大きな塊になることも重要で、JarとかWarとかになるのがいいのかもね。
ちなみに、僕はシステムの本題とは違うところでちょっとしたページを作らなきゃならなくなって、Perlで書いたCGIを動かしたりしましたよ。ただ、ちょっとした奴ね。フレームワーク作ってどうたらって話じゃなくて、元々あるプログラムのラッパーみたいな奴。
端末とかATMとか
もはやグリーンディスプレーのダム端末などはなくて、Web端末ですよ。でも、頑張って昔の端末っぽく動くようにしているｗｗ努力無駄すぎｗｗ
まあ、テーラーさんに余計なことをやらせないためたっぷりと縛りをくれているわけです。JavaScriptを駆使したりしてて色々と大変なんだけど、とにかく電文がホストの電文だから、GWとかWebサーバは一生懸命だろうなあ。未だに高輝度指示とかするわけよｗ
ATMの印字票なんかも今更ホストに場所とか指示されなくても十分できるんだろうけど、ホスト側を変えるのもめんどくさいしなあ。
行内システムとか
これはもうWebとNotes。たまにSAP。Web部分はJavaだし、DBのバッチはCとOracleの場合Pro*Cとかで。情報系コアの処理量が多いところはホストと同じだったりするし、昔のシステムを引きずっているところもそう。面倒なのは外字だよなあ…
行内システムはわりと新しいシステムを採用する傾向があるんだけど、見た目は相変わらずホストの端末ですｗ勘弁ｗ
軽量な言語とこれから
なんでPerlやRubyが銀行で使われないのか。それはベンダー側の都合だよねえ。別に言語として使えないから、ではなくて、Javaを売り込みたいから、という戦略が続いているだけで。もちろん、スケーリングの問題が常にあるし、インタプリタなのが微妙に気持ち悪いとか、遅いだろうとか、そういうのもあるだろうけれど、Javaを中心にすえて、自社のミドルのAPIも作って、技術者も養成して、開発環境も世の中に提供して、という戦略だよね、やっぱり。
そういう意味では、SOAを大企業に適用していくってのは、フロントエンドはなんでもいい宣言になりうるわけで、現にIBMなんかはJavaとRubyの親和性を探っているし、結構プッシュもしている。Groovyってのを作ったけどあまり使われる話を聞かない。JRubyはどうなるかな。
ミッションクリティカルだったり、特殊な仕様をつかわなきゃならなかったり、他のモジュールと連携しなきゃならないときに、色々できるプログラマを集めるのもめんどいから、できるだけJavaで完結するように、という現状はありますが、今後フロントエンドのWebにJava以外の言語が使われるシチュエーションは増えていくようにも思えます。バックエンドのサービスを弄らなくていいシステムを作るんであれば、Javaである必然性はあんまりない。
でも銀行のシステムみたいな、戻るボタンを使ってあれこれして見た目と結果が違うじゃないか的難癖を付けられることを怖れるシステムでは普通のフレームワークをそのまま使えなかったりはして、色々とね。
まとめ
というわけで、銀行は、その時々によってそれなりに最先端なシステムを、しかし、慎重に導入してきました。言語もアセンブラ⇒PL/I・COBOL⇒C⇒Javaと移り変わっていっています。そのうち別の言語が使われるかもしれません。でもJavaが停滞したとしても、それに変わる言語はなかなか出てこなさそう。関数型言語なんてどうなんだろう。結構な技術者がやられちゃうような気もする。
で、今Javaが覇権を握っているのは、そうしたいと思った人と、それでいいと思った人の利害の一致に過ぎないと思います。それだけのポテンシャルがあったからこそだけれども、それだけじゃないよね。
ああ、そういえばC#というか.NETのことを忘れていましたｗポータビリティーのなさがアレなんだけど、こいつもフロントエンドだったら使いどころはあるようなないような…メガバンクじゃしばらくないよな。
あくまで某都銀の一部の事情でした。
ボトムズ (ハヤカワ・ミステリ文庫)
