金融系エンジニア必読：Fintech Engineering Handbookが示す設計の考え方

今回は、お金を扱うソフトウェアの設計原則をまとめた海外発のドキュメント「Fintech Engineering Handbook（フィンテック・エンジニアリング・ハンドブック）」を取り上げる。決済や台帳、外部プロバイダとの連携など、金融系システムに共通する考え方が体系的に整理されており、実務経験のあるエンジニアが読んでも学びが多い内容になっている。

Fintech Engineering Handbook（フィンテック・エンジニアリング・ハンドブック）とは何か

このハンドブックは、エンジニアのVoytek Pitula氏がまとめた実践的なドキュメントである。お金という「絶対に間違えられない」データを扱うシステムを設計する上で、何度も繰り返し登場するパターンを一冊にまとめたものだ。決済サービスやカストディ、会計、トレーディングなど、フィンテック領域に新しく参加するエンジニアの入門書としても、すでに実務にいるエンジニア同士の共通言語としても使えるように書かれている。

内容は、お金の表現方法、台帳（レジャー）への記録方法、資金移動の実行方法、外部システムとの連携方法、そして内部統制という五つの大きなテーマで構成されている。付録には金融ドメインの用語集や、実際の入出金フローを追った実例も収録されており、単なる理論に留まらず現場で使える形にまとまっている。

Fintech Engineering Handbook
https://w.pitula.me/fintech-engineering-handbook/

ハンドブックの土台にある三つの原則

このドキュメントで紹介されるあらゆるパターンは、三つのシンプルな原則から導かれている。まずはこの三原則をざっくりと押さえておくと、以降の話が理解しやすくなる。

原則	意味するところ
データを勝手に生み出さない	お金は無から生まれない。二重処理や根拠のない残高更新を許さず、重複排除や照合で担保する。
データを失わない	お金にまつわる出来事はすべて記録し続ける必要がある。精度、少なくとも一度の配信保証、イベント記録、不変性でこれを守る。
何も無条件には信用しない	外部の連携先も社内の別コンポーネントも世界そのものも信用しない。通知の検証や複数情報源の突き合わせ、前提が崩れたら大きな声で失敗することで担保する。

この三原則は、以降で紹介する個別のテクニック一つひとつと必ず結び付けて説明されているのが特徴だ。単なるベストプラクティス集ではなく、なぜそのプラクティスが必要なのかという理由が常に明示されている。

ハンドブックに書かれていることをざっくり解説する

まずお金の表現の話から始まる。浮動小数点数はほぼ確実に精度崩れを起こすため使うべきではなく、代わりに任意精度型や、最小単位を整数で持つ方式が推奨される。ユーロなら12.34ではなく1234という整数で持つイメージだ。あわせて、金額と通貨は必ずセットで一つの型として扱い、異なる通貨同士の足し算を型レベルで禁止する設計も紹介されている。

続いて記帳の話に移る。ここでの核となるのが複式簿記だ。すべての取引は貸方と借方という二つの動きとして記録され、残高そのものは保存せず、記録された動きから毎回導出する。一度記帳したレコードは変更せず、間違いがあれば打ち消しの記録を新たに追加していく。これによって、過去に何が起きたかを後から改ざんできない形で追跡できるようになる。

資金移動の実行に関するパートでは、外部の審査や確認が挟まる処理で残高を仮押さえしておく手法や、通信が何度再送されても処理が一度しか実行されないようにする設計、そして途中で処理が落ちても正しい状態から再開できるようにする仕組みが取り上げられている。分散システムではネットワークが必ずどこかで失敗するという前提に立ち、それでも二重にお金を動かさないための工夫が並ぶ。

外部世界との付き合い方も一つの章として独立している。決済プロバイダなど他社のサービスを呼び出すときは、返ってくるデータの形式を信用しすぎず、想定外の値が来ることを前提に防御的にコードを書く。通知の着信についても、届いた内容をそのまま信じるのではなく、あくまで何かが起きた合図として扱い、必ず本体側に問い合わせて事実を確認するという考え方が繰り返し強調されている。定期的に外部システムと自社の記録を突き合わせる仕組みも欠かせない要素として紹介される。

最後に内部統制の話がある。金額の大きな操作や台帳の手動修正には必ず承認者を二人立てる仕組みや、アクセス権限を必要最小限に絞る考え方、そしてコードが本番環境に届くまでの過程を誰が見ても追跡できるようにしておく重要性が説明される。監査で問われるのは今の状態だけではなく、その状態に至った経緯そのものであるという視点が一貫している。

金融系エンジニアが大事にしていること

ここからは元金融系エンジニアの視点として、このハンドブックの内容を実務目線で整理してみたい。金融システムの開発現場で本当に大事にされているのは、派手な機能や新しい技術ではなく、地味だが徹底された基本動作だと感じている。

実践ポイント	現場での意味合い
丸め処理は業務判断として扱う	端数を誰の取り分にするかは技術者だけで決めず、税務や法務の観点を含めて業務側と合意しておく必要がある。
同じ操作は二度実行しても結果が変わらないようにする	再送されたリクエストや通知が二重に届くことを前提に、常に一度分の効果しか発生しない作りにしておく。
記録は追記のみで改変しない	一度確定した記録は書き換えず、訂正が必要なら打ち消しの記録を新たに積み上げる運用にしておく。
外部からの情報は一次情報で裏を取る	連携先からの通知内容をそのまま反映せず、必ず本体側のAPIに問い合わせて最新の状態を確認する習慣をつける。
定期的な突き合わせを仕組み化する	日次や月次で自社の記録と外部の記録を機械的に比較し、差分が出たら人手で原因を追う流れを用意しておく。

元金融系エンジニアの視点として付け加えるなら、これらは新しい発想というより、会計の世界で何十年も積み重ねられてきた統制の考え方をソフトウェア設計に翻訳したものと言える。監査対応や規制対応の現場で求められることの多くは、実はこのハンドブックの三原則に収まってしまう。逆に言えば、この三原則さえ守っていれば、細かい実装の是非で悩んだときの判断軸として十分機能するということでもある。

まとめ

Fintech Engineering Handbook（フィンテック・エンジニアリング・ハンドブック）は、お金を扱うシステムに関わるすべてのエンジニアにとって、共通言語となり得る内容が詰まっている。分散システムの一般的な作法として知られている冪等性やイベント記録、再送処理の考え方も、金融という一円たりとも間違えられない領域に置いたときにどれだけ重みを持つかがよく分かる構成になっている。新しくフィンテック領域に入るエンジニアはもちろん、すでに現場にいるエンジニアが自分の設計を見直す際のチェックリストとしても活用できるドキュメントだと感じた。

本記事は公開されているハンドブックの内容をもとに、要点を独自に整理・要約したものである。詳細な内容や最新版については、原典を直接確認することをおすすめする。