金融機関系SEの仕事につきまして教えて頂きたいです｡こちらの記事を拝見しますと､大変に厳しい内容が書かれているのですが､ http://zenikasegi.com/bank-engineer-work…

人力検索はてな

ﾓﾊﾞｲﾙ版を表示しています｡PC版はこちら

金融機関系SEの仕事につきまして教えて頂きたいです｡
こちらの記事を拝見しますと､大変に厳しい内容が書かれているのですが､
http://zenikasegi.com/bank-engineer-work-busy
都銀ではない場合や､雇用形態等にも関わらず､どこも平均的に
これほどまで厳しいのでしょうか？
例えば､地方大手銀行のｼｽﾃﾑ子会社で正社員で働く場合､
知力･体力の面で必要な水準の具体的な情報
(例えば何の言語でどれぐらいのｽﾋﾟｰﾄﾞ(納期)で組めるくらい､
何時間連続労働が出来るくらいの体力､等)
がどうしてもわからないため､教えて頂きたいです｡
10,000ptで質問させて頂きます｡何卒よろしくお願い申し上げます｡

●質問者: じゃっくそにっく
●ｶﾃｺﾞﾘ:経済･金融･保険
○ 状態 :終了
└ 回答数 : 6/6件

▽最新の回答へ

● 質問者から

(補足)すみません｡書き忘れてしまったのですが､
知力･体力の他にｽﾄﾚｽ耐性(必要な)についてもご存知でしたら教えて頂きたいです｡

▽1 ● ﾋﾞ＝ﾖﾝｾ
●1667ﾎﾟｲﾝﾄ

いわゆるIT業界に身を置いて十年近くになりますが､それほどﾌﾞﾗｯｸな職種ではないですよ｡
何をﾌﾞﾗｯｸと騒ぐかにも因りますが､どんな業種だって楽にお金は稼げません｡
起業した人は残業時間という物差しがなくなるだけでｻﾗﾘｰﾏﾝSEよりも働いている時間が多い人はたくさんいますし､農家やﾊﾟﾝ屋さんなど朝日が昇る前から働くのが当たり前の人達もﾌﾞﾗｯｸって言っておけばいいんでしょうか｡

質問で書かれているﾌﾞﾛｸﾞの話は､経歴の詐称がないという前提をおいても1?2割程度だと思って読んでおけば良いと思います｡
よく読まれている記事は十年も前に終わったﾃﾚﾋﾞ番組がﾈﾀですし類似のﾈﾀを書いているﾌﾞﾛｸﾞも他にたくさんあります｡
ﾄﾞﾒｲﾝ名からも察するにｱﾌｨ目的のﾊﾞｽﾞﾘを狙った記事という読み方で良いでしょう｡

たしかに鬱になったりする人がいないわけではありませんが割合で言えば少数です｡
最近はいろいろとうるさいので残業時間もきっちりと管理されますし､ｾｸﾊﾗ･ﾊﾟﾜﾊﾗも教育があったり駆け込み窓口みたいのもあるようです｡
ですから罵声が飛び交っているような職場なんてめったにありません｡

銀行系だけではありませんが､基幹系のｼｽﾃﾑを扱う場合だと実機を扱う時間帯が限られるｹｰｽがあります｡
夕方からしかﾃｽﾄができなかったり､納期が迫っているとｼﾌﾄ制で24時間交代でﾃｽﾄをしたりする場合もあります｡

言語でいうとCOBOL､JAVA､VBが多いです｡
最近はC#も割りと使いますが私のｲﾒｰｼﾞではﾒｲﾝではないです｡
銀行の直系子会社だとﾌﾟﾛｸﾞﾗﾑを作る機会は少ないです｡
いわゆるｴｸｾﾙ方眼紙と揶揄される仕様書を作って孫請けのｼｽﾃﾑ会社の管理や納品のﾃｽﾄなどが業務の中心となります｡

質問で聞かれていることがいまいちよくわかりませんで的を外した回答になっているかもしれません｡
質問者さんのﾌﾟﾛﾌｨｰﾙによると30才のようですが､銀行系のSEへの転職希望ということでしょうか｡
必要とされる知力､体力､ｽﾄﾚｽ体制が他の職種に比べて厳しいのかということがお聞きになりたいのであれば､さして変わりはないということです｡

