自社開発か導入か — コアバンキングシステムの本当のコスト

遅かれ早かれ、すべてのフィンテック創業者は同じ意思決定に値札を付けることになります。コアバンキングシステムを自社で開発するか、既存のものをライセンス導入して設定するか。素朴な比較 — 片側にライセンス料、もう片側に開発者数人分の給与 — はほぼ確実に間違っています。2つの列に入っている中身が、そもそも同じではないからです。

誠実な比較とは、プロダクトのライフサイクル全体にわたる総保有コストの比較です。構築そのもの、恒久的な保守、セキュリティとコンプライアンスの継続的な維持、そして構築している間に得られない売上。当社はコアバンキングソフトウェアを作る会社ですから、当然立場はあります — しかし以下の計算は、もし当社が買い手だったなら見たいと思うものです。

「コアバンキングシステム」が実際に意味するもの

自社開発か導入かの見積もりの大半は、数字を1つも書く前の段階で狂います。スコープが過小評価されているからです。顧客の目に映るバンキングアプリは、システムの見えている一部分にすぎません。本番品質のコアは、1つの中に4つのプロダクトを抱えています。

• トランザクションの中核：並行負荷の下でも均衡を保ち続ける複式簿記台帳。すべての残高は台帳から導出され、各プロバイダーと日次で照合されます。
• 顧客向けプロダクト：バンキングアプリ本体、KYC・KYBのティアを備えたオンボーディング、マルチカレンシー口座、送金、カード — そして近年ますます、実体のある鍵管理を伴う暗号資産ウォレット。
• 誰もスコープに入れない第二のプロダクト：コンプライアンスの処理キュー、取引モニタリング、手数料設定、レポーティング、きめ細かなスタッフ権限のためのオペレーション用バックオフィス。
• 見えないレイヤー：追記専用の監査証跡、ログイン以外の場面での二要素認証フロー、rate limiting、デバイスフィンガープリント、そしてシークレットをコードとデータベースの外に保つ鍵管理。

自社開発の道：予算に実際に含まれるもの

現実的な自社開発には、金融システム経験のあるシニアバックエンドエンジニア、フロントエンドエンジニア、DevOpsとセキュリティ、QA、そしてコンプライアンスを理解するプロダクトの統率が必要です。本番品質に到達するチームが6〜10名のシニア人材を下回ることはまれです — そして最も希少なプロファイル、つまり台帳とカストディを本番環境で運用した経験のあるエンジニアこそ、採用も定着も最も難しい人材です。

スケジュールについては、パターンは一貫しています。成熟したプラットフォームが初日から提供するものに到達するまで、1〜2年。時間が費やされるのは画面ではありません。並行処理下での台帳の正確性、それぞれが独自のsandboxの癖と認定手続きを持ち込むプロバイダー統合、セキュリティの堅牢化、そして実際の顧客と実際のお金があって初めて現れるエッジケースの長い尾に費やされるのです。

そして支出はローンチで終わりません。プロバイダーはAPIを変更し、ブロックチェーンネットワークはアップグレードし、規制は動き、依存関係は劣化します。自社開発のコアは終わりのあるプロジェクトではありません。プロダクトが存在する限り資金を投じ続けると約束する、恒久的なチームなのです。

スプレッドシートに決して現れないコスト

• 機会費用：台帳の構築に費やす1か月は、プロダクトが市場に存在しない1か月です。コアをライセンス導入した競合は、あなたがまだプロバイダーを統合している間に、顧客を獲得し価格設定を改善しています。
• 採用リスク：構築計画は、始めたチームが最後まで完走することを前提にしています。台帳を理解する2人のエンジニアのうち1人を構築途中で失うことは、月単位で測られるスケジュール事故です。
• 正確性の尾：99%正しい台帳は「ほぼ完成」ではありません — サポートチケットと照合不一致と規制インシデントの発生装置です。最後の1%は最初の99%より高くつきます。
• 運用としてのセキュリティ：ペネトレーションテスト、鍵のローテーション、インシデント対応、監視とアラート — 何も起きなくても発生し続ける経常コストです。
• コンプライアンスの維持：KYC書類の有効期限、進化し続ける暗号資産規制、新たな報告義務。この作業は毎年繰り返され、先送りできません。
• バックオフィス：自社開発ではスタッフ用ツールが後回しにされがちで、オペレーションチームはSQLコンソールを相続することになります。それを目にした規制当局や監査人は必ず、まともに作り直すことを要求します。
• ローカライゼーション：本物の右から左（RTL）対応を含む多言語展開は、初日から設計に組み込めば安く、プロダクト完成後に後付けすれば高くつきます。

