はじめまして。システム開発一部/内製開発Gのyamashitaです。普段は弊社の基幹システムであるGALAXYの内製開発エンジニアとしてシステム開発をしています。現在はGALAXYの将来的なリプレイスに向けたマイクロサービス化プロジェクトのチームリーダーをしています。
（他社様のプレスですがこんなことをやってます）
個人的な2026年の目標は
- 結婚式の準備を頑張る！！（ダイエット、プロフィールムービーづくり…etc）
- 風邪をひかない！！（昨年は約2か月に1回体調を崩していました…）
- お仕事頑張る！！
です。
業務領域と業務知識
さて本題に参ります。今私は証券会社のシステムエンジニアとして働いていますが、業務知識をどれくらい知っていればよいのかというのは、ここで働いているうえでの永遠の課題でもあります。知識習得のため『証券外務員一種の勉強をする』や『自分で証券取引をしてみる』とよく言われたりします。
しかし実際の証券システムのエンジニアの業務を行う上では、残念ながらそれらの行動は業務知識習得のためのスタート地点に立った程度といえるでしょう。では実際に事業会社で働くうえで求められるべき水準がどれほどなのかを、私の個人的な観点で考察してみました。あくまで個人的に考えていることなので、実際に弊社内で100%この水準を求められるということではありません。また私自身もこの水準に達しているわけではありません（Much to learn, you still have. - Yoda）。
参考文献
『ドメイン駆動設計をはじめよう - O'Reilly Japan』を参考文献として記載しておきます。今回はほぼこの著書の記載を証券会社であてはめたらどうなるかを記載しています。
ソースコードよりも現実世界で考えられるか
エンジニアやプログラマの間では、「動いているソースコードこそが真実であり、それが仕様である」という考えをしている方もいるかもしれません。しかし、証券・金融という世界においては、私は必ずしもそうは思いません。
なぜなら、証券業務は厳格な法規制や市場ルールの上に成り立っており「コードがどう動いているか」よりも、「現実世界（ビジネス）においてどう動くべきか」という正解が先に存在します。
Web画面や帳票といった表面的な部分だけでなく、裏側でお客様のお金がどう移動し、株式や投資信託がお客様のものになるのか、あるいは保証金や差金決済といった複雑なルールや規制がどう機能しているのか。こうした「現実世界のルール（業務知識）」を深く理解して初めて、ソースコードが「あるべき姿」になっているかどうかを検証することが可能になります。
ソースコードはあくまで現実の写し鏡であり、その真偽を判断するための真実（ソース・オブ・トゥルース）は、常に業務領域の中に存在しているのです。
『中核の業務領域』を理解し、自社の強みを考えられるか
当たり前ですが、証券会社は証券事業サービスを提供することでお客様よりお金をいただいています。事業をやっているうえではお客様に満足いただくサービスを提供するのはもちろん、『自社ならではの強み』を考える必要があります。このように他社との差別や競争優位を生み出す領域のことを上記の参考文献では『中核の業務領域（コアドメイン）』と言っています。中核の業務領域は差別化ができたらそれで終わりではなく、むしろ他社が追従できないように常に拡大・複雑化していきます。そのため、システム設計においても、この先避けられない変化や不確実性に耐えうる構造にすることが不可欠です。
そこで重要になるのが、「技術」の前に「業務」を深く理解するプロセスです。 まず何が中核の業務領域（またはそうなるかもしれないサービス）なのかを見極め、その強みや複雑さを業務レベルで正しく理解した上で、要件定義や設計・実装というふうに落とし込む必要があります。
現在の弊社におけるNTTドコモ様との業務提携も、まさにその好例です。提携を通じてどのような価値を提供したいのかを深く洞察し、将来の業務拡大を見据えて複雑さをコントロールしながら成長を支える設計を行う。そのすべての土台となるのが、「業務知識」なのです。
業務領域の境界を考えられるか
証券事業は明確に株式・投信・入出金（…etc）の業務領域に分かれているように見えますが、それらは実際にはかなり密接に関係しています（冒頭のマイクロサービス化のプロジェクトはそのようにモノリシックになった基幹システムをキレイにするプロジェクトでもあります）。
例えば『保証金』という言葉ですが、以下の業務領域で捉えられ方や複雑さが異なります。
- 株式領域…信用取引の証拠金。建玉の評価額によって必要金額が変化したり、現物株式を代用換算する等、複雑な業務ロジックが存在する。
- 投信領域…保証金の代用有価証券として投資信託を用いることがある。株式ほど複雑ではないが、保有する投信の評価額により代用換算額が変化する等の業務ロジックが必要。
- 入出金領域…預り金勘定⇔保証金勘定への振替の形跡を残す。お客様目線では特に変化はないが内部的な管理がされている
このように各業務領域での同じ言葉の違いを理解することは、『どこまでをその業務領域に含めるか』という責任の分岐点になるのです。そのためには業務領域を、非エンジニア部門（業務部門）と同じ言葉を使って理解しなければなりません。そうして初めて各業務領域ごとに在るべきシステム設計に昇華することができるのです。
まとめ
結局のところ業務知識を『どれくらい知るべき』を定量的に表現することはできません。ただ先述した3つの『考えられるか』という水準をあげてみました。これを読んでくれたあなたがその視点ですでに考えられている、または考えようとしている時点で、事業会社で働く素質はあると思います。あとはその思考ができるくらいの証券や金融の知識をつければよいだけ（これが一番大変ですが…）。
このブログを見て『業務知識をつけながら設計をしたい』『自分でサービスを考えて作りたい』と思われた方、ぜひ本ブログ右上の「エンジニア積極採用中」からのご応募をお待ちしております。
余談ですが、Wantedlyで私のインタビュー記事もあるので、気になった方はどうぞ（笑）
