CTO のいないフィンテック創業者:プラットフォームを設計し、作り、引き渡す会社をどう選ぶか

資金があり、作るべきフィンテックのプロダクトもあるのに CTO がいないなら、開発会社選びから始めてはいけない。まず、パートタイムでもよいので、技術のわかる人を一人自分の側につける。そのうえで、エンジニアリング企業の候補を絞り込む。エンジニアリング企業は、あなたのものになるシステムを作る。一方、プラットフォームベンダーは自社製品をあなたにライセンスし、フリーランスは、どれほど優秀でも、システムを一人の人間に依存した状態で残す。候補の中からは、本番で動いているものとして何を見せられるか、そして契約で何を手元に残させてくれるかで選ぶ。

本稿は会社のランキングをしない:ランキングには、あなたのライセンスもローンチの日付もわからないからだ。本稿は、創業者が必要とする順に確認事項を示し、amBrain については終わり近くの一つの節で説明する。

資金はあるが CTO がいない。まず何をすべきか

プロジェクトに技術的な判断力を持ち込む方法は三つある。主に違うのは、開発会社の仕事を誰がチェックするかだ。

• まずフルタイムの CTO を雇う。ふさわしい人が見つかれば最も強い立場になるが、開発は採用活動が終わるまで待つことになり、新しい CTO には最初のうち率いるチームがない
• フラクショナル CTO か、独立した技術アドバイザーを入れる。パートタイムであなたのために働き、あなただけから報酬を受ける経験豊富なエンジニアだ。開発会社の提案を読み、追加の質問をし、マイルストーンごとにあなたの代わりにチェックする
• 開発会社にアーキテクチャを主導させる。立ち上がりは最も速く、その会社が似たシステムを作ってきているので、設計も健全なことが多い。落とし穴は、システムを設計する会社がそれを作る報酬も受け取ることになり、しかもあなたの側には、必要な部分と相手に都合のよい部分とを見分けられる人がいないことだ

身を守ってくれるのは、二つ目と三つ目の選択肢を組み合わせることだ:開発会社がアーキテクチャの草案を書き、開発に踏み切る前にアドバイザーがそれをレビューする。アドバイザーには、トレーディングやブローカー業務のシステムに携わったことのある人を選ぶ。そうすれば、注文の経路や、規制当局が求める記録について何を尋ねるべきかがわかっている。ショートリストに載っているどの会社とも、紹介料やそのほかの取り決めがあってはならない。

コードを書く前に、アーキテクチャのフェーズから何を受け取るべきか

アーキテクチャのフェーズは、アドバイザーがチェックでき、あなたにも追えるように書かれたドキュメントで終わるべきだ:

• 1ページのスコープ:最初にどのプロダクトを作るのか（顧客向けのターミナル、その裏にあるブローカーのシステム、あるいは取引所）、どの市場で、どの最初の利用者に向けるのか
• システムと、それがつながるすべての相手を描いた図:ブローカーや取引所、銀行と決済事業者、本人確認、マーケットデータのベンダー
• 一つの注文が顧客の画面から市場へ行って戻ってくるまでの経路。リスクチェックの位置と、接続が切れたときに何が起きるかを書き込んだもの
• システムが何を、どれだけの期間、誰のために記録しなければならないか。ライセンスのルールから導いたもの
• どこで動かすのか:自社の名義で開設したクラウドやサーバーのアカウント
• 自社が署名しなければならない第三者との契約と、そのうち開発がどれを待つことになるのか
• 最初のリリースの内容を書面で。意図的に外すものも含めて
• 未解決のリスクと、全体で一つの数字ではなく、マイルストーンごとの見積もり

このフェーズは別建てで支払い、同じ会社と続けるかどうかにかかわらず、ドキュメントが自分のものになるようにする。そうすれば、二社目も同じ設計にもとづいて見積もれるし、将来の CTO は誰かの記憶ではなく、書かれた記録から始められる。次の節で見るとおり、同じ種類の資料を求める規制当局もある。

どのライセンスとルールが開発を形づくるのか

設計が固まる前に、規制に詳しい弁護士を交えてライセンスの問題に決着をつける。システムが何をしなければならないか、いつ稼働させてよいかを決めるのはライセンスであり、どのエンジニアリング企業も、それを代わりに取得することも、規制当局の判断を早めることもできない。

規制当局は、申請の一部としてあなたのシステムを見る:

