保険・証券業界の現役SEが語る!システム開発に必要な能力

突然ですが、保険・証券業界のSEに必要なシステム開発の能力ってなんだと思いますか?

なんだろう……?論理的思考力とか?
うまくイメージできない!

なんとなくはわかっていても、実際に働いた経験がないと理解・説明できない部分ってありますよね。

そこでこの記事では、保険・証券業界のSEに必要な「システム開発の能力」を現役SEが紹介していきたいと思います!

ちなみに私のプロフィールは以下の通りです!

プロフィール
新卒で証券系シンクタンクSEとして入社。システム開発に従事し、約7年間働く。

(その内3年間は親会社【ユーザ企業側】への出向。ユーザ側の立場でシステム要件定義を行う)

その後保険会社に転職。

業務は協力会社のパフォーマンス管理プロジェクトマネジメント支援など。

約6年間働く中で、案件の成功・失敗を数多く見てきた。

保険・証券SEのシステム開発に必要な能力①:ユーザの業務を知る

それでは早速、保険・証券業界のSEに必要な能力を見ていきましょう!

ひとつめは「ユーザの業務を知る」です。

システムユーザがIT部門に作って欲しい“システムの要件”をまとめたもの。

それを「要件定義書」といいます。

これを作成するためには、証券であれ保険であれ、SEは業務知識の習得が必須となります。

どうして「要件定義書」が必要なの?

それは、ユーザが言葉で語り要件定義書に書く部分というのは、“彼らが想像している完成形”のせいぜい多くとも2割程度だからです。

具体的に説明してみましょう。

例えばユーザが「◯◯できる機能が欲しい」と要件定義書に書いた時。

◯◯という専門用語を調べその機能を実装すればOK……と思うかもしれませんが、実はそうではないのです。

一口に“◯◯”と言っても

  • ◯◯の前にある業務
  • 後にある業務
  • 参照する業務
  • 類似した業務
  • ……など

たくさんの業務が関わっています。

“◯◯の機能”をつけるには、付随する業務を全て変更する必要があるんだ!

その通り!

そのため“◯◯”部分だけを変えたとしてもあまり意味はありません。

それどころか、変更対応ができていないことにより、システム障害が起こる可能性もあります。

これでは、ユーザ検証テスト時に幻滅されてしまいますよね!

◯◯という機能は△△という業務の1処理であり、一連の業務プロセスの中の◇◇~■■間で行われる

といったところまで理解した上で、必要な対応事項を確認していく必要があります。

ユーザが文書化した少ない情報量をもとに、IT部門の人間が気がかりな影響業務について具体的に問いかける

その回答から適切な対策方法を引き出し、記録していく。

これが大事です。

一般的にシステム開発は、後工程になるほど手戻りによる工数が大きく発生します。

ですので、最初の「要件定義」で

いかにユーザのニーズとブレのない要件定義書を作成できるか

これが成功の鍵を握っているのです!

このために、ユーザの業務を知ることはものすごく重要

ちなみに、保険・証券業界のユーザ業務学習の近道としては、こちらがおすすめ。

保険・証券業界を理解するなら
  • 保険会社生命保険講座
  • 証券会社証券外務員試験

「試験受けるの?」と思ったかもしれません。

でもただ漫然と学習するより、何かチェックポイント(合格や修了など)があるほうが勉強に身が入ると思うので、ぜひ受けてみてください!

また、

SEの求人や業界が知りたい、相談がしたい!

そんなあなたは、就職/転職エージェントのUZUZに相談してみるのもおすすめです。

保険・証券SEのシステム開発に必要な能力②:協力会社を上手に使う

ふたつめに必要なのは「協力会社を上手に使う」能力です。

金融機関のIT部門というのは、当然ながらシステム会社ではありません。

そのため、その社員数も保有するスキルにも限りがあります

そんな中で複雑なシステムの大規模改修を年に何度も行わねばならない……

そんなミッションを負っているのです。

このため金融機関では、常に協力会社リソースを大量に使いその依存度がかなり高いのが特徴的です。

彼らはITに関してのプロ。

プログラミングや設計、テストスキルにおいては社員を上回る技術を持っています。

でも、基本的には「作業指示書に書かれた作業をこなす」人々です。

余分な工数になる「指示されていない作業」は原則行ってくれません

また、責任分担が曖昧な作業も行いません

ですのでシステム障害の元となる検討漏れ作り間違いが、その指示されていない領域にあった場合……

協力会社はまずそのエラーを見つけることができないのです!

そ、そんな……!
それってどうなの!?

それが契約の内容です。

だから彼らを責めるのは筋違いなんですよね。

IT社員が上手に協力会社を使うためには、例えば下記のような対応が必要です。

協力会社を上手に使う方法
  • 作業指示書には「作業の趣旨」も記載。極力自分に近い観点を相手に持ってもらう
  • 作業指示書は上司・関係部署など、出来るだけ多くの社員に確認してもらい漏れを防ぐ
  • 各作業明細には「協力会社と社員の役割」をしっかり明記しておく
  • 協力会社のリーダーと定例会以外にも密にコミュニケーションを取り、相手の“気がかり”をタイムリーに汲み上げる

保険・証券SEのシステム開発に必要な能力③:プロジェクトマネジメント(進捗管理)能力

みっつめに必要なのは「プロジェクトマネジメント(進捗管理)能力」。

金融機関のシステム開発で大規模なものは、新商品対応や制度対応などの「延期が許されない」案件が多いです。

もし納期に間に合わなかったらどうなるの?

