トレジャリーマネジメントシステム（TMS）の発注は、現状整理、要件と契約の明確化、実データでの検証、段階導入の順に進めます。この順で進めると、資金の可視化と支払統制につながります。
開発方式と契約形態、進め方、費用相場、委託先の選び方を順に取り上げます。全体像は、下の完全ガイドもご覧ください。
▼全体ガイドの記事
・トレジャリーマネジメントシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
トレジャリーマネジメントシステムの全体像
トレジャリーマネジメントシステム（TMS）は、企業グループの現預金や借入、投資、為替、金利、支払いを一元管理する財務システムです。KPMGが整理する導入目的は、資金効率化、財務リスク管理、業務効率化の三つです。
発注側は、機能の数を比べる前に、標準化する資金業務と毎日つなぐデータを決めておきます。
POSや会計システムとの違い
売上の情報から実際の入金や支払いまでを追うには、各システムの役割と扱う情報を分けて把握しておく必要があります。
- POS：店舗やECの売上の集計
- 会計システム：仕訳や決算の処理
- TMS：売上から銀行入金までの予定と実績
TMSは、銀行残高と仕入・給与・賃料などの支払予定も、同じ資金の流れの中で管理します。たとえば、カード会社の入金が数日後になり、手数料や返金が引かれる場合も、TMSで把握できます。
一方で、POSの売上だけでは入金時期や差引額が分からず、短期資金が不足することがあります。RFPでは、売上日、決済ブランド、入金予定日を中心に、入金と売上をつなぐ項目を定義します。
さらに、手数料や返金、チャージバックの扱いも、RFPに書いておく必要があります。店舗、法人、入金口座の受け渡し方法も、RFPに定めます。
会計側では、法人と勘定科目、通貨を対応付けます。加えて、税区分と取引先も、会計データと合わせて対応付けておきます。銀行明細と自動突合する条件も、あらかじめ決めておきます。
発注を検討するタイミング
発注の判断材料には、店舗数以外のものもあります。複数法人間の資金移動や海外送金、為替予約が増えたときも、検討する時期です。
- 残高確認：銀行Webサイトを口座ごとに開く作業
- 月次業務：Excelへの転記が業務の負担になる
- 入金管理：決済会社ごとに入金サイクルが違う
余剰資金のある法人と借入が必要な法人を同時に抱えるグループでは、グループ全体を見渡す効果が大きくなります。
段階を分けて進めれば、全機能を一度に発注しなくても済みます。残高集約と入金突合から始め、資金繰り予測、支払承認、キャッシュプーリングへと広げていきます。その後に為替・金利リスク管理を加える段階導入が、現実的な進め方です。
KPMGは、将来像からロードマップを定め、ガバナンスや財務ポリシーとシステムを一体で検討する考え方も示しています。
発注前に決めるべき開発方式と契約形態
開発方式の選択は、費用だけでなく、銀行接続や監査対応を誰が担うかを左右します。
TMSには、権限管理、二重承認、監査証跡が必要です。さらに、取引履歴と金融データの保護も求められます。
独自性の高い周辺業務を開発し、中核機能は製品やSaaSで使う組み合わせにすると、保守の負担と導入の速さのバランスを取りやすくなります。
SaaS・パッケージ型での標準機能の活用
SaaS・パッケージ型では、標準機能の範囲と追加開発、契約条件を合わせて検討します。
- 標準機能：キャッシュポジション、予測、銀行接続、支払、借入・投資管理
- 連携部分：設定または追加開発による補完
- 向いている企業：初期インフラを用意しにくく、海外拠点を含めて早く運用したい企業
- 運用面：自動更新があり、複数拠点からアクセスできる
- 契約条件：追加モジュール、ユーザー・法人・口座・取引量ごとの課金、解約時のデータ返却、障害時の代替運用の確認
パッケージ＋SIカスタマイズでの連携部分の外注
パッケージ＋SIは、TMS製品を土台に、銀行API・SFTP・CSV接続、ERP・会計連携をSI会社へ委託する方式です。POS・決済データの突合や社内申請も、委託の対象にできます。
金融業務の基本機能や監査の考え方を再利用できるため、独自の要件にも対応できます。スクラッチ開発に比べて、標準機能を活かしやすい方式です。
製品ベンダーとSI会社の間では、責任分界を明確にしておく必要があります。障害時の連絡先や、仕様変更費用の負担者も、発注時に決めておきます。
スクラッチ・ハイブリッド型での独自業務の絞り込み
標準機能で対応しにくい独自業務がある場合は、スクラッチやハイブリッドを検討します。方式と契約は、4つの観点で整理します。
- 独自業務：店舗別入金配賦、手数料計算、グループ内貸借、独自配賦
- 中核機能：銀行仕様、監査ログ、暗号化、バックアップの継続的な保守
- ハイブリッド：コアに既製品を使い、周辺の開発を外部に任せる形
- 契約：上流は準委任、仕様確定後の開発は請負の組み合わせ
TMSの中核をゼロから作る場合は、為替・金利データや法令、会計基準の変更にも対応が必要です。
準委任で進めると、成果物や完了条件が曖昧になりやすくなります。一方で、要件定義から請負で固定すると、接続やデータの品質が分かった後に、変更費用や遅延が生じやすくなります。
フェーズごとの成果物と受入基準、工数上限を、契約書と別紙にそろえます。さらに、変更手続も、同じ別紙に書いておきます。
トレジャリーマネジメントシステム開発の進め方
候補製品を比べる前に、現状の資金業務と将来の統制を整理しておきます。財務、経理、情シスは、早い段階から参加します。店舗・決済、内部監査、経営企画の担当も、早期に加わります。
作業は、まずRFPと提案比較を行い、次にPoCと契約を進めます。その後、設計・連携、テスト、並行稼働へ移ります。この順に進めると、費用の抜けと手戻りを抑えやすくなります。
現状の口座・データ・承認業務の一覧化
導入後の効果を説明できるよう、資金業務の対象、データ品質、導入前の指標を一覧にしておきます。
- 対象と担当：法人、店舗、銀行、口座、通貨、決済ブランド、ERP・会計、POS、Excel台帳、支払承認者
- データの状態：発生元、更新頻度、形式、担当者、保存期間、正確性
- 導入前のKPI：全口座の残高把握にかかる時間、入金突合が何営業日遅れるか、支払承認に関わる人数、予測誤差
- 業務実績：作業時間、差戻し、手作業、監査指摘の件数
入金予定と実入金を別々に管理しているなら、差額を理由ごとに分けて把握します。差額の理由には、手数料や返金、チャージバックがあります。入金日のずれも、別に分けて記録します。
RFPでの業務要件と連携要件の具体化
各社の見積条件をそろえるため、RFPには業務範囲、接続仕様、導入・運用条件を具体的に書きます。将来の機能は、優先度ごとに分けておきます。
- 業務範囲：対象法人・店舗・口座、取引量、通貨、予測期間、承認ルート、会計連携
- 連携仕様：銀行・決済会社の接続先、銀行API、SWIFT、ホスト接続、SFTP、CSV、取得頻度、再送、エラー通知、手動登録、重複防止
- 導入・運用：監査ログ、権限、セキュリティ、移行、教育、保守
「将来対応」は、導入時に必須のもの、第二段階のもの、対象外のものに分けます。RFPを送る前に、代表銀行一行、決済ブランド一つ、会計データ一か月分を用意しておくと、各社は実装の難しさを見積もりに織り込めます。
PoCとパイロットでの実データ検証
提案書の内容は、代表データで機能と例外処理を確かめてから判断します。PoCでは、資金管理、統制、例外対応の3つを確認します。
- 資金管理：残高集約、入金予定表示、銀行明細突合、資金繰り予測、仕訳生成
- 統制：支払申請、二重承認、異常アラート、監査ログ
- 例外対応：データの修正方法と、その履歴を確認できる担当者
本番は、一法人または一地域から始めるパイロットで進めると安全です。そのうえで、旧Excelや既存システムと一定期間並行して稼働させ、予測誤差、突合率、支払承認時間を確かめます。
銀行接続が止まったときに、手作業へ切り替えられるかも確認します。INPEXは、既存システムの集約、会計連携、源泉税対応を軸に、クラウドTMSを導入しました。その後、為替や定期預金、資金繰り見込みなどを、稼働後に追加開発しています。
テスト・移行・運用設計まで含めた発注範囲
発注範囲には、テスト、データ移行、運用準備まで含めます。受入では、正常時だけでなく例外も試します。
- 取引データ：明細欠損、取引重複、入金差異、返金
- 処理条件：休日、為替レート未取得、承認者不在、通信障害
- 移行データ：口座マスター、取引先、勘定科目、過去残高、借入・投資・為替契約
監査や照会に必要な期間のデータだけを本番へ移し、残りを参照用に保管すると、費用とリスクを抑えられることがあります。
運用では、接続停止時の代替手順と締め時間を定めます。権限変更、アカウント棚卸し、マスター変更承認の手順も決めておきます。ログ保存とバックアップも、運用の範囲に含めます。
障害の連絡と保守の時間も決めておきます。成果物には、運用手順書や教育資料、管理者研修を含め、問い合わせ窓口も加えます。稼働日だけを納品条件にしない点にも注意が必要です。
トレジャリーマネジメントシステムの費用相場と内訳
TMSの国内価格は、法人・口座・銀行接続・取引量・通貨・モジュール数ごとの個別見積もりが中心です。そのため、ここに示すのは予算検討用のレンジです。
金額は、公開されている実契約、市場ガイド、類似する国内財務システムの開発単価から整理しています。TMS固有の公的な平均価格ではない点に注意が必要です。製品ライセンス、導入支援、連携、移行のほか、教育や保守も分けて考えるための目安です。
SaaS・海外パッケージのライセンス費
SpendHoundの2026年調査は、Kyriba実契約160社の年間平均を、企業規模別に示しています。
- 中小・中堅企業層：61,979米ドル
- エンタープライズ層：337,010米ドル
1米ドル150円で単純換算すると、それぞれ年間約930万円、約5,100万円です（出典：SpendHound「Actual Kyriba Pricing 2026」、2026年）。この数字は、匿名化された実契約の平均で、公開されている定価ではありません。金額は、機能、法人、ユーザー、取引量、値引き条件によって変わります。
別の市場ガイドでは、典型的な取引規模が7万5,000米ドルから50万米ドル超とされています。出典はFinantrixのガイドで、資料名は「Buyer’s Guide: Treasury & Liquidity Management Solutions」です。このガイドは2026年5月更新です。
このレンジも、製品の定価ではありません。多通貨や多法人、複雑なヘッジ、決済ハブ、数百口座の接続を含むほど、金額は上振れします。発注側は、見積書で年額ライセンスと導入サービスを別の行に分けてもらいます。
国内スクラッチ・連携開発の工数による費用見積もり
国内の類似システムの単価を基に工数を置くと、TMS導入の費用と期間を規模ごとに想定できます。参考にした単価は、1人月60万円から120万円程度です。
小規模PoC・第一段階は、残高集約と少数銀行接続を行う想定です。中規模になると、複数店舗・複数法人、API接続、ERP連携、支払承認、入金突合が加わります。大規模では、多通貨、キャッシュプール、海外銀行、為替・金利リスク、連結会計まで範囲が広がります。
- 小規模PoC・第一段階：10人月から20人月、約600万円から2,400万円、期間4か月から8か月程度
- 中規模導入：30人月から60人月、約1,800万円から7,200万円、期間9か月から18か月程度
- 大規模案件：80人月から200人月、約4,800万円から2億4,000万円以上、期間12か月から24か月程度になる可能性
類似する国内予実・財務システムでは、小規模で300万円から600万円、中規模で900万円から2,400万円、大規模で3,000万円以上という試算もあります。TMSには銀行接続や権限、監査、会計連携、セキュリティ試験が加わるため、単純な予実システムより費用が上振れしやすいです。
試算は、類似する国内開発をもとに置いた推定で、TMS固有の公開統計ではありません。
銀行接続・移行・保守を含めた総額での比較
見積もりは、初期費用だけでなく、継続費用や導入費、保守と契約条件まで含めた総額で比べます。
- 接続・基盤：銀行接続、API・SFTP、クラウド、追加モジュール
- 導入：移行、脆弱性診断、教育、問い合わせ、市場データ購読
- 保守と期間：スクラッチの初期費用の年5パーセントから15パーセント程度、SaaSのサポート範囲、3〜5年TCO
- 契約変更：拠点追加単価、更新時の値上げ条件
複雑な海外TMS案件では、導入サービス費を年間ライセンスと同額以上に見込むガイドもあります。また、初期導入予算を18か月から24か月分のライセンス相当とする指針もあります（出典：FinantrixのTMS費用ガイド、2026年）。
この指針は推定のため、発注側は自社の接続数と導入範囲で再計算します。スクラッチの銀行仕様変更や大規模な追加は、別費用になる場合があります。
SaaSのサポートや更新が年額に含まれる範囲は契約次第です。そのため、導入範囲に応じた総額を見積もります。
RFP・要件整理と委託先選定のポイント
委託先を選ぶときは、知名度や提示価格だけでなく、実績や体制も見ます。委託先の種類は、製品開発元、導入パートナー、銀行・ERP連携に強いSI会社、財務ポリシーを支援する会社と幅広く、得意分野も異なります。
候補会社には、自社に近い規模で法人・口座・店舗・海外拠点を扱った実績があるか、稼働後の保守体制はどうかを確かめます。
RFPに書く業務・技術・運用の三つの要件
業務、技術、運用の要件は分けて記載し、提案の前提をそろえます。要求の優先度も、あわせて定めます。
- 業務：残高集約、予測、入金突合、支払申請・承認、キャッシュプール、借入・投資・為替予約、レポート
- 技術：銀行・POS・決済・ERP連携、認証、権限、監査ログ、暗号化、バックアップ、障害通知
- 運用：データ修正承認、マスター管理、利用者追加、問い合わせ、障害対応、リリース、教育、サービスレベル
必須は稼働日にないと業務が止まる要件で、重要は第一段階、将来は第二段階以降に実現する要件です。たとえば、銀行残高の取得と支払承認を必須、キャッシュプーリングを重要、AIによる予測の高度化を将来の要件とする例があります。優先度の判断では、経営上の効果と現場の実装負担を合わせて見ます。
委託先の実績・専門性・体制の確認
委託先については、類似案件の経験、具体的な担当範囲、稼働後の体制を分けて確かめます。
- 専門性：TMS・CMS、銀行接続、会計・決済連携、為替・金利リスク、支払統制
- 実績の詳細：法人・口座数、接続方式、導入期間、担当範囲、稼働後の改善
- 担当体制：PM、財務、銀行接続、ERP・会計、セキュリティ、運用保守の担当者と稼働率
- 運用対応：稼働後の支援者、海外拠点や営業時間外の障害対応
INPEXの公開事例では、既存システムの集約と会計連携を短期間で進め、稼働後に機能を追加しています。段階導入を考える企業にとって、参考になる事例です。
見積比較での前提と成果物の統一
各社の見積前提と納期を、同じ基準にそろえます。そのうえで、追加費用や成果物を含めて金額を比べます。
- 見積項目：ライセンス、要件定義、設定、追加開発、銀行接続、ERP・POS連携、移行、テスト、教育、プロジェクト管理、保守、クラウド、第三者診断
- 単価と上限：銀行一行あたり接続費、法人・口座・ユーザー追加、データ量、環境数、テスト環境、サポート時間
- 納期の前提：マスター準備、銀行審査、会計改修、データ整備、受入テスト
- 変更・終了費：仕様変更、遅延、再テスト、追加接続、更新、解約、データ返却
安い見積もりでは、含まれない作業を明示してもらいます。候補は、金額や適合度、導入期間などを重み付けして選びます。運用負担と将来拡張性も、判断材料に含めます。
セキュリティ・契約・責任分界の確認
財務データの保護、委託先の管理、障害時の責任分界を、発注条件と契約に反映します。
- アクセスと承認：多要素認証、SSO、役割権限、職務分掌、二重承認
- 保護と復旧：通信・保存時の暗号化、鍵管理、改ざん耐性のある監査ログ、バックアップ、災害対策、脆弱性診断
- 委託管理：再委託、保管場所、障害通知、復旧目標、監査、脆弱性対応
- 責任分界：仕様変更、著作権、データ返却・消去
金融機関などに該当する場合は、FISC安全対策基準の適用・参照範囲を確かめます。委託先の監査報告書や認証も、あわせて見ます。
金融庁・FISCが2025年に扱った論点からも、機能だけでなくリスク管理を発注条件にする必要があります。論点には、システムリスクと生成AIがあります。このほか、顧客口座への不正アクセスとITガバナンスも取り上げられています。
契約では、個人情報や口座情報の取扱いを明記し、委託先への監査権の範囲も定めます。SaaSや製品ベンダー、SI会社、銀行が関わる場合は、障害原因の切り分け手順と連絡網を契約・運用資料に記します。
発注・外注で失敗しやすいポイントと対策
TMSは複数部署と外部サービスにまたがるため、発注時の小さな曖昧さが稼働後の手作業として残ります。
導入目的が残高表示だけに絞られていたり、接続先の責任者が決まっていなかったり、例外処理の要件が抜けていたりすると、失敗につながります。安い初期見積もりだけで決めたり、稼働後の改善担当を置かなかったりする場合もあります。そのため、契約前に判断基準を持つと、こうした失敗を防ぎやすくなります。
目的と対象範囲が曖昧なままの発注
製品や見積を比べるには、「資金を見える化したい」より具体的な目的が要ります。残高確認や13週資金繰り予測、入金差異削減などに、目的を分けて書きます。支払の二重承認も、別の目的として扱います。
そのうえで、目的ごとに対象データと利用者、処理頻度を決めます。導入前の数値と導入後の目標も、あわせて設定します。
銀行・決済・会計のデータ差異の洗い出し
入金突合がうまくいかない原因は、性能よりも、データの粒度やコード体系の違いにある場合があります。たとえば、POSは店舗単位、決済会社は加盟店契約単位、銀行は口座単位で情報を持つことがあります。
一方で、会計は法人・勘定科目単位で情報を持つ場合があります。RFPでは、共通キー、締め時間、タイムゾーンを定めます。通貨や小数点、返金・手数料の扱いも定め、実データで照合します。
全社一斉稼働を避けた段階導入
全法人・店舗・銀行を一度に切り替えると、障害原因を特定しにくくなります。さらに、現場が旧手順へ戻れなくなる恐れもあります。
まず一法人、代表的な銀行、代表的な決済ブランドで、残高と入金を検証します。その後、支払承認、予測、海外拠点へと広げます。
各段階の受入基準には、突合率と予測誤差を置きます。残高確認時間や支払承認時間も、基準に含めます。その基準を満たしているかどうかが、次の展開を判断する材料になります。
稼働後の責任者と改善予算
TMSは稼働後も、銀行仕様や決済サービスの変更に応じて、マスターと連携を更新する必要があります。組織、承認権限、会計コードの変更も、更新の対象になります。
財務の業務責任者と、情シスのシステム責任者、ベンダーの保守窓口を決めておきます。月次では、データ品質とKPIを確認します。さらに、店舗や法人を追加するときの標準手順と追加費用も、初期契約の時点で確かめておきます。
よくある質問
トレジャリーマネジメントシステムの発注で特に相談されやすい質問を、4つ取り上げます。自社の対象範囲や契約条件を決めるときの、確認材料として使ってください。
トレジャリーマネジメントシステムの開発費用はいくらですか？
公開されている価格は少なく、法人・口座・銀行接続・取引量・機能によって変わるため、一律に言い切れません。
- 小規模PoC：残高集約中心で、約600万円から2,400万円
- 中規模の連携開発：約1,800万円から7,200万円
- 大規模・多通貨案件：4,800万円から2億4,000万円以上という推定レンジ
- 総額比較：ライセンス、導入、銀行接続、移行、保守を含むかを確認し、同じ前提で複数社から見積もる
SaaSとスクラッチ開発はどちらを選べばよいですか？
標準的な資金管理や銀行接続、承認、監査を早く始めたいなら、SaaSまたはパッケージ＋SIが候補になります。
店舗固有の入金配賦や手数料計算が大きい場合は、標準製品をコアにして周辺をスクラッチで補う方法が現実的です。
中核機能をゼロから作る場合は、セキュリティや法令・銀行仕様の変更、保守人材を継続して確保できるかを確かめます。
RFPには何を書けば委託先が比較しやすくなりますか？
RFPには、まず対象の法人・店舗・口座、取引量、通貨を書きます。銀行や決済会社との接続先も記載します。機能やPOS・ERP・会計連携の要件も書き、認証、権限、監査ログも示します。
移行やテスト、教育も含めます。保守と納期も、RFPに入れておきます。入金突合や、手数料・返金・チャージバックの扱い、障害時の手動処理、データ返却も明示します。
そのうえで、必須・重要・将来の優先度を付けます。同じサンプルデータでPoCと見積もりを依頼すると、比較しやすくなります。
財務データをクラウドに置くとき何を確認しますか？
まず、データの保管場所と委託先、暗号化と鍵管理を確認します。認証では、多要素認証やSSO、権限分離、二重承認を見ます。加えて、操作ログとバックアップ、災害復旧も確かめます。
脆弱性対応や障害通知、監査報告書も確認します。金融機関などの場合は、FISCの適用範囲と社内規程、委託先統制が合っているかを見ます。
クラウドかどうかよりも、事故時に誰がどの手順で何分以内に復旧するかを、契約と運用手順に記します。
まとめ
最初に、自社の資金業務を、残高集約や入金突合、予測、支払の単位に分けます。借入・投資や為替・金利リスクも、同じ考え方で区切ります。
そのうえで、SaaS・パッケージ・パッケージ＋SI・スクラッチのどこまでを採用するかを決めます。連携範囲は、法人、口座、銀行、決済、会計の各領域ごとに、RFPへ記載します。
データと責任分界を基準にした発注判断
費用は、ライセンスや開発だけでなく、銀行接続や移行まで含めて比べます。テストや教育、保守、拠点追加も、同じ比較の中に含めます。
候補会社には、実データでPoCを依頼します。手数料や返金、差額、通信障害、承認者不在などの例外処理も確かめます。
保守やセキュリティ、データ返却、仕様変更の責任分界を契約に定めると、稼働後の手作業や予想外の追加費用を抑えやすくなります。
現状一覧と小さな検証からの着手
最初の準備から検証までを小さく始め、RFPとPoCで対象範囲を確かめていきます。
- 全口座・法人・決済手段を一覧化し、代表的な一か月分の売上・入金・銀行明細・支払データを用意します。
- 残高確認時間、突合率、予測誤差、承認時間を測り、必要範囲をRFPとPoCに落とし込みます。
TMSは、財務部門の画面としてではなく、店舗・決済・会計・銀行をつなぐ経営基盤として発注することが、継続利用につながります。
▼全体ガイドの記事
・トレジャリーマネジメントシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。