家賃管理システム開発の発注/外注/依頼/委託方法について

家賃管理システムの発注は、業務と例外処理を整理して要件を決め、委託先を比べ、受入テストへ至る流れで進めます。特に例外処理は、後から追加すると費用と納期を膨らませる原因になるため、発注前の確認が要ります。この流れで進めると、月次業務が安定します。

▼全体ガイドの記事
・家賃管理システム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

家賃管理システムの発注・外注の始め方

家賃管理システムの発注は、現場の困りごとを洗い出すことから始めます。そのうえで、標準クラウドで足りる範囲と開発が必要な範囲を分けます。

「何を作るか」だけを先に決めると、日割り計算や一部入金、保証会社の立替、オーナー送金などの例外処理が、後から追加されることになります。途中での追加は、費用と納期を膨らませる原因になります。そのため、発注前に業務ルールを確認しておきます。

家賃管理の中核業務3つの絞り込み

月次業務を回すうえで中核になるのは、契約条件の管理、請求と消込、オーナーへの精算の3つの機能です。

• 契約条件：賃料、共益費、駐車料、更新料、保証料などの契約への紐付け。
• 請求と消込：入金の取り込みと、請求額・入金額の照合。
• オーナー精算：精算明細から送金までを正確につなぐ流れ。

いずれかが止まると、月次の締めが成り立ちません。そのうえで、物件・建物・部屋・駐車場は、それぞれ別々の台帳で管理します。入居者、連帯保証人、オーナーは、別の台帳で管理します。

未入金や一部入金は一覧にし、精算明細までつなげる設計が要ります。

例外処理の事前確認

請求額や精算額がずれる場面は、契約、入金、退去の面ごとに洗い出します。

• 契約変更：月途中の開始・解約、日割り、フリーレント、賃料改定、更新。
• 入金：敷金充当、保証会社の立替、一部入金、滞納損害金。
• 退去・契約区分：原状回復費、費目ごとの消費税、住居・駐車場の別契約。

担当者の「普段はこうする」という話だけで終わらせず、実例で検証します。過去の請求書、入金明細、精算書から、代表的な20〜50件を選びます。そのうえで、各ケースの正しい結果を期待値として残します。

家賃管理システムの発注形態の選び方

発注形態は、既製クラウドや業界パッケージから、既存基幹の機能追加、フルスクラッチまでを候補にして検討します。

判断の基準は、管理戸数や独自の家賃計算です。既存データ、必要な連携、運用変更への許容度も見ます。初期費用だけで選ぶリスクを減らすため、この観点で比べます。

標準化を進めたい会社に向くクラウドSaaS

クラウドSaaSは、サーバーの調達や保守を自社で抱えずに済み、比較的短期間で使い始められる方式です。

• 複数拠点：同じ画面を複数の拠点で使いたい会社。
• 段階移行：Excelから少しずつ移行したい会社。
• 保守体制：法改正やサービス更新を自社で追う体制がない会社。

独自の精算ルールが標準機能に合わない場合は、運用を合わせるか、追加費用を払って連携・カスタマイズする必要があります。

契約前に確認するのは、データのエクスポート形式と解約時の返却方法です。さらに、バックアップや障害時の連絡方法も対象になります。

パッケージの設定と追加開発

業界パッケージを核に、帳票、権限、ワークフローを足せます。銀行・会計連携も、追加の対象になります。そのため、フルスクラッチより標準機能を活用しやすい方式です。

見積書では、標準設定と設定変更、API連携、個別開発を分けてもらいます。

オプション費用は、管理戸数やユーザー数で生じる場合があります。電子契約、ストレージ、口座振替でも生じることがあります。デモで見た機能が無料かどうかは、条件を確かめて判断します。

独自ルールが競争力になる場合のスクラッチ開発

標準サービスで要件を満たせない場合は、スクラッチ開発を検討します。そうなりやすいのは、独自の計算や制度に伴う精算、既存基幹との深い連携がかかる場面です。

