今回はこういった疑問にお答えします。
私は新卒でIT企業に入社し最初の２年間は金融系のプロジェクトに属していました。その後１年は流通系のプロジェクトにうつり、紆余曲折のあと、そして現在はイギリスのロンドンでSoftware Engineerとして働いており、日々コードと戦っています。
今回は金融系のプロジェクトに関わっていた時の経験を元にIT業界でも金融系は避けた方がいい理由３つをご紹介いたします。
(2022年4月追記)
この記事でも書きましたが、イギリスでSoftware Engineerとなった今思うことは、こういう金融系の辛さって、日本独自の労働文化や同調圧力から来ている、というのもあるかもなと思いました。
目次
その１：常駐になりやすく環境は劣悪。
まずこれですね。なぜ金融系の案件が常駐になりやすいかというと、セキュリティのためにLAN環境（インターネットに接続していない環境）になっている場合が多いからです。
例えばとある銀行のシステムに対してなにか作業したいとき、自分の会社からインターネット接続してリモートで作業するということができないのです。
物理的に自分がそのシステムが存在している銀行なり証券会社などに行く必要があります。
常駐になると通勤時間がのびる
常駐のなにが困るかというと、まず通勤時間がのびるということです。
私も実際に本社通いだったら片道30分だったのですが、常駐してきてねと言われて通勤時間が片道１時間30分になりました。笑。
しかもこれは地下鉄乗り換えあーりの、バス乗りーの、です。寝れもしないですね。笑。
特に東京の地下鉄は乗れば乗るほどストレス増で、消耗してしまいます。
常駐になると劣悪な環境に閉じ込められる
常駐になると概ねどこでも常駐部屋という所で作業することになりますが、概ねこの「常駐部屋」というのは以下の特徴があります。
- せまい
- 汚い
- 風邪が蔓延する
- テーブルや椅子の質が低い
そうなんです。常駐部屋では複数の企業から人がきているので１つのテーブルを大勢でわけるのが常であり、個人のスペースはかなり狭いです。
そして普通に汚いです。自分の机じゃないという感覚からか、ホコリが散乱していることが多いです。（誰も掃除しません。）
さらに密封された部屋であり、多くの人が行き来するので誰かがせきをするとすぐさま風邪が蔓延します。笑。マスク必須です。
テーブルや椅子はその常駐先のお古であることが多く、常駐先（銀行なら銀行に勤めている人たち）が使わなくなったテーブルや椅子を常駐部屋に回すことが多いようで、椅子がガタついていたり、机も古めかしいものが多いです。笑。
これは場所によるかも知れませんが、以前私が常駐していたところは上記にプラスして「ネットワークの速度がとてつもなく遅い」ということもありました。
作業したいのですが、ネットワークがもともと遅い＋常駐部屋にいる複数の企業からきた人たちが同時に使うのでさらに救いようのないぐらい遅いという状況で、正直仕事にならず土日にきて作業するということもありました。笑。
スポンサーリンク
その２：下請けに下請けを重ねた炎上案件が多い
まず普通のシステム会社が金融系のお客さんから直接案件を受けるということはあまりないです。
最先端のアプリとかWeb系はそうではないかもしれませんが、銀行内部で使われるようなシステムの案件には必ず、N○○関連の会社が絡んできます。
そのN○○の関連会社さんが銀行さんから話を請け、システム会社がさらに案件を請け、さらにそのシステム会社は中国の会社に開発をなげるという構造になっている場合が多いですね。
これのなにが良くないかというと下請けが増えれば増えるほど、二度手間が発生するリスクが高まるんですよね。
どういうことかというと、
銀行本体「Aという機能をシステムを６ヶ月後に追加したい」
N○○関連の会社さん「かしこまりました、おいシステム会社、A機能やりたいんだってあとはよろしく」
システム会社「A機能をやるには、A1とA2とA3をしなきゃな、スケジュールはこうこうで、設計書はこっちで書いたから、下請けさん開発よろしく」
下請け開発会社「まずはA機能のためにA1から開発していきます。」
～数週間後～
銀行本体「やっぱA機能じゃなくてBにしたいわ、なんとかしてよ、期限はそのままね。」
N○○関連の会社さん「ですよね～かしこまりました、おいシステム会社、やっぱB機能やりたいんだってあとはよろしく」
システム会社「え？！A機能っていったじゃないですか。もうAに向けてスケジュール決めて開発し始めてるんですけど…」
N○○関連の会社さん「いいからBでやってください。銀行さんがそういっているんです。」
システム会社「うーん、Bをやるには、B1とB2とB3をする必要があって、スケジュールはこうかなぁ、ちょっと厳しいけど期限に間に合わせなきゃ…下請けさんよろしく」
下請け開発会社「え、もうA2まで開発おわったんですけど…いまからBは間に合いません」
システム会社「土日出勤できるでしょ。われわれも下請け開発会社さんからもらったソースコードをテストしなきゃいけないので急いでください」
下請け開発会社「…」
ということです。このようにして、二度手間を繰り返して最終的には期限に間に合いそうにないので炎上し、人がバンバン投入され、それでも土日出勤、徹夜、終電帰り、となります。
スポンサーリンク
その３：失敗が許されないのでとにかく厳しい
よく言われることですが、「金融系」と「医療系」は失敗が許されません。
例えば倉庫の在庫を管理するシステムでバグがあり在庫が１個少なく表示されるとか、企業のキャンペーンのメールマガジンを誤ったタイミングで送ってしまったというレベルであればまだいいかもしれませんが、（いやそれもあんまり良くはないのですが）
極端な話、あなたの銀行口座の残高がシステムのバグによって100万円すくなく表示されるとか、オンラインバンキングで送金したのに違う人の口座に送金されたとか、システムのバグによって誤った量のクスリを処方するということは絶対にあってはならないことなのです。
なので金融系はシステムに対するチェックは相当厳しいものがあります。
なんの資料を作成しても、内容はもちろんのこと、誤字脱字やエクセルの罫線が消えているとかそんなレベルでも細かく見られ、注意されます。
あんまり同意はしてませんが、そういう誤字脱字などへの配慮ができていない人が扱うシステムなんて信用できないという理論とのことです。笑。
辛すぎますね。正直萎えます。
さらにシステムの要素が１～１００あるとしてその内の２０～２５までの要素を修正した場合、
普通に考えれば
- その修正した２０～２５自体が正しく動くこと
- ２０～２５に影響がある要素を洗い出して、そこも正しく動くことを確認。
でOKだと思いますよね。
でも金融系だと慎重に慎重を重ねるので、たとえ修正したのが２０～２５だけであり、影響する範囲の確認を済ませたとしても１～１００が本当に正しく動くのか再度全部確認して、となります。
構造からみて絶対に影響がない要素（＝確認を省略しても問題ない）があると論理的に説明できてもです。笑。
スポ根です。
この「ただしく動くか確認」というのはいわゆるテストのことです。
ちょっとした例でいうと「このボタンを押して、この画面に遷移すること」とか「この画面に数字をいれたら次の確認画面で表示されていること」とかそんな感じのことを確認します。
確認する意味が妥当であれば確認すべきだと思いますが、
「なんとなく心配だから」という理由で全部の再確認を強いられ、結果徹夜・終電・土日出勤になってきます。笑。
実体験として…６ヶ月終電で帰るということもありましたし、43時間連続で働くということもありました…。いまやもう無理ですね。
どの業界がいいのか？
というわけで、金融系はマジでおすすめしません。ちなみに流通系も経験しましたが、じゃあ流通系がおすすめかというと…それはそれでおすすめできないですね。
じゃあなにがいいのかというと、WEB系エンジニアです。
WEB系エンジニアだとベンチャーが多く融通のきく働き方ができる会社が多いです。
現在Javaで金融系SEをしている方で、WEB系の言語をやる場合は学習コストも低く、応用できる知識も多いかと思います。
求人を探す時のポイントとしては「自社開発」などのワードが良いと思います。受託開発だと、下請け的≒ブラック的な働き方になりがちです。
優良な求人ほど掲載期間が短く、すぐ人が決まりますので新着求人情報をメールで受け取れるようにしておくべきでしょう。
もしくはこの記事でも書きましたが、イギリスでSoftware Engineerとなった今思うことは、こういう金融系の辛さって、日本独自の労働文化や同調圧力から来ている、というのもあるかもなと。。
まとめ
ということで今回はIT業界で金融系を避けたほうがいい理由を３つ紹介いたしました。
日本社会からブラック企業がすこしでもなくなることを願っています…それでは！