導入の道：支払うものと、あなたのものであり続けるもの

導入側では、テクノロジーの列は明示的です。プラットフォームのライセンスまたはレンタル料 — 真剣なベンダーはモジュール、チェーン、言語を個別に価格設定するため、請求額は実際に有効化したものに連動します — に加えて、インスタンスが稼働するインフラです。導入しても消えないもの：あなたの規制ライセンスやパートナー契約、プロバイダーとの商業契約、オペレーションスタッフ、販売チャネル。これらのコストはどちらの道でも運営者に帰属します — 導入が取り除くのはエンジニアリングの山であって、事業そのものではありません。

導入の正直なコストは依存という形をしています。ロードマップは完全にはあなたのものではなく、プラットフォームの価値は最悪のモジュールで決まります。緩和策は、契約前に検証できるものばかりです。専用インスタンスに自社のデータベースと自社の暗号化シークレットが伴っていれば、ベンダーから離れることは人質交渉ではなく移行になります。プロバイダー統合が抽象化レイヤーの背後にあれば、契約はあなたのものであり、プロバイダーは交換可能です。モジュール単位のライセンスなら、有効化したものにだけ支払います。そして、プラットフォームが実際の顧客と実際のお金を処理してきた実績の証拠です。

自社開発が正解になる場合

自社開発か導入かは、答えの決まった修辞疑問ではありません。次の条件が少なくとも1つ当てはまるなら、自社開発が正解です。

• インフラそのものがプロダクトである場合：台帳、カストディ、あるいはbanking-as-a-serviceの能力そのものを販売しており、それを所有することが事業である。
• 差別化の源泉が、どのベンダーもカバーしない要件にある場合 — ベンダーが今四半期にたまたま欠いている機能ではなく、プラットフォームの守備範囲から構造的に外れた能力である。
• 本番環境でのコアバンキング経験を持つシニアチームがすでに存在し、売上なしで数年間彼らを支える資金余力がある。
• 規制当局や親会社が、スタック全体の完全な内製管理を交渉不可能な条件として課している。

5つの質問フレームワーク

• 差別化：台帳が自家製であることを理由に顧客があなたを選ぶことは、いつか一度でもあるでしょうか。強みがプロダクト、販売チャネル、価格にあるなら、コアは配管です — 不可欠ですが、あなたが再発明すべきものではありません。
• スケジュール：待ってくれない市場の中で、コアを構築する1〜2年間の無収入を事業は吸収できますか。
• チーム：お金を動かすシステムを本番環境で運用した経験のあるエンジニアを、すでに抱えていますか。あるいは現実的に採用し、つなぎ留められますか。
• 3年コスト：構築コストに恒久的な保守チームを加えたものと、ライセンスに有効化モジュールを加えたものを3年間で比較すること — ローンチコスト同士の比較は決してしないこと。
• 出口：それぞれの道で、離脱はどのような形になりますか。内製の場合、リスクはキーパーソンが知識ごと去っていくことです。ベンダーの場合は、専用インスタンス、自社のデータベース、自社の鍵を要求してください。そうすれば出口は移行作業になります。

この意思決定におけるCorezaの位置

Corezaは導入の列に属し、上記のチェックリストに耐えるよう設計されています。各クライアントはAWS上の専用インスタンスを自社のデータベースと自社の暗号化シークレットとともに運用し、すべてのモジュール — チェーン、言語、トークンを含め — は個別ライセンスなので価格は有効化したものに連動し、プロバイダー統合は抽象化レイヤーの背後にあるため商業契約はあなたの手元に残ります。

このコアの一バージョンは2024年から規制下の欧州フィンテックの本番環境で稼働しており、新しいインスタンスは数週間でデプロイされます。ブランディング、モジュール、言語、チェーンは設定であって、エンジニアリングではありません。自社開発か導入かの数字を弾いているなら、それこそ当社がお誘いする比較です — 3年コスト対3年コストを、隠れた列まで埋めたうえで。