レンタル業向け貸出返却管理システム開発の発注/外注/依頼/委託方法について

レンタル業向け貸出返却管理システムを発注・外注するなら、貸出画面の開発費だけでなく、予約、出荷、返却検品、修理中在庫、料金計算、請求、データ移行までを一つの業務範囲として定義することが重要です。発注方式と契約を要件の確定度に合わせて選び、同じRFPとテストケースで複数社を比較すると、導入後の追加費用と現場の手戻りを抑えやすくなります。

レンタル業では、商品が貸し出されて返却された時点で、すぐに再貸出できるとは限りません。検品、洗浄、点検、修理、紛失確認、付属品の確認を経て、貸出可能な状態へ戻るからです。本記事では、レンタル業向け貸出返却管理システムの発注形態、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積比較のポイントを、2026年時点で確認できる公開情報と実務上の判断軸に基づいて解説します。

▼全体ガイドの記事
・レンタル業向け貸出返却管理システム開発の完全ガイド

レンタル業向け貸出返却管理システムを外注する前に何を決めますか?

レンタル業向け貸出返却管理システムの外注準備をするイメージ

最初に決めるべきことは、システムを作ることではなく、何を改善できれば発注が成功したといえるかです。貸出可能な商品を電話ですぐ回答したいのか、返却遅延と延滞料の計算を正確にしたいのか、倉庫の検品時間を短くしたいのかで、必要な機能と発注先の得意領域が変わります。

導入目的と改善指標を先にそろえる

目的は「在庫をシステム化する」のような抽象的な表現ではなく、「電話確認を減らし、予約時点で貸出可能日を回答できる」「返却後の検品待ちを在庫から除外する」「月末請求の手入力を減らす」といった業務結果で表します。改善指標も、在庫差異件数、返却処理時間、未返却件数、延滞率、修理滞留日数、請求訂正件数などから、自社で計測できるものを選びます。

指標を決めると、開発会社の提案を機能数だけで評価せずに済みます。たとえば、バーコード検品の機能があっても、返却されたセット品の一部だけを処理できなければ現場の課題は解決しません。現状値と目標値を厳密に測れない場合でも、導入前のサンプル期間を決めて、同じ指標を導入後にも計測できるようにします。

現行業務を貸出から再貸出まで可視化する

発注前には、現場の業務を「見積・予約・引当・出荷・貸出・延長・交換・返却・検品・洗浄・修理・在庫復帰・請求」の流れに分けます。各工程で誰が、どの帳票やExcelを使い、どのタイミングで状態を変更するかを整理します。営業担当が電話で受けた延長依頼を倉庫担当へ伝える方法や、返却品に破損があった場合の請求判断も、通常フローとは別の例外として記録します。

特に重要なのは、商品単位と個体単位を分けることです。同じ型番の商品を数量で管理できる場合と、建機、映像機器、無線機、IT機器のようにシリアル番号、付属品、点検期限、修理履歴を追う場合では、データ設計が異なります。返却済みでも検品中・修理中なら貸出可能数に含めないというルールを、業務フローとRFPの両方へ書きます。

発注形態はパッケージ・クラウド・個別開発のどれを選びますか?

発注形態を比較して選ぶイメージ

発注形態は、自社の業務を標準機能へ寄せられるか、独自の料金や個体管理を残す必要があるか、初期費用と月額費用のどちらを重視するかで選びます。レンタル業向けの製品を使えば短期間で始めやすくなりますが、製品名に「レンタル」とあっても、複数回返却、拠点間移動、修理中在庫、付属品、請求ルールまで適合するとは限りません。

既製パッケージへの発注が向いているケース

見積、予約、貸出、返却、在庫、売上、請求など、業界共通の業務を早く標準化したい企業には、既製パッケージが向いています。業務に合う製品であれば、ゼロから画面やデータ構造を設計するより、導入期間と初期費用を抑えやすく、同じ製品を使う他社の運用知見も得やすいです。一方、標準外の料金計算や帳票を無理に運用で吸収すると、Excelが残って二重入力になるため、Fit & Gap分析を実施します。

