保証管理システムの発注・外注は、業務整理、RFP作成、候補比較、契約、移行・テストの順に進めます。この順で進めると、受付から回収まで一貫して管理できるシステムを発注しやすくなります。
▼全体ガイドの記事
・保証管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
保証管理システムの発注前に押さえる全体像
保証管理システムは、保証依頼の受付だけでなく、保証契約の状態と融資残高を継続して管理します。事故後の代位弁済や求償債権の回収・償却、自己査定、引当金計算まで履歴を残す、基幹業務システムです。
発注前に対象範囲を決めないまま機能一覧だけで比べると、重要な業務が別のシステムやExcelに残るおそれがあります。
保証受付から回収までの業務ライフサイクル
保証管理の対象イベントを並べ、それぞれについて入力者や承認者、後続処理まで確認します。これにより、受付から完済までの業務の抜けを把握できます。
- 受付・契約：保証受付、審査結果、保証承諾、保証番号の採番
- 融資・返済：保証料計算と入金消込、融資実行、返済、条件変更、延滞
- 事故・回収：事故受付、代位弁済請求、求償債権の発生、督促、回収、償却、売却、完済
各イベントについて、参照情報や会計仕訳、外部報告を洗い出します。入力者や承認者、後続処理も、あわせて整理します。
代位弁済だけを画面にしても、計上や求償債権残高、回収予定、担保情報、自己査定がつながらなければ、二重入力は残ります。
日本電子計算は、JIP-RBについて個人融資業務に沿って保証料管理や返戻保証料を支援すると説明しています。求償債権の残高、回収、償却も、対象に含まれます。売却や自己査定まで含めて説明されています（出典：日本電子計算「ローン業務支援システム JIP-RBシリーズ」、2026年確認）。
業務範囲をもとに必要な機能と不要な機能を分けると、RFPの抜け漏れを抑えられます。
発注形態の比較：パッケージ・クラウド・スクラッチ
発注形態を比べるときは、標準機能と独自要件の境目を確認します。設定で吸収できる差異と、追加開発が必要な差異を分けておきます。
- パッケージ：実績ある製品を設定して導入
- クラウド等：クラウドやプラットフォームを利用
- 組み合わせ：既存パッケージに周辺開発を追加
- スクラッチ：独自システムを新規開発
保証料率や保証番号体系の違いは設定で対応し、独自の審査や例外処理だけを開発します。そうすれば、制度改定のたびに中核を作り直すリスクを減らせます。
クラウドやプラットフォームでは、月額費用に加えて、データ所在地、再委託先、権限管理、操作ログ、バックアップを確認します。さらに、障害時の復旧目標や契約終了時のデータ返却も、発注条件に含めます。
NTTデータのLDPfでは、2023年10月23日からSMBCコンシューマーファイナンスがローンWeb受付システムを利用開始した事例が公開されています（出典：NTTデータ「LDPf 保証会社 メリット／事例」、2023年）。
電子受付や審査依頼の電送化を含む場合は、金融機関と保証会社の接続方式も、発注の範囲に入れます。
保証管理システムの発注・外注の進め方
発注は、現状調査から本番切替まで、5つの段階で順に進めます。発注者は業務判断と優先順位を持ち、ベンダーには技術設計と実装を委託します。
- 現状調査を行い、業務とデータを整理する
- RFPを作成し、候補会社に説明する
- 提案と見積を比較し、契約する
- 要件定義、設計、開発を進める
- 移行とテストを行い、並行稼働を経て本番切替する
発注者の体制と委託範囲
体制には、業務、システム、経理、回収、監査、経営企画の責任者を置きます。たとえば、審査担当だけでは回収や自己査定が抜けやすく、システム部門だけでは現場の例外や承認権限を見落とすことがあります。
- 業務判断：プロダクトオーナーがルールを確定
- 計画管理：プロジェクト責任者が全体計画を管理
- 移行・受入：担当責任者がデータ移行と受入テストを担う
外注範囲は、要件定義のみ、パッケージ導入支援、周辺連携開発、運用保守までの一括委託などから選びます。
業務整理が不十分なら、現状調査や要件定義を先行発注し、その成果物をもとに本開発を競争させる方法があります。一方で、業務判断を保留したまま一括請負にすると、変更要求が積み上がり、予算と納期が不安定になります。
RFPに書く成果物と判断基準
提案会社が同じ前提で見積もれるよう、RFPには業務範囲と非機能要件を記載します。また、業務イベントは、保証受付から完済までを対象にします。
- 業務・機能：画面、帳票、バッチ、外部連携、移行対象
- 規模条件：保証商品数、利用者数、拠点数、月間受付件数、保有債権件数
- 運用条件：ピーク時間、保存年数、現行データ形式、権限、ログ、性能、復旧
提案書には、業務フロー、機能一覧、画面・帳票一覧を含めるよう指定します。加えて、I/F一覧、移行方針、テスト計画も盛り込みます。
さらに、体制表、工程表、費用内訳も揃えてもらいます。前提条件と除外事項、リスク一覧、保守条件も、同じ提案書のなかで示すよう求めます。
成果物がそろっていれば、移行を別料金にした安い提案と、総合テストまで含む提案の違いを見比べられます。
Fit & Gapによる標準利用・設定・追加開発・業務変更の分類
パッケージのデモは、画面の使いやすさだけでなく、例外を含む実際の業務シナリオで見ます。
- 保証・返済：保証料率変更、返戻保証料、条件変更、延滞段階管理
- 事故・債権：代位弁済の取消・訂正、求償債権の分割入金、償却
- 決算：担保評価、月次締め、決算処理
各要件は、標準機能か設定で対応できるかを確かめ、追加開発、業務運用変更、対象外のいずれかに分けます。
法定帳票、会計連携、残高の正確性は、初期リリースに含めます。監査証跡と切替に必須の移行は、初期リリースに入れます。
分析ダッシュボードや高度な自動化は、運用開始後に評価する方法もあります。ただし、後回しにした業務をExcelで続けるなら、担当者と期限を決め、二重管理の有無をRFPと契約書に書いておきます。
保証管理システムの要件整理とRFPの作り方
RFPは、発注者の希望を伝える資料であると同時に、業務の曖昧さを見つける設計図でもあります。
保証商品や審査から、融資実行後の管理、事故・代位弁済へと順に整理します。求償・回収から監査まで、この流れに沿って書き出します。特に、例外時の承認者と履歴を明記しておくと、一般的な業務システムのRFPとの差が出ます。
業務部門と定める保証商品と例外処理
まず、保証商品ごとの条件と、通常処理から外れるシナリオを定義しておきます。条件をそろえておけば、商品別の要件を比べやすくなります。
- 商品条件：対象債務、保証料率、料率変更日、返戻条件、保証期間
- 限度・属性：保証限度額、担保の有無、債務者区分
- 例外シナリオ：差戻し、条件変更、融資前取消、返済額不一致、二重入金、延滞解消
- 事故後処理：一部代位弁済、回収額訂正、債権譲渡、償却後入金
各シナリオには、開始条件と入力項目、計算ルールを付けます。承認者と帳票、会計処理も、そのシナリオに合わせて決めておきます。さらに、外部連携、ログ、エラー時の再処理も記しておきます。
入金消込では、全額入金と一部入金を分けて確認します。加えて、複数債権への充当、手数料差引、返金、組戻しも確かめます。具体化しておけば、デモや受入テストで想定どおりに動くかを判定できます。
外部I/F・権限・監査要件の見積条件
接続先ごとの方式と責任は、I/F一覧にまとめます。連携先が多い案件ほど、異常系テストと運用監視の作業も増えます。
- 主な接続先：勘定系、融資、審査、経理、信用情報機関、電子受付・契約、回収・サービサー
- 連携仕様：APIかファイルか、リアルタイムか日次バッチか、項目の正本
- 障害対応：エラー時の再送・照合の担当者
金融情報を扱うため、職務分掌、特権ID、承認権限を定めます。閲覧範囲、操作履歴、変更前後の値も決めておきます。
ログの保存期間や暗号化は、RFPに含めます。バックアップと復旧手順も、同じRFPに書き込みます。
FISCの「金融機関等コンピュータシステムの安全対策基準・解説書」は、2025年3月に第13版が発行されました。同書は、金融情報システムの開発・導入・運用に必要と考えられる安全対策を示しています（出典：金融情報システムセンター「安全対策基準・解説書 第13版」、2025年）。
適用の範囲は事業者や委託形態によって異なりますが、ベンダーへの確認項目として使えます。
RFP初期から扱うデータ移行と受入テスト
移行データは分けて調査し、難しい箇所と保管方針を決めておきます。過去分を新システムに入れるか、参照用のアーカイブに残すかも、あわせて検討します。
- 移行対象：保証番号、契約、顧客、融資残高、保証料、入出金
- 債権関連：延滞、代位弁済、求償債権、回収履歴、担保、査定、償却履歴
- 確認事項：項目欠損、コード差異、名寄せ、日付形式、残高合計、訂正履歴
テストには、結合と総合、性能を含めます。障害復旧と権限、ユーザー受入も、テストの対象に入れます。
移行は、テスト移行から始め、差分確認とドライランを経て、本番切替に進みます。
発注前に工程と判定基準を決めておくと、納品直前の残高不一致や帳票不備による手戻りを抑えられます。
保証管理システムの契約形態の選び方
契約形態は、要件の確定度と変更の頻度を見て選びます。検収のしやすさや、発注者の管理能力も判断材料になります。
未確定の上流工程と、仕様が固まった開発工程を同じ条件にはしません。作業範囲と責任は工程ごとに分けて定め、検収の条件や変更の手続き、費用の計算方法も、同じ考え方で決めます。
要件定義の準委任と開発の請負の基本
要件定義と開発では確定度が異なるため、作業の性質に合わせて契約を選びます。
- 準委任：要件整理、調査、設計支援、プロジェクト管理などに適する
- 請負：仕様、成果物、納期、検収基準を確定できる開発や設定に適する
準委任では稼働条件だけでなく、納品物も定義します。納品物には、業務フロー、RFP、Fit & Gap表、要件定義書などを含めます。
保証料計算や代位弁済の例外処理が未確定のまま請負にすると、変更管理が頻発します。
パッケージ導入では、設定と追加開発、移行、テスト、教育ごとに成果物と検収条件を分けます。対象外の作業は、見積書に残しておきます。
要件定義・開発・保守を分ける段階契約
段階契約にすると、工程ごとの成果物を確認し、継続可否を判断できます。
- 現状調査・構想
- 要件定義・RFP支援
- パッケージ選定または基本設計
- 開発・設定・連携
- 移行・テスト・教育
- 保守運用
一社に一括で発注する場合も、工程ごとの成果物と継続判断の時点は設けておきます。各工程の終わりには、経営層が予算や納期、残課題、追加開発の要否を確かめられます。
工程を分けると、次の工程で複数社を比べやすくなります。現行調査だけを専門会社に依頼する方法も選べます。
担当の境界が増えるため、発注者は全体構成とデータの正本を管理します。I/F仕様と障害時の一次窓口も、発注者が受け持ちます。
契約に入れる制度改定・再委託・障害時の責任分界
契約では、制度対応の範囲と費用を明確にしておきます。改定時の連絡方法や、テスト環境の提供条件も確認します。
- 改定費用：標準機能は保守料内か、個社固有の変更は別見積か
- 情報共有：改定情報の通知時期、テスト環境の提供方法
- 委託・情報：再委託先の開示と承認、個人情報・信用情報の取扱い
- 障害・終了：連絡時間、復旧目標、データ返却・消去、出口戦略
ログやバックアップの保存、脆弱性対応、損害賠償の範囲も定めておきます。特に、制度対応の期限は業務の継続に直結するため、通常の機能追加と同じ扱いにしないことが大切です。
また、クラウドの停止や事業者の変更に備え、出口戦略も用意しておく必要があります。初期の見積に別料金や対象外の項目がないかも、あわせて確認します。
保証管理システムの費用相場とコスト内訳
保証管理システムは公開価格が少ない分野で、費用は商品数や利用者数、既存連携の有無によって変わります。移行量や監査・可用性の要件も、費用を左右します。
ここで示す金額は、金融・基幹業務の一般的な相場とリサーチノートをもとにした編集上の推定です。個別企業の正式な見積ではありません。
予算を組む際の初期の目安として使い、RFPで条件をそろえたうえで、改めて確認してください。
中規模案件の初期費用：1,500万〜8,000万円の推定目安
初期費用と導入期間は、規模や開発方式によって異なります。金額は推定の幅として比べます。
- 業務整理・PoC等：300万〜1,000万円程度
- 標準パッケージ導入：1,500万〜3,000万円程度
- 複数連携・移行あり：3,000万〜8,000万円程度
- 大規模刷新・スクラッチ併用：8,000万円〜2億円超の可能性
複数連携・移行の例には、母体行や審査、経理、信用情報との接続が含まれます。求償債権や自己査定の連携も、その例に入ります。
期間の目安は、要件定義・PoCが1〜3か月、標準導入が3〜6か月、複数連携が6〜12か月です。なお、大規模刷新は12〜24か月以上かかる場合があります。
2026年7月更新の相場情報では、人月単価は60万〜200万円程度です。単価はスキルや地域で異なります（出典：SIA「受託開発費の相場と9つの決定要素」、2026年）。
金融業務では、業務知識やテストの密度に加えて、セキュリティや制度対応も関わります。そのため、必要な人月と工程も確認します。
開発費だけでなく移行・連携・保守まで分解した見積
見積項目を分けると、初期費用と稼働後費用の抜けを見つけられます。
- 導入：要件定義、ライセンス・利用料、環境構築、設定、追加開発
- 稼働準備：外部I/F、データ移行、テスト、教育、切替支援、管理
- 運用：保守運用、クラウド利用料、追加開発や制度改定の費用
仮に、初期費用の配分を要件定義12％、設計・開発45％、テスト25％、移行・導入18％と置いてみます。5,000万円の案件であれば、各項目は順に600万円、2,250万円、1,250万円、900万円になります。
初期費用の配分は、抜け漏れを確かめるための仮置きで、契約上の標準ではありません。
データクレンジングや移行リハーサル、並行稼働は、見積に入っているかを確認します。初月の残高照合や監視、バックアップ、障害訓練は、見積の範囲に入るかを確かめます。
制度改定への対応も含めて、クラウド利用料や保守費は、月額・年額・従量課金に分けてもらいます。追加連携や帳票の追加、制度変更、時間外対応の単価も明記してもらいます。そうすると、導入後のTCO（総所有コスト）を比べやすくなります。
安い見積の対象外と前提条件の確認
見積額だけで順位を付けると、移行や総合テストが含まれない提案を選ぶおそれがあります。
- 比較条件：同じRFP、業務範囲、データ件数、連携本数、SLA、保守期間
- 役割分担：含むもの、含まないもの、発注者が用意するもの
- 差額の理由：工程省略、要員経験、再委託、ライセンス期間、追加費用
費用を調整するなら、対象商品の段階導入や不要帳票の廃止、二期開発を検討します。さらに、標準機能への業務寄せや移行範囲の見直しも、選択肢に入ります。
保証残高や事故履歴の正確性を削ると、監査や事故対応のコストが増える可能性があります。権限、ログ、バックアップ、障害復旧も、経営判断なしに省かないことが大切です。
保証管理システムの委託先選定と見積比較のポイント
委託先は、知名度や価格だけでなく、保証・求償業務と金融機関連携の実績で評価します。また、移行や制度改定、障害対応、保守の対応力も、評価の対象にします。
専用パッケージと、金融基盤・個人ローンの大型SIでは得意な範囲が異なります。そのため、提案依頼で聞く質問はそろえておきます。
専用パッケージと大型SIの役割の違い
専用製品は保証業務の標準範囲と制度対応を、大型SIは広い金融基盤との連携を中心に、候補を見ます。
- 日本電子計算：JIP-RBで保証料、保証債権、求償債権、自己査定を支援
- 日立システムズ：受付から保証債権、代位弁済後の求償債権を扱い、料率・番号体系を設定可能
- アイティフォー：保証・求償管理、入金消込、代弁事務、査定・引当、委託・売却を対象
各社の説明は公式製品情報で確認できます（出典：日本電子計算・日立システムズの公式製品情報、2026年確認；アイティフォー「保証管理・求償債権管理システム」、2026年確認）。
3社のような専用製品は、保証業務の標準範囲や制度対応を重視する案件で比べやすいです。
NTTデータ、富士通、NECなどの大型SIやローンプラットフォームは、受付や審査、電子契約、勘定系、データ基盤を含む構想で評価します。
業務範囲、既存基盤、商品展開、内製化の方針から、各社の役割を決めます。専用製品が必ず安いわけでも、大型SIが必ず安心というわけでもありません。
機能・工程・運用の3層による見積比較
見積は、機能、工程、運用それぞれの範囲をそろえて比べます。各提案が業務に合うかは、証拠をもとに確かめます。
- 機能：受付、保証料、残高、延滞、代位弁済、求償、回収、償却、自己査定、帳票、権限、分析
- 工程：要件定義、設計、開発・設定、連携、移行、テスト、教育、切替、並行稼働
- 運用：保守、制度改定、監視、バックアップ、復旧、パッチ、問合せ、追加開発単価
点数表では、価格だけに高い配点を置かないようにします。失敗したときの影響が大きい項目ほど、配点を重くします。
例として、業務適合性を30点、連携・移行を20点、セキュリティ・監査と導入体制をそれぞれ15点とします。保守・制度対応と費用は、それぞれ10点です。
各点に、実績やデモ、提案書、契約上の保証などの証拠を付けると、印象で決まりにくくなります。
デモと面談で確認する例外処理
通常と異なる処理を示してもらうと、カタログだけでは分からない適合性を確認できます。
- 保証・融資：料率変更、商品別番号体系、融資データの遅延
- 入金・債権：入金額不一致、代位弁済後の一部回収、償却後の入金
- エラー・訂正：操作担当者、承認、ログに残す値
導入体制では、業務担当者の参加やPM経験を確認します。再委託や障害連絡の方法、交代時の引き継ぎ、稼働後の教育も確かめます。
過去の金融・保証案件は、許可を得た範囲で聞きます。期間や移行件数、連携先数のほか、稼働後の支援や制度改定の対応例も含めます。
発注者は、会社全体の実績だけでなく、今回の担当チームが同じ知見を持つかも確認します。
保証管理システムの発注で失敗しないための実務ポイント
対象業務を決めないまま契約すると、除外事項を見落としやすくなります。旧データの調査不足や例外テストの漏れも、追加費用や稼働延期の原因になります。
保守と制度改定も、別々に考えず、発注者が管理する実務を決めておきます。
部門ごとの最適化より優先するデータのつながり
部門ごとに台帳を分けると、同じ顧客や債権の残高が一致しないことがあります。
- 顧客・契約：顧客、保証契約、融資、保証料
- 入金・事故：入金、事故、代位弁済、求償、回収
- 担保・査定：担保、査定の正本データ
発注前に正本を決めておき、データは一度だけ入力して、必要な部門が権限の範囲で参照できる設計を優先します。
信用保証協会電子受付システムは、2022年度の稼働開始以降に利用が拡大していると公表されています（出典：全国信用保証協会連合会「日本の信用保証制度2025」、2025年）。電子受付・契約・審査・保証管理の間に紙や手入力が残ると、デジタル化の効果が薄れます。
新規開発では、画面を置き換えるだけで終わらせず、電子データを流す範囲を先に決めます。
切替判定と稼働後の改善責任者
本番切替は日付を先に決めず、品質条件を満たした日を候補にします。
- 照合・テスト：残高・件数・入出金照合、主要シナリオの受入完了
- 運用準備：重大障害の未解決件数、権限、バックアップと復旧確認、操作教育、問合せ窓口
- 残課題：影響、回避策、期限、責任者、経営承認を記録
また、稼働後は改善会議を設けます。追加開発や制度変更、データ品質、月次照合、利用状況を、そこで扱います。
ベンダー任せにせず、発注者側にも業務改善の責任者を置きます。効果は処理時間だけでなく、二重入力や照合時間、再処理、代位弁済から回収開始までの時間で測ります。
監査資料の作成時間も、導入前後で比べられる指標です。
よくある質問
発注では、パッケージの選び方、費用、RFPの記載項目、クラウドでの外注について質問が多く寄せられます。主な質問に順に答えます。
保証管理システムはパッケージとスクラッチのどちらがよいですか？
制度改定への追従、監査証跡、保証・求償の標準業務を重視するなら、パッケージか周辺開発との組み合わせが第一候補です。
独自商品や既存基盤との接続が競争力に直結し、標準機能で対応できない場合は、追加開発やスクラッチを検討します。判断の前に、Fit & Gapで差分を数値にしておきます。
保証管理システムの発注費用はいくらですか？
中規模のパッケージ導入と複数連携では、初期費用1,500万〜8,000万円程度が推定目安です。
要件定義やPoCだけなら300万〜1,000万円程度、大規模刷新やスクラッチ併用では8,000万円〜2億円超の可能性があります。
まず対象業務や連携本数、移行件数を決め、テストや保守、クラウド利用料も含めて同じ条件で見積もります。そのうえで、正式な金額を判断します。
RFPに最低限書くべき項目は何ですか？
RFPには、業務範囲、規模条件、連携、移行を記載します。権限や性能、テストも書きます。教育や保守、制度改定、費用、除外事項も、あわせて記載します。
業務範囲には、保証受付から完済までを含めます。延滞、代位弁済、求償、回収、償却、自己査定も、業務範囲に入れます。
通常・例外処理、エラー時の再処理、検収基準を具体化すると、提案を比較しやすくなります。
保証管理システムをクラウドで外注しても問題ありませんか？
判断の分かれ目は、クラウドを使うかどうかではなく、必要な項目を確認できるかどうかです。
データ所在地や再委託、暗号化、鍵管理を確認します。特権ID、ログ、バックアップ、RTO・RPOも、あわせて確かめます。
また、監査対応や障害時の責任の分け方、契約終了時のデータ返却も、確認の対象です。金融情報システムの安全対策や所属業界の監督上の要請を踏まえ、発注者の基準とベンダーの仕様を照らし合わせます。
まとめ
保証受付から自己査定までの業務の流れを、一つのライフサイクルとして整理します。保証料や融資後の管理、延滞、代位弁済から、求償、回収、償却までが対象です。
パッケージやクラウド、スクラッチを比べます。そのうえで、Fit & Gapでは、標準機能、設定、追加開発、業務変更に分けます。
RFPには、シナリオや例外処理、外部I/F、移行を記載します。権限や監査ログ、テスト、切替、保守、制度改定も含めます。
中規模案件の初期費用は1,500万〜8,000万円程度が推定目安ですが、移行・連携・セキュリティ・運用要件で変わります。
価格だけでなく、業務への適合性や体制、稼働後の責任の分け方を確かめることが、長く使えるシステムにつながります。
発注前に確認する項目の一覧
発注前に、対象業務と対象外業務、保証商品、連携先、移行範囲を整理します。また、初期費用とランニング費用、契約形態、検収条件、制度改定、障害対応の責任者は、同じ一覧に書き込みます。
提案を受けたら、発注者は金額だけでなく前提条件と除外事項を並べ、経営判断に必要なリスクが分かるようにします。
現状業務とデータの洗い出し
最初に、現場の業務イベントとデータの流れを確認し、RFPの前提を作ります。保証管理、求償債権、外部連携、移行、監査を整理しておけば、必要な範囲を明確にして発注できます。
▼全体ガイドの記事
・保証管理システム開発の完全ガイド
▼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を創業。