スタートアップで会計システムを構築する際に失敗しないために
- フィンテック企業にとって、お金の流れを見失わないことは基本である。しかし一部のスタートアップでは、取引のたびに数セントを取りこぼしてしまうことがある。
- スタートアップでは「まず動かし、次に正しくし、最後に速くする」という哲学に従い、複式簿記システムを構築しないことがある。
- こうしたミスはユーザーの不満を招き、会社の成長を妨げる。
- カスタマーサポートチームが誤った取引を手作業で補償する形で問題を解決しようとしていた。
会計システムの重要性
- お金は移動するときに生成され、その追跡は複雑である。
- 単式簿記システムは資金の流れは示せるが、その理由を説明できない。
- 複式簿記システムはお金の出所と行き先の両方を追跡し、問題を解決できる。
複式簿記システムのデータモデル
- 複式簿記システムは、アカウント、エントリ、トランザクションという3つのエンティティで構成される。
- アカウントは価値の変化を表し、エントリはアカウント間の資金の流れを表す。
- トランザクションは、エントリが正しく対になっていることを保証する。
2つの会計システム
- 会計システムは外部から見た台帳のインターフェースであり、エンジニアリングシステムは台帳の実装である。
- 会計システムには高可用性と低レイテンシが求められ、エンジニアリングシステムには強い一貫性とデータの正確性が求められる。
エントリの動作方式
- エントリは、保留、破棄、記帳の3つの状態のいずれかを取ることができる。
- エントリは常に保留状態で作成され、破棄されたエントリは記帳済みのエントリに置き換えられることがある。
トランザクションの動作方式
- トランザクションは、エントリが記帳または破棄されたときにのみ記帳される。
- トランザクションが部分的に失敗した場合は、補償エントリによって意味的に取り消すことができる。
アカウントの動作方式
- アカウントは複数のエントリと結び付いており、総残高はすべてのエントリの個別残高の合計と一致しなければならない。
- アカウントの通常残高によって、総残高の計算方法は異なる。
結論
- 台帳は、非技術分野に見せかけた難しいコンピュータサイエンスの問題の明確な例である。
- 複式簿記システムを構築することは、適切な文脈なしには難しいが、それによってより良い意思決定ができるようになる。
1件のコメント
Hacker Newsの意見
Synapse の顧客では多額の資金が消失した。銀行は資金の流れを厳格に管理すべきだが、フィンテックは FBO 口座にすべての資金を集約し、それを追跡する元帳を構築していた。Synapse の場合、元帳に記録された顧客残高が実際の FBO 口座の資金より多かった。これは詐欺というより、不具合のある元帳による可能性が高い。フィンテックの預金口座にお金を入れず、実際の銀行を利用することを勧める。フィンテックはしばしば預金が FDIC 保険の対象だと主張するが、それは基盤となる銀行が破綻した場合にのみ保護される。
Google で働きながら、信頼性や正確性を犠牲にしてスケーラビリティを得ることについて学んだ。数百万件のクエリを処理する際には一部が失敗することがあり、これはエンジニアリングに対する姿勢の違いを示している。Gmail を開いたときにエラーが発生することは珍しくなく、ユーザーは再読み込みで問題を解決する。ストレージの耐久性が 99.99999% の場合、20 億人の顧客のうち 200 人は不便を被る可能性がある。
エンジニアリングのリーダーシップにおけるドメイン知識の重要性を強調している。金融会社で働くなら金融への理解が必要であり、これはジャーナリズムや商業でも同じだ。成功している組織は、技術チームの面接にドメイン関連の非技術的な質問を含めている。
適切な人材を採用することが重要だ。データ構造やアルゴリズムに長けた人を採るより、実際に必要なものを構築できる人を採用すべきだ。エンジニアが他分野の教育を受けることは役に立つかもしれない。問題解決とエンジニアリングは、業界への深い理解と専門家との協力を通じて実現される。
インターネット/通信スタートアップで課金システムを構築した経験を共有している。課金ロジックを 2 か所に構築したため、同期を維持するのが難しかった。手作業で請求書を確認してエラーを防ぎ、二重のロジックで誤りを防止した。この経験を通じて複式簿記の重要性を理解するようになった。
単式会計システムを擁護する意見は多い。単式会計のほうが簡単かもしれないが、複式簿記を使うほうがよい。プログラマー向けの会計関連資料を探している。
"make it work, make it right, make it fast" という原則には誤解がある。"make it right" は 2 番目の段階であり、システムが正しく動作するまで作業は停止される。最適化はすべての問題が解決された後に始まる。
テストがない場合、取引でお金を失う問題が発生しうる。金融システムを構築する際に、このような問題を正常だとみなすのは誤りだ。
銀行の一部を再発明しようとしているなら、すでに検証済みのシステムを参考にするのがよい。たとえば、米国の中小金融機関で使われているコアバンキングの預金取引スキーマを参考にできる。
お金を扱うソフトウェアは非常に慎重に扱うべきであり、過去の失敗を認識しなければならない。英国郵便局スキャンダルは、こうした問題が現実にどのような結果をもたらすかを示している。