Bank Pythonのアーキテクチャ：独自の金融システムの口述歴史

大手投資銀行のインフラストラクチャは、Pythonのような汎用言語と、カスタム構築されたオブジェクトストアや実行環境を組み合わせた、大規模で独自の（プロプライエタリな）エコシステムに依存していることが多い。これらのシステムは、作成当時に市販のソフトウェアでは対処できなかった大規模な金融問題を解決するために設計されており、その結果、開発者がGoogleで検索したりAIでサポートを受けたりできないツールを使用するという「代替的なITの現実」を生み出している。

コア・アーキテクチャ：Pythonと独自のオブジェクトストア

投資銀行は、プログラミング言語とグローバルなオブジェクトデータベースを統合した内部プラットフォームを頻繁に構築する。主な例は、Pythonと「Barbara」のようなシステムの組み合わせであり、これは銀行全体のためのグローバルなオブジェクトストアとして機能する。

オブジェクトストアの役割

これらの環境において、オブジェクトストア（Barbaraなど）は単なるデータベース以上の役割を果たす。それはアプリケーションの状態、データ、さらにはシステム自体のソースコードの中心的リポジトリである。

• ソースコードの保存: 一部の構成では、システムのソースコードは従来のディスク上ではなく、オブジェクトストア自体（例：特別な「sourcecode」リング内）に保存される。
• 状態管理: アプリケーションは、最小限のロックやトランザクションのオーバーヘッドで、dataclassesをオブジェクトストアに直接書き込むことで、内部状態を保存することが多い。
• グローバルアクセス: これらのシステムは、銀行全体でデータへの広範なアクセスを可能にするデフォルトの「ring」またはグローバルエリアを備えていることが多いが、機密性の高い取引を管理するには特定の権限システムが必要となる。

系譜と影響

これらのPython中心のシステム（JPMの「Alpha」やMerrillの「Quartz」など）は、多くの場合、初期の独自のプロプライエタリな言語の末裔である。多くはGoldman SachsのSecDB/Slangエコシステムに由来しており、そこではSecDBがオブジェクトストアとして機能し、Slangは変数名にスペースを含めることができるといった非従来的な機能を持つCに似た言語であった。

金融におけるレガシー移行の課題

これらの独自のシステムからの移行は、金融インフラに関連する極端なリスク・リワード比のため、歴史的に困難なプロセスである。

リスク vs. リワード

開発者やアーキテクトは、レガシーシステムの近代化を試みる際に、重大な不均衡に直面する：

• 限定的なアップサイド: 移行が成功した場合の主な利点は、昇進や専門的な評価である。
• 高いダウンサイド: 移行中の失敗は、「ビジネスを崩壊させる」ほどの巨大なシステム停止（アウトレージ）を招く可能性がある。

「ビッグバン」移行 vs. 段階的なリファクタリング

段階的なリファクタリングが一般的に好ましいとされるが、一部の金融システムは非常に深く統合されているため、「ビッグバン」移行が必要となる場合がある。これは、エンジニアがより印象的な履歴書を作るために、実証済みでパフォーマンスの高いレガシーシステムを「輝かしい新しいシステム」に置き換えるという、バグをより多く導入する可能性のある状況をしばしば引き起こす。

独自の銀行向けテクノロジーの運用上の現実

これらのエコシステム内で働くことは、ソフトウェア業界の他の分野とは異なる、独自の技術的および運用上の制約を生える。

ソフトウェア考古学

エンジニアは、現代の基準では冗長または非効率に見えるコンポーネントに遭遇することが多い。しかし、これらは通常、「ソフトウェア考古学」の結果であり、開発当時に成熟した市販のソリューションが単に存在しなかったために、コードが書かれたものである。

極端なエッジケース

金融システムは、標準的なコーディングを超えた複雑さを処理しなければならない：

• 規制上の制約: 例えば、韓国の取引には、たとえニューヨークから操作している場合でも、サーバーが物理的に韓国に位置し、トレーダーが韓国のライセンスを保持している必要がある場合がある。
• トレード・ブレイク: システム全体が「トレード・ブレイク」（特定の約定における銀行間の不一致）を追跡するために専用されている。その中には、訴訟や企業の倒産により、数年間にわたって未解決のまま残るものもある。
• 長期的な注文の永続性: 一部のシステムは、歴史的に、数十年前に遡る「Good Till Cancel」注文（例：1997年の注文）を維持し続けている。

「代替的なITの現実」

これらのシステムはプロプライエタリなものであるため、エンジニアが培うスキルセットは単一の会社に紐付けられている。これにより、外部のドキュメント、Stack Overflow、またはAIアシスタントに頼ることができない専門家集団が形成される。使用するツールがパブリックドメインに存在しないためである。これは、包括的なドキュメントの不足によってさらに複雑化し、内部知識の転送が少数の個人に高度に依存することになる。