• 独自計算：標準機能で対応できない賃料計算。
• 制度・法人：自治体制度や複数法人の精算。
• 既存連携：基幹システムとの深い連携。

自由度が高い分、要件定義、テストデータ、保守契約を発注者が管理します。

仕様書と担当者変更時の引き継ぎも、発注者の役割です。

SCSKの自治体向け事例では、市営住宅の建物・駐車場、申込者、入居者を扱っています。さらに、家賃計算と収納管理も対象です。

複雑な制度改正に向けてルールを洗い出し、400ルールと30％のルール共通化を実現しています（出典：SCSK「導入事例 – 地方自治体」）。

制度や計算式が多い案件では、変更箇所を追いやすい構成をRFPに指定します。

ルールをプログラムに埋め込まない設計も求めます。

家賃管理システムのRFPと要件整理で決める内容

RFPは、同じ前提で各社に比べてもらうための発注仕様書です。前提として、事業背景や現行業務、データ、機能を書きます。さらに、連携、移行、体制、納期、保守についても、対象と範囲を示します。

家賃管理では、機能一覧に加えて、月次締めの流れと例外処理を共有できるかが見積の精度を左右します。

RFPに書く現行業務と対象範囲

まず、管理規模と業務の前提を整理します。

• 物件規模：管理戸数、物件数、部屋・駐車区画数、法人・拠点数。
• 利用規模：利用者数、月次請求件数、入金チャネル、オーナー数。

業務の流れは、図にして整理します。前半は契約登録、請求、入金取込・消込、督促の順で、後半は更新・解約、退去精算、送金、月次報告、会計仕訳の順です。

担当部署と締め日も記録しておきます。

対象には、現行Excelのファイル名や列定義、紙帳票、手作業のチェック表も含まれます。

情報が不足すると、開発会社は一般的な業務を前提にします。その結果、後から必要な作業が判明し、認識差が生じます。

機能要件のMUST・SHOULD・WANTの区分

初回リリースの範囲を決めるため、機能の優先度を3段階に分けます。

• MUST：契約条件、請求、入金消込、滞納、精算、権限、履歴、帳票。
• SHOULD：更新対象抽出、督促・修繕履歴、会計連携、電子契約。
• WANT：入居者・オーナーアプリ、分析画面、AI問い合わせ回答。

MUSTは、止まると月次業務が成立しない機能です。

便利な機能は、コア業務の検証後に第2段階へ回すこともできます。

GMO ReTechは、AI返信アシスタントや入居者Web版、ワークフロー機能などを案内しています。

GMO ReTechの例では、家賃計算からコミュニケーションを含むDXへと対象が広がっています（出典：GMO ReTech「GMO賃貸DX」の公開情報）。

連携・データ移行・非機能要件の明記

連携、移行、非機能要件は、対象と決定者を明記します。

• 連携：銀行、保証会社、会計などの接続先と、方式・頻度。
• 移行：物件、部屋、契約者、オーナー、契約条件、入金・滞納履歴、帳票と移行時点。
• データ整備：Excelの空欄、重複名義、住所の揺れ、退去済み契約の扱いは、発注者が決める。
• 非機能：利用可能時間、復旧目標、バックアップ世代、同時利用者数、応答速度、スマートフォン対応。
• 安全・運用：権限、二要素認証、操作ログ、暗号化、データ返却、再委託先、サポート窓口。

連携先の範囲は、ネットバンキング、口座振替、全銀振込に加えて、電子契約やCRMまで含めます。さらに、エラー時の再処理方法も決めておきます。

IPAの「中小企業の情報セキュリティ対策ガイドライン第4.0版」には、クラウド安全利用、外部情報サービス管理、インシデント対応などの付録があります（出典：IPA、2026年公開の第4.0版）。

家賃・契約者・口座情報を扱うため、セキュリティは委託先に任せず、RFPの評価項目に入れます。

家賃管理システムの契約形態：請負と準委任の使い分け