公開価格の実額例として、DACKSの「RENTAL ASSIST」価格表では、2024年11月時点でStandard版が税抜89万8,000円、Enterprise版が税抜420万円、Web版が150万円、導入支援が12万円と掲載されています。これは特定製品の価格であり、自社の導入費を保証するものではありませんが、同じ貸出管理製品でも利用形態や規模で価格帯が変わることを示しています。(出典:DACKS「貸出管理システム製品価格表」、2024年11月)

クラウド・ローコードへの発注が向いているケース

複数拠点や外出先から利用したい企業、サーバー運用を自社で担いたくない企業、小さく始めて利用範囲を広げたい企業には、クラウド型やローコード型が候補になります。バックアップやアップデートをサービス側へ任せやすい一方、月額課金、ユーザー数、ストレージ、API、データ出力、サービス終了時の移行条件を契約前に確認します。通信障害が起きたときに、紙の臨時伝票や後追い入力で貸出・返却を止めない運用も必要です。

2025年6月公開の足場資材レンタル管理クラウドパック資料には、kintoneスタンダードを1ユーザー月額1,800円、最低10ユーザーとする価格例、初期費用30万円から、月額4万7,000円からと読める例が掲載されています。税区分や設定範囲は個別見積で確認が必要ですが、クラウドでも初期設定、業務設計、帳票や連携に費用が発生することが分かります。(出典:株式会社アットリンク「足場資材レンタル管理クラウドパック」、2025年6月)

個別開発への発注が向いているケース

独自のレンタル料金、複雑な契約、全国拠点の在庫引当、個体ごとの収益管理、会計・販売・物流との深い連携が競争力に直結するなら、個別開発を検討します。既製品に合わせるために重要な業務を変えるより、自社の強みをシステムへ反映できる可能性があります。ただし、自由度が高いほど要件定義の責任と将来の保守負担も大きくなるため、最初から全機能を作らず、貸出・返却・在庫・請求の最小範囲から段階導入する方法が安全です。

パッケージと個別開発を組み合わせる方式もあります。標準製品で顧客、商品、貸出、返却を管理し、独自の料金計算やEC連携だけを追加する構成です。発注時には、標準機能、設定変更、アドオン開発、完全なスクラッチ開発を見積書上で分けてもらいます。これにより、将来の追加費用がどの部分から生じるかを判断しやすくなります。

RFPと要件整理には何を書けばよいですか?

RFPと要件を整理するイメージ

RFPは、開発会社へ「何か便利なシステムを提案してください」と依頼する文書ではありません。自社の業務、解決したい問題、対象範囲、制約、希望時期、予算の考え方、提案してほしい内容を同じ条件で伝え、提案と見積を比較可能にする文書です。未確定の項目は無理に決めず、候補案と確認方法を提案してほしいと明記します。

業務範囲と利用者・データ量を記載する

RFPには、対象業務を見積・予約・引当・出荷・貸出・延長・交換・返却・検品・修理・在庫復帰・請求に分け、今回の発注範囲と将来対応を分けて書きます。商品数、個体数、顧客数、拠点数、倉庫数、月間の貸出台数、同時利用者数、利用する端末、繁忙期の処理量も記載します。数字が不明な場合は、直近3か月の伝票やExcelから概算し、推定値であることを注記します。

データ要件では、商品マスタ、個体・シリアル番号、セット品と付属品、顧客・現場・担当者、料金表、契約、予約、貸出中、未返却、修理中、廃棄、過去の取引履歴を分けて示します。既存データを移行する場合は、対象ファイル、行数、期間、重複や表記揺れの有無、クレンジングを自社と委託先のどちらが担うかまでRFPに含めます。

レンタル特有の例外シナリオを必須テストにする

機能一覧だけでは、レンタル業の実力を評価できません。RFPには、同じ商品を同じ期間に予約したときの重複防止、セット品の一部返却、返却予定日の延長、別個体への交換、破損品の修理中登録、未返却品への延滞料、拠点間移動中の引当、月末の一括請求を、受入テストのシナリオとして書きます。各社には同じサンプルデータでデモしてもらい、できるかどうかだけでなく、何画面・何操作で処理できるかを確認します。

