市場系システムは、取引の入力からポジション、評価、リスク、決済、会計までを一つの流れでつなぎ、正確に管理する業務基盤です。
業務範囲や主要機能、開発の流れ、費用、発注の進め方、最新の動向を順に見ていきます。各テーマの詳細は、下の関連記事もご覧ください。
▼関連記事一覧
・市場系システム開発の進め方
・市場系システム開発でおすすめの開発会社6選と選び方
・市場系システム開発の見積相場・費用
・市場系システム開発の発注・外注・委託方法
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
市場系システムの定義と役割
市場系システムは、金融市場の取引を起点に、ポジション、評価損益、リスク、決済、会計情報までを管理します。市場部門の業務を支えながら、正確性や統制、監査可能性を確保する基盤でもあります。
市場系システムは、インターネットバンキングのように顧客が操作する仕組みや販売チャネルとは違い、市場部門の取引業務を支えます。
市場系システムが扱う業務範囲
まず、対象とする商品と業務の流れを洗い出し、共通データとしてどこまでを持つかを決めます。
- 対象商品：為替、金利、債券、株式、投資信託、先物、オプション、スワップなど
- 業務の流れ：取引入力、注文管理、約定確認、ポジション更新、評価、損益、担保・マージン、決済、会計、規制報告
- 共通データ：取引ID、商品コード、取引先、通貨、数量、価格、評価時点、データの出所
商品ごとに、キャッシュフロー、評価モデル、約定日、受渡日、休日カレンダー、タイムゾーンが異なります。このため、売買履歴だけを記録するデータベースでは、業務を完結できません。
データを共通化すると、部門ごとの解釈の違いを防げます。さらに、画面・帳票・計算結果から元の取引まで追跡できます。
勘定系・資産運用システム・決済システムとの違い
各システムの役割を分けて押さえておくと、接続する範囲と責任の所在を決めやすくなります。
- 勘定系・市場系：勘定系は預金・貸出の口座残高や顧客取引を管理し、市場系は市場取引の価格変動やリスクを扱います。
- 資産運用：投資信託や年金などの運用計画、銘柄選定、約定管理、運用成績の分析が中心です。
- 決済：資金・証券の受渡しや照合を扱います。
これらを完全に分けるか、一つの製品にまとめるかは、導入時に一律で決めなくてもかまいません。市場系を取引・ポジション・評価の正本とし、勘定系や会計、決済機関、分析基盤とAPIやファイルで接続する構成もあります。
業務の責任とデータの正本を先に定めておくと、システムの境界を筋道立てて決められます。
フロント・ミドル・バックの違いと主要機能
機能は、フロント・ミドル・バックの責任分界で整理すると、要件の抜け漏れを防ぎやすくなります。3領域は別々のシステムとは限らず、一つの基盤上で役割を分ける場合もあります。
フロントオフィスの機能
フロントオフィスは、トレーダーや運用担当者が取引を実行する領域です。入力の操作性と記録の完全性を、両立させる必要があります。
- 取引：注文入力、約定、ブック・デスク管理、ヘッジ取引
- 照会・分析：ポジション照会、プライシング、損益表示
- 入力時の事前確認：取引限度額、権限、取引可能商品、相手先の状態
入力項目を減らしすぎると、約定後の照合や監査に必要な情報が欠けてしまいます。たとえば為替取引では、通貨ペア、売買、金額を記録します。レートと受渡日、取引先も残します。約定者とヘッジ区分も、あわせて記録しておきます。
承認が必要な取引を自動でミドルへ渡せれば、後からExcelで補正する作業を減らせます。
ミドルオフィスの機能
リスク計測は、対象とするリスク、分析方法、限度額超過の監視を組み合わせて設計します。
- 計測対象：市場、信用、カウンターパーティー、流動性の各リスク、ALM
- 分析：VaR、ES、感応度、ストレステスト、損益要因分析
- 監視・報告：リミット超過の監視、経営向けレポート
計算結果を後から再現できるよう、入力した市場データとモデルのバージョンを記録しておきます。計算日時、対象ポジション、除外条件も残すと、どの前提で計算したかを追えます。
要件定義では、「正しいリスク計算」とは何かを具体化します。たとえば、既存システムとの日次照合で許容する金額や割合、異常値の承認者、モデル変更の検証環境を決めておきます。
独立計算や過去事例とのバックテストをテストケースに含めておくと、稼働後に計算の根拠を説明できます。
バックオフィスと市場データの機能
バックオフィスと市場データ管理は、決済とデータ品質を支える役割を担います。
- バックオフィス：取引確認、決済指図、資金・証券残高、担保・マージン、勘定系・会計連携、照合、例外・決済失敗管理
- 市場データ・マスタ：為替、金利、株価、債券価格、カーブ、ボラティリティ、指数、銘柄、取引先、契約条件、休日カレンダーを収集・正規化・品質確認
約定データが欠けると残高や会計が合わなくなるため、受信・変換・送信の各段階で件数、金額、通貨、ステータスを照合します。エラーの再送や、手動で業務を続ける手順も、本番要件に含めておきます。
データの欠損や重複、時刻のずれを管理しないと、フロントの損益、ミドルのリスク、バックの会計で数字が分かれてしまいます。訂正値や評価時点の違いも、同じように管理が必要です。
市場系システム開発の進め方
開発は、対象業務とデータを棚卸しし、検証できる要件に落としてから、段階的に導入するのが基本です。製品や技術を先に決めてしまうと、帳票や例外処理が後から加わり、費用と期間が膨らみます。
最初の段階で、経営課題、対象商品、拠点、処理量、許容停止時間をそろえておきます。
現状棚卸しと要件定義
まず現状の業務とデータを棚卸しして、正本をどれにするか、要件を何にするかを明確にします。
- 現状の収集：商品、取引フロー、組織・権限、画面、帳票、連携先、締め処理、例外処理
- 正本の決定：取引・ポジション・評価・損益・決済・会計データのうち何を正本にするか
- 要件の明文化：評価時点、許容誤差、リミット判定、承認者、監査証跡、データ保持期間
- RFI・RFP：入力例、期待計算値、異常時の処理、完了条件
正本が曖昧なまま各部門がExcelを正しいと主張すると、同じ取引について複数の残高が残ってしまいます。
発注者側に業務責任者、リスクモデル責任者、データ責任者を置き、開発会社に丸投げしない体制をつくることが欠かせません。
方式選定・設計・開発
方式を選ぶ際は、標準機能との適合性と、独自業務の比重をもとに比べます。
- パッケージ・SaaS：市場取引、リスク、担保、決済の標準機能を使える場合に候補です。
- 個別開発：独自評価モデルや複雑な業務フローが競争力に直結する場合に適します。
- クラウド設計：専用線、暗号鍵、MFA、特権アクセス、操作ログ、バックアップ、リージョン、委託先監査、障害時の責任分界を検討します。
- 段階導入：市場データ・ポジション、リスク・リミット、決済・会計の順に進めます。
この順序で進めれば、業務への影響を抑えながら価値を確かめられます。
独自業務のアドオンを増やすほど、バージョンアップや回帰テストの負担は大きくなります。
個別開発を選ぶなら、モデルの版管理と保守人材を先に確保しておく必要があります。
テスト・並行稼働・切替
テストと切替では、画面が動くかだけでなく、計算の妥当性、異常時の動作、業務を続けられる条件まで確かめます。
- テスト対象：計算精度、データ照合、権限分離、性能、障害、セキュリティ、監査証跡
- 代表取引：商品・通貨・受渡日・取引先ごとに選び、期待値を独立計算や既存システムと照合
- 異常系：市場急変、価格欠損、重複受信、訂正・取消、決済失敗、通信断、日付またぎ
本番切替では、旧システムと新システムを一定期間並行稼働させ、残高、評価損益、リスク量、決済予定、会計仕訳を日次で照合します。
切替では、数値の照合に加えて、切替を宣言する担当者と確認内容、手動運用へ移る条件、復旧訓練の頻度も決めておきます。復旧訓練では、RTO（復旧目標時間）とRPO（復旧時点のデータ損失許容範囲）を満たせるかも確かめます。
▶ 詳細はこちら：市場系システム開発の進め方
市場系システムの費用相場と5年TCO
初期費用の推定レンジは、限定的なPoCで500万〜2,000万円、ミドルオフィス中心の構築で3,000万〜1.5億円が目安です。
対象範囲が広がると、フロント・ミドル・バックの統合刷新では2億〜10億円超、大規模な基盤刷新では10億〜50億円以上が目安になります。
ただし、これらは市場系システム固有の公開統計ではなく、計画用の推定です。対象範囲、商品数、処理量、連携、可用性、テスト体制をもとにしています。
対象範囲別の初期費用と期間
対象範囲ごとの費用と期間は、計画の初期に比べるための目安として使えます。
- 小規模PoC：500万〜2,000万円、3〜6か月程度
- ミドル中心：3,000万〜1.5億円、6〜15か月程度
- 標準パッケージ：ライセンス込み5,000万〜3億円程度、9〜18か月程度
- 統合刷新：2億〜10億円超、18〜36か月程度
- 大規模レガシー統合：段階移行で3〜5年以上になる場合があります。
PoCでは、市場データの取り込み、限定した商品のポジション照会、簡易VaR、ダッシュボードなどを検証します。
ミドルオフィス中心の構築では、リミット管理、VaR・感応度、ストレステストを中心に扱います。データ品質や帳票、数系統のAPI連携も含みます。
統合刷新は、複数の商品と拠点を対象に、取引から決済・会計までをつなぎ、24時間運用や高可用性・災害対策まで備える場合の目安です。
費用の内訳と高くなりやすい要因
予算配分の目安と、費用が増える条件や別途かかる費用は、分けて確認します。
- 初期配分例：要件定義・業務分析15〜25%、設計・実装30〜40%、テスト・品質保証20〜30%
- 移行・管理の配分例：データ移行・外部連携10〜20%、プロジェクト管理・監査資料・教育10〜15%程度
- 費用増の条件：商品数、海外拠点・タイムゾーン、リアルタイム処理、外部連携、不正規化データ、過去データの大量移行、24時間365日の監視・災害対策
- 初期費用と別に計上：市場データ、ライセンス、クラウド、脆弱性対応、制度改定、追加商品、保守、外部監査
これらは固定の統計ではなく、重複を含む計画上の配分例です。そのため、見積書を見るときは配分の割合よりも、作業範囲と完了条件を確かめてください。
5年TCOで比較する方法
5年TCOでは、初期費用に継続費用を加えて計算します。その際、各社の見積前提と契約範囲をそろえておく必要があります。
- 5年分の費用：初期費用、年間保守・運用、データフィード、ライセンス更新、クラウド、監視、脆弱性対応、制度改定、追加商品、移行後の並行稼働
- 見積の共通条件：連携本数、移行件数、テストケース数、SLA、RTO・RPO、法改正対応の範囲
- 契約上の確認：制度改定の扱い、市場データ再計算の料金、障害時の原因調査の範囲
初期費用が安くても、独自アドオンが多く、更新のたびに回帰テストが必要になる場合は、長期では高くなる可能性があります。
▶ 詳細はこちら：市場系システム開発の見積相場・費用
市場系システムの開発会社・サービスの選び方
開発会社やサービスは、知名度や機能数だけでなく、対象商品と国内制度への対応で選びます。さらに、既存基幹との接続や、導入後の運用体制と責任分界も確かめます。
製品ベンダー、導入SI、運用会社が別々の場合は、提案書の上で役割を分けて確認しておきます。
金融商品と業務知識の評価
金融商品や実務の経験に加えて、計算結果を発注者が検証できるかも確認します。
- 商品・業務経験：為替、金利、債券、株式、デリバティブの標準対応と、決済・会計までの経験
- 類似案件：商品、拠点数、取引量、導入期間、稼働後の体制を匿名化された範囲で確認
- モデル検証：入力、計算式、パラメータ、丸め、例外、版履歴を追跡し、独立計算やバックテストに協力できるか
「金融機関向け」の実績があっても、フロント画面と、リスク計算・担保・決済・規制報告の経験は区別して見る必要があります。実運用の品質は、機能デモだけでは判断しにくく、日次締め、価格訂正、異常値の承認などを確かめてはじめて判断できます。
パッケージ・クラウド・スクラッチの適性比較
方式ごとの適性と、導入後の保守負担を比べます。
- パッケージ・SaaS：標準機能を活用できる方式です。
- クラウド：リスク計算・分析の計算資源を伸縮でき、新拠点やサービスとの接続にも向きます。
- スクラッチ：独自モデル・取引フローを実装できますが、金融工学人材、テストデータ、制度・形式変更、担当交代後の保守を自社で維持します。
- ハイブリッド：共通データ基盤を標準技術で整え、独自分析や画面をAPIで個別開発します。
パッケージでは、金融商品、リスク、担保、決済の標準機能と、その更新のノウハウを使えます。標準業務に合わせるほど導入期間と保守負担を抑えられる一方、独自アドオンは更新の調査や回帰テストを増やします。
導入後の運用と責任分界の確認
運用、障害対応、変更管理のそれぞれで担当範囲を具体化し、将来の負担も比べます。
- 障害対応：一次受付、原因切り分け、復旧判断、データ訂正、再計算、外部連絡、監査対応の担当
- 責任分界：基盤、アプリ、市場データ、外部接続先ごとの責任。責任分界表、SLA、RTO・RPO、復元実績、訓練計画
- 変更管理：制度改定・新商品対応の範囲と、受付、影響分析、見積、テスト、承認、本番反映、証跡保存の流れ
- 将来負担：初期提案だけでなく、5年後に自社が担う運用負担
▶ 詳細はこちら：市場系システム開発でおすすめの開発会社6選と選び方
市場系システムの発注・外注・委託の要点
発注者側が正本データ、業務ルール、計算結果の受入基準、リスク許容度を持っておくことが、発注を成功させる前提です。実装、移行、テスト、運用設計は外注できます。ただし、何を正しいと判定するかまで手放すと、受入の場面で判断できなくなります。
RFPに入れるべき項目
RFPは、業務・データ・運用と、例外時の要件に分けて書きます。
- 業務・規模：対象業務・商品、拠点・通貨・タイムゾーン、取引量とピーク、業務フロー
- データ・連携：データ項目、正本、計算式、許容誤差、連携先、移行件数、帳票、規制報告
- 運用・統制：権限、監査証跡、セキュリティ、SLA、RTO・RPO、成果物、テスト責任、教育、保守、制度改定対応
- 例外・障害：訂正・取消、価格欠損、重複、決済失敗、障害時の手動継続
候補先には、代表的な取引データと日次締めの期待結果を渡します。既存帳票やエラー例、過去の市場急変時のポジションも、あわせて渡しておきます。
提案は、価格に加えて、業務への適合度と計算の説明可能性で評価します。さらに、移行計画、テスト方法、体制、運用、セキュリティ、将来の変更のしやすさも見ます。
準委任・請負・段階契約の使い分け
要件がどこまで確定しているか、どんな成果物を求めるかに合わせて、契約形態やマイルストーンを選びます。
- 準委任：現状分析や業務整理を進めながら仕様を決める段階で、専門人材の稼働を確保します。
- 請負：成果物と受入基準が明確な機能開発や移行作業で、範囲と責任を定めやすくなります。
- 段階契約：調査・PoC、要件定義、主要機能、段階移行に分け、適合性とリスクを早期確認します。
契約では、仕様変更と追加費用、知的財産、データ返却、監査権を確認します。そのほか、再委託や秘密保持、脆弱性対応、障害報告、終了時の移行支援も、契約書に書かれているか見ておきます。
ベンダー、導入パートナー、運用会社が複数に分かれる場合、連携不具合の窓口と切り分けの手順を、契約書や運用設計書に書いておきます。
発注者主導の受入テストと運用引継ぎ
受入テストと運用引継ぎでは、発注者が判断できるよう、記録と手順を整えておきます。
- 受入確認：業務担当者が代表取引、計算値、帳票、承認、例外処理を見ます。
- テスト記録：データ、期待値、実績値、差異、原因、対応、再テストの記録と、リスクモデル責任者による計算の承認。
- 運用引継ぎ：日次・月次手順、監視、アラート、再実行、復元、権限申請、訂正、障害連絡、制度改定、リリース判定の手順書。
- 稼働後のKPI：照合差異、決済失敗、手動補正、リスク計算時間、復旧時間、変更リードタイムで、安定運用と改善の指標を決めます。
▶ 詳細はこちら：市場系システム開発の発注・外注・委託方法
2026年の市場系システムで重視すべき最新動向
2026年の市場系システムは、クラウドやAPIを使って段階的に刷新し、規制、サイバー、第三者リスク、AI、復旧の可否まで設計に含めます。
技術を入れること自体を目的にせず、市場が急変したときや外部サービスが止まったときも、取引・リスク・決済を続けられるかを評価します。
規制対応とリスク計測の継続性
金融庁によると、日本では、バーゼルIII最終化に関する国内規制が整備されています。
国際統一基準の金融機関などでは、2024年3月31日から適用されます（出典：金融庁「自己資本比率規制等（バーゼル規制）について」）。
内部モデルを採用しない国内基準の金融機関などは、2025年3月31日から適用されます。そのため、適用の範囲とリスク情報のつながりを確かめ、過去の計算を再現できる状態にしておきます。
- 適用要件：範囲は金融機関ごとに異なるため、計測方式、データ項目、報告帳票、モデル変更、証跡に分けて確認します。
- リスク情報：取引・ポジション・市場データ・評価モデルの履歴を管理し、リスク量を損益、限度額、資金繰りと結びつけます。
- 再計算：規制変更後に過去期間を再計算できるデータを保持し、モデルの版を管理します。
サイバーセキュリティとITレジリエンス
金融庁は2025年6月に、金融分野のITレジリエンスに関する分析レポートを公表しました。サイバーや地政学のリスクを背景に、金融業界ではセキュリティとオペレーショナル・レジリエンスの強化が求められています（出典：金融庁「金融分野におけるITレジリエンスに関する分析レポート」）。
金融庁は2025年7月に、金融分野のサイバーセキュリティに関するガイドラインの一部改正も公表しています（出典：金融庁「金融分野におけるサイバーセキュリティに関するガイドラインの一部改正」）。
対策は、システム内部の統制と、外部委託先を含む管理の二つに分けて整えます。
- 内部統制：最小権限、職務分掌、MFA、特権操作記録、暗号化、脆弱性管理、バックアップ、復元テスト、インシデント報告、手動継続
- 外部リスク：委託先監査を行い、第三者リスクやAI悪用も考慮して、データフィード、クラウド、導入・運用パートナーを含むサプライチェーンを管理
高速処理・クラウド・AIの使いどころ
まず性能の指標を把握したうえで、クラウドやAIを用途に合わせて検討します。
性能指標の例として、日本取引所グループの現物取引システムでは、注文応答時間が約0.2ミリ秒、情報配信時間が約0.5ミリ秒です。注文や約定、注文板などは、三重化したサーバーで処理されます（出典：日本取引所グループ「システム概要（arrowhead）」）。
- 性能指標：注文応答と情報配信の速度を把握します。
- 性能要件：社内システムが同等性能を要するとは限らず、ピーク遅延、障害時の冗長化、容量拡張を数値化します。
- クラウド：取引量やリスク計算の負荷に応じて、必要な時間帯に計算資源を増やせます。低遅延取引、大量計算、帳票、分析で要件は異なります。
- AI：異常検知、レポート要約、テスト仕様の作成への利用
評価・リスク・規制報告は、検証なしに自動化せず、データと根拠、モデル変更を記録したうえで、人の承認を残します。
市場系システムに関するよくある質問
市場系システムの最適な形は、商品、拠点、規制、既存システムの組み合わせで変わります。発注の前によく寄せられる質問を取り上げ、判断の軸が分かるように答えます。
市場系システムはパッケージとスクラッチのどちらがよいですか？
標準的な取引、リスク、決済の業務を早く安定させたい場合は、パッケージやSaaSが候補になります。一方で、独自の商品や評価モデルが競争力の中心なら、スクラッチも候補に入ります。
共通データや標準機能はパッケージで整え、独自分析や画面だけを個別に開発するハイブリッドが適する場合もあります。そのうえで、独自性と保守負担を5年TCOで比べます。
市場系システムの開発期間はどのくらいですか？
限定機能のPoCは3〜6か月、ミドルオフィス中心は6〜15か月、標準中心のパッケージ導入は9〜18か月程度が目安になります。
統合刷新は18〜36か月程度、大規模レガシー統合や複数拠点の段階移行は3〜5年以上になる場合があります。期間は、商品数、移行データ、並行稼働、テスト件数、制度対応の範囲によって変わります。そのため、工程ごとに完了条件を決めておきます。
市場系システムはクラウド化できますか？
クラウド化は可能ですが、処理の特性ごとに責任分界を分けて設計します。リアルタイム取引やリスク計算、データ保管などを、必ずしも同じ環境に置くわけではありません。
暗号化や鍵管理、特権アクセスの扱いを要件に書き込みます。そのほか、ログ、専用線、リージョン、復元テスト、委託先監査、障害時の手動運用も要件に含めます。クラウド事業者と導入・運用パートナーの責任も、明確にしておきます。
市場系システム開発で最初に決めるべきことは何ですか？
最初に決めたいのは、対象商品と業務、正本データ、評価時点です。加えて、許容誤差や権限、例外処理、障害時の継続方法も定めます。製品や開発言語は、その後で選びます。
これらが決まると、必要な連携、移行データ、テストケース、RTO・RPO、費用の前提が具体的になります。あわせて、業務、リスクモデル、データの各責任者を置いておきます。
RFIやRFPには、サンプルと受入基準を添えて相談します。
まとめ
市場系システムは、取引画面だけでなく、フロント・ミドル・バックをまたいで取引のライフサイクル全体を管理する業務基盤です。
商品から取引、ポジション、評価、損益までを一貫して追跡し、決済、会計、リスク、監査証跡とつなぎます。
開発を成功させる鍵は、正本データと計算結果の検証方法を先に定めておくことです。
発注前に行う三つの準備
発注の準備は、現状の棚卸し、PoCやサンプル照合、RFP作成の順に進めます。
- 現行の取引・評価・リスク・決済・会計フローと、Excelを含むデータの流れを棚卸しします。
- 対象範囲を限定したPoCやサンプル照合による、計算精度とデータ品質の確認。
- 対象商品、正本データ、連携、移行、テスト、SLA、RTO・RPO、制度改定、5年TCOを含むRFPで、複数の提案を同じ条件で比較します。
費用・技術・運用まで含めた比較
費用は、PoCの500万〜2,000万円から大規模刷新の10億〜50億円以上まで幅があります。そのため、初期の価格だけでは判断しきれません。
- 5年TCO：市場データ、ライセンス、移行、テスト、保守、制度改定、監視、障害復旧を含めて比較します。
- 責任分界：開発会社、サービス提供者、運用委託先の役割を、契約の中で明らかにしておく。
市場系システムの刷新は、業務データと統制を設計し直すこととして進めると、安定運用と将来の変更のしやすさにつながります。
▼関連記事一覧
・市場系システム開発の進め方
・市場系システム開発でおすすめの開発会社6選と選び方
・市場系システム開発の見積相場・費用
・市場系システム開発の発注・外注・委託方法
▼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を創業。