完成の範囲と責任を明確にできる工程には請負を使います。一方、要件を一緒に検証しながら進める工程には準委任が適します。

工程ごとに組み合わせる形もあります。たとえば、要件定義と現状分析は準委任、仕様確定後の開発とテストは請負、稼働後の改善は準委任とします。

契約形態は、名称だけでなく契約書と個別仕様書で確認します。確認するのは、何を納めるか、作業範囲、検収、変更管理です。さらに、瑕疵対応、知的財産、再委託も見ます。

請負契約の仕様・検収・変更条件

請負契約は、受託者が作業を完成させ、発注者が検収する前提の契約です。そのため、検収範囲と仕様変更の扱いをあらかじめ定めます。

• 検収範囲：家賃計算、請求・入金消込、オーナー精算、権限、帳票、エラー処理、移行結果。
• 仕様変更：月途中解約、既存帳票、銀行連携の変更を、無償・別見積・納期変更のどれで扱うか。

仕様が曖昧なままだと、発注者は追加費用を、受託者は想定外の作業を抱えることになります。その結果、双方の不満につながります。

準委任契約の役割と作業時間の管理

準委任契約は、専門家の作業や支援を一定期間依頼し、要件整理や設計を共同で進める場合に適します。

完成条件が決まっていない初期段階や、既存システムを調査する段階、移行方針を作る段階で使いやすい契約です。稼働後の改善にも使えます。

作業時間や体制に応じて費用が発生します。加えて、発注者側にも業務知識が必要です。

• 週次確認：進んだ作業の内容、課題、判断待ち事項、次週の作業予定。
• 発注者側：責任者と現場メンバーの稼働も、計画に含めること。

契約前に確認するデータと仕様の所有権

顧客や契約の情報、入金履歴、帳票データについて、帰属と利用範囲を確認します。

• クラウド：CSV・画像・帳票の返却時期と形式、データ消去の確認方法。
• 個別開発：ソース、設計書、テスト仕様書、環境設定、外部契約の管理者。
• 再委託：委託先の範囲、アクセス権限、事故時にどこまでを誰が受け持つか。

家賃管理システムの発注費用・外注費用の相場

費用は、管理戸数と機能範囲に加えて、移行、連携、帳票、カスタマイズ、導入支援によって変わります。公開料金と、一般的な業務システムからの推定は分けて考えます。

2026年8月時点の公開情報では、小規模なクラウド導入の初期費用は約5万〜50万円、月額は約3,000円〜8万円が一つの目安です。

料金の単位は、区画、戸数、法人、ユーザーなど、サービスによって異なります。

公開料金の条件をそろえた比較

公開料金は、区画数や初期費、税をそろえて見ます。機能範囲も、同じ条件にそろえて比べます。

• 料金単位：区画数や戸数など、各社の前提をそろえること。
• 費用の範囲：初期登録、追加機能、移行代行の区別。
• 機能差：台帳機能か、入出金・督促・送金・会計連携を含むか。

株式会社BambooboyのReDocSは、公式料金ページで、100区画の月額2,980円と500区画の月額6,980円を掲載しています。1,000区画の月額は12,480円です。

初回登録料は49,800円です。ただし、この価格は掲載時点の税別で、追加機能や移行代行の条件は別に確認します。

いい生活の家賃管理タイプは、公開例で1,000戸・区画を前提に、月額78,000円から、初期設定500,000円からです（出典：各社公式料金・サービス紹介ページ、2026年8月確認）。

価格差は、台帳機能に限るか、業務基盤まで含むかによって生じます。

中規模導入の初期費用と月額費用の内訳

中規模の見積は、規模と追加機能、費目、利用期間に分けて整理します。

• 基本範囲：管理戸数1,000〜5,000戸、権限、帳票、入出金、会計、オーナー報告。
• 追加要件：口座振替、データ整備、複数銀行、API、帳票変更、電子契約、アプリ。
• 費目：初期設定、環境構築、ユーザー登録、移行、研修、連携、保守、サポート、追加ストレージ、口座振替手数料。
• 総保有コスト：初期費用、月額、オプション、連携費、移行費、社内運用費、保守費を5年間で試算。

