「メインフレーム」を含む日記 RSS

はてなキーワード: メインフレームとは

2017-10-13

俺は役所側のシステム担当だけど

https://anond.hatelabo.jp/20171012165214

うちのプロジェクト普通に成功したので特に面白い話はない。

つーか失敗が稀だからニュースになるのであって、実際は成功するのが大半だよ。

そもそも入札してもらえないと始まらないので、仕様書にあまり無茶なことは書けない。

開発中に新規要件が出ることはあるけど、こっちだって完成しないと困るから適宜調整するし、無理な分は来年度以降の課題ということで先送りする。

その結果市民からは「不便すぎる役所死ね」と叩かれることもあるけど平謝りするしかいね…。

なので京都市ほどこじれるのはうちの役所では考えられん。

まあメインフレームはどんどん消えてくし、異動があるとはい組織内でのノウハウは蓄積されるし、特許庁みたいな反面教師を挙げて庁内を説得できるようにもなったし、どこも段々と良くなってくんじゃないかなー。

公務員から成功しても失敗しても給料は(ほぼ)変わらんけどな。

京都市システム開発トラブルに対する雑感

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

https://anond.hatelabo.jp/20171012165214

市町村役場で大規模開発が必要システムと言えば住記・税・福祉系の3つだが、この中でも福祉系がぶっちぎりで地雷

住記:住民票管理住民票はほぼ全国統一フォーマットなのでシステム移行は容易。

税:市町村の税で大きいのは住民税固定資産税軽自動車税。細かい税率は違うが基本の計算式はほぼ全国統一されてるのでこれも移行は容易。

福祉系:一言福祉系というが、その範囲は多岐にわたる。

国民健康保険住民への給付保険料徴収等。

国民年金運営日本年金機構が行っているが、申請受理審査の窓口業務市町村

高齢者福祉系:介護保険後期高齢者医療介護予防等。

障害者福祉系:障害者手帳交付自立支援医療給付・通所サービス・その他医療費助成(重心)等。

児童福祉系:児童手当・児童扶養手当・保育(保育園幼稚園)・妊婦健診・その他医療費助成(小児慢性や養育医療)等。

生活保護生活保護認定給付

保健所系:健康診断難病対策医療費助成)・予防接種等。

これらの業務それぞれが国・県から権限移譲されたもの市町村独自のものが混在している。

市町村ごとに千差万別と言っても過言ではない。また、普通市町村中核市政令指定都市でも、どこまで権限があるかは異なる。

これらの業務を全て1つのメインフレーム運用しておりそれを新しいものに入れ替えるだけ、

であれば話は簡単なのだがもちろんそんなわけはない。

これらの業務根拠法令が成立して制度が始まった時期がバラバラなため、そのたびに入札を行って新たにシステムを構築する羽目になる。

そのため、役所内にメインフレームと、異なるベンダー・異なる言語パッケージが乱立する状態になる。

京都市は今回そんな状態を解消すべくシステムの一括更新を試みたがプロジェクト炎上した、と推測する。

パッケージ業務を合わせろという指摘、業務役所の内部だけで完結するシステムなら簡単

人事給与財務や決裁のシステムであればどこの役所業務を適宜修正してる。

問題仕様変更住民に影響を及ぼす業務印刷物を送って申請をしてもらわなければならない類のもの)。

毎年送られてくる役所から文書が変わると混乱してしま住民の方はものすごく多い。

もちろん事前に今年からこのように変更になります、とお知らせはするんだが読まない方は読まないので。

京都市レベル大都市役所から書類が全部いっせいに変更なんてことになったら、

問い合わせと苦情で窓口電話口は間違いなくパンクする。

なので、対外的住民に出す文書様式は従来のものから変更はなしで、という仕様になりがち。

京都市の件でもオンライン処理は無事稼動したが帳票印刷のためのバッチ処理の移行で躓いたとあったので、

おそらくそのへんの印刷物仕様で揉めたのではなかろうか。

2017-10-12

京都市が今回失敗したような、自治体システム更新について

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

Q1.役所仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの?

A1.地方自治体事務財務について法律で決まっているのは大枠だけだよ。

  それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセス全然役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。


Q2.なんで新規で作らないの?

A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市更新しようとしてるような、メインフレーム上のシステムだよ。


Q3.メインフレーム汎用機)って何?

A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代コンピュータだよ。IBMとかがベンダーごとに作っていてOSベンダー謹製だよ。性能はいいけどメチャ高いよ。

システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。

オープンソースソフトウェアとは全然関係ないよ。


Q3.使いまわしってどうやってやるの?

A3.80年代かに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語コンバートしてリコンパイルするよ。

DBデータ階層データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。

あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。

コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。

COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。

今回もめたのもバッチらしいね


Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん

A4.お金無限にあればできるよ。今の時代お金があった時代システムフルスクラッチ再開発するととんでもない予算になって市役所内の決裁が通らないよ。

しか汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから費用さらにかさむよ。


Q5.そんなんでよく運用できてたな

A5.当時はSE汎用機付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。

そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。

マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね


Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。



Q7.なんで入札にしたの? 現行ベンダ指名してやらせたほうが良くない?

A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。

随意契約(随契)は無理だし、入札業者発注者指定する指名競争入札談合の温床になってたか最近あんまりやらないよ。


裏技としてRFP指名したいベンダーに書かせて公募指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね



Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

入札案件RFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。

なので、技術点の項目に現行システム調査にかかる項目を入れるとかして、現行機の開発・保守ベンダ高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。

もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社めっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。



Q9.じゃあベンダーは悪くないのか?

A9.ここまで述べたようにこの手のマイグレーション火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。

安すぎる見積もりを出したSEだか営業だかは死んでね。



Q10.お前(増田)は何者?

A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね

  しょぼいSEからここに書いたことは個人体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。





(2017.10.13 追記)

Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。


あと、「オープン化」の定義が違くない?という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。

メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。

これに対しPCサーバ標準規格で作られているよ。こういう標準規格に基づくサーバオープン系と呼ぶよ。

独自規格クローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。

京都市で火中にいるシステムズさんのサイト解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ

http://www.migration.jp/column/column01.html

完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。

H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

オープン化(オープンではない)みたいなことになって面白いよ(面白くない)

2017-08-26

https://anond.hatelabo.jp/20170826233411

メインフレームCOBOLについては、言語には責任はない。

仕様がわからないんだ。

銀行同士で違うシステム使ってるって時点で察しろ

あと、オブジェクト指向が判れば、もう大体言語による差なんて小さいと思うけどね。

WindowsPowerShellはクソだけど。

https://anond.hatelabo.jp/20170826232407

プログラム言語なんぞプラットフォーム次第だろ

メインフレームはまだまだCOBOL全盛なんだぞ

COBOL死ぬ死ぬ言われてるけれど、恐らく今後も使われ続ける

2017-06-10

幸せのために競争するんじゃないよ

将来死なないで済むために、競争するんだよ

ガチンコ競争死屍累々の山を築く、そりゃもう悲惨なことだ、そんなことは分かってる

でも余所じゃそれをやってるし、その結果の技術革新が生まれ

ドロップアウトして安穏としてりゃ、いずれ黒船に全部持っていかれる

メインフレームスパコンPC、全部そうなったよね

まだ繰り返すの?

少しずつ犠牲者出しながら切磋琢磨するか、全滅エンドにレッツゴーするか、どっちがいいのよ

http://anond.hatelabo.jp/20170610163114

2017-06-06

SI(メール右から左へ受け流すお仕事)

入社3年目までwebアプリを開発する部署所属していたのだけど、

4月から業務系のシステムを取り扱う部署へ異動になった。

これまではjavaソース書いたりしてたけど、

今度担当するシステムの中核はcobol?という言語構成されているらしい。

といっても今度の部署は、下流工程ソフトハウスさんに投げてしまうので、

これからの主な仕事は、発注元の「業務フロー変えたいかシステムもこんな感じに変えてくれ〜」

みたいな要件を聞いて、それをソフトハウスさんに伝えて開発してもらう、

いわば橋渡し役みたいなものになる。

全く異なる毛色の部署からの異動だし、なんとか手探り手探り手探りで4月から業務をしてみたけど、

