金融系SESの現場はどんな場所か【5年いた実感】

前回はSES全般の実態を書いた。今回はもっと狭く、僕が5年いた「金融・保険系」の現場に絞って書く。

金融系SESは、SESの中でも独特な世界だ。単価が比較的高い一方で、堅さ・厳しさ・古さが同居している。これから金融系の現場に入る人、今いて「ここは特殊なのか?」と感じている人の参考になればと思う。

例によって、良い面も物足りない面も、ポジショントークなしで書く。

とにかく「書類・ルール・セキュリティ」が多い

金融系の現場に入って最初に感じるのは、とにかく管理が厳しいことだ。書類が多い、独自ルールが多い、セキュリティが固い。この3つは、ほぼどの現場でも共通していた。

扱っているのが人のお金や個人情報である以上、当然といえば当然なのだが、他業界から来た人は最初に面食らうと思う。「なぜこの作業にこんなに承認が要るのか」と感じる場面は日常的にある。

セキュリティは現場によって別世界

セキュリティの厳しさは案件によって差があるが、厳しい現場はかなり厳しい。僕が経験・見聞きした範囲だと、こんな具合だ。

  • 強い守秘義務(案件の内容を外で一切話せない)
  • 私物スマホの持ち込み禁止(入口のロッカーに預ける)
  • 本番環境のある部屋は顔認証でしか入れない

「私物スマホ禁止」は、慣れていないと地味にきつい。日中は完全に連絡が取れなくなる。一方で、これだけ守られているということは、それだけ重いものを扱っているという裏返しでもある。

開発はウォーターフォール、技術はレガシー寄り

開発手法は、主にウォーターフォール。要件定義→設計→製造→テストと、工程がきっちり分かれて進む。アジャイルのようなスピード感を期待して入ると、ギャップを感じるはずだ。

技術スタックも、新しいものより安定・実績が優先される。僕が見てきた範囲では、

  • 古いバージョンのJava
  • COBOLが現役で残っている現場もある
  • クラウドより、オンプレミス中心

金融系は「枯れた技術=信頼できる技術」という価値観が強い。最新技術を触りたい人には物足りないが、逆に「動いて当たり前のシステムを長く支える」世界だと割り切れば、学べることは多い。

テスト・承認フローが、とにかく重い

金融系で消耗しやすいポイントがここだ。テストと承認のフローが、他業界より明確に重い。

  • テストのエビデンス(証跡)を細かく取る
  • 何重にもなるダブルチェック
  • リリースまでの承認手続きが多段

「コードを書く時間より、エビデンスを整える時間のほうが長いのでは」と感じることもあった。これも、ミスが許されない世界ゆえの仕組みだと理解はできる。ただ、開発そのものが好きな人には、しんどく感じる部分だと思う。

一番のキツさは「障害が許されない」プレッシャー

金融系ならではの本当のキツさは、技術の古さでも書類の多さでもない。障害が絶対に許されないという空気だ。

お金が動くシステムは、止まれば直接的な損害が出るし、社会的な影響も大きい。だから本番リリースには独特の緊張感がある。深夜や休日にリリース対応が入ることも珍しくない。「何も起きないのが当たり前、起きたら大問題」という世界で、長く気を張り続けることになる。

このプレッシャーに価値を感じられるかどうかで、金融系が向いているかが分かれると思う。

正直、「良かったこと」はあまり多くない

ここは正直に書く。金融系で5年やってきて、「良かった」と心から思えることは、実はあまり多くない。

しいて挙げるなら、普段ニュースや生活で目にする銀行・保険のシステムの裏側を、内側から知れたこと。これは確かに面白かった。

ただ、単価が高めという話はよく聞くが、第1回で書いたとおり、その単価が自分の給料に反映されるかは別問題だ。「金融系だから安泰」とも、僕は手放しでは言えない。

それでも、金融系の経験は「資産」にはなる

ネガティブに寄りすぎたので、最後にフェアな視点も書いておく。

金融・保険系のドメイン知識(業務知識)は、転職市場で評価されやすい領域だ。金融機関のシステムを理解しているエンジニアは一定の需要があり、経験者として見てもらえる。

つまり、現場での消耗と引き換えに、市場価値という資産は確かに積み上がっている。問題は、その資産を「今の会社の給料」で受け取れていないこと。だからこそ、自分の市場価値を一度ちゃんと確かめてみる価値はあると思っている。

次回は、その「市場価値の確かめ方」、つまりSESから転職を考え始めたら最初に何をすべきかを書く。

コメント