• 英国では、FCA が申請者に対し、「使用する予定のテクノロジーまたはシステムが、申請した規制対象業務を遂行できる状態にあることを示す」よう求めている。また、「仮に今日あなたを認可するとしたら」、申請した業務を遂行できるかどうかも見る
• 米国では、ブローカー・ディーラーは営業を始める前に SEC に登録し、FINRA のような自主規制機関の会員になる。FINRA の加入基準には、「事業継続に合理的に備える」通信システムと業務システム、そして「申請者が連邦、州、および自主規制機関の記録保存要件を遵守できるようにする記録保存システム」が含まれる
• EU では、暗号資産サービスプロバイダーになるための申請に、「ICT システムとセキュリティ体制の技術文書、およびその非技術的な言葉による説明」を含めなければならない。暗号資産の取引プラットフォームを運営したい会社は、さらに、プラットフォームの運営ルールと、不公正取引を検知するための手続とシステムも説明しなければならない

規制当局の時計は月単位で進む。FCA の申請者向けガイダンス（最終更新は2026年3月）によれば、ブローカーのような会社からの完全な申請は通常6か月以内に審査され、不完全な申請は最長で12か月かかることがある。EU の投資サービス業者向けの法律である MiFID II では、完全な申請を提出してから6か月以内に、認可されたかどうかを申請者に通知しなければならない。EU の暗号資産規則である MiCA では、当局は25営業日以内に申請が揃っているかを確認し、完全な申請を受け取ってから40営業日以内に決定する。当局が質問への回答を待つあいだは、最長20営業日まで期間の進行が止まる。FINRA の規則では、申請から180日たっても、あるいは書面で合意したそれより後の日付までに決定が出なければ、申請者はエスカレーションを求めることができる。

ルールは、システムが何を保存するかも決める。EU の投資サービス業者は、自らのすべてのサービス、業務、取引について、「所轄当局が監督上の任務を果たせるのに十分な」記録を残し、顧客の注文に関する通話の録音と電子通信の記録を5年間、当局が求めれば最長7年間保存しなければならない。こうした要件は、最初の設計から、データをどう保存するかを形づくる。

その会社が本当にフィンテックのシステムを本番に出してきたのか、どう確かめるか

本当に本番に出したと言えるのは、実際の顧客の注文や資金が流れている本番のシステムで、あなたが見ることができ、それを作った人たちに質問できるものだ。どこから始めるかについての記事は、基本となる証拠を挙げている:名前の挙がった本番システム、それを一通り見せてもらうこと、障害の話、そして実際に仕事をした人たち。自社に CTO がいないなら、コードを読めるかどうかに左右されない確認を加える:

• 顧客を自分で確かめる。規制を受ける顧客のためにプラットフォームを作ったと会社が言うなら、その顧客が認可を受けているかどうかは公開の登録簿でわかる:米国なら FINRA の BrokerCheck、英国なら FCA の金融サービス登録簿（Financial Services Register）、EU なら ESMA の認可済み暗号資産サービスプロバイダーの登録簿
• 紹介された顧客に、その会社を同席させずに自分で電話し、稼働開始後に何が壊れ、会社がそれにどう対処したかを尋ねる
• システムを見せてもらう場にはアドバイザーを連れていき、あなたにはできない質問をしてもらう
• その会社が、そのシステムを作ったエンジニアがあなたのシステムも担当すると言うなら、その人たちの名前を契約書に書き込む

どの経験が意味を持つのかを厳密に見る。決済アプリもトレーディングプラットフォームもフィンテックと呼ばれるが、壊れ方は違う。トレーディングやブローカー業務のプロダクトなら、注文が市場へ向かう途中でその会社のコードを通るシステムを求める。

コード、アカウント、引き継ぎについて、契約には何を書くべきか

コードの代金を払っただけでは、それは自分のものにならない。英国の知的財産庁（Intellectual Property Office）のガイダンスによれば、委嘱して作らせた著作物の著作権の最初の法律上の権利者は、「書面で別途合意しない限り」、それを作成した者である。米国では、著作権の移転は、書面で行い、権利者またはその授権された代理人が署名した場合にのみ有効である。所有権の条項そのものは、専任チームの確かめ方についての記事が扱っている。フィンテックの開発では、次の条件を加える:

• コードリポジトリ、クラウドアカウント、ドメイン、アプリストアのアカウントは、初日から自社が開設し、会社には、こちらで取り消せるアクセス権を与える
• ブローカー、取引所、銀行、マーケットデータのベンダーの認証情報は自社に発行させ、それらの契約は自社の名義で結ぶ。会社がそれを持っていると、あなたの取引はその会社が残り続けることに依存する
• 会社が手元に残すもの、たとえば自前の再利用可能なライブラリは、名前で列挙し、関係を解消したあとも使い続け、変更できるライセンスを付ける
• 引き継ぎには、最後のマイルストーンより前に受け入れテストと予行演習を設ける。引き継ぎに何を含めるべきかは、エンジニアを雇うか、パートナーを入れるかについての記事に一覧がある
• 出口の条件には、通知期間、移行期間中の会社の支援、そして使える形式でのデータの返還を含める