この、発注元とソフトハウスさんの橋渡し役って、何の利益を生み出してるのかよくわからなくなってきた。

この橋渡し役は、「システムのことわからない発注元の要望を、システム仕様翻訳する」という役割があるらしい。

だけど、このシステム発注元はちゃんと要望システムチックに出してくれるんだよね。

先日受けた、エラー時のチェック仕様変えたいですっていう要望についても、

要件書の記載がそのままif文作れるような文章になっているので、

僕はそれを受け取って、いくつか申請書を作って、あとはソフトハウスさんに要件を伝えるだけ。

それで設計工程での僕の仕事ははおしまい

また、テスト工程でもあんまり特に何もしてなかった。

というのも、COBOLとかメインフレームとか、まだ圧倒的に知識不足の為、

ソフトハウスさんが作ってくれた成果物実施してくれたテストの証跡を検証できないんです。(ごめんなさい。)

テスト証跡ではなく、「テスト結果の報告」をチェックして、それをもとにいくつかのチェックリスト作って提出して、

発注元に完了報告してテスト工程おしまい

一連の工程がなんだかよくわからないうちに完了して、

その結果がなんだがよくわからないうちにシステムに反映されていた。

この仕様変更について僕がやったことといえば、

·発注元の要件書をソフトハウスさんに転送する

·いくつかの申請書をつくる

·ソフトハウスさんのテスト結果報告に対して「確認しました。対応ありがとうございました。」と返信する。

·いくつかのチェックリストをつくる

·発注元に完了報告をする

くらいだ。

エクセルメーラーしか触ってないのに、いろんなことがトントン進んでいくのが不思議だし、

こんな業務にもちゃんとお給料が発生するのがいちばん不思議だ。

·······。

もっと月日が経って、色んな仕事任せてもらえるようになったら、また振り返ろうと思う。

悩み

メインフレーム知識つけたいなあ

おすすめ方法などあったらおしえてください。

周囲の先輩方もあんまりわかんないようだ。

···「内部のロジックなんて読めなくてもなんとかなるよ」なんて言われるし、

ひとつひとつを深くこなす、みたいなのがイレギュラー、という空気を感じるけど

まだその空気に慣れてない。

やっぱり中身知りたいし、テスト結果はなるべくナマに近い証跡で確認したいな。

2017-03-12

書き換える必要なくね?

大企業銀行で、昔から動いている基幹システムは、大抵メインフレームCOBOLの組み合わせである

それをここ十年くらい、リプレースx86サーバJavaという構成に変更することが多い。

しかし、ハード汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。

ぶっちゃけCOBOLCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは?と思うのだ。

その理由はこうだ。


COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。

勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOL文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである

そういうモノが既にある企業銀行文化において、当然発注側は担当者からお偉いさんまでCOBOLerフローチャート脳だし、新しいシステム設計でもそれを踏襲しようとする。

というか踏襲すること前提じゃないと設計書をレビューできない。

UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。

というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法設計書で処理を組み上げざるを得なくなる。


そうなると、実装フローチャート設計を基にコードを書くわけだが、こういう設計ハッカー文化で発展してきた言語(FortranC/C++Javaという流れと、PerlからPythonPHPというインタプリタ系の諸言語)との相性が最悪である

設計とは実装を楽にするために書くのに、これらの言語において、フローチャート設計は役に立たないどころか、邪魔しかない。

からFortranしかなかった頃から、本物のプログラマ達はフローチャートdisってきたわけである

ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である

しかし、「普通人達普通思考からはかけ離れ過ぎているという意味で、「普通人達普通仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。

…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLアセンブラ選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。


というわけで、自分COBOLからリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。

COBOLリプレースするのでない限りは。

2016-12-03

宙船モーレ 聖地巡礼の旅 ~迫るセンテンススプリングの脅威~

宙船モーレ号がH28植民恒星系を離脱してから、すでに300日以上が経過していた。

副長、主機の調子はどうかね?」

「はっ、PPAPの出力は99.89%でほぼ安定。マイナス金利の影響で一部トランプ現象の発生が見られますが、聖地巡礼には支障のないレベルです」

「そうか。引き続き、ジカ熱を絶やさぬようアスリートファーストで頑張ってくれ」

了解です」

「か、艦長!」

「どうした、先任通信士?」

通信です!」

「どこからだ?」

「それが……。この周波数は、おそらく『センテンススプリング』……」

バカな! センテンススプリングは、とうの昔にゲス不倫の影響でSMAP解散したはずだ」

しかし、この復興城主特有民泊は、どう考えてもセンテンススプリングのものしか……」

「推測はいい。すぐに確認を取りたまえ」

「り、了解。副通信士、通信だ!」

「はっ。レガシーレガシー。こちらはH28植民恒星系第5惑星シン・ゴジラ所属宙船モーレ未確認通信の発信者に問う。君の名は。

「…………」

「こちらはH28植民恒星系第5惑星シン・ゴジラ所属宙船モーレ通信に応答せよ。君の名は。

「……返答はまだか」

艦長。もしやこれは、おそ松さん陰謀では?」

分からん。だが、いざという時にはすかさずEU離脱できるよう、主機を都民ファーストに変更しておけ」

了解しました」

「……へ、返答ありました! こ、これは……!」

「どうした! 報告しろ

目標より返答。『斎藤さんだぞ』……以上です!」

いかん! 総員、第一種戦闘態勢! 文春砲直ちに発射準備に入れ!」

「駄目です! 斎藤さん、タカマツペアを展開しました。歩きスマホ盛り土を散布しています!」

「びっくりぽん」

艦長、このままでは文春砲使用できません。新しい判断を!」

《ホイクエオチニッポンシネ……ホイクエオチニッポンシネ……》

「こ、この音声は?」

斎藤さんが一般回線を通じて強制割込を行っています! 本艦のメインフレームにも斎藤さんの侵入確認!」

くそっ。斎藤さんの狙いはパナマ文書か」

艦長、もはやAIが止まりません!」

「ぬうぅ。かくなる上は、あれを使うしか……」

「ま、まさか! 駄目です、艦長。あれは危険過ぎます

「事ここに至っては他に手段はないだろう」

しかし……」

「……命令だ、副長ポケモンGO!!!」

艦長英断によって使用された未完の最終兵器PokEMONが放った「くまモン頑張れ絵」は、その神ってる威力によって、斎藤さんを一瞬でマイナスイオン水素水還元した。

窮地を切り抜けたアモーレ号は、予想外のアクシデントで遅れた日程を取り戻すため、盛り土転換によるジカ熱PPAPの出力を120%にして、一路、母なる惑星地球を目指すのであった。

ポリティカル・コレクトネス

2016-07-08

からみずほ銀行の開発拠点を見てみよう 中目黒

https://www.google.co.jp/maps/place/@35.6386097,139.6999833,521a,20y,41.58t/data=!3m1!1e3!4m5!3m4!1s0x60188b48682c837f:0xa07320890573c72c!8m2!3d35.6427516!4d139.6999923

