株式売買システムは、利用者、接続する市場、約定後の業務範囲によって種類が分かれます。開発では、対象を決めてから必要な機能と運用責任を定義し、開発方式を選びます。
種類ごとの機能から委託先の選び方まで、順に解説します。
▼関連記事一覧
・株式売買システム開発の進め方
・株式売買システム開発でおすすめの開発会社6選と選び方
・株式売買システム開発の見積相場・費用
・株式売買システム開発の発注・外注・委託方法
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
株式売買システムの全体像
株式売買システムは、注文の受付から決済までをつなぐ仕組みを指します。
画面は、その一部にすぎません。
注文管理、リスク判定、市場接続を扱います。さらに、約定管理、清算・決済、監視も含みます。顧客通知も、この範囲に入ります。
対象範囲を先に決めることが、見積と品質を安定させる第一歩です。
証券会社・金融事業者向けの顧客取引システム
顧客向けオンライン取引では、口座開設や本人確認から取引報告書までを扱います。フロント画面に加えて、注文管理システム（OMS）も必要です。
- 取引機能：銘柄検索、株価・気配・板情報、現物・信用取引、注文の訂正・取消。
- 取引後の機能：約定照会、入出金、取引報告書、バックオフィス連携。
- 計算・管理：余力・委託保証金、手数料・税の計算。
フロントだけを先に作ると、約定後の残高や帳票との整合性で手戻りが起きやすくなります。
ディーラー・自己売買向けのディーリングシステム
ディーリングシステムは、複数の市場や銘柄を監視し、注文やポジション、損益を管理します。顧客向けの画面に比べて、操作速度とリスクを一目で把握できることが重視されます。
- 市場監視：板情報の更新頻度と複数銘柄の表示。
- 注文操作：ショートカット操作と複数注文の一括処理。
- 管理：ポジション・リスクの把握と権限分離。
アルゴリズム取引やAPI発注を含めるなら、注文レート制限、異常注文の停止、自己対当防止が要件になります。操作ログの保存も、要件に含まれます。
取引所・市場向けのマッチングシステム
取引所向けシステムの役割と性能は、処理方式や公表例から把握できます。
- 注文処理：価格・時間の優先順位で注文を突き合わせ、約定結果と相場情報を返します。
- 処理方式：顧客向けの注文取次とは方式と性能が異なります。
- 応答・配信性能：arrowhead4.0は注文応答約0.2ミリ秒、情報配信約0.5ミリ秒です。
- サーバ構成：注文・約定・注文板などを三重化サーバで処理します（出典：日本取引所グループ「システム概要（arrowhead）」）。
取引所と同じ性能が不要な案件でも、レジリエンスとピーク耐性を設計する際の参考になります。
株式売買システムの定義と種類別の違い
株式売買システムは、注文を入力してから市場で約定させ、その結果を顧客や社内に反映するまでを処理します。
種類は、「誰が使うか」と「どの市場へつなぐか」で分けられます。
約定後の業務をどこまで持つかも、分類の基準になります。たとえば、模擬取引アプリと本番の証券取引基盤では、費用も責任範囲も異なります。
インターネット取引システム
インターネット取引では、利用方法と業務範囲を一貫して設計します。
- 利用方法：個人・法人顧客がWebやスマートフォンから注文します。
- 業務範囲：口座開設・本人確認、認証、相場表示、注文、約定通知、残高・損益照会、入出金、帳票出力まで扱います。
- 商品条件：NISAや信用取引を追加する場合、商品ごとの取引条件、余力計算、注文可能時間を業務ルールに明記します。
- 税務・帳票：商品ごとに異なる扱い。
注文管理・約定管理を中心とするOMS
OMSは注文管理の中核となるため、注文状態と障害時の対応をあらかじめ定義しておきます。
- 注文状態：注文内容を検証して市場や接続先へ送り、受付・拒否・一部約定・全約定・取消を管理します。
- 識別子・再送：注文と約定に一意の識別子を付け、通信の再送があっても二重発注を防ぎます。
- 接続停止時：保留、再送、取消、手動介入、顧客通知を状態遷移として定義します。
模擬取引・分析・API連携システム
模擬取引・分析システムでは、対象範囲と外部接続の条件を先に決めておきます。
- 対象範囲：模擬取引、株価分析、ポートフォリオ管理に限れば、本番決済や厳格な金融機関運用を切り離せます。
- 将来拡張：本番発注へ広げる可能性も考慮に入れます。
- データ設計：顧客・注文データ、銘柄コード、時刻、権限を拡張しやすい形式にそろえます。
- 外部API：利用規約、相場データの再配布条件、遅延表示の扱い。
パッケージ・クラウド・スクラッチの開発方法
標準的な証券業務を早く立ち上げたいなら、パッケージやASPを中心に検討します。一方で、独自の商品や顧客体験、業務連携で差別化するなら、ハイブリッド方式が現実的です。
スクラッチ開発では、制度改正と接続仕様への対応が続きます。試験や24時間運用を担う体制も必要です。方式は、事業の独自性と運用責任を基準に決めます。
パッケージ・ASPの特徴と制約
パッケージやASPを使うと、口座・注文・約定・管理画面などの標準機能と、金融業務の運用知識を生かせます。
初期開発を抑えられ、制度対応や保守を任せられる可能性もあります。
制約が出る場合があるのは、次の点です。
- 商品・手数料：独自の手数料体系や商品設計。
- 既存基幹：既存の基幹システムとの連携。
- 画面：画面の作り込み。
標準機能と追加開発の範囲は、一覧にして分けておきます。
費用は5年分で比べる必要があります。月額利用料や取引量課金、接続料のほか、データ返却費用も対象です。
クラウド利用の特徴と確認点
クラウドは開発環境を早く用意でき、マーケットデータ配信や参照画面の負荷に合わせて構成を伸縮できます。さらに、バックアップや監視、災害対策の部品を使える場合もあります。
クラウドは、何をどこに置くかによって確かめる内容が変わります。
- 中核の処理：注文受付や約定処理に置く場合の通信遅延、リージョン障害、切替時間。
- データ：データ所在地と暗号鍵管理。
- 委託先：委託先の監査。
クラウド自体が可用性を保証するわけではありません。そのため、RTOとRPOを数値で検証する必要があります。
スクラッチ・ハイブリッドの特徴と継続費用
スクラッチでは、独自の注文ルールやリスク計算、商品、分析、顧客体験を細かく作れます。その一方で、標準機能がない分、継続費用が増えます。継続費用の対象は、設計、試験、障害訓練、制度改正です。
標準業務はパッケージなどで使い、顧客画面や分析、社内ワークフローをAPIで個別開発する方法もあります。この方式は、初期リリースと独自性のバランスを取りやすいのが特徴です。
将来の乗り換えに備えて、データやAPI、ソースコードが誰のものかを契約で定めておきます。
株式売買システム開発の進め方
開発は画面デザインから始めず、証券業務の流れと非機能要件から逆算します。また、各工程で何を納めるか、誰が決めるかもあらかじめ定めておきます。
- 企画と要件定義。
- 方式設計と実装。
- 接続試験・総合試験。
- 移行と段階リリース。
- 稼働後の改善。
注文と約定の状態管理、外部接続、障害時の復旧は、特に早い段階で検証しておきます。
1. 企画・要件定義での業務範囲の決め方
企画・要件定義では、業務範囲と非機能要件をそろえておきます。
- 業務範囲：対象顧客、商品、市場、取引時間、注文種別。
- 口座・業務：口座、入出金、決済、帳票、承認、監視対象。
- 非機能要件：ピーク注文数、同時接続数、画面表示の許容遅延。
- 運用条件：RTO、RPO、ログ保存期間、稼働時間。
業務シナリオには、始値・終値、急騰急落を含めます。さらに、相場データの大量配信や外部接続断、復旧後の再送も入れます。
RFPには、接続範囲や認証方式、監査ログを記載します。データ移行や運用時間、障害時にどこまでを誰が受け持つかも書いておきます。必要な機能だけを並べると、提案の前提が足りなくなります。
NDAを締結する前には、顧客情報や接続情報を開示しすぎないよう注意します。
匿名化した業務フローで提案を依頼する方法も有効です。
2. 方式設計・開発でのデータの一貫性
基本設計では、システムの責任範囲とデータ定義をそろえておきます。
- 機能の分担：フロント、認証・顧客管理、OMS、リスク・余力計算。
- 接続・管理：接続ゲートウェイ、約定管理、データ配信、バックオフィス。
- 共通データ：注文・約定・顧客ID、銘柄コード、時刻、状態。
- 再送処理：同じ注文を一度だけ処理し、注文と残高の食い違いを防ぐ。
監視や帳票の責任範囲も決めておきます。画面ごとに状態を別々に持つと、ずれが起きやすくなります。
標準機能の検証と独自機能の開発は、分けて進めます。API仕様、エラーコード、タイムアウトは、早めに合意しておきます。加えて、再送間隔や手動取消、監査ログも決めておきます。
まず、外部接続先のテスト環境で疎通を確認します。そのうえで、異常時にも正しい注文状態を保てる設計を優先します。
3. 試験・移行・リリースでの本番リスクの抑え方
試験は単体、結合、総合の順に進めます。その後は、次の順で行います。
- 性能試験。
- 障害試験。
- セキュリティ試験。
- 業務受入試験。
正常な注文だけでなく、異常なケースも再現しておきます。
- 注文条件：価格・数量の不備、余力不足、取引時間外。
- 約定・取消：部分約定と取消の競合。
- 通信・データ：通信断、重複電文、相場データ遅延、復旧後の再送。
ピーク試験では、平均値だけでなく、始値・終値付近の注文集中時も確認します。
判断材料は、応答時間とデータ整合性を維持できるかどうかです。
移行対象は、顧客、口座、残高です。建玉や注文履歴、帳票履歴も含まれます。変換ルールや照合方法、切戻し条件も、あらかじめ決めておきます。
社内利用から始め、限定顧客、商品限定を経て全体展開へ広げると、影響範囲を抑えられます。
稼働後は、運用設計へ引き継ぐ項目を決めます。監視アラートや当番体制、障害連絡のほか、制度改正の受付やリリース手順も含みます。
▶ 詳細はこちら：株式売買システム開発の進め方
株式売買システムの費用相場とコストの内訳
株式売買システムには公開された標準価格が少ないため、ここに示す金額は、機能・体制・非機能要件を置いて考えた概算です。
小規模な金融Webアプリは約100万〜300万円で、中規模の業務システムは約500万〜2,000万円です。
大規模な証券基盤は、数千万円〜1億円以上とされます（出典：金融システム開発費用の整理、2025年）。
本番の株式売買では、接続や監視が加わります。試験や運用も必要になるため、これらの金額はそのまま適用しません。
スコープ別の初期開発費と期間
開発範囲が広がるほど費用と期間が大きくなり、初期費用は300万円台から10億円超、期間は2か月から48か月まで幅があります。
- 模擬取引PoC：株価表示・銘柄検索・模擬注文で300万〜1,000万円、2〜4か月。
- パッケージ・ASP：画面・認証・連携・帳票の個別対応で1,000万〜5,000万円、6〜12か月。
- 顧客向け新規構築：口座・注文・余力・取引所接続などを含み5,000万〜3億円、12〜24か月。
- 複数市場の基盤：24時間監視・災害対策・移行まで含み3億〜10億円、24〜48か月。
- 取引所級基盤：超低遅延・三重化・ピーク耐性などが必要で、10億円超の可能性。
模擬取引PoCの費用には、実売買や決済、金融監査は含みません。この金額と期間は、確定した相場ではなく、要件を置いた推定です。
費用を押し上げる主な要因
費用を左右するのは、取引対象、ピーク注文数、接続先です。可用性や規制対応、運用体制も要因になります。そのため、見積もるときは条件をそろえます。
- 商品・取引量：商品数が増えると注文ルールと余力計算も増加。
- 接続先：電文変換、疎通試験、障害時の切替が増加。
- 可用性・運用：冗長構成、遠隔地バックアップ、訓練、監視要員が必要。
- 初期費用の構成：要件定義・業務設計10〜20%、アプリ開発30〜45%、外部接続10〜20%。
- 基盤・試験：インフラ・監視・災害対策、セキュリティ・性能試験・移行は各10〜20%の仮説。
比率は案件によって変わります。接続費や試験費を開発費に含めるかどうかで、見積の見かけも変わります。
初期費用以外のランニングコスト
運用開始後の費用は、固定費、従量費、保守運用費に分けて確認します。
- 基盤・データ：クラウド、データセンター、相場データ、接続回線、ライセンス。
- 運用・保守：監視、24時間対応、保守改修、脆弱性診断、バックアップ、制度改正。
- 比較する費用：月額固定、取引量課金、追加機能、障害対応、データ移行。
- 費用を抑える方法：模擬取引、分析、管理画面を段階導入し、標準機能を活用します。
- 削らない安全機能：認証、注文の一意性、誤発注防止、監査ログ、バックアップ、障害切替、セキュリティ試験。
これらの安全機能を後から追加すると、データモデルや運用手順の作り直しが起きます。だからこそ、初めから組み込んでおくことが大切です。
関連費用も含めて、5年分を試算します。初期費用が低くても、月額と従量費によっては総額が逆転することがあります。
▶ 詳細はこちら：株式売買システム開発の見積相場・費用
株式売買システムの開発会社・サービスの選び方
開発会社やサービスは、知名度や提示価格だけでなく、同じ評価表で比べて選びます。評価表には、業務実績や接続範囲、性能を入れます。可用性やセキュリティ、保守、費用モデルも含めます。
個社の実績があっても、自社と同じ商品や市場、運用時間を扱えるとは限りません。そこで、提案書への確認質問も用意しておきます。
証券業務と接続実績の確認
実績を確認するときは、金融システムの経験だけでなく、対象商品や市場、担当した業務範囲を聞きます。
- 商品・接続：現物・信用・ETF、接続先、市場データ。
- 業務機能：口座・決済、帳票、監視の担当範囲。
- 障害対応：注文受付、拒否、部分約定、取消、再送、復旧。
約定と残高の整合性を、どのように検証したかも確認します。
社名や件数よりも、業務機能と責任範囲で実績を比べます。
性能・可用性・セキュリティの数値評価
性能は、平均応答時間だけでなく、ピーク時の注文受付、相場情報配信、約定通知の遅延を分けて評価します。管理画面の遅延も、対象に含めます。
可用性は稼働率に加えて、障害検知から切替までの時間と、切替中の注文を確認します。さらに、データ損失や復旧後の照合方法も確認します。
多要素認証、権限分離、暗号化を評価します。脆弱性診断や監査ログ、委託先管理、インシデント訓練も評価対象です。
制度改正・保守・契約条件の確認
商品制度や認証、接続仕様が変わると、改修が必要になります。
税・帳票や相場情報の変更も、改修の対象になります。
契約の段階で保守の範囲を文書にしておくと、後の認識違いを防げます。
- 制度改正：情報収集、影響分析、試験、リリースの担当。
- 保守・契約：基本保守と別見積、再委託先、障害責任、SLA。
- 権利・移行：データ等の帰属、データ返却、ベンダー切替支援。
評価表の例では、証券業務実績が25点、接続・性能・可用性が20点、セキュリティ・監査が20点です。残りは、制度改正・保守が15点、5年TCOが10点、体制・契約・移行が10点とします。
価格よりも、障害時の注文状態や復旧方法を説明できる提案を評価します。長期の運用で失敗しないようにするためです。
▶ 詳細はこちら：株式売買システム開発でおすすめの開発会社6選と選び方
株式売買システムの発注・外注・委託方法
外注では、業務、システム、運用のそれぞれについて、どこまでを誰が受け持つかを明確にします。
発注前には、業務を洗い出してRFIを行います。
NDAを締結したあと、RFPで要件をそろえます。その後、提案やデモ、見積、契約を経て、受入、移行、運用引継ぎへ進みます。
未確定の要件まで固定価格にすると、変更費用が増えたり、品質が下がったりしやすくなります。
発注前の業務整理と情報開示の範囲
発注前に、現行業務を業務フローとしてまとめます。そこには、商品や利用者、取引量、既存システムを含めます。外部接続やデータ移行、運用時間、法令・社内規程も、整理の対象です。
RFPでは、必須、希望、将来対応を分けて書きます。性能・可用性・セキュリティは、数値で示します。また、顧客情報や接続情報は、NDAの範囲と閲覧者を決めておきます。
提案に必要な最小限の情報から開示します。
契約方式と開発体制の使い分け
要件がはっきりしている部分は請負、探索や優先順位が変わる部分は準委任やアジャイルを組み合わせる方法があります。
完成の定義や受入基準、仕様変更の扱いを、契約に明記します。遅延報告や検収、知的財産、再委託の条件も、契約に書き込みます。発注側にも、業務とセキュリティの責任者を置きます。
受入担当と運用担当も置き、意思決定が止まらない体制を整えます。
受入試験と運用引継ぎの契約条件
受入試験と運用引継ぎでは、発注側も業務シナリオと障害対応を確かめます。
- 業務シナリオ：注文、約定、残高、決済、帳票、顧客通知。
- 合格条件：重複注文防止、約定・残高の一致、監査ログでの経緯追跡、復旧後の未処理照合。
- 検収資料：性能・脆弱性診断、不具合、切戻し手順。
- 運用演習：監視、アラート、一次切り分け、エスカレーション、顧客告知、手動処理、復元・災害訓練。
- 引継ぎ合意：制度改正の窓口・費用、終了時のデータ返却・移行支援を合意し、責任の空白を防ぎます。
▶ 詳細はこちら：株式売買システム開発の発注・外注・委託方法
2026年の最新動向と要件チェック
2026年時点では、株式売買システムの要件が、不正アクセス対策やオペレーショナル・レジリエンス、データ連携の標準化へ広がっています。
制度やガイドラインは更新されるため、要件定義、試験、運用の各工程で見直せる仕組みを作ります。
フィッシング耐性のある認証と不正取引検知
金融庁は、フィッシングサイトで窃取された顧客情報による不正アクセスや不正取引を踏まえ、インターネット取引の認証と不正防止策を強化する監督指針の改正を2025年10月に適用しました（出典：金融庁「監督指針等の一部改正」）。
- 認証：重要操作では、パスキーなどフィッシングに耐性のある多要素認証を検討します。
- 通知・ロック：ログイン・取引通知と、連続失敗時のアカウントロックを検討対象にします。
- 不正取引対策：振る舞い検知、ログ保存、不審アクセスの遮断も要件の中心です。
安全対策基準とレジリエンスの設計
認証機能の追加に加えて、障害時の業務と安全対策基準を併せて設計します。
- 障害対応：障害を検知し、安全に取引を止めて代替経路へ切り替えます。
- 復旧対応：注文・約定・残高を照合し、顧客や関係者へ説明します。
- 基準の更新：FISCの安全対策基準も参照します。
- 適用範囲：発注時に、対象年度の最新版と自社業態に応じた範囲を見ておきます。
FISCは2025年3月に第13版を公表し、2026年3月には第14版も案内しています（出典：FISC「金融機関等コンピュータシステムの安全対策基準・解説書」）。
バックオフィスのデータ標準化と市場機能の変化
2026年には、証券関連事務の効率化と高度化に向けて、業界横断の共通データ基盤が検討されています。
- 共通データ基盤：2026年に検討され、2027年春ごろの開始が目標。
- データ設計：すぐ接続しない場合も、銘柄・企業・権利処理・取引情報の手入力依存を抑えます。
- 市場仕様：arrowhead4.0は2024年11月にクロージング・オークションなどを導入しました。
- 変更管理：市場の注文方式・接続仕様が変わると、注文入力、説明文、テストデータ、監視、顧客通知に影響します。
共通基盤は、企業・取引情報を集約し、自動処理しやすい形で配信する構想です（出典：日本取引所グループ「証券関連事務の共通データ基盤」）。
市場機能を外部接続する場合は、仕様変更を受け取る担当者と、リリースを判断する責任者を決めておきます。
よくある質問（FAQ）
答えは、実売買をするかどうか、市場につなぐかどうか、約定後の業務をどこまで含めるかで変わります。
企画段階でよく質問される論点を、前提とともに説明します。
株式売買システムの開発費用はいくらですか？
開発費は、対象範囲と取引や運用の機能によって変わります。
- 模擬注文PoC：300万〜1,000万円が目安です。
- パッケージ・ASP導入：1,000万〜5,000万円が概算です。
- 顧客向け新規構築：5,000万〜3億円が目安です。
- 追加スコープ：取引所接続、24時間監視、災害対策、決済、移行を含めると数億円規模へ広がります。
見積は、対象機能と期間をそろえたうえで、複数社で比べてください。
株式売買システムはクラウドで開発できますか？
株式売買システムはクラウドで開発できます。
注文受付や約定処理、顧客画面、バックオフィスのどこにクラウドを採用するかを、分けて設計します。
クラウドは伸縮性やバックアップを使える一方で、遅延やリージョン障害を検証する必要があります。切替やデータ所在地、委託先管理も確認します。そのうえで、RTO・RPOと外部接続条件を満たせるかで判断します。
開発に金融業の許認可や法規制の確認は必要ですか？
必要です。許認可や登録、社内規程はシステム開発とは別の論点ですが、設計には影響します。
検討対象は、本人確認や適合性確認、顧客情報、注文記録です。加えて、帳票や監査、セキュリティも検討します。法務やコンプライアンス、業務の責任者は、要件定義の段階から参加させます。
対象サービスに適用される法令、監督指針、業界基準、取引所仕様を確認してください。
株式売買システムは内製と外注のどちらがよいですか？
証券業務、外部接続、24時間運用、制度改正への対応を自社で継続できるかで判断します。
独自画面や分析だけを内製する方法もあります。
注文・約定・決済などの標準領域は、外部サービスと組み合わせる選択肢もあります。その場合は、どこまでを誰が受け持つか、データとAPIの所有権、障害対応、引継ぎ条件を先に決めます。
まとめ
株式売買システムは、顧客向けの取引、ディーリング、取引所・市場基盤に分かれます。
種類によって、必要な性能や機能、費用は異なります。
画面より先に、注文や約定、余力の業務を定義します。
決済や監視、障害復旧も、業務の定義に含めます。
RFPには、取引対象、ピーク注文数、接続先を記載します。加えて、可用性や規制対応、運用体制も書き込みます。
最初に決める事項
開発範囲と方式を選ぶときは、判断の前提をそろえておきます。
- 取引範囲：実売買か模擬取引か、顧客向けか社内向けかを決めます。
- 接続先：接続する市場と商品。
- 約定後の業務：決済や帳票を含めるか定義します。
- 開発方式と費用：パッケージ・クラウド・スクラッチ・ハイブリッドを比較し、初期費用ではなく5年TCOと運用責任まで含めて判断します。
次に進める準備と確認
発注後の手戻りを抑えるため、次の順に準備と提案内容の確認を進めます。
- 現行業務と将来のサービス範囲を洗い出し、必須・希望・将来機能を分けたRFPを作成します。
- 重複注文、通信断、部分約定、復旧、監査、データ移行のシナリオを提案依頼に示し、証券業務と運用の理解度を比べます。
- 安全性と拡張性を確保し、段階導入で価値を検証します。
▼関連記事一覧
・株式売買システム開発の進め方
・株式売買システム開発でおすすめの開発会社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を創業。