自社が EU の投資サービス業者、暗号資産サービスプロバイダー、または取引施設になるなら、2025年1月17日から適用されているデジタル・オペレーショナル・レジリエンス法（DORA）の対象になる。DORA の第30条は、テクノロジーサービス（この規則の言い方では ICT サービス）の契約に最低限盛り込むべき条件を定めている。その中には、データが処理・保存される地域または国、プロバイダーが破綻した場合、事業をやめた場合、または契約が終了した場合のデータの返還、そして通知期間付きの解約権が含まれる。クリティカルまたは重要な機能を支えるサービスの契約には、さらに、義務的な移行期間を伴う出口戦略も必要になる。開発会社との契約のどの部分がこれに該当するのか、とくにローンチ後のサポートとホスティングについて、弁護士に確認する。

仕事をマイルストーンと支払いにどう分けるべきか

開発は、支払いのたびに、動いているのを自分の目で確かめられるものが手に入るように分ける。その確認は、作業を始める前に合意した基準に照らして、アドバイザーが行う。トレーディングやブローカー業務のシステム開発なら、たとえば次のような形になる:

• アーキテクチャのドキュメント。単独で値付けし、続けるかどうかにかかわらずあなたのものになる
• 一つの注文が、テスト口座からリスクチェックを通ってブローカーか取引所のテスト環境へ行き、画面に戻ってくること。それが自社のクラウドアカウントで動いていること
• 最初の市場がエンドツーエンドで動くこと:口座、残高、ポジション、ライセンスが求める記録、そしてブローカーや取引所がそれぞれの日程で行う接続テスト
• 少数の実際の顧客に向けたローンチ。監視を有効にし、誰かがオンコールで待機している状態で
• 引き継ぎの予行演習。開発会社の人たちが見守るなか、自社のエンジニアが変更をデプロイし、それをロールバックする

マイルストーンはライセンスの申請に合わせて並べる。たとえば FCA は、申請の時点でシステムが規制対象業務を遂行できる状態にあることを求めるので、それまでに開発はかなり進んでいなければならない。

どのマイルストーンのあとでも、それまでに作ったものすべてを持って止められる権利を確保しておく。アーキテクチャのフェーズの直後、開発全体を約束する前の時点も含めてだ。

フィンテックの開発パートナーを選ぶときの危険信号は何か

• どのライセンスを申請するのか、どのブローカーや取引所に接続するのかを誰も尋ねないうちに、最初の返信で固定価格とローンチの日付が出てくる
• 規制当局の判断や、ブローカーの接続テストのための余地がないローンチ計画
• ドキュメントに対する権利が書面で定められていない無料のアーキテクチャのフェーズ。これでは、設計を別の会社へ持っていけない
• ブローカーや取引所の認証情報、あるいはクラウドアカウントが、会社の名義になっている
• 「当社のプラットフォームは規制に準拠している。」ライセンスを持つのはソフトウェアではなく、あなたの会社だ。設計がどのルールに照らして、誰によってチェックされたのかを尋ねる
• 独立したアドバイザーを連れてきて設計をレビューさせようとすると、抵抗される
• フィンテックの実績として挙がるのがウェブサイトとダッシュボードばかりで、注文や資金を動かすシステムが一つもない

amBrain はどこに位置づけられるか

上で挙げた会社の種類のうち、amBrain はエンジニアリング企業にあたる。amBrain は2019年からソフトウェアを作っている。

トレーディング分野のサービスは、こう記載されている:「トレーディングターミナル開発、注文管理システム、FIXプロトコルによる取引所連携。」amBrain は Spectre Trade のトレーディングターミナルを構築した。amBrain は MOEX のコロケーションで本番稼働するミニ取引所も構築している。ミニ取引所の顧客の名前は明かされていない。

amBrain は、顧客との仕事の進め方を一行でこう説明している:「三つの形態:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。」所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」この例外こそ、本稿がはっきり詰めておけと言っている種類のカーブアウトである。だから署名の前に、そのコンポーネントを名前で列挙した一覧を amBrain に求めること。本稿は事例紹介ではなく、ここで挙げた確認は、ほかのどの会社と同じく amBrain にも当てはまる。

まだ始めたばかりなら、誰かに連絡する前に1ページを書くこと:最初に作るプロダクト、申請するライセンス、最初の市場と利用者、そして稼働していなければならない日付。それをまずアドバイザーに送り、次に二、三社に送る。amBrain でも、ほかのどこでもよい。そして返ってくる質問を比べる。