みずほ情報総研 中目黒事業所(オーク中目黒ビル

みずほ銀行PJの陣頭指揮を取っているはずのみずほ情報総研、開発拠点は全国にありますがその中でも有数の規模を誇るのがこの中目黒です。

毎日夜遅くまでフロア電気が付いているそうですが、大変ですね。

みずほ銀行 中目黒センター(旧富士銀行 中目黒電算センター

Google Mapで見ると室外機が沢山載っている、まるで要塞のような建物が見えると思います

ここはみずほ銀行システムの中核をなすデータセンターの一つです。

IBMメインフレームが沢山入っていたそうですが、今後はどうなっていくのでしょうか。

ちなみにこの建物建築業協会賞を受賞しているそうです。かっこいいですしね。

みずほ情報総研 中目黒出張所(秋元ビル

中目黒センターの南にある、駒沢通りに面したちょっと変わった形のビル秋元ビルです。

ビルオーナーは1階で秋元商店という酒屋さんをやっており、

ここの数フロアみずほ情報総研事務所として借り上げています

みずほ関連の怪文書中目黒という単語が出てきた場合中目黒駅近くのみずほ建物ではなく

このビルのことを指しています

秋元ビル中目黒センターの間には、自販機と灰皿が設置されているのですが

朝の九時頃には首からMIZUHO」のカードキーを下げた方々が大勢喫煙されています

どんな立ち話をしているのか、気になりますね。

からみずほ銀行の開発拠点を見てみよう、今回はおしまい

次回は多摩が出来たらいいですね、では。

2016-07-07

良く分かる「みずほ銀行デスマーチ

やあ、デスマーチってるかい

実はデスマーチ基準ってのがあって、7時間寝られるか。

なんと自宅に居る時間は5時間だけ?継続してたらデスマーチよ。

法律守って作業者が自宅に9時間いられるようにマネジメントするのがお仕事

(鎮火の初動は、終電まで働かせといて健康管理自己責任とか言う人の排除から

というわけで、みずほ銀行最近また話題になったので、振り返ってみよう。

銀行権力闘争根本原因

さて、みずほ銀行吸収合併は、こんな感じ。

で、記憶に新しい2011年東日本大震災システムトラブルの影響で、

システム刷新して再発防止するぜ!というのが2012年スタートの話。

みずほコーポレート銀行みずほ銀行吸収合併されて、

みずほコーポレート銀行みずほ銀行改名

はい、クソメンドクサイですね。

モメにモメるぜ銀行格式の話

しっかし、この合併って超ややこしくて

第一銀行が1873年(明治6年)創業

安田銀行1880年明治13年)創業

日本銀行1881年明治14年)創業

日本興業銀行1900年明治33年)創業

とか並べると、ウワー関わりたくね-って判るでしょ。

今のみずほ銀行は、旧みずほコーポレート銀行なので、旧富士銀行なのね。

法人格法律上会社人格)も、SWIFTコード世界的な銀行識別番号)も、旧富士銀行のを使ってる。

でも、日本国内で使う統一金融機関コードは、旧みずほ銀行で、旧第一勧業銀行で、旧第一銀行なのね。

なぜなら、旧第一銀行統一金融機関コードは0001で、旧富士銀行が0003だから

なんでマルチベンダーなのよ

ベンダーってのは企業システムを納入する業者だと思ってね。

銀行システムを納入すると継続的に儲かります保守とかで。

しかも、元みずほコーポレートたる興銀は企業向けメインで、元みずほ銀行は個人向けがメイン。

AKB宝塚歌劇団合併したみたいなもんスよ。そりゃ一歩も引かないわな。

自分とこのシステムが他行の軍門に下るのは承服しがたい。

という政治的決着を経て、

銀行としての本懐は第一勧銀の富士通

信託として信頼と実績の富士日本IBM

外向けに儲かってるところは興銀の日立

全銀システムはそもそも開発保守をずっとNTTデータがやってるんで、そこしかやるところがないという)

なぜデスマーチが終わらないのか

あのね、マルチベンダー地獄っていうのは、違うのよ。

全銀ネット使うなら、NTTデータ噛ませないのはありえない。

そして三菱東京UFJ銀行の開発はちゃんと終わりました。あそこも無茶やりました。

ポイントは、どの派閥が主導権を握って、有無を言わせないか

UFJ派閥抗争で完全に疲弊しきった所を、天下の三菱御三家東京三菱銀行が救済しました。

から、旧UFJ系(日立)は「実利で残した」という形で、東京三菱側(IBM)が完全にコントロールしてた。

主導権が完全に旧東京三菱側にあるので、旧UFJ(旧三和銀行)がなんか言っても鼻で笑われるレベルね。

まりクライアント(依頼主)側の命令系統キッチリしてるかどうかが全て。

結局みずほシステムって完成するの?

家を建てる時にさ、大工左官職人と配管職人ガラス屋と設備屋が居るから完成しないとか、無いでしょ。

それぞれの職人にそれぞれの指示をして、結果として一つの建物ができるのはそんなに珍しく無い。

(もちろんちゃんと連携しとかないと穴空いてないか換気扇付けられんとかあるんだけど)

から、誰かが主導権を握れば普通に完成するよ。

例えば、みずほ銀行の現頭取の林さんは富士銀行の人。

だもんで、日本IBMプロジェクトマネージャーに全権委任して、組み直せば終わるよ。

みずほ銀行内の揉め事は、全部林さんがOK/NG決めて、IBMPMが采配して進める。

要は、クライアント(依頼主)側の意思統一ができていないのが一番の問題

これは、ベンダーがーとか多重請負構造がーとか、そういう問題じゃない。

第一勧業銀行富士銀行日本興業銀行合併が終わってないのが問題

(外面の話じゃなくて、内部的に一つにまとまってるかってことね)

つうか、みずほ情報総研音頭取らないの謎だけどな。

自社もまともにできてないのにSIとか臍が茶を沸かすぜ。

追記その1

みんなコダワルねぇ。

ヤヤコシイということだけ判ればエエのに。

とするじゃろ

/*合併前の法人格リスト 第一勧業銀行, 富士銀行, 日本興業銀行*/

/*ここから2002年*/

社名変更(みずほ銀行, 吸収合併(吸収合併(第一勧業銀行, 会社分割(富士銀行, 富士リテール)), 吸収合併(新規設立(みずほ統合準備銀行), 会社分割(日本興業銀行, 興銀リテール))))

社名変更(みずほコーポレート銀行, 吸収合併(富士銀行, 日本興業銀行))

/*ここから2013年*/

社名変更(みずほ銀行, 吸収合併(みずほコーポレート銀行, みずほ銀行))

追記その2

第一勧業銀行第一銀行から来てることは知らなくて良いなんてコメントは甘い甘い。

日本では古いほうがエライ。それは実にシンプル帰属意識や誇りに結びつく。

今をときめく日本銀行よりも第一銀行(第一国立銀行)の方がエライのよ。

まり第一勧銀の方が富士よりも格が上だと思ってたりする。

んで、明治創業の三行がプライドを漲らせたママ

  1. 一般人相手預金業務を第一勧銀の富士通システムにする
  2. 企業相手の貸付業務を興銀の日立システムにする
  3. 信託業務は富士日本IBMシステムにする
  4. 信管理とか項目名どうする?
  5. 合併元それぞれの銀行マンがそれぞれのシステム担当者に違うこと言う

よしもと新喜劇AKB宝塚歌劇団合併したみたいな話に例えると

「この衣装リストはどう管理しますか?」

衣装衣装で良いだろ」

「じゃあそれで」

「おい衣装セットリストは揃えるのが常識だろ」

レビュー衣装は別で管理が良いな」

「えぇ……」

小道具って衣装とセットにしますか?」

「しないだろJK」「含めるに決まってるだろ?」「千秋楽だけ生花衣装扱いで」

「えぇ……」

「どうかな?公演の日取りは決まってるけど」

「「「おおむね順調です!」」」

(オマエラマジいいかげんにしろよ)

追記その3

はいはい結論だけ読みたい人ようこそ。産業

(三行で正確に知りたいってのは業腹ってもんだ)

期日があるし作り出してから摺合せとか、そりゃ炎上せずにはいられない(相川七瀬感)

2016-05-29

富士通退職した話」に言及とついでに自分の話でも。

自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。

富士通を退職した話

彼のへの感想

富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いか想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると(後述の富士通入社して10年が経った人の話にもあるのだけど)新人能力客観的判断材料って大学資格応用情報レベル以上)程度なのよね。資格に関しても基本情報なんてMARCHクラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT業界に入りたいかどうかの判断材料にはなる程度。自分の同世代富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士しか居なかった覚えがある。あと確か2~3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。

ただ、20人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、(自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた)、そういうのに入社して間もなく入ってしまうと自身勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。(自分炎上案件に放り込まれ新人が寮で死んでたとか話を聞いたことある

上司対応はまあこれだけ見ればクソだわな。

富士通を退職して思うこと

はあ、としか。この人がこう判断した際の判断材料にするであろう自己体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業経営とか体制とか理解出来るんかね?と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的巨大企業特有問題があってそうなってるんだなって思う事が多々あった。

富士通に入社して10年が経った - blog

近い時期に入社したと思われる。具体的な話が自分経験と一致してる。特に富士通ソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか(特に学生なんかじゃ)判らないかなと。

それでこれらの話を見てどんな人が富士通(というか大企業)に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる(要するにそこそこの大学に行って卒業した人)、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解やすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社子会社で色々アルかもしれないけど。

で、自分入社から退社までの話。

入社10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1~2年したら子会社の統廃合とのことで富士通本体連携してる部署自分がそうだった)は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由実家事業を継ぐ事にしたため。