「返却」ボタンを押したら在庫が増える仕様では、検品前の破損品まで貸出可能になる危険があります。RFPでは、返却済み、検品中、洗浄中、修理中、紛失、廃棄、再貸出可能を別の状態として扱い、各状態で在庫照会、予約、請求、権限がどう変わるかを回答項目にします。状態を細かくしすぎると入力負荷が増えるため、現場が実際に判断できる粒度に絞ります。

連携・セキュリティ・移行後の運用を明記する

会計、販売管理、請求書、EC、配送、顧客管理、固定資産など、連携したいシステムを一覧化し、連携方向、頻度、項目、エラー時の責任者、APIの有無、CSVで代替する場合の運用を記載します。売上だけを渡すのか、延滞料や破損請求、入金消込まで戻すのかで設計は変わります。システム間で同じ商品や顧客を二重管理しないため、どのシステムを正とするかも決めます。

顧客の連絡先、契約情報、本人確認書類、決済関連情報を扱う場合は、権限分離、暗号化、操作ログ、バックアップ、保存期間、削除、委託先の再委託、障害時の連絡、データ返却を要求事項に含めます。IPAは2026年3月27日に中小企業向け情報セキュリティ対策ガイドライン第4.0版を公開し、バックアップや不要な外部通信、サプライチェーンに関する対策を拡充しています。開発会社には、これらの対策を自社サービスでどこまで実装・運用しているかを回答してもらいます。(出典:IPA「中小企業の情報セキュリティ対策ガイドライン第4.0版」、2026年)

契約形態は請負と準委任をどう使い分けますか?

システム開発の契約形態を検討するイメージ

契約形態は、名前だけで選ばず、成果物の完成責任、作業範囲、変更の扱い、報酬の支払条件、検収、知的財産権、契約不適合責任、損害賠償、再委託、データ返却を確認して決めます。要件が固まっていない企画・要件定義と、仕様が固まった開発・納品では、適した契約の考え方が異なるため、工程ごとに分けることが実務上有効です。

要件定義・企画は準委任を基本に検討する

準委任契約は、ベンダーが業務を遂行することに対して報酬を支払う形態で、要件定義、現行業務の整理、Fit & Gap分析、プロトタイプ検証、プロジェクト支援など、開始時点で成果物の完成形を確定しにくい工程に向いています。完成保証を期待する契約ではないため、稼働日数、担当者、会議体、作業内容、報告物、終了条件を具体的に定めます。

レンタル業では、現場ヒアリングを進めると、拠点ごとに返却状態や延長の承認方法が違うことがあります。最初から全工程を請負で固定すると、仕様変更が追加費用や納期遅延に直結しやすいため、まず準委任で業務と要件を確定し、その成果をもとに開発契約へ移る段階発注が適しています。準委任だからといって曖昧にせず、成果物の定義と意思決定者を明記します。

仕様が確定した開発は請負を検討する

請負契約は、合意した仕様に基づく成果物の完成と引き換えに報酬を支払う形態です。画面、帳票、データ項目、連携仕様、テスト項目、納品物、検収条件が確定している開発工程では、完成責任と受入基準を明確にしやすいです。ただし、レンタル料金の変更や新しい拠点運用が途中で決まる場合は、変更管理の手続きと追加見積のルールを契約書・仕様書に入れておきます。

IPAの情報システム・モデル取引・契約書では、企画段階は準委任、開発段階は準委任と請負のいずれもあり得るという整理が示されています。発注側が「請負だから何でも変更できる」と考えたり、受注側が「準委任だから完成責任は何もない」と説明したりすると、検収時に争いになります。工程ごとに契約類型、成果物、協力義務、変更の承認者をそろえて確認します。(出典:IPA「情報システム・モデル取引・契約書」、2020年公開・第二版の解説)

契約書で確認すべき責任分界と変更管理

