フィンテックエンジニア必読：システム開発の完全ガイド

フィンテック領域におけるエンジニアリングのベストプラクティスや設計指針をまとめたハンドブックです。堅牢な金融システムを構築するためのアーキテクチャ、セキュリティ対策、API設計、信頼性の高いサービス運用のコツを網羅しています。

冪等性キー（idempotency keys）のセクションだけでも読む価値があるな。多くのエンジニアが苦労して学ぶ教訓だからね。

金額を表現する際に「最小単位（minor-units）の精度」戦略を検討している人へアドバイス：やめておけ（少なくとも、交換データやAPIデータフォーマットとしては使うな）。

賢いアイデアに見えるかもしれない（整数演算は速いし、加減算での丸め誤差もないから）。でも、通貨ごとに暗黙的な桁数が異なるパートナーと連携するようなエッジケースに遭遇したとき、めちゃくちゃ痛い目を見るぞ。特にステーブルコインは、表現対象の「法定通貨」とは暗黙の小数点以下の桁数が異なることがよくあるから、これは非常に重要な話だ。

また、JSONベースのAPIでは金額を文字列型で表現することも検討してくれ。JSONには小数点以下の精度の規定がないから、パーサーやシリアライザーを経由した際に浮動小数点数に変換されて精度が失われないよう、自分（とすべてのユーザーやベンダー）が常に注意を払う必要がある。これはすぐに収拾がつかなくなる可能性があるし、文字列の方が概念的にすっきりしないように見えても、この問題を完全に回避できる。（これをアンチパターン[1]と呼ぶ人もいるが、イデオロギー的な純粋さのためにユーザーや株主に負担を強いるような戦いは避けたいね。）

[1] https://blog.json-everything.net/posts/numbers-are-numbers-not-strings/

これのほとんどはFintechに限らず、ソフトウェアエンジニアリング全般に当てはまると思う。

例えば、リトライ、冪等性、イベントの順序制御などの話は、金銭が直接関わらない場合でも、ある程度の正確さが求められるすべてのシステムに適用できる。「いつでもリトライできる」という前提で作られたシステムをたくさん見てきたけど、そもそも最初に正しく失敗できて、かつダウンストリームのシステムが想定通りの冪等性を提供してくれていないとリトライなんてできないんだ。残念ながら、それがテストされていないことは本当によくある。

ざっと目を通したが、このハンドブックは浅いし、一部では悪いアドバイスすら含まれていると思った。

例えば、金銭的な値を整数以外で保存しているのを見たら、俺は悲鳴を上げて逃げ出すね（RustのDecimalがJSONの浮動小数点数として表現されているのを見るとか、勘弁してくれ）。特別な理由がない限り、常に整数であるべきだ（出力用のビューは何でもいいけどな。奇妙なビットコード形式だろうと）。

FX（外国為替）についても言えば、FXのレートは「ある時点」で決まるものじゃない。買い手や売り手の時点レート、契約、許容範囲、合意されたレート決定のタイムスタンプなどが影響してくる。

イミュータビリティ（不変性）については、金銭に関わるあらゆる場所でイベントソーシングが必要になる理由がこれだ：

    # 解決済みストリーム
    A -> B -> E

    # 実際のストリーム
    A0 -> Edit(A0, A) -> B -> C -> D -> Rollback(B) -> E

結局のところ、Fintechと言っても千差万別だよ。金銭を単なる荷物のように扱う現場もあれば、金銭がすべての中核にあるFintechで働いたこともあるしね。

プログラマーとして、Fintechのプログラマーたちがそれぞれの経験や視点から語っているのを見ると、「プログラミングがうまい」ってどういうことなんだろうと考えさせられるな。

xliiが言った「金銭を浮動小数点数で保存するな」というのは、よくあるIEEE 754の問題だ。金融の追跡は不変ログやイベントベースの記録で行うべきだというのは正しいが、すべての周辺サービスをイベントソーシングで作る必要はないと思う。台帳、決済、注文、約定といったコアロジックだけに適用すれば十分だろう。xliiのコメントを見ると、モデリングが成功した時に初めて実現可能な技術のように思える。

lxgrのコメントは「最小単位」の問題を指摘している。JSONの数値が言語やパーサーによって浮動小数点数として解析されると、精度が失われる可能性がある。通常は別途小数点以下の桁数フィールドを送るが、HFT（高頻度取引）の世界ではオーバーヘッドが大きすぎるからやらないとも聞くしな。

antonymooseのコメントは多くの書籍と一致している。FXやAPIの文脈でこうした設計がよくあるのはそのせいだろう。まるでプロトコル設計みたいだ。

まとめてみると、みんな自分の領域内では正しいんだ。xliiのような人をシニアエンジニアとして迎えられたら最高だろうけど、自分自身でこれほど複雑なシステムを設計できる気はしない。そういう意味で、全員の主張は妥当だし、領域によって意見が分かれるのは興味深い。専門性ってこういうものなのかもしれないな。

こうやって見ていくと、プログラマーの経験値によって意見がどこから来ているのか大体推測できる気がする。プログラミングは正しい答えを見つけることというより、世界観を選ぶことに近いのかもしれないね。

HNでプログラマーたちがどのようにドメインをモデル化しているかを見るのはいつも魅力的だ。時々プロフィールをクリックして、そのドメイン知識を自分の個人的なWikiにメモしたりしてるよ。いつか役に立つかもしれないからね。