入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と

富士通本体ソフト開発配属の人達研修をやったのだけど、その際に富士通本体人達と知り合った。(この際に全員のプロフィール冊子が配られた)そのときは流石子会社に入る人達本体とじゃレベルが違うな~と思いましたね。(ちなみに自分MARCHより下の院卒。)

自分が配属されたのは某製品部署API部分チーム。その製品C言語Java言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPポートプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙ヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語APIリニューアルするって開発してたのだけど、設計担当Javaしかやったことない人で色々とC言語流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね(ちなみに機能はそれサーチか?思うのもあった)。もっと酷かったのが初期製品Javaの公開メソッドで、マニュアルには「このメソッド引数○○を□□を指定した場合戻り値Objectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。

これは、ミドルウェアの開発をやってる人達って基本的C言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象OSWindowsLinuxSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。

それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0Genericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計実装結構良い感じに出来たと思う。ああ、そういえばRuby用のAPI効率化の開発ツールとかの名目仕事中に勝手に作ってたなあ。他にもC言語APIも内部実装がクソすぎ!とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対LDしてるんで完全に趣味なんだけどな。これでAPIC言語Java.NETになった訳だけど、現場案件で使われたのってほぼ全てJavaだったと思う。(開発中のサーバテストアプリC言語だけど)。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟必要かもね。

で、.NETAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品担当が増える事に。インストーラWindowsがInstallShieldというクソみたいな言語上で作られたものLinuxSolarisシェルスクリプトのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS対応(Vistaとか)とか保守作業が大変だった覚えある。

んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味C++勉強してたので何とかなった。あと、結構OSの知識(プロセスとか)が必要WindowsLinuxSolarisで動くコードを書く必要があってまあまあ大変でした(と言ってもifdefで切り分けるだけなんだけど)。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品バッチ処理に使えないかとか話が出てきたあたりで自分退職する事に。(退職の話は1年ぐらい前に話し合って決定済み)引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしま実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。

振り返ってみて残業時間は月40~60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部(だったかな?)単位残業禁止になってホント残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通ソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか(そんなに深くはないけど)色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモ体験出来たのは良かったです(こなみ)。

2016-05-05

日本って死んでたんだな

製造業メインフレーム(追記:メインフレームじゃなくて生産ラインでした)がPC-9800系ベースにしてくまれており、設備投資する費用がないために今でも、PC-9800のパーツに需要があるっていうのを聞いて

金がなくても、儲かる見込みがあったかガンガン設備投資できる余裕があった1980年代製造業が止まってるっていう事実愕然とした。

 

http://www.asahi.com/articles/ASJ5432RSJ54UEHF001.html

http://withnews.jp/article/f0160314001qq000000000000000W00b0901qq000013115A

 

これって、日本製造業設備投資して技術とか効率化をアップデートできる体力がなくなったってことで

技術力が痩せ始めてるってことなんだよな。

 

 

本来なら、高給だったはずの派遣労働自由化などいろいろな要因で今では低賃金労働代表格になってしまって久しい。

田舎にもコンビニが普及して便利になった反面、一人ひとりの生活が貧しくなってる。

 

 

私事になるが、若いころから介護士してた叔母も、月収20万を越えでボーナスもあったのに

どんどん給料下がっていって最期にはバイトと変わらない給料(総支給15万くらいだったかな?)になって、

しまいには、定年前に更年期調子崩したのもあって退職し今では、飲食店の皿洗いのバイト年金で細々と暮らしている。

 

 

他の親戚でも恩給貰ってる両親と一緒に暮らして養ってもらってる壮年のオジサンもいる。

 

 

知り合いには、停職につけない中年のオジサンがいるけれど、言動が年齢に比べて幼く、

仕事だけじゃなくて、人との待ち合わせの約束を忘れてすっぽかし、物事全般がなかなか覚えられず、言動も怪しいくて

しかしたら、精神か知能に障害があるかもしれないけれど、病院に行ってないから特に病名もなく

親に養ってもらって何とか生きている人もいる。

 

 

前に派遣先職場にいた派遣仲間には、新卒職場サービス残業を強いるそれはそれはとても過酷職場

過労と人間関係パニック障害になって、職場パニック発作を起こして仕事を辞めた人もいた。

パニック障害の原因になった職種仕事をすると、発作が出やすなるみたいで、もうそ仕事はやりたくないのだそうだ。

 

 

あ、あと自分の親もリストラされて非正規でなんとか食いつないでる。正規雇用とき給料の半分になって自動車を維持するのも一苦労してる。

公共交通がない田舎から仕事行くにも自動車必須なので、手放せないので大変そうだ。

 

 

自分だけかもしれないけれど、なんか身近な人がみんな、病んだり昔より生活レベルが落ちてて

日本って死んでたのかなって。

 

 

そういう自分最近は酒が手放せなくなってきてて、毎日のんでないとやる気がわかなくて

仕事に行きたくなくなっている。この調子でいけばアルコール肝臓精神ダメになるだろう。

 

 

美少女美少年が悩んでたら、望もうと望まぬとも誰かが手を差し伸べてくれるのかもしれない。

最低限のコミュニケーション能力があって、助けてあげたいって魅力のある人なら、美少年美少女じゃなくても、話を聞いてくれるかもしれない。

 

でも自分は、美少女美少年でもなく、コミュニケーション能力もなく、話す相手もいない。

仕事もいつ終わるともわからない、単純労働しかない。

業務命令する上の人間からバイト君扱いされ、仕事をするただの駒でしかない。

仕事を覚えたって、それが他の業種で役に立つような技術や知識でもない。

 

 

まるで、出口の見えないトンネルの中を歩いているみたいだ。

2016-04-23

モダンな開発がしたい学生大手IT企業に行く際に知っておくべきこと

http://anond.hatelabo.jp/20160413023627 を見て触発されたので書く。

タイトルのようなことについて、実態というか現実というか、そういうのを当たり障りない範囲で書こうと思う。全ての企業学生に当てはまるはずはない(むしろかなり偏見単純化を混ぜてる)けど、参考になれば幸い。

ちなみにトラバ先は研究を志望したという話だけど、本エントリ研究志望というよりは一エンジニア志望向けかも。

前提1: モダンな開発とは?

あえて定義はしないけど、Github で公開されてるような OSS を使ってます/いじってますとか、LL 使って Web アプリ作ってますとか、アジャイルやらテストコードやら最近主流の手法使ってますとか、そんな感じで捉えていただければ幸い。あるいはメインフレームCOBOL とか周辺機能を全部車輪の再発明してるC言語アプリとかそういう古い仕事ではない仕事、と捉えてもいいかも。

前提2: 大手IT企業(SIer)とは?

トラバ先のトラバ言葉を借りると「日本的な旧来型のIT大企業」という感じ。

大手IT企業にとっての「IT」とは「モダンな開発」ではない

ITという言葉には色々な意味がある。大手IT企業だとこれが特に広い。もちろん「モダンな開発」も含まれているけれど、そんなの全体のごく一部でしかない。(主観だけど数 % とかじゃないだろうか)

話は少しそれるが、大手IT企業は元々メインフレームなど「化石」で発展してきた経緯がある。何十年以上も昔、コンピュータといえば化石しかなくて(それでも当時は最先端)、それを個人やそこいらの企業では相手にできないような大組織に対して導入してきた。プログラミング手法ノウハウが十分存在しない時代だったけど、それでもやるしかなくて、幸いにも昔は今ほど不景気ではなかったし人材豊富だったか人海戦術で何とかなった。

そうやってつくられた化石コード化石システムは今なお動いているし、時代に合わせてそれなりに機能追加もある。大手IT企業化石から離れることができない。現代化石で食べていけるほど甘くない時代だとしても。