じゃっくそにっくさんのｺﾒﾝﾄ
ご回答大変ありがとうございます｡おっしゃる通りで､銀行直系子会社へ転職の岐路におります｡答えにくいところがありまして申し訳ありません｡私が考えるIT業界でのﾌﾞﾗｯｸは､例えば･経営者が利益優先で労務管理が事実上機能しておらず､技術者が消耗品扱い･ﾓﾉ作りが好きな人が嫌になってしまうほど､理不尽な超短納期､使用者の安全性を無視した製造方法を強要される｡･ﾍﾞﾝﾁｬｰ的過ぎて本当に出来るか出来ないか全くわからないものに対し､常に見積もりやｷﾞﾘｷﾞﾘなｽｹｼﾞｭｰﾙを出さなければならないといったような部分になります｡銀行直系の場合､もしかしてﾌﾟﾗｲﾑ案件をﾌﾟﾛﾊﾟｰのPM的な立場で行うことが多いのかな？と思いました｡

ﾋﾞ＝ﾖﾝｾさんのｺﾒﾝﾄ
> ･経営者が利益優先で労務管理が事実上機能しておらず､技術者が消耗品扱いあくまでも会社によります｡少人数のｿﾌﾄｳｪｱ会社でﾜﾝﾏﾝな社長だとそういう会社がなくもないですが回答にも書いた通り最近は発注側でもうるさいのであまり見かけません｡｢消耗品｣という言い方にはそれぞれのｲﾒｰｼﾞがあると思いますが､大規模な開発案件をするような場合には属人的なものは忌避されます｡そういう意味では作業者は取り換えが効く駒でなければいけません｡普通の言い方をすれば｢あの人じゃないと保守ができない｣ようなﾌﾟﾛｸﾞﾗﾑを作る人は敬遠されます｡ > ･ﾓﾉ作りが好きな人が嫌になってしまうほど､ > 理不尽な超短納期､使用者の安全性を無視した製造方法を強要される｡短納期な案件がないわけではありませんが､普通はありません｡発注元の銀行では､開発案件の審査があって予算がつけられてからの発注になりますから､そもそも無理な発注はしてきません｡受発注には適宜監査が入りますので100人月を一ヶ月でというような案件は架空発注の疑いをかけられてしまいます｡ > ･ﾍﾞﾝﾁｬｰ的過ぎて本当に出来るか出来ないか全くわからないものに対し､常に見積もりやｷﾞﾘｷﾞﾘなｽｹｼﾞｭｰﾙを出さなければならない良くも悪くも最先端な技術要件を求められるような案件は出てこないです｡そういう意味では下手なWeb制作会社などに比べるとﾎﾜｲﾄだと言えます｡逆に言えば｢ﾓﾉ作りが好きな人｣にとっては面白味に欠けるきらいはあるかもしれませんが､そういう人はﾍﾞﾝﾁｬｰ色が強いところに行くなり､自分で起業するなりすればいいと思います｡｡ > 銀行直系の場合､ > もしかしてﾌﾟﾗｲﾑ案件をﾌﾟﾛﾊﾟｰのPM的な立場で行うことが多いのかな？ﾌﾟﾛｼﾞｪｸﾄによります｡内製ではまかなえない大きなﾌﾟﾛｼﾞｪｸﾄではPMとして動くことが多いでしょう｡最近は単価の安い海外のｿﾌﾄｳｪｱ会社を使うことも多いのでﾌﾟﾛｼﾞｪｸﾄにかかわる人数も増える傾向にあります｡またｷｬﾘｱｱｯﾌﾟしていくとPMの立場での仕事がほとんどです｡これはIT企業であれば､だいたいどこでも同じような事情でしょう｡