契約前には、発注側と委託先の役割を表にして、マスタ整備、移行データの正しさ、テストデータ、受入判定、現場教育、障害連絡、バックアップ復元、アカウント管理をどちらが担うかを決めます。発注側の回答遅れが納期へ影響した場合の扱いも、協力義務とスケジュール変更のルールとして残します。再委託がある場合は、再委託先の範囲と管理責任を確認します。

変更管理では、変更内容、理由、影響範囲、追加費用、納期、テスト、承認者を記録します。特に、延滞料、破損請求、料金の日割り、締め日、税区分、会計連携の変更は、画面だけでなく請求結果や既存データにも影響します。軽微な変更を保守範囲に含めるのか、別途見積とするのか、月次の改善枠を設けるのかを契約時に決めると、導入後のやり取りが安定します。

発注・外注の費用相場はいくらですか?

レンタルシステムの費用相場を比較するイメージ

レンタル業向け貸出返却管理システムの費用は、標準機能中心なら初期30万〜180万円程度、パッケージに帳票・API・料金計算・ハンディ端末を加えるなら150万〜500万円程度、中規模の個別開発なら500万〜1,500万円程度が検討レンジです。多拠点、個体管理、会計・物流・ECとの統合まで含む大規模案件は1,500万〜3,000万円超になる可能性があります。いずれも公開価格と類似案件からの目安であり、一律の平均価格ではありません。

初期費用は工程ごとに分けて見積もる

初期費用は、要件定義、設計、設定・開発、連携、テスト、移行、教育、リリース支援に分けて確認します。個別開発の初期見積を分解する軸として、要件定義10〜15%、設計15〜20%、開発30〜40%、テスト15〜20%、移行5〜10%ほどを使える場合があります。ただし、既製機能が多い案件、データ整備が難しい案件、端末を多数導入する案件では比率が変わるため、固定の相場として断定しません。

安い見積でも、RFPに書いた移行、帳票、検品、修理、権限、外部連携が「対象外」なら、契約後に追加費用が発生します。見積書には、標準機能、設定、カスタマイズ、連携、機器、データクレンジング、研修、現地支援を分け、数量、単価、作業回数、前提条件、除外条件を記載してもらいます。作業一式だけの項目は、内訳と成果物の確認が必要です。

月額・保守・端末を含む総額で考える

クラウド型では、ユーザー数、拠点数、ストレージ、API、サポート、端末、ラベル発行などの月額費用が継続します。個別開発やオンプレミス型では、年間保守を初期開発費の15〜20%程度で検討することがありますが、障害修正だけか、法改正、OS対応、監視、バックアップ、問い合わせ、軽微な帳票変更まで含むかで実額は変わります。月額3万〜20万円程度の業務パックが候補になる場合も、ユーザーや機能の増加条件を確認します。

比較期間は、少なくとも5年を一つの基準にします。初期費用100万円の買い切り型と、初期30万円で月額8万円のクラウド型を比べる場合、単純な利用料だけでも5年で480万円となり、保守、端末、移行、サポートを加えると順位が変わる可能性があります。これは特定の製品を評価する計算ではなく、初期費用だけで安さを判断しないための比較方法です。

価格公開情報と個別見積を分けて読む

公開価格は、導入検討の初期に予算帯をつかむ材料として有効です。一方、価格非公開の製品や個別開発は、対象範囲が決まらないまま価格を推測できません。提案書で「要見積」とされた項目は、必要な前提、確認するデータ、決定時期を質問し、RFPの回答欄へ残します。公開価格のある製品でも、導入支援、データ移行、帳票変更、連携、端末、税、保守が含まれるかを分けて確認します。

費用相場を使うときは、「このレンジに収める」ことより、「自社のどの条件が上振れ要因か」を考えます。個体数、拠点数、同時利用者、月間取引量、料金ルール、連携先、移行対象、現場教育、繁忙期の切替制約を委託先へ伝えれば、提案の前提がそろいます。予算に上限がある場合も、必須・できれば・将来対応の三段階で機能を分けて共有します。

委託先の選定と見積比較では何を見ますか?