そもそも化石に詳しい化石人が現役引退や昇進などによりいなくなったということもあって、実は現状維持ですら大変である。たとえばレガシーで汚い膨大なソースコードを知る者は誰もいない。もちろんネットで調べても答えなど出ないし、IT界隈のコミュニティに頼ったところで知る者はやはりいない。どんなに時間がかかっても読んで、理解するしかない。どんなに時間がかかっても。

以上のような現実があるので、化石お仕事新人を割り当てることも普通にあるし、むしろそうなる確率が圧倒的に高い。

大手IT企業にとっての新人とは?

大手IT企業にとって新人とは「専門的な技能経験は無いが、地力(頭の良さ、伸びしろ、根気など)はあるため近い将来使える戦力になる卵」である

対人コミュニケーションには自信ありますという遊んでばっかのリア充も、OSSContribute してました大学ほとんどパソコンと向き合ってましたという趣味グラマも、同じ「新人」でしかない。

新人」は技能経験もないので、いきなり一人前の仕事を任されることはない。電話応対、飲み会企画運営など雑用全般を任されつつ、簡単な仕事アサインされる。

この簡単な仕事というのが曲者で、手順書にしたがって環境を整えるとかテストをするとか、そういう仕事だ。手順書を読める程度のIT知識があれば誰でもできる。でもボリュームは多いし、手順書は不完全で不正確だからからないところが多々あって、忙しい先輩や上司に何度も相談しにいくことになる。言うなれば属人性の高い単調な手作業仕事」とでも言えようか。

ITを知らない素人新人ならこれが仕事だと抵抗なく受け入れられるが、ITを知る新人だったら、これはとてつもない苦痛だろう。配属先が「モダンな開発」を行う部署であれば苦痛具合も軽減されるし、なんなら「君結構詳しいんだね。じゃあ早速本格的な仕事任せてみようかな」なんてこともありえる。化石部署だとそんなことはない。だって仕事で扱ってるシステム化石からモダンIT知識なんて役に立たないもの

新人」を脱した次にあるもの

この「新人」に、早くて数ヶ月、遅くて数年耐えると、次第に仕事を任せてもらえるようになる。設計コーディングといった、エンジニアらしい仕事だ。といっても、配属先が化石部署であれば、当然扱うのも化石なわけで、いつまでたっても化石で苦しみ続けることになる。

一方で化石部署から異動し、「モダンな開発」を行う部署で働く者も存在する。これには色んなパターンがあるが、おおよそ以下のような状況が重なって異動するパターンが多い気がする。

さらに次にあるもの

ここから大手IT企業キャリアパスの話になる。

大手IT企業では エンジニア中間管理職(部長以下)→偉い人(部長より上) というキャリアパスがつくられている。特徴は

こんな感じ。

いつまでもエンジニアとして働いて、でも給料はそれなりにもらって、ということはありえない。成果を出せば昇進するし、昇進すればエンジニアから離れていく。成果を出さなければエンジニアとしていれるけど、いつまでたっても給料は増えない。大手だけあって新人時点での給料はそこそこ良いけれど、30代以上になってくるとそれでも苦しい(物欲無き健康一人暮らしなら問題無いが、家族を養うつもりなら相当苦しい)し、そもそも無能管理職に振り回されることに対して苛立つだろう。つまりエンジニアとして何十年も働き続けにくい。

「昇進するつもりだから問題無し」と考えている人も要注意である。というのも、大手IT企業管理職で溢れかえっているからだ。新人が昇進するのは非常に難しい。昔は割と誰でもなれていたし、実際「こんな奴がなんで管理職になれてんだ?」っておっさんもたくさんいるけれど、今は違う。一握りの社畜必死仕事に食らいついてきた&先輩や上司からのウケも良い)だけが昇進できる。たとえエンジニアとして優秀な仕事をし、正当な意見を主張してきたとしても、空気を読んでウケの良い社畜にならなければ昇進はできないのである

普通キャリアパスはクソだね、じゃあ研究所を志望しようっと

大手IT企業研究所は非常に狭き門であるトラバ先でも言及されているが、博士課程を終えたようなガチさに加え、当然のことながら学歴必要になってくる。実際、研究所人間英語を当たり前に読み書きできたり、分厚い技術書を躊躇なく読み込んだりするような変態であり、裏を返せばそれほどの実力と熱意がなければやっていけない世界というわけで。とにかく多少ITに覚えのある凡人が入れる場所ではない。

また、入社後に研究所に異動するケースもほとんど無い。一般部署の凡人をわざわざ引き入れる理由が無いからだ。

それでも大手IT企業を目指すワケ

ここまで色々書いたが、そもそもなぜ大手IT企業を目指すのか。それは以下のような理由や期待があるからではないか。

確かに上記のメリットはある。あるけれど、ここまで書いたように

といったこともあるわけで。

モダン仕事バリバリしたいならベンチャー行け」という話もあるけれど、ベンチャーで通用するほどの人材ならそもそも大企業を選ぶことに悩みなどしないだろう。大企業を選ぶということは、実力なり待遇なり何かを求めているわけで、そうなってくると大企業以上に適切な選択肢は無い。でも、その大企業にも上記のデメリットがあるわけで。

結論

世の中は甘くないですね。

2016-04-16

富士通20年勤務している側から見たお話

富士通退職した話」を読んで、20年近く努めている側から感想と疑問について書いてみたいと思います

山奥の工場

私も、情報科学大学時代専攻した後、新人で山奥というかむしろ雲の上にある天空工場に勤務してメインフレーム関連の仕事をしていました。

その工場に配属される新人は(希望すれば)寮に入るわけですが、高専卒は工場敷地内にある山頂の寮で二人部屋、学士卒は山の5合目にあるアパートの一人部屋、修士ドクターは街中にあるマンションという感じでした。

街中の下界から工場がある天上界への通勤バスで移動することになるのですが、わたしは、バスディーゼルエンジン排気ガスが苦手なので、頼み込んで工場敷地内にある寮にしてほしいと願い出て、山頂の寮に特別に入れてもらいました。そもそもが2人で一部屋なのですが、学歴関係か私は一人で2人部屋を使わせてもらっていたため、ものすごく広々と部屋が使えました。

わりと頼み込めば、人事や勤労も柔軟に対応してくれる会社という印象です。

メインフレームというレガシー業務

20年前でさえ、メインフレームは古いというイメージがありました。

ただ、私は古臭い部署に配属されたことは不幸とは思いませんでした。電話からスーパーコンピュータまで幅広く扱っている世界でも稀な会社に入ったからには、いろんなことを経験してみたい。

そのためには、そろそろ絶滅してしまいそうなメインフレームを今経験せずにいつ経験出来るのか?くらいな感じでむしろラッキーくらいに考えていました。

最新の流行を追いかけるのもそれはそれで面白いが、そういったものは出来合いのライブラリを組み合わせて流行を少し遅れて追っていく2位集団であるし、やりたければ個人で家でも出来るじゃないか程度の感覚です。

自分意見が割と通る環境

ただ、せっかくメインフレーム部署に来たのですが、私の担当ワークステーションで動作するUNIXPCでの開発が主体でした。

そもそもが、メインフレームを扱っていた部署ですから、先輩の人達はあまりUNIXPCに詳しくなかったので、大学UNIXPC経験した新人が入ってきたことは非常に重宝されました。

その部署では開発言語は、社内の独自言語(Cよりもさら機械語に近い言語マウスグラフィカルに操作してコーディングする言語)を使っていました。もともとはメインフレーム用の言語なのですが、UNIXワークステーションPC用にも

その言語コンパイラはあり、あわやその言語UNIXの開発する羽目になりそうだったのですが、私は猛烈に反対して自分意見を通しました。当時はJavaRubyなどの言語は無くCが全盛でしたが、

その部署の開発メンバーはCをほとんど知らなかったのです。そこで、社内のカイゼン活動として、C言語勉強会を開くことを提案し私が講師になってC言語メンバー習得してもらい、

PCUNIXでの開発は独自言語ではなくC言語を利用することを認めさせました。

元の増田の方は、自分エクセルVBAソースが見れない立場のようだと言っていましたが、ソースをみようとしたらシートにロックがかかっていたのを見て諦めてしまったのではないでしょうか?

元のEXCELを使った業務が非効率であるならば、業務改善活動として提案すれば、それを拒む上司というのはちょっと考えにくいです。