5年間の総保有コストを費目ごとに計算しておくと、経営会議でも比べやすくなります。

公開価格の近似例では、初期費用90万〜500万円、月額5万〜15万円程度が見積の出発点になります。なお、これは統一された市場統計ではなく、管理戸数別のマンション管理システム価格例を近似値として整理したものです。

口座振替やデータクレンジング、複数銀行、API、帳票変更を追加する場合、初期費用は100万〜800万円程度まで広がり得ます。電子契約や入居者・オーナーアプリも、同じ追加要件に含まれます。

月額だけで比べると、データ移行や帳票の追加によって、総額の順位が逆転することがあります。

スクラッチ開発の1,000万円単位の推定

スクラッチや基幹との大規模連携では、概ね1,000万〜3,000万円以上を見込む場合があります。この金額は、要件定義、設計、開発、テスト、移行を含む推定です。

• 推定の参考値：小規模300万〜700万円、複数領域1,500万〜4,000万円。
• 人月単価の参考値：エンジニア月額80万〜120万円。
• 試算時の要件：家賃計算、金融連携、帳票、権限、監査との照合。

上記は、NotebookLMによる業務システム一般の調査を、家賃管理の要件に照らして推定したものです。家賃管理に固有の公表相場ではありません。

案件の複雑さによって金額は上下します。そのため、ここで示した目安を、そのまま予算の確定額にしないことが大切です。

家賃管理システムの委託先の選び方

委託先は、知名度や営業資料だけでなく、自社の業務範囲に合うかで選びます。

家賃管理の導入、賃貸管理全体の刷新、接点のデジタル化、独自開発のどれを目指すかで、候補が変わります。

候補を3〜5社程度に絞り、同じRFPとテストケースを渡します。そうすると、機能表だけでは分からない適合性も比べられます。

委託先の得意領域と自社の課題の照合

自社の課題に合わせて、委託先の得意領域を選びます。

• 不動産SaaS：標準業務、拠点統一、法改正への対応。
• 小規模クラウド：少数区画から拡張。独自帳票や複雑な精算は要確認。
• アプリ・対応支援：オーナー報告や入居者対応。家賃計算の担当範囲も確認。
• 独自開発：自治体制度や独自ルールを整理し、保守できる会社。

実際の業務ケースを使ったデモ

デモは、ベンダーが用意したサンプルではなく、自社に近いケースを使って依頼します。

• 月次処理：一括請求と銀行入金の自動消込。
• 例外処理：一部入金、滞納、月途中の開始・解約、日割り。
• 精算と会計：退去精算、オーナー送金、会計仕訳、帳票訂正。

入力から帳票までに必要な承認者を確認します。

誤った消込の取消方法や、締め後の修正履歴も確かめます。

例外処理や訂正が手作業に戻るなら、画面が使いやすくても、発注の目的を満たしません。

導入支援と稼働後の保守体制の評価

導入後の運用は、ベンダーの支援と保守の体制に左右されます。契約前に、次の点を確認します。

• 導入支援の範囲：初期設定、データ移行、操作研修、月次締めのリハーサルが含まれるか。
• 問い合わせ・運用支援：問い合わせ窓口、マニュアル、運用変更の支援。
• 面談の相手：営業担当だけでなく、要件定義、開発、移行、サポートの責任者。
• 稼働後の対応：対応時間帯と担当者。
• 契約終了時の引き継ぎ：データ返却、API停止、追加開発の引き継ぎ。

これを導入時から確認しておくと、ベンダー変更時のロックインのリスクを抑えられます。

家賃管理システムの見積比較で確認するポイント

見積は、合計金額の安さではなく、同じ業務範囲と前提で比べます。RFPの要件が、見積書のどの項目に対応するかを確認します。

見積書の未回答や前提条件、別途費用、納期に影響する発注者作業を洗い出します。