じゃっくそにっくさんのｺﾒﾝﾄ
1つ1つの不安な点に対し丁寧なご返信､誠にありがとうございます｡ 1人あたりの負荷量を度外視した消耗品扱いには困った経験があるのですが､業務の継続性や安全上の観点から､常に2人以上で情報や技術を共有する事には大賛成と考えております｡また､監査のない急激な受発注形態や､技術の流行り廃りが激し過ぎると疲弊しますし､なかなか落ち着いて働くことが難しい､比較的堅いほうがよいかと思っています｡ただ､あまり人に指示を出すことに慣れておらないため､そこだけが少し不安に思っております｡

ﾋﾞ＝ﾖﾝｾさんのｺﾒﾝﾄ
> また､監査のない急激な受発注形態や､技術の流行り廃りが激し過ぎると > 疲弊しますし､なかなか落ち着いて働くことが難しい､ > 比較的堅いほうがよいかと思っています｡監査は必ず入ります｡事後に行われ不備には指摘が入ります｡進行中のﾌﾟﾛｼﾞｪｸﾄに対する是正という意味では弱いですが､そのようなことを繰り返しているとほじくりかえせばいろいろとほこりは出てきます｡指摘をされた後には改善されたかどうかの予後ﾁｪｯｸも行われます｡技術のはやり廃りについては一概に言えませんが､予算を取るさいに償却期間もﾁｪｯｸされますので大抵のﾌﾟﾛｼﾞｪｸﾄでは保守期間は長めにとられる傾向があります｡ > ただ､あまり人に指示を出すことに慣れておらないため､ > そこだけが少し不安に思っております｡発注関係にあれば発注先にもﾌﾟﾛﾏﾈはいますし､通常はｷﾞﾘｷﾞﾘの判断を求められるようなことはなくﾙｰﾁﾝﾜｰｸです｡最初の内は判断に困ることがあれば上司に相談すればよいだけです｡ﾌﾟﾛｼﾞｪｸﾄの規模はﾋﾟﾝｷﾘですし､よほどの実績を提示しての転職でなければ最初の内はそれほどﾘｽｷｰな判断は求められません｡

じゃっくそにっくさんのｺﾒﾝﾄ
ありがとうございます｡なんだか最初に驚いて感じていた不安が色々と教えて頂いて安心してくることができました｡

▽2 ● lovevoiceryu
●1667ﾎﾟｲﾝﾄ

私はSI側で､主に都銀を担当し､地銀､信託､証券などを経験してきました｡
一口に銀行といっても､銀行ごとにｶﾙﾁｬｰはかなり異なります｡
地銀のｼｽﾃﾑはｸﾞﾙｰﾌﾟ化が進んでおり､ｼｽﾃﾑ部門､運用部門ともに縮小傾向にあると思います｡

すでに回答に出ているとおり､言語はCOBOL､Javaが中心です｡
しかし歴史的経緯からｼｽﾃﾑによってはﾏｲﾅｰな言語を使用しているｹｰｽも散見されます｡

要求水準については､案件により異なります｡
例えば法改正による制度案件は余裕がありますが､銀行合併のようなｹｰｽではﾊｰﾄﾞﾜｰｸになることもあります｡
つまり繁忙期と閑散期に波があるということです｡

ﾘﾝｸ先の記事のようなところもありますが､全部ではなく､一部だと思います｡
個人的には､信託､証券では理不尽な思いをしました｡

じゃっくそにっくさんのｺﾒﾝﾄ
SIerからのご視点のご回答､誠にありがとうございます｡もしﾊｰﾄﾞな開発案件になる場合を想定してもう少し具体的な部分をできましたらお伺いしたいのですが､大規模なｼｽﾃﾑになりますと､習得の必要があるﾌﾚｰﾑﾜｰｸが多くなるｲﾒｰｼﾞがあり､個人的にCOBOLはﾊﾝﾄﾞｺｰﾃﾞｨﾝｸﾞしか行ったことがなく､言語仕様的にあまりﾌﾚｰﾑﾜｰｸを構成させるｲﾒｰｼﾞが湧かず､ Javaは逆に標準ﾗｲﾌﾞﾗﾘもﾌﾚｰﾑﾜｰｸも大変種類が多いｲﾒｰｼﾞを持っております｡そこで､もしこれは最低限知っておらないと困ると推定されるようなことがあれば少しでも構わないので教えて頂きたいです｡よろしくお願い申し上げます｡