忙しい部署にも、改善活動ノルマが課せられるのですが、先輩はそういったことに関わっている時間が中々取れないので新人がそういった仕事をやると宣言しても拒むのはまずありえません。

案外苦労するゼネコン

下請けプログラマーからみると富士通のような会社中間搾取していて高給をとっているのに、仕事は丸投げという印象があるでしょうが、実際やってみると案外大変です。

私は、富士通本社SE的な立場グループ会社に出向して、そこから顧客先に派遣される4次受け5次受けのプログラマ両方を経験しましたが、はっきりと下請けの方が精神的に楽と感じました。

商売や、自分でやっているわけではない人に依頼した仕事について、責任をとるのは非常に苦しいものがあります。そもそもプログラミングはとても楽しいというのもありますが。

異動の希望はまず通る

私見ている範囲では違う部署に異動したいという希望100%通りました。異動を希望しているのにその部が解散するまでその部署にいる羽目になった人など見たことがないです。

もちろん、「プロジェクトが佳境で君に今抜けてしまわれては困る」というケースはあるのですが、IT業界プロジェクトの開発周期は年々短くなる一方ですから、割と早い段階で異動の希望は通る感じです。

もとの増田の方は巨大プロジェクトだったので大量の人がいるわけですが、こういった部署は異動の希望は通りやすいです。

なぜなら、新規プロジェクトで最も忙しいときは大量の人員を動員しているわけですが、バージョン2、バージョン3あるいはメンテナンスフェーズに入ればそんなに大量の人員必要がないので、会社としてもその部署人員を異動させたいわけです。

けれど、プロジェクトで中核の技術を担っているようなメンバーマイホーム天上界に立ててしまったメンバー、新しい仕事対応しにくい高齢メンバーは異動させにくいので、

EXCELをいじっているだけのような新人は異動の希望が通りやすいのです。

もとの増田も、もう少し我慢していれば希望が通った可能性は極めて高いですが、プロジェクトが佳境でまだ新人で入ったばかりといった状態では、もう少しその部署で頑張れと言われるだろうと思います

ただし、異動先の都合もありますので、ここから出たいはほぼ100%通りますが、あそこに行きたいは必ずしも通りません。

今更「京」スーパーコンピュータをやりたいといっても、人気部署ですし、プロジェクトの最盛期は過ぎているのでその希望が通る可能性は低いでしょう。

嫌な上司はすぐにいなくなる

色々な部署がある大きな会社では、管理職クラスは頻繁に異動が起こりますから、嫌いな上司はわりと直ぐにいなくなります。小さい会社だとそもそも部署が開発部と人事部営業部しかないというかんじなので、上司がやめるか自分が辞めるまで、嫌な上司と付き合う羽目になりがちです。

入社時の部署希望のコツ

新人研修期間が終わった後、人事の面談のチャンスがあるのですが、そこにはコツがあります

「おおざっぱにはっきりと希望を言うこと」です。

いちばん最悪なのが、大学での研究を話し、それを活かせる部署に行きたいと話すことです。

人事の人は技術には詳しくないですから研究内容が最先端であればあるほど、人事の人には通じないです。

キャッシュコヒーレンシが。。とか話すと、「よくわからないけどこの人は基本ソフトウェアに向いているのかな?だったら、自社でOSを開発しているメインフレーム回そう」という感じになってしまます

それよりは、人事の人が、会社組織のどの部署に配属すればいいかわかりやすいように、おおざっぱに希望をいうことです。

例えば、

上記のことを強い口調ではっきりというのが良いと思います

そのうえで、できれば○○製品をやりたいだとか、こういった業種のSEをやりたい等の希望だすと、どの部署に配属すればいいか相手にも伝わり希望が通りやすくなります

私の同期で入社して新人研修で山奥に配属されたバブル時代末裔のようなおねーちゃんとか、数人は、割とはっきり希望をいって、下界に戻っていきました。

2016-04-13

http://anond.hatelabo.jp/20160413023627

入社して1週間後に告げられた自分の配属先は、山奥の工場メインフレームを主とするシステムの開発・保守を行う関連会社への出向だった。

富士通がそうかは知らないがこういう部署って黙ってても利益が入るドル箱なので会社から評価は高いはず。

新卒の右も左も分からない時期にこういうイージーモード部署に配属して貰えるのはむしろ良い待遇だと思う。

国税庁が出してる所得統計を見れば分かるけどFのような大企業は30代に入る頃から一気に年収が跳ね上がる。

もう少し世間を調べてから就職した方が良かったと思う。

増田相談した相手若い人やウェイウェイベンチャー系の人しか居なかったんじゃないかな?

普通はFみたいに加齢するだけで楽に年収500万超える企業をすぐ辞めたりしないよ。

http://anond.hatelabo.jp/20160413023627

入社して1週間後に告げられた自分の配属先は、山奥の工場メインフレームを主とするシステムの開発・保守を行う関連会社への出向だった。

富士通がそうかは知らないがこういう部署って黙ってても利益が入るドル箱なので会社から評価は高いはず。

新卒の右も左も分からない時期にこういうイージーモード部署に配属して貰えるのはむしろ良い待遇だと思う。

国税庁が出してる所得統計を見れば分かるけどFのような大企業は30代に入る頃から一気に年収が跳ね上がる。

もう少し世間を調べてから就職した方が良かったと思う。

増田相談した相手若い人やウェイウェイベンチャー系の人しか居なかったんじゃないかな?

普通はFみたいに加齢するだけで楽に年収500万超える企業をすぐ辞めたりしないよ。

富士通退職した話

少し前に新卒入社した富士通株式会社退職した

理由は簡単に言ってしまえば自分の目指すキャリアパスとのミスマッチ

おそらく人事部書類にも、今頃そんな感じのことが書かれているんだと思う。

ただ、それだけで済ませてしまっては腹の虫が治まらないので、

なぜ好き好んでそんな会社入社して、短期間で退職するはめになったのかを書こうと思う。

入社する前は大学情報学部に通い、大学院まで進学して専門分野の研究にそれなりに熱意をもって取り組んでいた。

それもあって、同じ分野の研究企業として行なっている同社に入社しようと考えた。

内定前後にいくつかの職種マッチングを行う機会はあり、自分希望についてはしっかりと主張したつもりだったけれど、

入社して1週間後に告げられた自分の配属先は、山奥の工場メインフレームを主とするシステムの開発・保守を行う関連会社への出向だった。

当然この決定に対して人事に不服を申し立てたけれど、返ってくる答えはあらかじめ用意してあったような定型文と、「みんな我慢しているからお前も我慢しろ」というお説教だけ。

もちろん、規模の大きい会社だし、全員が希望通りの職種につけるとは思っていたわけではない。

でも、曲がりなりにも現代IT企業入社したつもりなのに、20代そこそこの新卒社員化石みたいなプラットフォームの世話を押し付けられるなんて想像だにしていなかったし、

綺羅びやかな会社説明資料の中にそんな説明を見た覚えもなかった。

もちろん決定は全く覆らなかったのだけど、その後も思いつくだけの人脈を辿って色々な人に相談して助言を貰い、

せめて担当業務オープンプラットフォームにしてほしいとか、COBOLは嫌だとか、ついでに可能であれば山奥の工場に押し込まれるのも勘弁してほしいとか、

できる限り主張をしつつ、しばらくの間実際に働いてみてから身の振り方を決めることにした。

それからしばらくの間新入社員研修をこなし(富士通に限らず、いわゆる日本的大企業研修期間がやたらに長い)、

そろそろ本格的に業務に携わりたいと思っていた矢先、上司に告げられた自分担当業務はほかでもない、あの20人月案件だった。

例によって守秘義務があるので詳しくは書けないのだけれど、業務を行うツールはもちろんMicrosoft Excel

自分仕事は言われたとおりにExcelシートに入力し、マクロを実行して成果物となるファイルを吐き出すことだった。

このマクロ挙動はとても怪しいものだったのだけれど、どうやら自分はこのマクロ修正はおろか、ソースを見ることもできない身分らしい。

SI現場で日々行なわれている業務内容については詳しく知っているわけではなかったけれど、自分のやっていることが著しく非効率的であることだけははっきりとわかった。