最悪の場合、制度対応に間に合わなかったせいで金融庁から業務停止命令を受け、会社全体の風評を落とすような結果になってしまうことも……

そしてこういった大規模開発の大半は協力会社が担います。

ですので、彼らの実施状況を管理する能力は大変重要となります。

例えば定例会の中で

  • ずっと進捗が遅れているタスクがあるのに「後の工程で取り返せます」と自身満々に言われる
  • 「今週も問題なく進んでいます」の一言で報告を終えられる

これらは社員にとっては大変リスクのある状況です。

これまでこういった協力会社の「ポジティブ報告」。

プロジェクトの終盤までこの報告が続き、そして最後の最後で「実は……」と切り出され、そこで初めて進捗に致命的な事象が裏で発生していたことを知る……

ということは少なからずありました。

協力会社の中には、問題を社員の目に留まるギリギリまで隠すところもあります。

これは「なんとしてでも評判を落としたくない」という気持ちからくる行動なんですが、プロジェクトを回しているほうとしては困ってしまいますよね。

それを見抜けないと、結果的には社員のミスとされてしまいます。

進捗管理を有効にさせるためには下記のことが必要です。

協力会社の有効な進捗管理方法
  • 各タスクについて数字で進捗率を設ける
  • 報告時「先週から何%進んだのか」を根拠を交えながら報告してもらう
  • 遅れが出る場合「いつ追いつくのか」「具体的に何をするのか」をきちんと説明してもらう
  • 作業フォルダ内の中間成果物を途中で確認するなど、自ら作業現場をまめにチェックする

こんなに細かく管理するんだね!

これくらいやって当然、という人もいますよ!

事実、金融機関における一流のマネージャーは皆基本的には疑り深いです。

保険・証券SEのシステム開発に必要な能力④:“厳しい変更管理”を理解する

最後は「“厳しい変更管理”を理解すること」です。

実は、私が金融機関のシステム開発を経験してきて、一番理不尽に感じたのがこの「変更管理」です。

開発の一般論では、ユーザがシステム要件に口を出せるのは原則「概要設計」工程まで。

それ以降は決められた設計書に基づき構築がなされます。

家を建てる時、設計図が完成したら内見までは発注者が口出しをしないのと同じですね。

しかしながら多くの金融機関では、ユーザはこのルールを守りません

「詳細設計」工程や「開発」「テスト」工程になっても、機能追加や仕様修正の依頼を出してきます。

実はこの「遅すぎる変更依頼」への無理な対応が、主なシステム障害の原因のひとつなんです。

設計を終えた後にある部分を修正すると、その影響がどこに及ぶのかを検証するのに大変時間を要します

その対応を行っている最中に更に次の依頼が来ると、もはや結果がどうなるか誰も保証できない状態になってしまうのです。

そしてその結果システム障害が発生すれば、ユーザは「ITがミスをした」と主張するのです。

なんて理不尽なんだ!

そう、理不尽なんです。

でもこの“理不尽”がまかり通ってしまうのは、ユーザ部門がシステム案件の発注者であるため立場が強いという事情があります。

役員同士でも、営業・マーケティング部門とIT部門の本部長同士では、ほぼ例外なく前者の方が立場は上です。

また、大金を投じ滅多にないチャンスで開発してもらえるユーザ部門の立場としては、多少の我侭くらい聞いてもらえないと困るといった認識もあります。

こういった状況の中では、いくら正論を説いても簡単にはこの構造は変わりません

これについては特効策が余りないのですが……

しいて言えば、このような感じでしょうか!

“変更管理”への対応策
  1. 設計後の変更要求は「ユーザ部門、IT部門の部長クラスの承認が必要」というルールを作る
  2. 追加対応工数とスケジュール延期を見積ってユーザに承認を求める(その変更が他の機能に多大な影響を及ぼすことが見込まれるならば)

理不尽な要求に対し、泣き寝入りするのだけは絶対にダメです!

最後のアドバイスは「人を疑え!」

証券会社や保険会社のシステム開発プロジェクトは、銀行並に厳しい品質とスケジュール管理が求められます

そして、その大部分を協力会社に委ねなければならず、一方ではいつまでも変更要求を出してくるユーザがいます。

このような環境で成功を収めることは本当に難しいと思います。

ですので「常に人を疑って」ください!

ここまで読んできて、元も子もないように思われますが……

自分が心の中で相手に期待していることは相手には通じていない」と考えたほうがいいです!

「〜〜してくれるだろう」「わかってくれるだろう」と考えないことだね!

だからこそ書面に明記したり、詳細な説明を求めたり数字で相手に“無謀”を分からせたりすることが必要なのです。

私生活でこんな性格ですと人から好かれないかもしれません(笑)

でも、開発プロジェクトの成功のためには

自分の意思をいかに相手に「間違いなく」伝えるか
あるいは相手から聞き出すか

これがとても重要です!

保険・証券業界でSEを目指している人は、ぜひ参考にしてください!

このほかのSEの求人・業界を知りたい人は、UZUZに相談してみてくださいね!

UZUZってなんなの??
すっきりしている男性

「第二の就活」を運営するUZUZは、
20代に特化した就職/転職エージェントです。

創業から7年がたち、これまでサポートしてきた方は、約6万人!

もちろん、ただサポートしているだけではありません。

UZUZの実績紹介

  • ESなどの"書類通過率80%"越え
  • 面接からの"内定率85%"越え
  • 入社後1年間の"定着率90%"越え

以上のように業界内でも特に高い実績が残せている自負があります!

下のボタンより、詳しいサービス説明を見ることができるようしました。

私たちと一緒に内定を勝ち取りませんか?

おすすめの記事