lovevoiceryuさんのｺﾒﾝﾄ
どういうｽｷﾙが求められているかは募集要項次第だと思います｡守秘義務に触れない程度に書きますと､言語にCOBOLをあげましたがPL/1が中心の銀行もあります｡ Javaのﾌﾚｰﾑﾜｰｸにしても､ある大規模開発ではWACS､別の大規模開発ではStrutsが採用されたｹｰｽがあります｡つまり､最低限知っておくべきことを具体的にあげるのは難しく､就職先次第だと思います｡なお､銀行は教科書に近い開発の仕方をしますので､情報処理試験の内容などは他の業種よりも役に立つと思います｡ (むしろ銀行などの開発や運用のﾉｳﾊｳが試験にﾌｨｰﾄﾞﾊﾞｯｸされていると考えた方がよいかもしれません) 30才という年齢ですと､ﾏﾈｼﾞﾒﾝﾄｽｷﾙを求められる可能性もあると思います｡ｽﾍﾟｼｬﾘｽﾄでいくのか､ﾏﾈｼﾞﾒﾝﾄもやるのか､はっきりしておいた方がいいでしょう｡

じゃっくそにっくさんのｺﾒﾝﾄ
ありがとうございます｡ひとえに言うことができない質問になってしまっており大変申し訳ないのですが､頂いた情報は非常に参考になっております｡私は性格的にはｻﾎﾟｰﾀｰﾀｲﾌﾟのようなので､できればﾘｰﾀﾞｰをｻﾎﾟｰﾄするｽﾍﾟｼｬﾘｽﾄを目指したいと思っております｡

▽3 ● kotaeru3
●1667ﾎﾟｲﾝﾄ

国立大学で情報系を出ましたが､情報系に就職しなかった者です｡
大企業と中小企業にて働いた経験がありますが､知識と経験上､
社内SE的な仕事やｼｽﾃﾑ管理者として発注者側の仕事もしています｡

地銀系のｼｽﾃﾑ会社ですと､自分の銀行のｼｽﾃﾑの他に､
銀行と取引のある企業や行政系から発注を受けて､
業務管理系のｼｽﾃﾑのｶｽﾀﾏｲｽﾞなどを行う部署もあります｡
都合上発注したことがありましたが､正直､実力は感じませんでした｡
しかし､対応はとても親切でした｡
接遇系の研修がしっかりしているのかなという印象です｡

地銀の友人もいますが､やはり銀行によってｶﾗｰがかなり違います｡
どの企業も信用商売なので､丁寧さは他業種よりあります｡
そう考えると､大企業系の情報系会社や中小の情報系よりも居心地が良さそうです｡

どの会社でも色々な仕事がありますので､
自分の適性にあった仕事ができる能力
が高い人が上手に仕事をされているのではないでしょうか｡

ｻﾝﾄﾞﾊﾞｯｸﾞやｸｯｼｮﾝ材的な仕事はどの会社にもありますし､
ﾌﾞﾗｯｸ企業にも多くの人が働いていて企業として成長しています｡

企業の中で自分がどのﾎﾟｼﾞｼｮﾝでありたいのか､
どんな役割を果たしたいのか｡
それが明確なほど､判断を迷わないと思います｡

過去の質問や回答などを拝見させて頂いたのですが､
ﾒﾝﾀﾙ系の勉強をされるのも､良いのでは無いでしょうか｡
個人的には｢人を動かすﾃﾞｰﾙｶｰﾈｷﾞｰ｣あたりがｵｽｽﾒです｡

すべてのことは､自分の心の使い方次第です｡

ｺｯﾌﾟ半分の水をどうとらえるかと同じです｡
同じ物や現象を見ていても､受け取る側のとらえ方次第です｡

ﾏｲﾅｽにとらえている人の文章を読みすぎると､
ﾏｲﾅｽなｱﾝﾃﾅの感度が高くなってしまいます｡

給与や待遇以外の会社や職業のﾌﾟﾗｽ面を調べて､
ご自分に合った職種や働き方を見つけてください｡