レンタルシステムの委託先と見積を比較するイメージ

委託先は、会社規模や知名度だけでなく、レンタルの業務状態を理解し、導入後の現場運用まで支援できるかで選びます。公式サイトにレンタル実績があっても、自社の商品種別、拠点数、個体管理、料金計算、会計連携が同じとは限りません。候補を3社程度に絞り、同じRFP、同じサンプルデータ、同じ質問で提案とデモを依頼すると、比較の精度が上がります。

レンタル業務への適合性と実績を確認する

実績確認では、建機・仮設資材、イベント用品、映像機器、OA機器、IT機器など、自社に近い商品種別の事例を聞きます。貸出と返却だけでなく、予約重複、個体・シリアル、付属品、検品、修理、再レンタル、拠点間移動、日額・月額・延滞料、請求・入金まで、どこを実際に使っているかを確認します。社名や導入年だけでなく、導入前の課題、標準機能と追加開発の範囲、利用定着の支援内容を聞くことが大切です。

キッセイコムテックの公式導入事例では、レンタルバスターズが、従来は貸出・返却や貸出スケジュールを管理できず、在庫管理と販売管理も分断されていた課題に対してKAREN-COREを導入した事例が紹介されています。導入後は受注から入庫・出庫・在庫管理の一元化や、個体識別による収益把握が示されています。こうした事例は、機能名ではなく、業務分断と個体管理をどのように解消したかを見る材料になります。(出典:キッセイコムテック「株式会社レンタルバスターズ様導入事例」、掲載確認2026年)

導入支援・教育・保守体制を評価する

レンタル業の導入では、システムが完成しても、現場が返却状態を正しく選べなければ在庫精度は上がりません。業務ヒアリング、マスタ整備、データ移行リハーサル、操作研修、現場立会い、並行稼働、切替後の問い合わせを、誰が何回支援するかを確認します。遠隔支援だけで足りる拠点か、倉庫へ訪問が必要かも、見積条件に影響します。

保守では、受付時間、初動時間、復旧目標、休日対応、障害時の代替手段、バックアップの保持期間、データ復元テスト、脆弱性対応、OSやブラウザの更新、法改正対応を確認します。2026年3月31日に経済産業省などが公表したサイバーインフラ事業者の役割に関するガイドラインでも、ソフトウェアの供給者と利用者がサプライチェーン全体で責任を分担する考え方が示されています。セキュリティ回答を価格だけでなく、契約上の責任分界まで見ます。(出典:経済産業省・国家サイバー統括室「サイバーインフラ事業者に期待される役割に関するガイドライン」、2026年)

見積比較は金額・前提・操作性を同時に見る

見積比較では、総額、納期、機能の適合度、追加費用の出やすさ、運用支援、契約条件を同じ比重で見ます。金額は初期費用、月額、保守、端末、移行、連携、教育、現地支援、5年間の総額に分けます。機能は「対応可能」だけでなく、標準、設定、追加開発、将来対応、対象外に分類します。対象外の機能が業務上必須なら、安い見積ではなく別の発注形態を検討します。

デモでは、予約重複、分割返却、破損品、延長、月末請求の5つを最低限試します。営業資料で機能が豊富でも、倉庫担当者がスマートフォンやハンディ端末で迷わず入力できなければ定着しません。現場担当、営業、経理、情報システム、経営の各立場から評価者を出し、操作数、待ち時間、エラー訂正、履歴確認、権限の分かりやすさを採点します。

最後は、提案書に書かれたリスクと前提条件を比較します。現場の協力が必要な作業、発注側が準備するマスタ、移行できないデータ、追加になりやすい連携、切替時の並行稼働、繁忙期の制約が明示されている会社は、見積が高く見えても予算管理の透明性が高い場合があります。質問への回答が担当者ごとに変わらないか、契約前の説明と契約書の内容が一致しているかも確認します。

よくある質問

レンタルシステムの発注に関するよくある質問を確認するイメージ