「標準機能で対応」とあれば、画面、帳票、権限、エラー処理、運用手順のどこまでかを尋ねます。

工程・機能・費目の3方向での見積書の分解

見積項目を、工程・機能・費目の3方向から並べて照合します。

• 工程：要件定義、設計、開発、連携、移行、テスト、研修、リリース、保守。
• 機能：契約・物件台帳、請求、入金消込、滞納、更新・退去、オーナー精算、帳票、権限、会計連携。
• 費目：初期費用、月額、ライセンス、環境、外部サービス、移行、追加開発、交通・研修、保守。

3方向を掛け合わせると、安く見える理由や、高額になっている要件を説明できます。

データ移行と発注者側の作業の確認

移行費用に、ファイルの取り込みだけでなく、移行に必要な作業が含まれるかを確認します。

• 移行作業：項目定義、名寄せ、重複削除、欠損補完、変換、検証、リハーサル。
• 対象範囲：テーブル、件数、履歴期間、画像・添付、移行回数。
• 発注者作業：データクレンジングの範囲と、業務上の正解の決定。

見積が「データ移行一式」となっている場合は、対象範囲の具体的な内訳を尋ねます。

発注者の担当者が月次締めや受入テストに参加できないと、ベンダー側の作業が止まることがあります。そのため、社内の工数も予算とスケジュールに含めます。

安すぎる見積と高すぎる見積の理由の確認

金額の差が出る理由を、見積の範囲と方式から確認します。

• 安い見積：要件定義、移行、帳票、テスト、研修、保守の漏れ。
• 高い見積：スクラッチの必要性、標準機能・APIでの代替、将来機能の一括計上。

NotebookLMによる業務システム一般の整理では、請負は仕様変更リスクが反映され、準委任より1.3〜1.5倍程度高い傾向とされます。

これは家賃管理システム固有の統計ではありません。そのうえで、契約方式と見積の関係を説明してもらい、金額だけで優劣を決めないようにします。

発注時の法令・セキュリティ・運用継続の確認

家賃管理システムは、個人情報、契約書、口座情報、家賃・敷金などの金銭情報を扱います。

そのため、発注時には、業務効率化の機能に加えて、情報へのアクセスと変更を追跡できる仕組みも要件に入れます。

賃貸住宅管理業に該当する会社は、法令上の業務や帳簿、報告をシステムで支えられるかを確認します。この確認は、法務、経理、現場責任者と一緒に進めます。

賃貸住宅管理業法の要件の業務フローへの落とし込み

国土交通省は、管理戸数200戸以上の事業者に登録を義務付けています。また、営業所・事務所ごとの業務管理者は1名以上です。

管理受託契約前の重要事項説明と契約時の書面交付、財産の分別管理も対象です。さらに、オーナーへの少なくとも年1回以上の定期報告と、帳簿の備付けも対象になります（出典：国土交通省「賃貸住宅管理業法ポータルサイト」）。

システムで支える業務要件は、次のように整理できます。

• 金銭管理：固有財産と受領金銭を区別する口座・帳簿。
• 契約単位：管理受託契約ごとの入出金管理。
• 報告・保存：報告書作成履歴、書面保存期間、承認者。

法令上の判断は、専門家にも確認します。

システムを導入しただけで法令遵守が完了するとは考えないことが大切です。

MFA・権限・ログ・バックアップの具体的な確認

セキュリティの運用と情報へのアクセスは、具体的に確認します。

• 認証・権限：二要素または多要素認証、管理者分離、退職者停止、IP制限。
• 保護・復旧：通信・保存時の暗号化、バックアップ頻度、復元テスト。
• 監視・対応：操作ログの保存・検索、脆弱性対応、障害連絡体制。
• 重要情報：口座情報や契約書の閲覧・出力・ダウンロードを権限で分け、オーナー送金前の承認を残す。

