信託業務システムの発注は、業務の整理、提案の比較、契約、移行、運用の順に進めます。この順で進めることで、監査証跡を備えた業務基盤につながります。
発注形態の選び方を見たうえで、RFPと要件整理、契約を順に確認します。費用相場、委託先の選定、稼働後の進め方も続けて取り上げます。
▼全体ガイドの記事
・信託業務システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
信託業務システムの発注・外注の進め方
信託業務システムの外注では、企画から運用まで、判断を一段ずつ積み上げていきます。発注条件は、機能の一覧に加えて、業務結果の確定や証跡の残し方まで決めて初めてそろいます。機能一覧だけを開発会社へ渡すと、発注条件が不足します。
- 企画と刷新目的を定める
- 業務・データ要件と非機能要件を整理する
- 提案を比較し、契約を結ぶ
- 開発、移行、運用を進める
「何を作るか」に加えて、誰がいつ業務結果を確定し、どの証跡を残すかを決めておきます。前提がそろわないまま見積もりを取ると、提案の差が何から生じたのか分からなくなります。
発注側は、契約条件や決済、帳票、監査証跡、障害復旧も、業務基盤の一部として扱います。
一般的な会計システムとの違い
信託業務システムは、委託者から受託した資産を、契約条件に沿って管理・運用するための基盤です。受益者への報告や会計処理まで、正確に行う必要があります。
一般的な顧客管理や会計ソフトとの違いは、信託契約、受託資産、取引を一連で扱う点です。評価や分別管理、受託者責任、承認履歴も、同じ基盤で扱います。機能は、次の4つの領域に分けて整理できます。
- マスタ：委託者、受益者、契約条件の管理
- 資産台帳：国内外の有価証券、現預金、不動産、年金資産の管理
- 取引・計算：入出金、配当、利息、償還、信託会計、基準価額・単価
- 統制・連携：報告書、権限、操作ログ、外部機関との連携
画面の使いやすさだけで選ぶと、計算根拠や監査対応が抜けるおそれがあります。そのため、発注時には業務結果まで確認します。
発注前に決める目的と対象範囲
信託業務システムの刷新では、まず解消したい業務課題をはっきりさせ、それに合わせて目的を定めます。目的があいまいなままだと、優先する機能を決められません。
- 保守期限：旧システムの保守期限に対応する
- 転記削減：紙やExcelの転記を減らす
- 一元管理：不動産信託の受益権・物件・賃料をまとめる
- 改修負担：制度改正時の改修負担を抑える
目的によって、優先する機能や許容できる業務変更、稼働時期、投資対効果の測り方が変わります。また、中核会計まで含めるか、周辺業務に絞るかも、早い段階で決めておきます。
全体を一度に刷新する場合も、段階稼働に分けることができます。たとえば、第一段階で契約・台帳・照会、第二段階で会計・決済、第三段階で分析や顧客向け報告を稼働させると、リスクを抑えやすくなります。
信託業務システムの発注形態の選び方
発注形態は、パッケージ、金融向けクラウド・ASP、スクラッチ、ハイブリッドに整理できます。業務特性と投資方針を踏まえて選ぶため、信託の中核計算を独自開発するか、標準機能に業務を合わせるかを、早い段階で比べておきます。
各方式の適合性は企業ごとに異なります。そのため、方式ごとに向いているケースを続けて見ていきます。
パッケージ導入が向いているケース
業界共通の業務を早く安定して稼働させたい場合は、パッケージが候補になります。信託会計、契約管理、帳票、資産台帳などが該当します。
既存製品には、制度対応や監査機能、信託特有の用語・業務フローが含まれている場合があります。ゼロから作るより要件漏れを抑えやすい点が、パッケージの利点です。
一方で、標準機能に合わない業務をアドオンで増やすと、初期費用に加えて、更新や制度改正のたびに検証費用も膨らみます。そこで、Fit＆Gapで業務ごとの対応方法を分けます。
- 標準設定：製品の機能で対応する
- 業務変更：業務を変えて標準機能に合わせる
- 追加開発：標準機能にない要件を開発する
- 対象外：今回の導入範囲から外す
対応方法ごとに、アドオンの総額と5年分の保守への影響まで確認します。費用だけでなく、更新時の検証負担も判断材料になります。
クラウド・ASPが向いているケース
新規参入や小規模な業務開始では、クラウド・ASPが候補になります。初期投資を抑えて、一定水準の機能を使いたい場合に適しています。
サーバーや一部の運用監視を自社で抱えずに済む可能性があります。利用開始までの期間を短くできる場合もあります。
RFPの段階では、機密データの保管場所、バックアップと復元の担当、障害時の切替時間を具体的に確かめます。
- 保護と権限：所在地、暗号化、MFA、特権ID管理
- 運用記録：ログ保全と再委託先の管理
- 終了時：データ返却、移行支援、SLA
スクラッチとハイブリッドを選ぶ判断基準
標準機能で競争力や業務品質を出せない場合は、独自機能の範囲を見極めたうえで、スクラッチを検討します。
- 商品設計：独自の商品や高度な収益配分
- 資産評価：特殊な資産評価
- 既存連携：複雑なシステム連携
独自性が必要な範囲と、信託会計や共通帳票のように標準化しやすい範囲を分けて考えます。すべてを独自開発する必要はありません。
中核の信託会計や基準価額は、パッケージまたは共同利用型サービスで持つ構成が考えられます。一方で、独自ワークフロー、顧客ポータル、分析画面、社内申請は、APIやファイル連携を使って周辺で開発できます。
TrustPORTは信託会計と事務管理の連動構成を公開しています（出典：BIPROGY株式会社「信託業務管理システム TrustPORT」、2026年確認）。同製品は、パッケージ販売とASP提供も公開しています。構成を比べるときの参考になります。
RFPと要件整理の準備範囲
RFPは、各社が同じ前提で提案と見積もりを行うための発注条件書です。希望する機能だけでなく、比較に必要な前提もそろえておきます。
自社だけで完璧な仕様書を作る必要はありません。対象業務やデータ、連携を準備しておくと、比較しやすくなります。さらに、非機能、移行、成果物、提案条件も用意します。
RFPに含める業務・データ・帳票
業務要件は、信託業務の流れに沿って整理します。商品ごとの違いや、日次・月次・決算の締め時間、担当者と承認者、再鑑の要否も記載します。
- 受付・管理：契約受付、委託者・受益者管理
- 資産・取引：資産登録・異動、取引・決済
- 計算・報告：配当、利息、償還、評価、会計、決算、報告書
- 例外・運用：問い合わせ、権限変更、訂正・取消
データ要件には、契約IDや委託者、受益者、資産を含めます。銘柄や残高、簿価、時価、評価差額も、項目として必要です。取引・入出金の記録や、帳票、操作履歴も洗い出します。
保存期間、訂正前後の値、基準日を決めます。タイムゾーン、データの正本、外部データの受領責任も、あわせて定めます。
帳票はサンプルを添付し、計算結果だけでなく、明細から集計値をたどれることを検収条件にします。
非機能要件と金融向け統制の数値化
非機能要件は、数値や手順まで具体的に書きます。「高可用性」や「金融機関水準」といった表現のままでは、各社の提案を同じ基準で比べられません。
- 性能・稼働：稼働時間、同時利用者数、処理完了時刻、応答時間、可用性
- 復旧：RTO（目標復旧時間）、RPO（目標復旧時点）、バックアップ世代、復元テスト
- 運用：監視、脆弱性対応、処理件数、許容停止時間、復旧手順、テスト頻度
認証では、MFAや特権IDの申請・承認、職務分掌を定めます。ログについては、改ざん防止と保存期間も決めます。
データ暗号化も要件に含めます。さらに、開発・検証・本番の分離と、委託先・再委託先のアクセス範囲も定義します。
FISCの安全対策基準・解説書は第13版が2025年3月に発行されており、サイバーセキュリティ、オペレーショナル・レジリエンス、AIの安全対策などを反映しています（出典：公益財団法人金融情報システムセンター、2025年3月）。
RFPでは「FISC準拠」の一言で済ませず、該当項目と実装方法を書きます。そのうえで、証跡、検査方法、責任分界まで分解します。
移行・テスト・検収条件の事前整理
信託案件では、旧システムのデータをそのまま取り込めるとは限りません。データ移行と旧新突合が本番稼働を左右するため、RFPに移行条件と一致条件を記載します。
- 移行範囲：対象期間、データ、欠損・重複・不整合の扱い、コード変換
- 切替計画：リハーサル回数、並行稼働期間
- 一致条件：旧システムとの残高、帳票、仕訳
テストでは、正常系に加えて、代表的な商品や資産、期末と休日、外部データの遅延や重複受信も対象にします。
取消・訂正や権限外の操作を試します。通信断やバックアップ復元、障害復旧後の再処理も対象です。
合格の基準には、計算結果と残高、帳票を含めます。ログや復旧時間も、基準に入れます。
受入では、担当者が使えることに加えて、業務結果が正しいことを確かめます。
基準に届かなかった場合の是正方法と追加費用の扱いは、契約前に合意しておきます。
信託業務システムの契約形態の使い分け
契約は、要件の確定度と成果物に応じて、工程ごとに使い分けます。
全工程を固定価格の請負にする場合は注意が必要です。要件が曖昧なままだと、変更時の追加費用や責任分界が不明確になりやすくなります。
反対に、すべてを準委任にすると、成果物と完了条件が曖昧になりがちです。
請負契約を使う工程と確認事項
成果物の完成を求める工程では、請負契約が候補になります。その前提として、要件、仕様、成果物、検収条件が確定している必要があります。
- 開発物：確定済みの画面、帳票、API、バッチ
- 構築物：環境構築、パッケージ設定
- 契約条件：成果物一覧、品質基準、検収期間
- 責任・権利：契約不適合、納期、変更手続、再委託、知的財産、秘密保持、損害賠償
納品をもって完了とせず、計算結果の正確性や性能、セキュリティも検収の対象にします。ログやバックアップ、移行結果も含めます。
画面が動いていても、残高や帳票が合わなければ業務には使えません。そのため、受入条件は業務結果で定めます。
準委任契約を使う工程と確認事項
専門家の作業や助言を委託する工程では、準委任契約が候補になります。その際は、対象業務と、契約時に定める事項を整理しておきます。
- 要件整理：現状分析、業務要件整理、Fit＆Gap
- 導入支援：プロジェクト管理、移行計画、テスト支援
- 運用改善：運用改善に関する専門家の作業や助言
- 契約条件：月次の稼働範囲、担当者、会議体、成果物、報告方法、意思決定者
初期フェーズは仕様が変わりやすいため、作業内容と発注者の判断範囲を共有します。
「情報システム・モデル取引・契約書（アジャイル開発版）」は、成果物の完成ではなく、専門家としての業務遂行に対価を払う準委任を前提としています（出典：独立行政法人情報処理推進機構）。同モデル契約の最終更新は2025年4月です。
信託業務でも、発注者と受託者の役割、指揮命令関係、成果物の扱いを整理してから契約します。
変更管理と責任分界の契約書への反映
追加費用につながりやすい変更や問題を先に把握し、変更管理と責任分界を契約に反映します。
- 追加費用の要因：要件・外部連携の変更、移行データの品質問題、制度改正、テスト環境の追加、稼働延期
- 変更手続：影響機能、工数、納期、テスト、費用、セキュリティ審査を変更票に記載する
- 責任分界：クラウド、アプリ、データ、ネットワーク、認証、監視、障害一次対応、制度対応、帳票の正確性を割り当てる
- 契約前の確認：再委託先の管理、本番アクセス、データ持ち出し、退職者ID削除、データ返却、消去証明
変更要求は、承認者の決裁を経てから着手します。
契約前にこれらの点を確かめておくと、運用開始後の不一致を減らせます。
信託業務システムの費用相場と5年TCO
信託業務システム単体の公開見積もり統計は限られています。そのため、ここでは一般的な業務システムの公開相場に、信託特有の計算・監査・移行・金融向け非機能を加味したモデルケースとして示します。
小規模は300万〜3,000万円、中規模は3,000万〜1億円、大規模は1億〜数十億円以上が一つの目安です。金額は、対象資産や取引量、商品数で大きく変わります。連携数、SLA、移行範囲も、金額を大きく動かす要素です。
規模別の初期費用と期間の目安
照会機能中心の導入から全社刷新まで、対象範囲に応じて初期費用と期間の幅が広がります。特に大規模刷新では、初期費用を1億〜数十億円以上と見込みます。
- 小規模：照会、帳票、一部ワークフロー、補助ツール。300万〜3,000万円、1〜3か月程度
- 中規模：信託会計周辺、権限管理、複数連携、部署横断ワークフロー。3,000万〜1億円、3〜6か月程度
- 大規模：受託資産台帳、基準価額、決済、複数商品、法定帳票、旧システム移行、全社連携。1億〜数十億円以上、10か月〜2年以上
移行、並行稼働、受入テストを含めると、中規模でも6か月を超える場合があります。
SIA株式会社の一般的な開発目安は、小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円〜数千万円以上です。同社は、人月単価を60万〜200万円程度としています（出典：SIA株式会社「システム開発の費用・相場【2026年版】」、2026年7月）。
信託案件では、一般相場に金融水準のテストや監査、移行、制度対応を上乗せして考えます。
見積もりに含める費用の内訳
初期費用は、工程と役割ごとに分けて確認します。各社で費目の区切り方が異なるため、比率だけで優劣を決めないようにします。
- 企画・要件定義：全体費用の10〜20%程度
- 設計・実装：40〜50%程度
- テスト：15〜25%程度
- PM・品質管理：10〜15%程度
- インフラ・移行・教育：インフラは5〜15%、移行・教育は5〜10%程度
見積もりには、企画・設計・実装のほか、インフラやセキュリティを含めます。PMや品質管理、移行、教育、稼働立ち会いも、見積もりに入れておきます。
ランニング費用には、ライセンス費や利用料がかかります。クラウドやデータセンターの費用も、継続して発生します。監視、ヘルプデスク、バックアップも含めて見ておきます。
脆弱性診断や保守、制度改正、追加開発、教育、監査対応も、費用として確認します。一般的な受託開発では、保守の目安として新規開発費の年15〜25%という例があります。
この割合は、信託向けの実費を示すものではありません。そのため、通常保守と制度改正、障害対応、性能改善、追加要件の境界を契約前に確かめます。
初期費用と5年TCOによる比較
パッケージとスクラッチは、初期費用だけでなく5年TCOで比べます。同じ期間の費用と運用負担を並べて見ます。
- 導入：ライセンス、アドオン、データ移行、テスト、教育
- 継続：月額利用料、保守、制度改正、バージョンアップ
- 運用：追加監査対応、担当者の運用工数
初期費用が安くても、アドオンが増えて更新のたびに再テストが必要になれば、長期の負担は大きくなる可能性があります。
信託向けのモデル試算では、スクラッチの初期費用は3,500万〜6,000万円、5年TCOは5,250万〜9,000万円です。標準中心のパッケージは、アドオン100万〜500万円程度で、5年TCOは4,800万〜8,400万円という推定レンジです。
この試算は公開統計ではなく、信託固有の専門性や保守を加味したモデルです。自社の取引量、移行件数、担当者数、SLAを当てはめて、TCO表を作ります。
モデルケースは確定価格として扱わず、自社の条件に置き換えて比べます。
委託先の選定と見積比較の確認事項
委託先は、知名度や見積総額だけでなく、信託業務の理解や類似案件の経験をもとに選びます。移行・テストの実績、金融向けセキュリティ、保守、発注者の支援力も確認します。
信託会計、投資信託バックオフィス、資産運用DWH、金融インフラ、発注者側PMOでは、会社ごとに得意な領域が異なります。
信託・資産運用の実務経験の確認
提案会社には、過去案件でどの業務範囲を担当したかを聞きます。「金融実績がある」だけでなく、実務で扱った領域まで確認します。
- 信託業務：契約、受託資産台帳、信託会計
- 資産・商品：基準価額、金銭債権、不動産、年金
- 周辺業務：決済、カストディアン連携
差し支えない範囲で、稼働年数やデータ移行件数、並行稼働期間も聞いておきます。あわせて、障害や制度改正への対応と、現在の保守体制も確認します。
BIPROGYは、TrustPORTで信託会計、契約管理、信託財産管理、金銭債権信託、不動産信託などの領域を示しています。
NRIは、投資信託の信託財産管理や基準価額算出を含むバックオフィス向けのT-STAR/TXを公開しています（出典：BIPROGY株式会社、野村総合研究所、いずれも2026年確認）。
候補は、社名の知名度ではなく、自社の対象業務との適合性で比べます。
見積書の同条件での比較
相見積もりでは、各社に同じRFPを渡します。あわせて、業務フローやデータ件数、帳票サンプル、連携仕様、非機能要件も共通で示します。
見積もりが安く見えるときは、まず含まれていない作業を確かめます。
- 見積内訳：要件定義、ライセンス、設定、アドオン、移行、テスト、教育、稼働支援、保守、制度改正、クラウド、監査対応
- 別料金の確認：データクレンジング、移行リハーサル、性能試験、脆弱性診断、受入テスト支援、並行稼働
- 運用関連：休日対応、運用手順書、教育、バックアップ復元試験
価格差は、単価だけでなく、対象範囲や想定工数、再委託、品質保証、保守期間の違いから生じることが多くあります。そのため、差分表を作って評価します。
委託先への質問と評価軸の統一
評価は、価格だけでなく、業務適合性や要件理解、体制で行います。移行・テスト、セキュリティ、保守、拡張性、意思決定の方法も、評価の対象に入れます。
配点の例は、業務適合性25点、移行・品質20点、体制・実績20点です。セキュリティ・運用15点、費用15点、提案の分かりやすさ5点も、例として挙げられます。
価格の比重を下げると、極端な低価格に引っ張られにくくなります。配点は、自社の重視事項に合わせて決めます。
- 実績：類似案件の範囲と移行リハーサル方法
- 品質：残高・帳票の突合基準、制度改正への対応時間
- 運用：障害一次対応、復旧目標、再委託先の管理
- 終了・継続：データ返却、担当交代時の引き継ぎ
回答が抽象的な会社については、提案書の見栄えにかかわらず、実行計画の深さを慎重に確かめます。
発注後の開発・移行・運用の進め方
発注後も、業務・IT・データ・セキュリティの各責任者と業務承認者は、発注者側に置いておきます。業務ルールや受入の判断、リスクの受容は、発注者が決めます。
委託先に任せる範囲が広くても、判断まで任せきると、完成後に想定とのずれが生じやすくなります。
移行リハーサルと並行稼働の工程計画
旧システムから抽出したデータは、そのまま取り込めるとは限りません。そのため、対応表や品質確認、複数回のリハーサルを計画に含めます。
- 対応表：顧客、契約、資産、銘柄、勘定科目、取引コードを対応させる
- 品質確認：欠損、重複、桁あふれ、日付形式、過去訂正、未決済取引を調べる
- リハーサル：複数回の実施を工程と予算に含める
本番直前には、移行の実行時間や外部連携の停止・再開を確かめます。さらに、担当者の承認、残高突合、帳票確認、障害時の切り戻しも、あわせて確認します。
重要業務は、一定期間、新旧を並行稼働させます。そのうえで、日次・月次・決算の結果が一致するかを確かめます。
並行稼働の期間は、短いほど安全とは限りません。締め処理や例外処理を検証できる長さを確保します。
障害復旧と制度改正の運用への組み込み
稼働後の運用では、復旧の準備と日常的な統制を定常業務として位置づけます。
- 復旧準備：バックアップ、復元、遠隔地DR、障害連絡、インシデント対応
- 日常統制：監視、権限の見直し、脆弱性対応、ログ確認、運用教育
金融庁は、金融分野のサイバーセキュリティ対策の情報を公開しており、2025年7月にはガイドラインの技術的修正も公表しています（出典：金融庁「金融分野におけるサイバーセキュリティ対策について」、2025年7月）。
攻撃の防止に加えて、検知や封じ込め、復旧、復旧後の残高・帳票突合まで、要件定義の段階で決めておきます。
制度改正は、発生してから相談するのではなく、影響調査から仕様変更、テストデータ作成、受入、リリース、マニュアル更新までの流れを保守契約に含めます。
定例会やロードマップ、更新方針、緊急修正の優先順位を合意します。知識が特定の担当者に偏らないよう、設計書と運用手順も更新します。
外注後も発注者が持つべきガバナンス
外注しても、業務責任は発注者に残ります。受託者責任や顧客・受益者への報告、当局・監査への説明、最終的なリスクの受容も、発注者が担います。
- 月次確認：障害、未解決課題、変更要求、アクセス権、バックアップ結果、SLA、制度改正、再委託先変更
- 移行可能性：データ形式、API仕様、帳票定義、移行手順、テストデータ、運用手順を成果物に含める
- 契約終了への備え：ソースコード・設定情報の利用権、終了時の支援を定める
すべてを自社で保有する必要はありません。ただし、移行に必要な情報がそろっていないと、将来の見積もり比較が難しくなります。
よくある質問
信託業務システムの発注・外注でよくある質問に答えます。費用や発注者の準備、パッケージとスクラッチの選び方を、質問ごとに確認できます。
信託業務システムのRFPは自社だけで作成できますか？
自社で作成できます。業務、IT、セキュリティ、監査の各部門が、共同で作る前提で進めます。
業務フロー、帳票、データ項目、現行の課題は、自社で整理できます。一方で、非機能、移行、契約、相見積もりの設計は、第三者に支援を頼む方法もあります。
信託業務システムは数百万円で発注できますか？
照会画面、帳票、一部ワークフローに絞れば、数百万円から始められる場合があります。
信託会計、受託資産台帳、外部連携、移行、金融水準のセキュリティ、監査証跡を含めると、数千万円から億単位になることもあります。
見積もりを取るときは、対象範囲やデータ件数、連携数、テスト、保守を明示します。
信託業務システムはパッケージとスクラッチのどちらが安全ですか？
安全性は、方式だけで決まるものではありません。パッケージは共通機能や制度対応を使いやすく、スクラッチは独自要件に合わせやすいという特徴があります。
どちらの方式でも、権限、ログ、暗号化は要件として定めます。バックアップと復旧、テストと保守体制も、要件に含めます。中核はパッケージにして、独自性の高い周辺を個別開発する方法もあります。
まとめ
信託業務システムの発注では、機能一覧と初期費用だけで判断せず、業務の全体像を押さえたうえで比べます。まず、信託契約、受託資産、取引・決済、評価、信託会計を整理します。
発注者は、帳票や承認、監査証跡、外部連携、移行対象も、業務フローとデータで洗い出します。
発注前に整理するポイント
発注前には、パッケージ、クラウド・ASP、スクラッチ、ハイブリッドを比べておきます。RFPには、非機能要件やFISCと金融庁の考え方、RTO・RPOを記載します。
バックアップや復元、移行リハーサル、検収条件も定めておきます。そのうえで、要件定義やPMOは準委任、確定仕様の開発・構築は請負として、工程ごとに契約と責任分界を設計します。
委託先選定と稼働後の要点
委託先は、費用と実務対応の両面で確認します。
- 5年TCO：移行、テスト、教育、保守、制度改正、クラウド、監査対応を含めて比べる
- 実務経験：信託・資産運用と、稼働後の復旧・制度対応を確認する
- 発注者の責任：業務責任と受入判断を持ち続け、長期利用につなげる
▼全体ガイドの記事
・信託業務システム開発の完全ガイド
▼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を創業。