ここでは、発注前に多く寄せられる疑問へ、費用・契約・選定の観点から回答します。自社の条件と異なる場合は、質問をそのままRFPの確認事項へ変換し、候補会社から同じ形式で回答を受けると比較しやすくなります。

パッケージとスクラッチ開発はどちらを選ぶべきですか?

貸出、返却、予約、在庫、請求などの標準業務を早く整えたい場合は、既製パッケージやクラウド型が候補です。独自の料金計算、個体管理、拠点間業務、基幹連携が競争力に直結し、標準機能に合わせる負担が大きい場合は個別開発を検討します。最初から一つに決めず、標準製品で実現できる範囲と追加開発の費用を比較して判断します。

RFPが未完成でも開発会社へ相談できますか?

相談できます。現状のExcel、帳票、業務フロー、困っている事象、商品・拠点・利用者の概数、希望時期を共有し、要件整理から支援してほしいと伝えます。ただし、会社ごとに前提が違うまま複数見積を比べると価格差の理由が分かりにくくなるため、最初の相談で準委任による要件定義を行うのか、無料提案の範囲はどこまでか、成果物と費用を確認します。

要件定義から開発まで一つの請負契約にできますか?

一つの契約にすること自体は可能ですが、要件が未確定な工程と完成物を納める工程を同じ条件で扱うと、変更や責任範囲が曖昧になりやすいです。企画・要件定義は準委任、仕様確定後の開発は請負、保守・運用は別契約というように工程を分ける方法があります。契約類型よりも、成果物、検収、変更管理、協力義務、障害対応、データ返却を具体的に合意することが重要です。

外注費用を抑えるにはどうすればよいですか?

機能を一律に削るより、必須業務と将来機能を分け、既製機能を優先し、データ移行の対象期間を整理し、同じRFPで複数社を比較します。現場の例外を隠すと、導入後の追加開発や手作業として返ってくるため、二重予約、分割返却、破損、延長、請求などの難しい処理は先に伝えます。初期費用だけでなく、5年間の月額・保守・端末・教育を含む総額で判断します。

委託先の提案で必ず確認すべき項目は何ですか?

同じサンプルデータを使ったデモで、予約重複、分割返却、破損品、延長、月末請求を確認します。次に、標準機能と追加開発、データ移行の範囲、連携の責任分界、導入支援、保守、障害時の復旧、データ返却、契約終了時の移行条件を確認します。営業担当だけでなく、導入責任者や開発責任者が質問へ答えられるかも、発注後の体制を判断する材料です。

まとめ

レンタル業向け貸出返却管理システムの発注外注をまとめるイメージ

レンタル業向け貸出返却管理システムの発注では、まず現行業務を貸出から返却後の検品・修理・再貸出まで可視化し、改善したい指標を決めます。そのうえで、標準化を優先するなら既製パッケージ、複数拠点や小さな開始を重視するならクラウド・ローコード、独自の料金や基幹連携を競争力にするなら個別開発を候補にします。どの方式でも、商品・個体・在庫状態・料金・連携・移行をRFPへ記載します。

契約と費用は工程・責任・総額で確認する

契約は、要件が固まりにくい企画・要件定義を準委任、仕様が確定した開発を請負、導入後の保守・運用を別契約とする構成を一つの検討方法にします。費用は初期30万〜180万円程度の標準導入、150万〜500万円程度の追加開発・連携、500万〜1,500万円程度の中規模個別開発などを目安にしつつ、公開価格と個別見積を分けて読みます。根拠のない特定金額ではなく、条件とレンジをセットで確認します。

同じRFPと5つのテストで委託先を比較する

最後に、候補会社へ同じRFPとサンプルデータを渡し、予約重複、分割返却、破損品、延長、月末請求を同じ条件で試します。金額だけでなく、現場の操作性、標準機能と追加開発の境界、データ移行、教育、保守、セキュリティ、契約終了時のデータ返却まで確認してください。レンタル業の業務状態を理解し、発注側と一緒に要件を育てられる委託先を選ぶことが、導入後に使われるシステムにつながります。

▼全体ガイドの記事
・レンタル業向け貸出返却管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。