そもそも、具体的な配属先については希望とズレがあったにせよ、少なくとも自分は開発職として入社したはずで、SI業務がやりたくてこの会社に来たわけではない。

とどめに「君はオープンプラットフォームでの開発には多少覚えがあるらしいけど、メインフレームではそんなものは役に立たないから。」なんて台詞が飛んできた。

確かに、Excelシートへの入力作業情報学修士号なんていらないし、キャッシュコヒーレンシの話なんてオタク気持ち悪い自分語りみたいなものでしょうね。

結局これが引き金になって、転職を決意した。

しばらくの間働いてみてそれから考えるなんて、とんでもなく愚かなことだとようやく気付いた。

ただ、短い期間ではあるけども世話になった上司と、開発職の社員SI業務に割り当てざるを得ない状況については自分一定の理解を示しているつもりだったので、

多少なりとも会社への影響を軽減できればと思い、転職するつもりである旨を早い段階で上司に明かした。結果としてこれが大きな間違いだった。

転職の旨を伝えた週の金曜日、自席に上司から電話があり、「働く気がないならすぐに辞めてもらう」といった調子一方的退職日を設定された。

流石にこれは法的にも問題がある行為だと思い、すぐに折り返し電話をかけて抗議し、翌週時間をとって直接話すことになった。

翌週直接話してみると、上司はケロッとした顔で「なんだ、働く気がないわけじゃないんだ、勘違いしてた。じゃあ退職はいつにする?」なんて聞いてきた。

自分が抗議しなかったらどうするつもりだったんだろう。

幸い、書類上は見栄えのいい学歴と、知人からの紹介と、"多少覚えのある"スキルのおかげで転職には全く困らなかった。

それでも、無駄にした時間は何をどうやっても返ってこない。

そろそろ就職活動が本格的に始まる頃だけど、今の就活生には是非とも就職先は慎重に選んで、貴重な若い時間無駄にすることがないようにしてもらいたい。

2015-05-21

ドキュメントを残さなプログラマ

どうもスーツです。

実際にはスーツは着てないけどギークではありません。

某社に見るシステム開発における社内政治無駄さ加減について

http://b.hatena.ne.jp/entry/d.hatena.ne.jp/NOV1975/20150512/p1

これのはてブと元記事見て血圧上がったので、チマチマ反論するよ。

時間がない人向けのまとめ

記録を軽視するな。

今日常識」が未来永劫担保されることはない。

スーツからすると、ギークに釘を指しておきたいこと

業績が個人について回ったら、誰も保守しないだろ。

金を生むのかそのドキュメントレビューリファクタリングでいくら稼げますか?

ロボットアニメ博士みたいにな、空中から予算が湧いて出たりしないんですよ。

誤解があるみたいだから言っとくが、評価には減点も加点もある。

ただ、スケジュール前倒しで予算が浮くようなシステム作ったりしてないだろ。

何故ならばスケジュールは常にキチキチで、間に合わなきゃ減点されて当たり前だ。

そこは同情する。

見積は常に過少で、調整は過小評価され、日程だけが評価軸になりがちだ。

  • 隣の島の人は同僚ではなく調整相手
  • 文書のない調整結果は意味を持たない
  • 1分で済む会話より3往復かかるメールを選択する
  • やったという証拠を残すためだけのレビュー実施する

オマエらが椅子を滑らせて隣の同僚と1分会話して実施した内容は、キサマが風邪引くと誰にも共用されない。

コードレビューした。仕様書レビューした。まあギークが言うなら内容に間違いはないんだろう。

だが、その部分は三年前に転職した同僚がやったはずです?それじゃダメなのは判るよな?

オマエ独りで完結するプロダクトをオマエがケツもって仕事するなら文句は言わないが、違うよな?

記録に残せ。ドキュメントを書け。やったという事実を示せ。

本来は「指摘事項ゼロ」「問題がないか再精査しろ」「再精査したが無い」「一筆書け」「書いたから通せ」をやるのが正しいというのは判る。

やって欲しいのか。

ギーク不要だと思ってるレビューに、さらチェックリストが加わったり、書類が増えたりするぞ。

  • 予定と違う報告は許されないので報告の数字捏造される
  • できないから遅延するよりも中身が空でも枠だけで出来たことにするのが政治的に正しい

正しい数字で出せ。

恐らく上から順番に怒られた上にいらん書類を書かされた上に再発防止策を延々と書いた挙句本業であるコードを書く仕事が遅延して、さらに同じことがループするが。

政治的に正しいんじゃ無いんだよ。

そうした方が、ギークの遅延が少なくなると思うからスーツが知恵絞ってんだ。

杓子定規スーツが付いてみろ。

ギークが一度遅延したが最後、遅延が無くなるまで延々と再発防止策(しかも一度着手しているのでスケジュール見積もりについて以外でだ)書かされるぞ。

  • どんなに正しくても政治的に間違っていると判断されたことは闇に葬られる

その「どんなに正しくても」は、どこの誰が担保してるんだ。

ギークの勘か?