いい記事だ。この本には他でも得られる情報がたくさん詰まっているが、それを一箇所にまとめているのは非常に実用的だね。Martin Kleppmannの『データ指向アプリケーションデザイン』を読むことを強く勧めるよ。初版も素晴らしかったけど、最近第二版が出たばかりだ。

俺はFintechのCTOとして、ソフトウェアスタック全体をゼロから構築したことがあるが、この本に書かれている教訓のほとんどは正しい。ただ「ほとんど」と言ったのは、いつものようにプロジェクトごとに考慮すべき「場合による」要素が山ほどあるからだ。例えば、俺は状態計算の問題を避けるためにイベントソーシングを使わない選択をした。標準的な追記専用の監査証跡があればそれで十分だったんだ。

「厳密に一度だけ（exactly-once）」の配送を保証するのは無理だけど、「実質的に一度だけ（effectively-once）」の処理を構築することはできる。そしてそれが本当に必要なものだ。

リクエストとレスポンスをすべて保存せよ：これは絶対だ。APIを消費する時だけでなく、外部から情報を収集する時は常に保存すべきだ（可能なら、境界内での中間変換ステップもすべてログに取るのがいい）。コンテンツアドレッシング可能なバケットとリレーショナルテーブルを組み合わせるのが非常に有効だよ。

また、テキストではデータリネージ（データの系譜）について何も触れられていない。もしベンダーが日中にデータを更新し、それを絶対に知っておく必要があるとしたらどうする？古い値を使った計算を再実行して同じ結果を得つつ、その変更を考慮に入れられるようにしておく必要がある。解決できないほど難しい問題ではないけど、少し工夫が必要だな。

悪いアドバイスすら含まれている

これでも丁寧な言い方だよ。正直、この「ハンドブック」はほとんどLLMが書いたんじゃないかと思う。

例えば、イミュータビリティのセクションにはこうある：

   "PII（個人識別情報）を金融データから分離することで、保持義務のある金融履歴を失うことなく、削除要請に応じることができる。"

金融機関において、この2つはKYC（顧客確認）やAML（マネーロンダリング対策）の観点から当然セットで扱われるものだ。法的な保存期間が過ぎる前に、顧客の名前や住所などを要求に応じて即座に廃棄しつつ、金融データだけを残すなんてことをしたら、犯罪捜査で$lawful_body（法執行機関）がデータを求めてやってきた時に、組織全体がとんでもない大惨事になるぞ。

Fintechで働くなら、どこかの誰がどこの管轄かも分からない場所で書いた「ハンドブック」なんて頼りにすべきじゃない。

Fintechで働く人は、常に雇用主の社内ハンドブックやガイドラインに従って仕事をするべきだ。それらは、その企業が活動する管轄区域の法律や報告義務を確実に遵守するために、社内の弁護士やコンプライアンス担当者と協力して作成されているはずだからな。

Plaidの残高照会は、これから送信しようとするACHデビットが確実に通るという保証にはならないぞ。

残高が100万ドルあろうと関係ない。ACHが処理される前に、(a)電信送金で送金されたり、(b)「昨日」のACH（請求書、自動引落しなど）や小切手で引き落とされたり、(c)デビットカードやATMで使われてしまう可能性があるからだ。

一部のFintech企業がこの問題に対処していない理由を俺が知っている背景は、たぶん言わない方がいいだろうな。

「Fintech」というのは非常に広い言葉で、実際に「Fintech」と呼ばれるもののほとんどは、単なるコミュニケーションだ。企業間、トレーダー間、システム間、台帳間のやり取りなどね。業界全体で通用する「正しい」プログラミング方法なんて存在しない。なぜなら、最終的に正しい方法とは、やり取りする相手方が理解してくれる方法に他ならないからだ。

もし通貨をセント単位で追跡する相手と取引しているなら、それ以上の精度で通貨を追跡しても、丸め誤差による不一致が起きるだけだ。逆もまた然り。このドキュメントに書かれている他のアドバイスもすべて同じことだよ。

浮動小数点数を避けるべきっていう話は、まったく正しくないね。私はFintechで20年の経験があるが、そのほとんどでdouble（倍精度浮動小数点数）を使ってきた。Excelもdoubleを使っている。フロントエンドもdoubleを使うし、データベースもdoubleをサポートしている。標準ライブラリはdoubleのパース方法を知っているし、JSONも（理論上はともかく、実際には）doubleを使う。多くのERPシステムもdoubleを使っているよ。

通貨の計算でdoubleを使うなら、全体で15桁の精度を保持できるということを心に留めておかないといけない。123456789.01や123.456789のように、これ以上の桁数を使わない限り、金融計算においても完璧な小数の精度を保つことができる。計算のたび、そして比較のたびに、常に15桁の精度以内に丸めさえすればいい。Excelがやっているのはそういうことだ。

doubleの最大の利点は、1) 広くサポートされていること、2) 国際金融や高度な金融商品で必要となる異なる精度の数値をシステム内で混在させられることだ。会計には小数点第3位までの精度が必要なこともあれば、0.25の倍数に丸める必要があるものもある。結局のところ、基本的な算術演算だけでなく、専門的な会計ライブラリを使うことになるだろうし、そのライブラリはバックエンドとしてfloatを完璧に利用できるんだ。