レンタル業向け料金計算システムの費用は、100万円から4,000万円以上まで幅があります。金額を左右するのは、料金ルール、拠点数、連携範囲です。
発注形態から委託先の選び方まで、順に見ていきます。全体像は、完全ガイドでもご覧いただけます。
▼全体ガイドの記事
・レンタル業向け料金計算システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
レンタル業向け料金計算システムを発注する前の全体像
このシステムは、商品マスタだけでなく、個体・シリアルや契約期間も扱います。
貸出・返却、延長、休止、請求締め、顧客別単価も、業務の流れとして管理する対象です。
発注時には、料金を自動計算する画面に加えて、料金の根拠となる業務イベントを正確に記録する設計も必要になります。
販売管理システムとレンタル管理の違い
販売管理では、受注、出荷、売上、請求を一度処理すれば取引が完了します。一方、レンタルでは、契約と資産の状態を分けて管理する必要があります。その違いは、次の3点に表れます。
- 資産の状態：予約から貸出・返却・修理・再レンタル・売却まで変化します。
- 請求の発生：一つの受注から月次請求や追加請求が複数回発生します。
- 料金の計算：貸出・返却や先取・後取を含む業界固有ルールに対応します。
レンタル業向けの製品では、貸出・返却・Wレンタル・販売を一画面で処理する機能があり、先取と後取の料金計算にも対応します（出典: 株式会社コンピューターシステムハウス「機材レンタル業向け販売管理システム」、2026年確認）。
自社で使う業界固有の処理を先に決めてから、パッケージか個別開発かを比べます。
料金計算で重要なのは単価より期間ルール
単価表の登録に加えて、開始日や返却日を利用日数に含めるかを決めておく必要があります。
月をまたぐ日割りの扱いも、あらかじめ明確にしておきます。
顧客別・現場別の単価も対象です。
延長や早期返却などの例外も、料金計算の対象に含めます。
- 単価の種類：日極・週極・月極・固定単価・基本料・保証料を扱う。
- 契約条件：最低利用日数や長期割引、顧客別・現場別単価を定める。
- 例外処理：延長・早期返却・休止・破損・紛失・違約金・Wレンタルを整理する。
これらが組み合わさると、同じ商品でも請求額が変わります。たとえば、30日利用の月極契約を15日で返却した場合、日極に戻して精算するか、月極のまま精算するかも業務ルールになります。
発注前には、代表的な契約を5パターンほど選び、期待する請求明細を決めておきます。
発注形態と契約形態の選び方
発注形態は、標準機能との適合度と、社内にIT人材がいるかどうかで選ぶのが基本です。
導入をどれだけ急ぐか、独自ルールをどこまで重視するかも判断材料です。独自の料金エンジンや既存の基幹システムとの連携も、判断材料に含まれます。
- SaaS・パッケージ：標準業務が近い場合の候補です。
- 追加開発・ERP連携：基幹連携や独自ルールを補う場合に検討する方式です。
- フルスクラッチ：独自の料金エンジンが競争力に直結する場合の候補です。
全社を一度に切り替えず、料金計算と請求明細から段階的に導入する方法もあります。
SaaS・パッケージ・個別開発の比較
方式ごとに、適する業務と導入後に負担する作業が異なります。そのため、契約シナリオを入力したデモで、適合性を確かめます。
貸出・返却・在庫・請求の標準機能が自社の業務に合えば、パッケージは期間と費用を抑えやすい選択肢です。
顧客別単価や複雑な締め、独自の配送・修理・会計連携が必要な場合は、個別開発が適しています。
- SaaS：サーバー運用の負担を抑えつつ、複数拠点で早く使いたい企業向けです。
- パッケージ：貸出・返却・在庫・請求が合えば、期間と費用を抑えやすい方式です。
- 個別開発：顧客別単価や複雑な締め、配送・修理・会計連携に適します。
SaaSを選んでも、連携や移行、権限設計などの作業には費用がかかります。
パッケージでも、標準にない料金ルールを合わせようとすると、追加開発が増えます。
個別開発では、要件変更やテスト、保守を自社が負担します。
担当者が替わったときの引き継ぎも、自社の役目になります。
請負・準委任・保守契約の使い分け
作業内容に応じて契約を分けると、成果物や支援範囲を整理できます。仕様を固める段階と、完成条件が明確な段階とでは、契約形態が異なります。
完成する機能と検収の条件が明確な設計・開発には、請負が向いています。一方、現状調査や要件定義のように、作業しながら仕様を固める段階では、準委任が合う場合があります。
- 請負契約：機能と検収条件を明確に決められる設計・開発で使う。
- 準委任契約：現状調査や要件定義、業務整理、アジャイル開発の初期に合う場合があります。
- 保守契約：稼働後の支援を、開発契約とは分けて検討します。
要件定義は準委任、開発は請負、稼働後は保守契約に分ける構成も可能です。
契約書では、成果物と受入基準、仕様変更の扱いを押さえます。
再委託や知的財産権、ソースコードと設計書の帰属も、契約書に書かれているかを確かめます。
個人情報の扱いや、障害の優先度、対応時間も、契約で決めます。
バックアップとデータ返却についても、あわせて定めておきます。
計算誤りは、請求や売上、顧客との信用に影響します。そのため、障害時の手動請求と復旧後の再計算の手順も、契約や運用設計に含めておきます。
一括発注と段階発注の違い
一括発注は、責任範囲と予算をまとめやすい一方で、現場の理解が不足したまま大規模な開発に進むリスクがあります。
段階発注なら、小さく検証しながら進められます。
段階発注では、作業を次の4つの段階に分けます。
- 現状調査・要件定義：業務と料金ルールを明らかにする。
- 料金計算の試作：請求明細が期待どおりかを検証する。
- 1拠点のMVP：貸出イベントと請求計算を本番前に確かめる。
- 本番展開：在庫、配送、会計、顧客向けWeb発注へ広げる。
最初の契約では、第一段階の完了条件をはっきりさせておきます。たとえば、対象拠点の商品で貸出イベントを記録し、請求明細を計算できる状態にすることが挙げられます。さらに、承認後に既存の会計へ連携できることも、条件に加えられます。
将来の拡張に備えて、APIやマスタ構造、権限設計を初期段階で確認しておくと、段階導入での手戻りを抑えられます。
発注・外注から稼働までの進め方
外注は、現状調査から稼働まで段階を追って進めます。
各段階で誰が決めるのかを明確にし、料金計算を確認する業務責任者も置きます。
全体の流れは、大きく4つの段階に分かれます。
- 現状調査と要件整理を行う。
- RFPを配布し、提案と見積を比較する。
- 契約後に設計・開発を進める。
- テスト・移行、教育を行い、稼働する。
経営層と、営業・倉庫・配車・請求・経理・情報システムの代表を、早い段階から巻き込みます。
現状調査で洗い出す請求のズレと属人ルール
見積書や契約書、請求書、単価表といった資料を集めます。出庫・返却伝票や修理記録、会計データも対象です。件数と締め日のほか、帳票や連携方法も調べます。
件数の規模は、見積もりの中身を読むときの手がかりになります。
Excelや紙を使っている場合は、担当者が金額の根拠にしているセルや記録を確認します。
- 業務量：商品・個体・拠点数、月間契約数、1日の出庫・返却件数を把握する。
- 請求条件：締め日と顧客別帳票、既存システムとの連携を確かめる。
- 判断根拠：Excelや紙のどの記録で金額を決めるか、担当者に聞く。
現状の課題には、請求漏れや返却未処理があります。延長の見落としや日割りの誤り、変更後の再計算も、課題に含まれます。
営業所間の在庫の不整合や、担当者ごとの割引判断も確かめます。問い合わせや訂正請求を手がかりに、頻度の高い例外を選び出します。
機能名に置き換える前に、いつ誰が何を見て判断しているのかを業務フローに書き出しておきます。
料金計算エンジンとデータモデルの設計
設計では、品目や契約、料金のデータと、貸出・返却、請求のデータを分けて持ちます。こうすると、金額の計算根拠を後からたどれます。
開始日と終了日、税、端数処理の規則も、料金エンジンに持たせます。
- 品目・取引先：商品・個体・付属品・消耗品・顧客・現場を定義する。
- 契約・料金：契約・単価・割引・貸出・返却イベントを定義する。
- 請求：請求締めと明細を分け、計算結果を再現できるようにします。
計算結果だけでなく、契約や期間、単価、割引、返却情報をたどって、金額を追跡できるようにします。
訂正や取消も履歴に残すと、顧客への説明や社内監査に役立ちます。
料金エンジンには、日数の算定や月またぎの扱い、最低利用日数、長期割引を設定します。休止や延長、早期返却の扱いも、同じエンジンで決めておきます。
違約金や破損・紛失も、料金計算の対象です。
条件分岐を画面に直接書いてしまうと、ルールを変えるたびに改修が必要になります。そのため、料金をマスタやバージョンで管理し、契約時点のルールを再現できる構造を委託先に求めます。
本番前のテスト・移行・教育
テストでは、短期貸出に加えて、料金や契約の例外も再現します。そこで、実データに近い契約を3〜5パターン用意します。
- 料金変更：日極から月極、月またぎ、途中延長、早期返却を試す。
- 契約例外：休止や返却遅延、分割請求、単価変更、契約取消を試す。
- 損傷・併用：破損・紛失やWレンタルも再現する。
旧システムや手計算の期待値と、新システムの請求明細を、一行ずつ照合します。
移行の対象は、商品コード・個体番号・顧客・現場・単価と、貸出中データ・返却予定・請求残・過去履歴です。また、旧コードと新コードの対応表や、欠損値の扱い、件数と金額の照合方法も決めておきます。
教育では、営業や倉庫、請求、管理者の各担当が、契約登録・返却・延長・請求訂正までを演習します。操作の説明で終えず、実際の業務に近い演習まで行います。
RFPと要件整理に盛り込む内容
RFPには、料金の自動計算に加えて、業務全体の条件を書き込みます。
業務課題と範囲は、各社に同じ条件で示します。データと連携の条件も、そろえて書きます。非機能・納品物・評価基準も、同じ前提で明記します。
要件が曖昧だと、各社が異なる前提で見積もります。その結果、最安の会社を選んだあとに、追加費用が発生しやすくなります。
RFPに書く業務範囲と優先順位
業務範囲には、見積から請求までの流れと会計連携を記載します。範囲は、稼働初日に必要なものと後日追加するもの、対象外に分けて示します。
営業所単位の在庫、現場単位の請求、顧客単位の締めなど、集計単位も明記します。
- 対象業務：見積や予約、契約、受注から、出庫・配送・貸出・延長・休止までを含める。
- 返却後の業務：返却・検品・修理・再レンタル・売却・請求を記す。
- 集計単位：営業所別の在庫、現場別の請求、顧客別の締めを明記する。
優先順位は、事業への影響で決めます。判断の材料は、請求の正確性・返却状況・在庫・入力の負担・会計連携・顧客向け発注などです。
請求額の説明と手作業での訂正を必須条件にする一方で、便利なダッシュボードは次の段階に回す判断もできます。
候補の会社が要件の抜けを指摘するかどうかも、確かめておきます。
マスタ・連携・端末の条件の具体化
マスタと連携方式を具体化しておくと、各社が同じ条件で提案できます。
現場端末の要件も、機能要件として示します。
- マスタ：商品・個体・シリアル・付属品・単位・顧客・現場を含める。
- 料金情報：営業所・倉庫・料金ランク・割引・保証料・税区分を含める。
- 連携：会計・販売・倉庫・配送・電子請求書・Web発注の受け渡しデータを決める。
データごとに、API・CSV・EDI・手入力のどれを使うかを示します。あわせて、やり取りの頻度やエラー時の再送、重複防止も決めておきます。
現場でスマートフォンやタブレットを使う場合は、バーコード・QR読取・写真・署名・オフライン保存の扱いを決めます。
通信が復旧したあとの再送や、端末の共有、権限、電池切れ時の代わりの運用も、要件に含まれます。
返却の登録が遅れると、請求と在庫がずれてしまいます。そのため、画面の使いやすさも、機能要件と同じ重さで評価します。
発注条件に入れる非機能要件・法令・監査要件
性能や運用、法令、監査の条件をRFPに含めます。
IPAの「非機能要求グレード」は、要求を分類して段階的に示し、認識の違いを防ぐための材料です。
運用と安全の条件は、各社が同じ前提で提案できるよう、具体的に書いておきます。
- 規模・性能：利用者・商品・個体・拠点・同時利用者・請求処理時間を示す。
- 運用・復旧：稼働時間・バックアップ・復旧目標・監視・保守窓口を決める。
- 安全・監査：権限・ログ保持・脆弱性対応・訂正・削除履歴を確認する。
出典は、IPAの「システム構築の上流工程強化（非機能要求グレード）」の2023年アーカイブ情報です。
電子取引データを保存する場合は、電子帳簿保存法の要件を確認します。
国税庁は、電子取引情報の電磁的記録保存を求めています（出典: 国税庁「電子帳簿保存法の概要」「優良な電子帳簿の要件」、2026年確認）。
優良な電子帳簿では、訂正・削除の履歴や、取引年月日・金額・取引先での検索性が示されています。そこで、料金訂正の理由・承認者・変更前後の値を保存できるかを、RFPで質問します。
配送や回収がある場合は、物流データも対象になります。
国土交通省は、2026年4月から一定規模以上の荷主・物流事業者を特定事業者に指定します。また、中長期計画や定期報告の求めについて、情報を公開しています（出典: 国土交通省「物流・自動車：物流効率化法について」、2026年確認）。
義務は企業によって異なりますが、荷待ち時間や配送予約、回収実績を記録できる設計は、将来の改善と説明に役立ちます。
レンタル業向け料金計算システムの費用相場
費用は、利用料だけでなく、要件定義から保守までの作業ごとに考えます。作業には、設定・開発・連携が含まれます。移行・テスト・教育も、作業の一部です。稼働立会いと保守も、作業に含めて考えます。
レンタル専用システムの公的な価格統計は確認できません。そのため、ここに示すのは、類似する業務システムの公開相場と、レンタル固有の計算や個体管理、連携の工数をもとにした2026年時点の目安です。正式な見積ではありません。
導入パターンごとの初期費用レンジ
導入の範囲によって、初期費用の目安は大きく変わります。範囲の広さは、料金ルールや拠点数、連携範囲で決まります。
- 小規模Web：契約・単価・日割り・請求明細・CSVまたはAPI出力を含む。
- パッケージ導入：貸出・返却・在庫・請求、帳票、数拠点、会計連携で300万〜800万円程度です。
- クラウド・ERP連携：複数営業所・個体管理・Wレンタル・配送・会計・購買・顧客発注・履歴移行で800万〜2,000万円程度です。
- フルスクラッチ：独自料金・モバイル・API・BI・複雑な権限・監査で1,500万〜4,000万円以上の可能性があります。
料金計算と請求明細だけに絞った小規模な開発であれば、100万〜300万円程度、期間は1〜3か月程度が目安です。
各金額は、公開相場とNotebookLMリサーチノートをもとにした推定です。実際には、レンタル固有の業務範囲や連携条件に応じて見積もりを取ります。
初期費用とランニングコストの分け方
初期費用は、工程や成果物ごとに確認します。「システム一式」とだけ書かれた見積では、どこまでの作業が含まれ、どこから追加になるのかが分かりません。
- 設計・開発：要件定義・基本設計・画面・データ・料金ルール・開発の範囲。
- 導入作業：外部連携・テスト・データ移行・マニュアル・教育・稼働支援の範囲。
- 見積前提：1人月単価・想定工数・作業期間・成果物。
ランニング費は、クラウド利用料・保守・監視・バックアップに分けて考えます。ユーザー・拠点・商品点数に応じた従量料金も、ランニング費に含まれます。
更新や帳票の変更、法改正への対応、追加開発も、あわせて確認します。
類似する基幹・業務システムのクラウド利用料は、月額5万〜30万円程度からが目安です。変わり方は、ユーザー数・API・帳票・サポート・データ容量によります。
保守費は、初期開発費の年15〜20％程度を見込んで予算化する考え方もあります。ただし、実際の費用は契約条件によって異なります。
費用が増えやすい要因
工数は、機能の数に加えて、料金の例外や古いデータ、連携先、現場の環境によっても変わります。
- 料金例外：日極・月極・割引・休止・延滞・遡及再計算が重なる場合。
- データ整備：マスタ名寄せや過去履歴の移行が必要なとき。
- 外部連携：会計・倉庫・配送・電子請求との接続があるケース。
- 現場対応：端末利用やオフライン対応が必要な現場。
費用を抑えるには、料金計算と請求の根拠を第一段階にし、Web発注や高度な分析は次の段階に回します。
将来のデータモデルやAPIを後から作り直すと費用が増えるため、拡張の境界は初期設計で確認します。あわせて、請求漏れや訂正作業にかかっている現行のコストも比べます。
委託先の選び方と見積比較のポイント
委託先は、知名度や価格だけでなく、レンタル業務と料金計算の境界条件を理解し、それを説明できるかで見ます。
候補は3〜5社程度に絞ります。そのうえで、同じRFP・契約シナリオ・データ連携の条件で、提案を受けます。
回答の速さや前提の明示、リスクの指摘、導入後の体制も、開発力を見極める材料になります。
レンタル業の実績と料金ルールの確認
「実績あり」と説明されたら、標準で対応できる料金や請求の範囲まで確かめます。そのうえで、契約を使ったデモで結果を評価します。
- 期間・割引：日極・月極、最低利用日数、長期割引の扱い。
- 契約変更：休止や延長、返却遅延への対応。
- 請求方式：先取・後取、分割請求への対応。
キッセイコムテックのKAREN-COREは、レンタル業向けの販売・在庫管理で、貸出・請求・顧客マスタを一つにまとめて管理できると案内しています（出典: キッセイコムテック「KAREN-CORE」、2026年確認）。
西部電気工業の稲尾産業向け事例では、販売管理・財務会計・仕入管理・受付を連携しています。
データの流れは、一度の入力から複数業務へ渡す構成です（出典: 西部電気工業「Dynamics 365 BCで業務改革を実現」、公開事例を2026年確認）。
既存システムを残すか刷新するかも含めて、複数の案を提案できる会社を選びます。
見積書の比較は金額より前提と作業範囲
見積もりは、工程ごとの作業と前提を比べます。そのうえで、含まれない作業や、追加になったときの単価、承認の方法も確かめます。
工数の前提となる数字が明記されていないと、見積もり同士を比べにくくなります。
- 作業範囲：要件定義、設計、開発、連携、テスト、移行を確認します。
- 導入後まで：教育、稼働支援、保守が含まれるか確認します。
- 工数の前提：料金ルール数、例外、連携本数、移行件数、テスト数、拠点数を確認します。
安い見積でも、移行や現場教育、受入テスト、請求照合、稼働立会いが別料金であれば、総額は変わります。一方で、業務整理から障害時の運用設計まで含む見積なら、金額が高くても妥当な場合があります。
同じ契約シナリオでの計算結果や、納品物一覧・体制表・予定・リスク一覧を、候補の各社に提出してもらいます。
保守・データ返却・セキュリティ体制の確認
稼働後も、料金の改定や税制・帳票の変更、拠点の追加、単価の変更が起きます。OS・ブラウザの更新や障害、データ修正も発生します。
担当者が替わっても運用が続くように、引き継ぎに使う資料を納品物として求めておきます。
- 保守条件：対応時間・窓口・一次切り分け・復旧目標。
- 変更費用：軽微な改修と追加開発の見積方法。
- 引き継ぎ：設計書・料金ルール一覧・テスト結果・データ辞書を納品対象にする。
IPAは2026年3月に「中小企業の情報セキュリティ対策ガイドライン」第4.0版を公開しました。バックアップを含む情報セキュリティ6か条や、ランサムウェア・サプライチェーン被害への対応も拡充されています（出典: IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版、2026年3月27日）。
委託先については、多要素認証・権限分離・暗号化を確かめます。ログやバックアップ、脆弱性対応も、確認の対象です。加えて、事故時の連絡と、契約終了時のデータ出力・削除証明も決めておきます。
よくある質問（FAQ）
費用や期間は要件で変わります。ここでの回答の範囲を、自社の拠点数や商品数、契約件数、連携数に当てはめて確かめます。
レンタル業向け料金計算システムはパッケージとスクラッチのどちらがよいですか？
貸出・返却・在庫・請求が自社の業務に近ければ、パッケージで期間とリスクを抑えやすいです。一方、標準機能で扱えない料金ルールや会計連携がある場合は、追加開発を検討します。
実データに近い契約でデモを行い、機能表の比較だけで決めないようにします。
開発費用と期間はどれくらいかかりますか？
料金計算と請求明細だけの小規模開発は、初期で100万〜300万円程度、期間は1〜3か月程度が目安です。
貸出・返却・在庫・会計連携を含めると300万〜2,000万円程度のケースがあります。さらに、独自ルールの多い全社刷新では、1,500万〜4,000万円以上になる可能性があります。
拠点数、連携本数、移行データ、テストの深さで変わります。見積もりでは、範囲と前提を分けて確かめます。
RFPにはどのような資料を添付すればよいですか？
現行の見積書や契約書、請求書、単価表、業務フローを添付します。商品・顧客・拠点の数と、連携先の一覧も示します。契約シナリオ・帳票・非機能要件も含め、希望日程も書き添えます。
個人情報や機密条件は匿名化してサンプルデータで示します。月またぎ・延長・早期返却・休止・破損・契約変更の5パターン程度に期待結果を添えると、比較しやすくなります。
委託先を選ぶときに最も重視すべき点は何ですか？
料金ルール、返却・延長、請求の再計算、個体管理を、実際の契約で説明できるかを重視します。会計・倉庫・配送との連携も確認します。
要件定義から移行・教育・保守までの体制や、障害対応、データ返却、セキュリティも確かめます。リスクや対象外を明示しているか、請求誤りや手戻りを減らす提案をしているかが、判断の材料になります。
まとめ
発注前には、貸出・返却・延長・休止・日割り・割引・契約変更・請求締めのルールを整理しておきます。方式は、標準適合度・費用・期間・拡張性・社内運用の観点で比べます。
費用の目安は、小規模開発で100万〜300万円程度、貸出・返却・在庫・連携を含む導入で300万〜2,000万円程度です。全社刷新では、1,500万〜4,000万円以上になる可能性があります。これは公開相場と要件から整理した幅で、特定の金額を断定するものではありません。
RFPには期待する請求結果・連携条件・非機能・移行・保守範囲を含め、同じ条件で3〜5社を比較します。
料金計算と請求の根拠を1拠点で検証し、返却登録が定着してから在庫や配送、会計、顧客向け発注へ広げれば、リスクを分散できます。
請求額の根拠・訂正・削除の履歴・バックアップ・データ返却・障害時の手動運用を、契約と設計に含めておくことが、長く使えるシステムにつながります。
▼全体ガイドの記事
・レンタル業向け料金計算システム開発の完全ガイド
▼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を創業。