じゃっくそにっくさんのｺﾒﾝﾄ
ﾒﾝﾀﾙ面も含めたご回答､大変ありがとうございます｡事情を説明させて頂きますと､私は現在は､製造業の大企業を親会社とするｻｰﾋﾞｽ業種系のｸﾞﾙｰﾌﾟ子会社内で､社内SE(と呼べるかどうかﾚﾍﾞﾙ的にはわからないこと)をやっております｡ここ5年ほどはあまりｺﾝｽﾀﾝﾄ･本格的な開発をやる機会は無く､基本的に親会社から下りてきている出来合いの基幹ｼｽﾃﾑでは出来ない事を出来るようにする道具を作る社内の道具屋のような存在です｡何も無い時はｲﾝﾌﾗ管理や障害対応の用心棒的な立場で､進歩に欠けるところがあるので､悩んでおります｡ただ､私自身の考え方としては､人の役に立てて感謝をして頂けるのであれば目立たない裏方でも構わないとも思っております｡おっしゃるような心構え的なところも､何が必要かを知りたく､大変重要視しております｡

kotaeru3さんのｺﾒﾝﾄ
私も裏方で､仕事をすることを望んでいます｡できるだけ前には出ないようにしています｡企業内で､成長する方法は､与えられた仕事に120％の成果を出すことと言われています｡つまり､言われたこと以上の成果を出したり､納期より早めに終わらせたり､仕様書にﾌﾟﾗｽした提案することが､仕事を楽しむｺﾂなのだと思います｡そういった信頼を積み重ねると､やめられては困る人間になれるので､仕事内容が自分で決められるようになったり､できないことはできないと言えるようになり､異動先が叶うようになります｡笑企業の一員である以上､職場環境は自分の行動からも作られるため､自分から行動することを心がけています｡

じゃっくそにっくさんのｺﾒﾝﾄ
ありがとうございます｡現在の職場でもそのような経験をしたことがあり､異動が通ったことがあるため､とてもよくわかります｡もし転職する場合､また0から信頼を積み重ねることになりますが､ 2年くらいはどうしても必要になるのではないかと思っております｡

▽4 ● newta
●1667ﾎﾟｲﾝﾄ

結果的にどんな人間でﾁｰﾑが構成されているかによるので現場によります｡
ﾏﾈｰｼﾞｬがしっかりしていれば､それなりにしっかり仕事は進みますが
ｴﾝｼﾞﾆｱの力不足が目立てば残業は多くなります｡

ｴﾝｼﾞﾆｱの力だけあっても､ﾏﾈｰｼﾞｬが仕事をちゃんと定義できなければ､締切は変わらないままﾀｽｸが落ちてくるので徹夜続きになるでしょう｡

ｴﾝｼﾞﾆｱとしてできることは技術を磨き続けることです｡
おそらくJavaをちゃんと学んでいけば､銀行系以外でも仕事は多くあるので食いっぱぐれるｺﾄは無いかと思います｡

じゃっくそにっくさんのｺﾒﾝﾄ
ご回答ありがとうございます｡そうですね､人間で左右される部分は大きいですね｡最近読んだ本に｢人間関係が良ければ人生の80％はうまくいく｣とあり､少し誇張はしているとは思ったものの否定できないとも思いました｡ Javaについて､もし自宅でうまく学ぶ方法があればｱﾄﾞﾊﾞｲｽを頂きたいです｡

newtaさんのｺﾒﾝﾄ
まずはJavaの基礎を本を1冊読んで理解した後は､何かｱﾌﾟﾘｹｰｼｮﾝを作ったほうが理解が早いと思います｡一番の流行りのﾌﾚｰﾑﾜｰｸはSpringBootだと思うので､これでｱﾌﾟﾘｹｰｼｮﾝを作ってみるといいかなと思います｡特に作る題材が無ければ簡易Twitterのようなものがいいかなと思います｡どこに行っても需要がある技術を身につけられれば､その現場がﾌﾞﾗｯｸだったら異動をするか転職できるので技術を身につけるのが一番です｡ｴﾝｼﾞﾆｱとしての強みは純粋に技術力だと思うのでがんばってください｡

1-5件表示/7件 4.前の5件|次5件6.