結論：証券代行システムの開発費用は、発行会社向けポータルだけなら500万〜2,000万円、
株主管理・配当・株主総会まで含む標準導入なら1,500万〜5,000万円、証券代行基幹を大規模に刷新する場合は1億5,000万〜5億円超が目安です。
ただし、証券代行システムは株主名簿を保存するだけの管理画面ではありません。総株主通知の受信、
名簿の確定、株式の異動、配当金の計算、議決権の集計、株主総会資料、発行会社との情報連携、
操作ログ、データ移行まで含めて業務が成立します。本記事では、証券代行システムの費用相場、
内訳、価格が変動する要因、開発の進め方、見積もりの取り方、コストを最適化するポイントを、
2026年時点の公開情報と業務分解に基づいて解説します。
▼全体ガイドの記事
・証券代行システム開発の完全ガイド
証券代行システムとは何ですか？費用は何で決まりますか？
証券代行システムとは、株主名簿、株式の権利、配当、議決権、株主総会などの株式事務を正確に処理する業務システムです。
費用は、発行会社数・株主数・対象業務・外部連携・データ移行・可用性・監査要件をどこまで含めるかで決まります。
まず「発行会社が使う周辺ポータル」なのか、「株主名簿管理人が業務を処理する基幹システム」
なのかを分けます。同じ証券代行システムという呼び方でも、既存の業務コアに照会画面を追加する案件と、
名簿・配当・総会・外部連携を一体で刷新する案件では、必要な人員も期間も大きく異なります。
証券代行システムは何を管理するシステムですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
証券代行システムは、株主名簿、株主属性、所有株式数、取得日、異動履歴、所在不明株主、配当履歴、議決権数などを管理し、株式事務を正確に処理する業務システムです。
会社法上の株主名簿管理人が担う名簿管理や株主総会関連事務を支えるため、一般的な顧客管理システムよりも、基準日と権利確定の考え方が重要になります。
信託協会の説明では、株式等振替制度のもとで口座管理機関、証券保管振替機構、株主名簿管理人の間で情報が伝達され。
株主名簿は株主確定日ごとに通知される総株主通知を利用して作成されます（出典: 信託協会「証券代行業務」）。
このため、画面の数が少なくても、通知の検証、名寄せ、訂正、再処理、照合まで含めると開発難易度は高くなります。
費用比較ではポータル、標準導入、個別開発、基幹刷新を分けます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
発行会社向けポータルは、株主構成や帳票の照会、帳票ダウンロード、事務指示、承認ワークフローを既存システムとAPI連携する構成です。
名簿や配当の確定ロジックを既存の基幹に残せる場合、画面・権限・連携・監査ログが主な開発範囲になるため、500万〜2,000万円程度に収まりやすいです。
一方、株主管理、株式異動、配当計算、株主総会、電子提供、総株主通知、帳票、移行までを新しい業務基盤で扱う場合は、システムの中心が変わります。
パッケージの標準機能を中心に導入するか、固有の株式実務をアドオンで追加するか、業務コアから作り直すかを分けて見積もることが、相場を正しく読む第一歩です。
証券代行システム開発の進め方と期間の目安
証券代行システムは、画面を先に作ると、基準日処理や権利確定の例外が後から見つかりやすい領域です。
現行業務の棚卸し、業務シナリオの作成、方式比較、外部連携の検証、移行リハーサル、
総合試験、本番切替までを一つの計画に含めます。標準導入なら4〜9か月、個別開発を含む中規模案件なら9〜18か月、
大規模な基幹刷新なら18〜36か月以上が期間の目安です。
要件定義では基準日・権利・例外処理を業務シナリオにします
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初に、上場会社向けか非上場会社向けか、対象となる株式や新株予約権は何か、発行会社が何社あるか、株主数と過去データの保持期間は何年かを確認します。
次に、総株主通知の受信から検証、名簿更新、エラー訂正、再処理までを一連の業務フローにします。
配当基準日の確定、配当金・源泉税の計算、未払配当の管理、支払通知、株主総会の議決権集計も、正常系だけでなく例外系を記述します。
成果物は、機能一覧だけでは足りません。業務フロー、データ項目定義、権利イベントの状態遷移、帳票一覧、外部連携一覧、権限マトリクス、監査証跡の要件、業務シナリオ別の受入条件をそろえます。
要件定義を短くするほど安くなるとは限らず、曖昧なまま設計に進むと、後から手戻り・追加テスト・契約変更が発生して総額が上がりやすいです。
方式選定ではパッケージ・クラウド・スクラッチを比較します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
方式は、既存の業務コアを生かしてポータルとAPIだけを刷新する案、パッケージやマネージドサービスを標準中心で導入する案。クラウド上で業務コアを個別構築する案、スクラッチで大規模に刷新する案に分けます。
標準的な株主管理や帳票を早く導入したいならパッケージ、既存業務との差分が少なく運用負荷を平準化したいならクラウド。独自の権利処理や複数の証券代行業務を統合したいなら個別開発が候補になります。
外部連携は、総株主通知等のファイルまたはAPI受信、発行会社ポータル、金融機関、帳票・通知、会計・決済、認証基盤、監視基盤などに分けて整理します。
連携先ごとに、データ形式、暗号化、認証、再送、重複防止、エラー通知、照合結果の保存場所、障害時の責任分界を定義します。
連携本数だけを数えるのではなく、リアルタイムかバッチか、双方向か、一度の処理量はいくつかまでRFPに書くと、見積もりの差が小さくなります。
移行リハーサルと業務シナリオテストを先に計画します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
移行対象は、株主・株主属性・所有株式数・異動履歴だけとは限りません。配当履歴、未払配当、所在不明株主、議決権の基準値、帳票の発行履歴、訂正履歴、監査ログを残すかを決めます。
旧システムと新システムで、株主数、株式数、配当金額、未払残高、発行会社別の集計値が一致するかを照合し、差分が出た場合の修正者と承認者を記録できるようにします。
テストでは、総株主通知の再送、同一データの二重受信、株式分割・併合、単元未満株式、配当基準日の変更、源泉税の端数、株主総会の議決権行使。電子提供と書面交付請求、外部システムの停止を確認します。
決算期や株主総会期に停止しにくい業務であるため、本番前に旧新並行照合と切戻し訓練を行う期間も、開発費と期間に含めることが大切です。
証券代行システムの費用相場とコストの内訳
証券代行システム単体の契約金額を横断的に示す公的な統計はほとんどありません。そのため、
以下の価格帯は、公開されている一般的な業務システムの費用情報に、金融系基幹の連携・移行・監査・可用性の追加工数を加味した記事用の推定レンジです。
契約金額を保証するものではなく、RFPの初期予算を置くための目安として利用します。
対象範囲別の費用相場は500万〜5億円超です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
発行会社向け照会・事務指示ポータルは、500万〜2,000万円、期間3〜6か月が目安です。
既存の株主名簿・配当基盤と接続し、権限管理、承認、帳票の閲覧、事務指示、操作ログを追加する範囲を想定しています。
既存APIが整備されていない場合や、複数の発行会社ごとに画面・帳票を分ける場合は、連携と権限設計の費用が増えます。
パッケージまたはクラウドを標準機能中心で導入する場合は、1,500万〜5,000万円、期間4〜9か月が目安です。
株主管理、配当、株主総会の標準機能に加えて、初期設定、データ移行、教育、受入試験を含めます。
パッケージのライセンスまたは利用料は、初期構築費と別に請求されることがあるため、利用ユーザー数、発行会社数、株主件数、帳票出力数、保管容量を確認します。
パッケージに個別アドオンと複数の外部連携を加える場合は、5,000万〜1億5,000万円、期間9〜18か月が目安です。
独自の株式実務、総株主通知の検証・再処理、配当や未払の計算、議決権集計、電子提供、発行会社ポータル、移行リハーサルまで含めると。この価格帯を超えることもあります。
証券代行基幹のスクラッチ開発や大規模刷新は、1億5,000万〜5億円超、期間18〜36か月以上が目安です。
複数の発行会社、大量の株主データ、名簿・権利・配当・総会・帳票・外部接続、24時間運用、災害対策、全履歴移行まで含める場合は。
一般的な業務システムの数百万円〜数千万円という相場をそのまま当てはめないことが大切です。
初期費用は要件定義・開発・試験・移行に分けて確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
初期費用の配分は、要件定義・業務設計10〜20%、アプリケーション設計・開発35〜50%、外部連携10〜20%。
テスト・移行・切替リハーサル15〜25%、PM・監査文書・教育10〜15%、インフラ・監視5〜15%をたたき台にできます。
案件の重複計上を調整する必要はありますが、実装費だけで予算の大半を占めていないか、移行や試験が一式で隠れていないかを確認するための比率になります。
2026年公開の一般的なシステム開発相場でも、簡易な業務ツールは数十万円から。
業界特化型の複雑な基幹システムは数千万円〜億単位まで幅があると説明されています（出典: SIA株式会社「システム開発の費用・相場（2026年版）」）。
証券代行では、そこに制度・権利イベント・外部接続・金融水準の統制が重なるため、画面数や開発人数だけで比較しないことが重要です。
稼働後には、アプリケーション保守、制度改正対応、クラウド利用料、ライセンス更新、監視、セキュリティ診断、バックアップ、DR訓練、復元テスト。アクセス権レビュー、障害対応が継続します。
保守費は初期開発費の年15〜25%を仮置きできますが、24時間365日の監視や厳格なSLA、法令・制度改正への短納期対応を含む場合は別途積み上げます。
初期費用が2,000万円、年額保守・クラウド・診断・制度対応が600万円なら、5年TCOは単純計算で5,000万円です。
初期費用だけが安い提案でも、月額利用料、データ転送料、追加ユーザー、帳票、保守範囲、移行後の手作業を加えると逆転することがあります。必ず初期費用と5年分の運用費を同じ表計算上で比較します。
証券代行システムの価格が変動する主な要因
同じ機能一覧を提示しても、対象データ、ピーク処理量、連携方法、可用性、移行の難しさ、
監査水準の違いで見積もりは変わります。とくに証券代行では、画面数よりも「いつの時点の株主・株式数を正とするか」
「計算結果をどの証跡で再現できるか」「失敗した処理を安全にやり直せるか」がコストに直結します。
株主数・発行会社数・権利イベント数で処理規模が変わります
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
株主数と発行会社数が増えるほど、データベース容量、検索性能、バックアップ時間、帳票生成時間、権限の分離、監視対象が増えます。
平均的な日次件数だけでなく、基準日、決算期、配当支払日、株主総会前後に処理が集中するかを確認します。
3年後・5年後の株主数、株式数、通知件数、同時利用者数をRFPに記載すると、将来増強分を含めた現実的な見積もりになります。
株式分割、株式併合、増資、株式交換、単元未満株式、種類株式、新株予約権などの権利イベントをどこまで扱うかでも、計算ロジックとテストケースが増えます。
処理を都度プログラムに埋め込む方式は初期開発が膨らみやすいため、制度や商品をマスタ・ルールとして設定できるか。ただし設定変更に承認とテストを必須にできるかを比較することが大切です。
外部連携・データ移行・帳票の範囲が追加費用を生みます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
総株主通知、発行会社ポータル、認証、帳票・通知、金融機関、会計・支払、電子提供、データ分析などの接続先が増えると、インターフェース設計、認証、暗号化。
再送、重複防止、エラー通知、照合、障害時の連絡が必要になります。
総株主通知を受け取れれば終わりではなく、形式エラーを隔離し、訂正後に再処理しても二重更新しない仕組みまで含めて積算します。
移行では、株主の基本情報と現在残高だけを移すのか、過去の異動履歴、配当・未払配当、議決権、所在不明、帳票履歴、操作・承認履歴まで移すのかを決めます。
旧データの氏名・住所表記、株主コード、証券コード、日付、税区分が統一されていなければ、クレンジング、変換、手動確認、移行リハーサルの工数が増えます。
見積書の「データ移行一式」という表現は、件数、対象期間、変換ルール、照合方法、リハーサル回数に分解してもらいます。
可用性・監査・セキュリティの水準が費用に反映されます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
発行会社の担当者が平日の日中に使うポータルと、基準日処理や配当計算を担う業務コアでは、可用性の考え方が異なります。
冗長化、バックアップ、遠隔地の災害復旧、RTO、RPO、監視、夜間・休日の保守、障害時の手作業手順、再処理の仕組みを数値化します。
RTOを30分にするか4時間にするか、RPOを直前まで戻すか前日まで許容するかで、インフラと試験の費用が変わります。
認証・多要素認証、職務分掌、特権ID、操作ログ、承認記録、ログ改ざん防止、脆弱性診断、暗号化、バックアップ、委託先管理も。金融系システムでは後付けにしにくい要件です。
FISCは2026年3月25日に金融機関等コンピュータシステムの安全対策基準・解説書の第14版を公表し。開発・導入・運用に必要な安全対策を示しています（出典: 金融情報システムセンター、2026年）。
RFPには「FISC準拠」とだけ書かず、対象項目を設計・試験・運用のどの成果物で満たすかを記載します。
見積もりを取る際のポイントとコスト最適化の方法
コストを最適化する方法は、名簿の正確性、配当・議決権の計算、監査証跡、障害復旧といった品質を削ることではありません。
開発範囲を分け、既存資産を再利用できる箇所と、将来の変更を見越して投資すべき箇所を明確にすることが基本です。
初期費用だけでなく、5年TCO、制度改正、移行、監査、運用まで同じ条件で比べます。
RFPでは対象範囲と前提条件を数字で示します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
RFPには、発行会社数、株主数、保有データの期間、1日平均とピークの通知件数、同時利用者数、対象業務、帳票数、外部連携先、利用時間、希望稼働日。
移行対象、RTO・RPO、監査とセキュリティの要件を記載します。
総株主通知の受信、名簿更新、配当計算、議決権集計、訂正・再処理、障害復旧の代表シナリオと受入条件も添えると、提案会社が同じ前提で見積もりやすくなります。
提案書と見積書では、パッケージ標準、設定、アドオン、個別開発、データ移行、テスト、教育、運用引き継ぎ、対象外を分けて記載してもらいます。
さらに、要件追加時の単価、制度改正対応の契約範囲、再委託先、障害時の責任分界、ソースコードやデータの返却、クラウド解約時の移行支援も確認します。
安い一式見積もりより、前提と除外条件が明確な見積もりの方が、発注後の予算管理に向いています。
既存資産を生かし、段階導入と標準化を組み合わせます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
費用を抑えやすいのは、既存の名簿・配当基盤を残し、先に発行会社ポータルや帳票照会を刷新する方法です。
業務コアを置き換える場合でも、株主情報、権利処理、配当、総会、分析をすべて一度に作らず、業務影響とデータ移行の難易度で段階を分けます。
最初のフェーズでAPI、認証、監査ログ、データ照合の共通基盤を作ると、後続機能の追加費用を抑えやすくなります。
一方、標準機能に合わせられる業務まで個別開発すると、初期費用だけでなく制度改正時の保守費も増えます。
帳票の完全な個別レイアウト、発行会社ごとの例外画面、固有コードの乱立は、将来の移行やテストを難しくします。
Must、Should、将来検討に分け、競争力や法令対応に直結しない機能は設定・運用変更・第2期に回すと、品質を保ちながら投資を平準化できます。
開発会社は金融実績ではなく証券代行への適用力で比較します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
開発会社を選ぶときは、「金融機関の実績がある」という説明だけで決めません。
総株主通知の受信・再処理、名簿確定、配当・未払配当、議決権、株主総会、電子提供、移行照合、制度改正に関する実績を。業務責任者やプロジェクトマネージャーが説明できるかを確認します。
証券代行固有の実績がない会社でも、証券・信託・金融基幹の実績をどこまで転用できるか、業務有識者をどの体制で置くかが判断材料になります。
証券代行主要業務の開発実績を公開するHIMACSは、名義書換、株主名簿の確定。剰余金の配当などのシステム開発実績を紹介しています（出典: 株式会社HIMACS「信託銀行向け証券代行システム」）。
候補会社には、証券代行の完成品があるかだけでなく、再処理の設計、データ移行時の照合、障害時の責任分界、再委託、監査資料の提出範囲を同じ質問票で確認します。
よくある質問（FAQ）
証券代行システムの費用は、公開された定価だけでは判断しにくい分野です。最後に、発注担当者からよく寄せられる費用・方式・期間に関する質問へ、
前提を分けて回答します。
証券代行システムの開発費用は最低いくらですか？
既存の名簿・配当基盤を残し、発行会社向けの照会や事務指示ポータルだけを追加するなら、
500万〜2,000万円程度が初期費用の目安です。株主情報の確定、配当計算、総株主通知、
移行、監査、災害復旧まで新規に作る場合は、最低価格だけを基準にせず、1,500万円以上から対象範囲に応じて予算を置くことが現実的です。
パッケージとスクラッチ開発はどちらが安いですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
標準的な株主管理、配当、帳票、権限を業務に合わせられるなら、パッケージやクラウドの方が初期費用と期間を抑えやすいです。
ただし、固有の権利処理、複数の発行会社、既存基幹との複雑な連携、全履歴移行をアドオンで重ねると、スクラッチとの差が小さくなることがあります。
初期費用、5年TCO、制度改正時の追加費用、データ取り出しや移行のしやすさを一緒に比較します。
証券代行システムの開発期間はどのくらいですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
ポータル中心なら3〜6か月、パッケージの標準導入なら4〜9か月、個別アドオン・複数連携・移行を含む場合は9〜18か月。大規模な基幹刷新なら18〜36か月以上が目安です。
期間には、要件定義、総株主通知や配当の先行検証、移行リハーサル、制度シナリオテスト、旧新照合、本番切替を含めて考えます。
株主総会や配当の繁忙期に合わせる必要がある場合は、開発完了日ではなく安全に切り替えられる業務カレンダーから逆算します。
クラウドで構築するとセキュリティ費用を抑えられますか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
クラウドは、サーバーを自社で保有する初期投資や一部の運用負荷を平準化しやすい一方、利用料、監視、バックアップ、データ転送、冗長化、セキュリティ診断。委託先管理が継続します。
金融系の業務では、クラウドを使うこと自体で要件がなくなるわけではありません。FISCの対象項目、データ所在、アクセス管理、復旧目標、障害時の責任分界をRFPに落とし、5年TCOで判断します。
まとめ
費用相場で押さえるべき結論
費用の比較では、ポータル、標準導入、個別アドオン、基幹刷新を同じ案件として扱わないことが大切です。
見積書に含まれる対象範囲と対象外を明確にし、初期費用・運用費・制度改正費・移行費を5年TCOとして並べると、
予算の妥当性を判断しやすくなります。
発注前に整理する項目
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
まず、株主数・発行会社数・対象期間・外部連携・権利イベント・帳票・移行範囲・RTO/RPOを整理し、業務シナリオと受入条件を作成します。
そのうえで、証券代行実務を理解する開発会社へ同じRFPを提示し、総株主通知、配当、議決権、訂正・再処理、監査証跡をどのように実装・試験するかを比較します。
証券代行システムの初期費用は、発行会社向けポータルなら500万〜2,000万円、パッケージ・クラウドの標準導入なら1,500万〜5,000万円。
アドオンと複数連携を含むなら5,000万〜1億5,000万円、大規模な証券代行基幹の刷新なら1億5,000万〜5億円超が目安です。
これらは証券代行固有の公表統計ではなく、一般的な業務システム相場と、金融業務に必要な連携・移行・監査・可用性の工数から算出した推定レンジです。費用を左右するのは、画面数だけではありません。
株主数、発行会社数、総株主通知、株式異動、配当・未払配当、議決権、株主総会、電子提供、帳票、外部連携、データ移行、RTO・RPO、監査証跡。制度改正対応をどこまで含めるかで変わります。
要件定義で業務シナリオと対象データを定義し、RFPでは標準・設定・アドオン・個別開発・移行・試験・運用の境界を明らかにします。
最適化の基本は、品質や統制を削ることではなく、既存資産を生かしながら段階導入し、将来の制度改正や追加業務に耐えられる共通基盤を作ることです。
候補会社には証券代行実務への適用力、移行照合、再処理、障害復旧、監査・委託先管理の体制を確認し、初期費用ではなく5年TCOと業務上の成果で比較します。
参考情報: 信託協会「証券代行業務」、金融情報システムセンター「安全対策基準・解説書 第14版」、HIMACS「信託銀行向け証券代行システム」。
SIA「システム開発の費用・相場（2026年版）」を参照しています。
▼全体ガイドの記事
・証券代行システム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。