それ違約金を含んだ形で書面にして公正証書として頂けますか?

  • 言ったもの負けで誰も言わないので全員が負ける(実は言ったら勝てることが多いが賭けを許容しない

オマエが言えよ。

言えないならその立場に無いってことだ。

そして立場のあるもの理由があって言わないんだ。

  • 常識で考えればこうするでしょということを決めるのに年収1000万超の人の判子が100個必要
  • そもそも常識で考えればこうするでしょという選択がなされない

常識で考えればこうする」というのは、何時の時点の誰の判断だ。

未だにCOBOLが現役で使われていると想定してたか

たった30年前までメインフレーム全盛だったが、常識的に今後はオープンシステムだと断言できたか

その選択が為されないのは、ギークの提案が間違ってるからだ。

コンピュータが間違ってると言うタイプか?

違うだろ。

オマエの書いたソースが間違ってて、コンピュータソース通りに正しく動くんだよ。

  • 事前にわかっている問題を指摘するよりも蓋を開けてみたら問題があったということにしてしまうことを選択する
  • わざと調整を怠り認識相違という理由を残す

バッドノウハウなのは認めるが、誰も幸せにならない正しさを貫くことはギークとしての職責の一部か?

もしそう思うならそうしろ

責任は取られてるんだよ。

はんこの数だけな。

機械学習の重み付けと同じでな、それがスーツ出世パラメータに影響してんだよ。

ギークに向けて

記録を軽視するな。

証拠を残せ。

ログ無しにサーバ管理しろと言われたらどう思う?

「なんでバグが無いのが判ってるのに単体テストするんだよ」とか言って、テスターがサボったら困るのは誰だ。

バッドノウハウなのは理解してる。

ただ、監視システムタイムレコード追加するより、カメラ範囲内に時計を置くのがハックなんだろ?

コードスニペットは溜め込むくせに、口頭で言った内容をメールで送れないのは何故だ?

ギークなら可読性を上げろコメントを残せソースを引き継げるようにしておけ。

JavaコンパイラC++ソース突っ込んだってエラー吐くだけだ。

クソコンパイラだと思っても、作法には従って書け。

まあ、見通しが悪いと思うなら、オマエが新言語作ってくれても良いんだぜ?

2015-02-10

お耳汚し

自分の取り組み姿勢が悪いのはわかってるけど愚痴りたい。

稚拙文章ですが勘弁してね。

入社5年目の業務系SE

たくさんのシステムがある中、保守する人が大規模案件に連れて行かれいつの間にか担当システムが増えている。

それはいいんだけどさ、1回も触ったこと無い、障害対応もしたこと無いシステムメンテ費用見積もれって言われてもわからんよ。。。

まず業務がよくわからん。いや、業務は何とか理解しようと努めているけど、メインフレーム上で山のようにバッチ処理があるって時点で体が拒否反応起こしちゃう

プロセス見てもいろんなところからデータ引っ張ってきてるし、いろんなデータ吐き出してるし、途中でワケワカメになって最後まで辿り着けない。

機能全体通して検証するって言われても、どんなデータ必要でどういう順番で処理してなんか把握しきれないし。

それでも考えて前任者に確認して、「いいんじゃない?」ってなって一度は見積もり提出したけど、今日見てたらちょっと違うんじゃ?ってところ出てくるし。

明日は協力会社さんに説明するんだぜ。説明ってか相談だな。開発時のメンバーだって言うし。

もうこりゃ任せっるきゃない。何とかなる、いや、何とかしてくれ!

あーもーやだなー。なんでこんなに後ろ向きな気持ちなんだろう。

仕事やめる?

できないよねー。

だって今年結婚するんだもんなー。

新生活楽しいなー。新しいお家楽しいよー。

でも仕事イヤだなー。

2014-08-11

http://anond.hatelabo.jp/20140811150735

その気になればスパコンと同じ性能をクラウドから個人が引き出せる。

クラウドコンピューティングって今時のスパコンと同程度の性能発揮できるんですかね???

10年前のスパコンと同じ性能、っていうんなら、10年前のパソコンだって20年前のメインフレームより性能良かったべな。

2014-06-02

UNIXってそういえば

おいらがエンジニアになった90年代頭にUNIXが商用で使われだしたんだけど、その時はまだメインフレームが強力な時代で、UNIXエンジニアは日陰者だった。

こんなの使える訳ないとか、おもちゃとかさんざん言われた。

偉そうなおじさん達が3270端末を使っている横で、xtermでemacsしこしこ使っていた。1280x1024のディスプレイは自慢だったけど。

それが今やレガシー扱いなわけだが、よく考えると当時のメインフレームはまだ20何歳だったわけで、今のUNIXより歴史がなかったわけだ。

なんだか感慨深い。

そういえば、当時数少ないUNIX本の「Life with UNIX」に、MacUNIXっぽいみたいな記述があったけど、本当にUNIXになるなんて当時誰が想像したんだろう。

2014-03-06

http://anond.hatelabo.jp/20140306120859

XMLDBもだけど、階層DBが昔メインフレームではCOBOLとセットでよく使われていたと聞いたので、オープン系で使われないのが不思議というか。

2013-05-17

かつて、私の隣にSQL魔女がいた

今日プロジェクト打ち上げがあったのだが、とあるサプライズ……三ヶ月前に寿退社した先輩との再会に思わず涙ぐんでしまい、ひどくばつが悪い思いをしている。今も顔の火照りが抜けてくれない。アルコールは抜けたのに。彼女はかつてSQL魔女と呼ばれていた。

から遡ること一年前、私は辞令を貰い、二年目にして事業部ごと変わるという波乱をようやく乗り切って、業務系のSE仕事内容、特にWebアプリレイヤーについてOJT形式で学んでいた。そこで先生にあたる方として付いたのが、ちょうど手待ちだった先輩である。初めてお会いした時の先輩に対し、私は正直ちょっと物足りなく感じていた。

初日に行ったPCのセッティングでは、これやってと先輩から資料を渡されたのだが、外部にネットが繋がらない。先輩に相談して弄ってもらったのだけど繋がらず、今日は社内ネットで我慢して、と言われてから二日後、資料が古かったことが判明。

与えられた課題を終えるごとに、コードを提出するのだが、見たよ〜出来てると思う、頑張ったね〜と言われた後で、そのプロジェクトを下敷きに発展課題に足を進めたら、でっかいバグがあったり。

万事その調子で、今やってる課題放り出して、プロジェクトオイラーの問題でも解いてた方がよっぽど楽しいなぁと若干サボりたいと思い始めた頃、炎上プロジェクトへ先輩と二人テスターとして出向するよう、上司から命じられた。炎上プロジェクトリーダーから手待ち要員いない?と声がお上に届き、降りて来た結果先輩と自分がいたわけだ。

前の事業部ではずっと同じ客先にいたわけで、頭では分かっていても鼻先三寸で飛ばされることには不安がつきまとった。

「これから行く先はどうなんでしょうね?」

先輩へ問うと、

「基盤にいたんでしょ。メインフレームが扱えるなら大丈夫だよ〜」

豆腐すらぷるぷる震えそうな声が返ってきた。

この時の私は、まだ事業部を転属して間もなかったし、プライドばかり高くて奢ってたように思う。事業部を変える→入社して以来の経験値がまた0に、と失うことに対する不満ばかりで、それが拗れて数少ない基盤系経験アプリ開発者、そんな肩書きばかりを強調する変人に成り果てていた。自己紹介で、どうも、基盤から参りましたと、そこだけは大きい声が、今思い出したけどマジで恥ずかしい。

から、だろう。このゆるふわな先輩とドナドナされることに密かに感じていた屈辱には、出向いた先で押された駄目テスターという烙印によって罰があたることになった。

その理由は、私がSQLを全く使えなかったことにある。テスターとして行うことになったのは表示画面の統合テストで、UI検索結果とデータベースに直接SQLを打ち込んで得たレスポンスを目で確認していく作業だった。UIは、境界値さえ気をつけて、仕様通りに実施すれば何とかなる。しかし、SQLで再現が出来ない。この仕様はどうやったらコマンドに落とし込めるんだよ。頭を抱える中で思い出したことがあった。

教育過程Javaサーブレットを学んだが、その一つにJDBCも勿論習った。そこで私は何をしたかmysqlに繋げればそれでいいやと、エグゼキュートで実行する際に渡す魔法文字列……つまりSQLの中身は、すべてコピペで済ませていたのだ。社内教育資料を内部作成するにあたり参考にしたと思われるネットから……構文チェック効かないし、ここは手を抜いてもいいだろう、これが要領の良さというものさ……アホーアホー私のアホー。

三日目の午後二時、進捗を確認しに来たPMにすべてを告白すると、ちょっと来てとPMが連れ出したのがあの先輩の席だった。

「申し訳ないけど今やってるテストは止めて、これから定時いっぱい最低限テストが出来るように彼にSQLを教えてやってくれ。」

良いのですか?と顔をあげるとPMは何を勘違いしたのか、やにわに私の肩を叩くと、

彼女SQL魔女と呼ばれている。半日でお前も即戦力だよ。」

と去っていった。顔を先輩へ戻すと、あのPMさんは嘘つきだから信じないほうがいいよといつものふわふわした声でにっこり。

宜しくお願いします。ノートパソコンを横に私は型通りの挨拶。四時間後、私は傲慢さを、尻の毛まで抜かれることになる。

私はSQLの深さを知った。SQLのQとは何だ?Queryであります、サー!!今も時々夢問答を繰り返す。そう、全ては問い合わせ次第なのだ。今思えば、あの時やったことはT2テストを使ったSQL文の作成添削しかSELECTによる条件抽出のみだったが、そこに全てが詰まっていた。

DISTINCTとORDER BY共存で詰まってわけがからなくなったコードは、もっとシンプルにいけるよと副問い合わせに書き換えられて。ネストワイルドカードを多用してスパゲティになったコードを、先輩はLEFT JOINとWHEREとORで全てをすませた。

なんということでしょうマニキュアが塗ってある長い爪から想像もつかない早さで直されていく構文に脳内で途中から匠の曲が流れ始めたのを覚えている。本当に、なんということでしょう。先輩はSQL魔女だった。

翌日、先輩の教えはしっかり自分に身に付いていた。すらすら書けるSQLサクサク進むT2テスト。条件設定に悩んで、エクセルに吐き出してからリストコピペで逐一加工してた時間馬鹿みたいだった。先輩のところへ、帰りしなに昨日のお礼と作業進捗に激震が走ったことを伝えると別にお礼なんていいよーといつものふわふわした顔で微笑んでくれた。

それから先、配属先が決まるまでの条件付きでテスターとして入っていたはずだったが、T2試験が終わり、T3試験が始まってもなぜか私はそのプロジェクトにいたままだった。DB担当者として。もともと基盤だったわけだし、バッチファイル処理でスクリプトがそこそこ書けたというのもあるけど、SQLが書けたというのはすごく大きい。昼休み、いつのまにか私はプロジェクトオイラーの問題に代わって、名著「SQLパズル」を解くのを日課としていた。

先輩は仲良くなる暇もなく、その後すぐにプロジェクトを移り、メーリングリスト寿退社を知った。炎上したプロジェクトは、なぜか横展開を経て今に至り、私は相変わらずここにいる。だが、あの時SQL魔女がかけた呪いは今もしっかり私に根付いている。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん