もう2007年といえば5年前のことになってしまう。時のたつのは早いものです。 当時の増田のエントリが何故か今頃盛り上がっていて、その結果それに言及した僕のエントリも盛り上がっているようなのですが、5年前の状況というのはさすがに古かろう、ということでちょっとアップデートしてみたいと思います。 参考： IT業界で無事にいたいなら銀行に関わるな 銀行SE…かわいそうです… - novtan別館 ここ最近の銀行システムの大きなトピックというのは三菱統合UFJ銀行のDAY2（システム完全統合）と、みずほ銀行の3.11後の大障害とそれに伴う銀行の統合・システム刷新でしょう。 特に後者は銀行システムの停止が社会に与える影響が如何に大きいものかということを体現してくれました。 なんどかリークもされているからここだけの話をすると、みずほ銀行はいわゆる第三次オンラインをちゃんとやらなかった建て増しシステムであ

僕の選ぶ2008年SIer3大ニュース。 インテックとTIS合併 IBMリストラ 三菱東京UFJ無事システム統合 さて、2009年ですが、かなり先行き不透明です。IT投資は企業にとって競争力を保つためにはやらないわけには行かないものですが、安く早くという要求はますます増えてくるでしょう。そんな中でも、お役所のうるさい官公庁とか銀行とか公共交通機関は多額の投資を強いられますが。 なんとなく、見えているところだけ、予想とか妄想。 金融業界 システム統合というつまらなく、かつ大変な仕事を終え、いよいよ新しいチャレンジを行うはずだった三菱東京UFJもサブプライム問題の波で投資を抑えてきていますから、前半はあまり動きなしか。後半は景気底打ちを見て少し増やしてくると思いますが、銀行の予算なんて一年単位で決まる大枠があるからそれほどは伸びない。となると、今まで三菱東京UFJで仕事をしていた人たちがどこの

スーパーコーダーならともかく。でもそれってツールを使いこなす技量と大差ない。 ということを上げているんだけど、なんでこれが理由になるのか分からない。「スーパープログラマーでもいつも生産性が高いとは限らない」ことの理由としてならわかるけど、体制が変わらない/変えられないことの理由としてはさっぱり分からない。誰か解説して。 Re: 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 - kなんとかの日記 ようはあなたが望む体制はスーパープログラマーに選ばれないってことじゃないの？僕はスーパーじゃないからわからないけど。 もとのエントリは単に「個人の能力差はとても大きいのにそれを無視して属人性をなくそうとするのは間違ってる」というだけの話。 Re: 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 - kなんとかの日記 という話が間違っていると思うからみんな反応するんだと思

今年最後の殴り書き。 ITに向いている人材が文系か理系かなんていう議論にはまったく意味がない。ものづくりには沢山のステップがあり、また各ステップの仕事には様々なタスクがあり、それぞれがいわゆる文系的タスクであったり理系的タスクであったりする。ITという名のつく職業における仕事は多くの部分で事務作業化が目指され、また、実現されてきているけれども、設計は決して事務作業ではない。設計がいらない建物はプレハブくらいだろう。プレハブを売るのがITの仕事の全てである、という話であれば、あるいは正しいのかもしれないが。 私がここで主に想定し、前提にしていた「ITのスキル」は、SEやプロジェクト・マネージャーのように対人スキルを要求される職務ではなく、純粋に「プログラミング」や「設計」のスキルだった。 ITエンジニアにコンピュータ・サイエンスは必須か - モジログ コンピュータ・サイエンスの知識は、もちろ

別に運営費用を広告収入でまかなっている団体が多かろうが、直接料金で回収してはいけない理由は何一つない。ビジネスモデル的に間違っていたらうまくいかないだけでしょ。 月額三万？無償もあるけど企画を審査？ 何様？気象庁が出す天気予報って税金で作られてるんだよね？ http://neta.ywcafe.net/000948.html すでに気象予報協会と気象庁がぜんぜん違うということは大勢に指摘されているけれども、まあ、国土交通省気象庁所管の公益法人だから役所の一種と考えても大外れではないかもしれない。でも、そもそも「税金で作った」としても利用料を払っているものはいっぱいあるでしょ。高速道路とか高速道路とか高速道路とか。あと新幹線とか新幹線とか新幹線とか。 公益法人がばんばん広告収入を得るってのもおかしな話だし、月額３万は確かに高い印象があるけど、個人は企画審査に通ればよいんだよね？むやみにサーバ

増田での議論が面白いことになっている。 日立製作所はまともな会社になるべき 日立のメインフレームがバカ高い話 http://anond.hatelabo.jp/20080720205422 Unixマシンも高い話 http://anond.hatelabo.jp/20080721015612 理由についての解説。主に垂直統合による高コスト化とリスクヘッジの話 今サーバー更改とかやり始めているところなので他人事ではない。 なんでメインフレームを使うのか 上記増田にも書かれているけど、メインフレームの高可用性というのは無駄にすごい。いや、新聞に「ATMがXX分停止」とか載らないようにするためには無駄じゃないんだけど。システムダウンを検知するとコンマ何秒かの間に待機系に切り替わる。富士通なんかはメインフレームの開発をやめたって言っていたけど、じゃあそういう高可用性のあるシステムをどうするか、とい

といってもグローバルに活躍するためのマルチリンガルな話ではありませんよ。 今やメガバンクになってしまいましたが、僕がIT業界に入ったときはまだ都銀と呼ばれていた某銀行でのお話。用語について一切説明せずに行ってみる。世代チェッカーかも。 ホスト系 今やメインフレームだからといってホストでもない時代ではありますが、都銀のシステムはトランザクション量やダウンタイムの問題からやっぱりメインフレーム、で、過去の遺産がありすぎてホスト型。 言語はCOBOLが中心ですが、コア部分に近づくとPL/Iだったりアセンブラだったりする。大事なスキルはJCLを書けること。まあ、JCL自体はシェルプログラミングと変わりません。VOL-=SELの指定とか面倒だけど。基本的に端末のI/Fを想定しているから、SNAとかFNAとかで通信しなきゃいけなくて手続きはめんどくさい。メモリとかディスクの容量が少なかったときの設計を