IPAのガイドラインは、クラウドの安全利用やインシデント対応を扱っています。委託先への質問項目としても活用できます（出典：IPA「中小企業の情報セキュリティ対策ガイドライン第4.0版」）。

稼働後のKPIと月次締めによる定着の判定

導入後は業務の改善指標を月単位で記録し、新旧の月次締めを照合します。

• 処理実績：入金消込時間、未収発見日数、精算訂正件数、手入力件数。
• 対応品質：報告書作成時間、問い合わせ一次回答時間、移行後のデータ不備件数。
• 締め照合：請求・入金総額、未収残高、送金額、会計仕訳の差額。

最初の1回は、新旧システムを並行稼働します。差額を説明できた段階で旧システムを停止すると、月次締めの混乱を抑えられます。

家賃管理システムの発注・外注でよくある質問

発注前は、既製サービスと開発の境界、見積の妥当性、移行方法、契約後の保守で迷いがちです。

比較検討の場面でよく出る質問に、発注者が判断しやすい形で答えます。

家賃管理システムは既製品とスクラッチ開発のどちらがよいですか？

多くの会社では、標準クラウドや業界パッケージを先に比べて、独自ルールや既存連携だけを追加する方法が現実的です。

スクラッチを検討するのは、標準機能で要件を満たせない自治体制度や複雑な精算に限られます。

判断は、保守、移行、仕様書を含む総コストで行います。

発注前に何社くらいから見積を取ればよいですか？

RFPとテストケースをそろえ、3〜5社程度から見積を取ると比較しやすいです。

候補数を増やすより、各社に同じ条件で実演してもらいます。実演するのは、家賃の一括請求、入金消込、滞納、退去精算、オーナー送金です。

金額、適合性、導入支援、保守体制を評価します。

Excelからのデータ移行はベンダーに任せられますか？

Excelからの移行作業は、ベンダーに依頼できます。一方で、移行後のデータが正しいかの判断は発注者が担います。そのため、移行前に次の4点を合意しておきます。

• 移行対象と名寄せルール：移行する範囲、履歴期間、名寄せの取り決め。
• 空欄・重複・画像・帳票：それぞれの扱いの取り決め。
• 照合：テスト移行と本番移行の2回以上で、件数・残高・代表契約を照合。
• 差異の承認：移行後の差異を誰が承認するか。RFPと契約に含める。

家賃管理システムのセキュリティは何を見ればよいですか？

二要素認証、権限分離、操作ログ、暗号化を確認します。加えて、バックアップと復元テスト、障害対応、再委託先、データ返却・消去も見ます。

口座情報や契約書の閲覧・出力を誰に許可するか、退職者アカウントの停止時期、送金承認の履歴も質問します。

具体的な運用まで確認すると、「安全です」という一般的な説明だけに頼らない評価ができます。

まとめ

発注前に決める業務と要件の責任者

現場、経理、法務、情報システムの代表者を決めておきます。そのうえで、契約条件、入金消込、オーナー精算、移行、セキュリティの判断を一つのRFPにまとめます。

標準機能で合わせる業務と、追加開発する業務を分けます。

同じテストケースで委託先を比べることが、予算と納期を守る出発点になります。

発注後の月次締めと改善指標の確認

発注後は、業務ケースの受入テストと月次締めを経てから本稼働します。

• 中核業務：契約条件、請求、消込、滞納、オーナー精算を優先する。
• 方式・要件：標準クラウドなどの選定と、業務・連携・移行・安全要件のRFP化。
• 見積比較：費目の区分と、3〜5社への同じテストケースの提示。
• 受入テスト：代表契約での日割り、滞納、退去精算、送金、会計仕訳の検証。
• 定着確認：消込時間、未収発見日数、訂正件数、帳票時間、問い合わせ件数の追跡。

新旧システムを並行運用し、差額を説明できる状態にします。要件と契約・データについて、どこまでを誰が受け持つかを明確にすると、属人化や精算ミスを減らし、管理戸数の増加にも対応しやすくなります。

▼全体ガイドの記事
・家賃管理システム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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