宿泊予約管理システムの発注は、まずPMS・サイトコントローラー・予約エンジンの役割と発注範囲を整理し、業務と連携の要件をRFPに書くところから始まります。そのうえで発注形態と契約条件、受入れ基準を決めてから導入すると、現場に合う運用につながります。
▼全体ガイドの記事
・宿泊予約管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
宿泊予約管理システムを発注する前に整理すべき全体像
宿泊予約管理システムは、単独の予約フォームではなく、宿泊施設の販売と現場オペレーションをつなぐ業務基盤です。発注の最初に「何を作るか」だけを話すと、見積の抜け漏れが生じやすくなります。「予約情報をどの部門へ、いつ、どの形式で渡すか」まで決めておくと、こうした漏れを減らせます。
PMS・サイトコントローラー・予約エンジンの違い
発注範囲を決めるには、3つのシステムの役割を分けて捉えることが大切です。
- PMS：施設内で予約、顧客、客室、部屋割り、売上を管理する業務システム
- サイトコントローラー：楽天トラベル、じゃらん、Booking.com、自社サイトの空室・料金・予約情報を一つにつなぐ役割
- 予約エンジン：宿泊者が自社サイトでプランを選び、予約を完了するための画面
この3つを一括で「予約システム」と呼ぶと、委託先の責任範囲が不明確になります。そこでRFPでは、予約受付、在庫反映、変更・キャンセルを機能単位に分けて書きます。
客室割りやチェックイン、会計、清掃、分析も、同じ単位で整理します。また、各機能は標準機能、設定対応、API連携、個別開発の4区分で記すと、委託先ごとの提案を比べやすくなります。
予約部門から現場までの業務範囲
予約部門だけで業務範囲を決めると、現場で必要な作業が見積から抜けてしまいます。そのため、発注前に担当部門、予約変更時の連動、繁忙期の例外を整理しておきます。
- 担当部門：予約担当、フロント、清掃、調理場、経理、施設責任者まで含む範囲
- 予約変更時の連動：客室在庫、食事数、送迎、清掃指示、決済金額、顧客への通知の順に、どこまで連動するかを確認します
- 繁忙期の例外：団体予約、連泊、部屋タイプ変更、ノーショー、電話予約の扱い
観光庁が2026年に公開した令和7年度のIT活用事例集では、PMSとサイトコントローラーで業務を一つにまとめて管理する例が紹介されています。リモートロック、電子マニュアル、施設管理アプリも省力化の取り組みです（出典: 観光庁「宿泊施設のためのIT活用事例集」令和7年度）。
このため、発注対象は予約画面に限らず、情報が現場で使われる範囲まで定義します。
発注形態の選び方と、パッケージ・クラウド・スクラッチの比較
発注形態は、施設規模、独自業務、導入期限、運用体制を基準に選びます。標準的な予約と客室管理なら、クラウドPMSとサイトコントローラーが候補になります。一方で、複数施設の独自料金や会員制度を統合する場合は、既存サービスを中心に追加開発する方式が現実的です。
標準業務を早く整えたい施設のクラウド型・パッケージ型
クラウド型・パッケージ型は、導入速度、保守負担、標準機能との適合の3点で見ます。
- 導入速度：予約台帳、在庫、料金、顧客管理、帳票が用意されているため、稼働までを短く抑えられます
- 保守負担：サーバー保守や機能更新を自社で抱えにくい点が利点です
- 標準機能との適合：特殊在庫、複合施設の料金計算、既存会計連携が不足すると、追加費用や業務変更が必要になります
楽天トラベルサービス株式会社の「ねっぱん！サイトコントローラー＋＋ 料金」では、初期設定料が55,000円、月額が6,600円または10,780円と示されています。料金表は2025年5月以降のものです。
ただし、PMS連携とセルフチェックイン連携には別途、初期費用と月額費用がかかります。公開価格があっても、PMS本体、決済、端末、設定支援を含めた総額で比べる必要があります。
クラウドと追加開発の組み合わせ
標準機能をクラウドで使い、独自部分をAPIや周辺システムで補うと、費用と柔軟性を両立させる形になります。
- 追加する機能：独自の予約導線、会員連携、分析、社内承認フローを、APIや周辺システムで補う部分
- データの中心：施設追加を見据え、PMSと独自基盤のどちらを中心に置くかを決めます
- 移行条件：データ返却形式、API利用条件、連携仕様の公開範囲、契約終了後の支援
予約や顧客のデータについては、持ち出し形式をRFPと契約書に残します。料金や決済、操作ログも、同じ書面で扱いを決めておきます。こうしておくと、将来の施設追加時に、顧客や予約を二重管理するリスクを避けられます。
スクラッチ開発の独自性と運用責任
スクラッチ開発は、独自の業務をどこまで組み込めるか、稼働後の運用を誰が受け持つか、検証をどこまで行うかで判断が変わります。
- 実現性：独自の部屋、料金、会員、クーポン、複合サービスを組み込める方式
- 連携：既存の基幹システムとの複雑な連携に向く方式
- 継続責任：重複予約、OTA仕様変更、決済、障害監視、セキュリティ更新、24時間運用を、発注側と開発会社が担います
- 小規模検証：主要機能に絞ったPoCや1施設のパイロットで、実データの操作時間とエラーを測ります
画面ができたあとも運用は続くため、保守契約と改善予算を含めて選ぶ必要があります。また、選定の際は、クラウド導入、追加開発、スクラッチの3案を同じRFPで比べ、初期費用と将来の負担を確かめます。
RFPと要件整理の進め方
RFPと要件整理は、機能一覧より先に、現場の流れ、課題、導入後の指標を整理します。見積を出してもらうために書くべきことは、画面の細部よりも、この3点です。
まず、対象施設、予約経路、客室数をそろえます。次に連携先と例外処理を書き、最後に納期と予算を添えると、提案の前提が明確になります。
現状業務と例外処理の整理
現状業務は、予約からチェックアウトまでの流れと例外処理に分けて図にします。
- 業務の流れ：担当者、使用帳票、入力データ、判断が必要な箇所を整理します
- 例外処理：電話予約、OTA取込、キャンセル料、部屋タイプ変更、複数室予約を含めます
- 追加ケース：子ども料金や食事・送迎の追加など、通常と異なる条件も記します
RFPには、施設数、客室数、部屋タイプ数を書きます。さらに、月間予約件数やOTA、自社予約比率を書き、スタッフ数と利用時間帯も添えます。既存のPMSや会計、鍵、決済も記載します。
導入前には、予約入力時間や二重予約件数、フロント待ち時間、変更時の転記回数を測っておきます。そうしておけば、導入後の効果を数値で確かめられます。
必須機能と希望機能の分け方
機能要件は、対象業務と必要時期で分けて、優先順位を付けます。
- 対象業務：予約、在庫・料金、客室割り、顧客、チェックイン、決済、清掃、帳票、権限、分析を、業務ごとに整理します
- 稼働初日：初日から必要になる必須機能を決めます
- 追加時期：3か月以内に追加する機能と、将来検討する機能の区別
非機能要件では、同時利用者数や繁忙期の処理速度を決めます。バックアップ頻度と復旧目標、監視、ログ保存も含めます。さらに、スマートフォン、多言語、アクセシビリティ、サポート時間も定めます。
予約連携では、通信が失敗したときの二重登録や在庫の戻し忘れに備える必要があります。そのため、再送と重複排除を定め、処理結果の確認画面や手動復旧も用意しておきます。
連携・データ移行・セキュリティの要件
連携要件は、対象システム、データの流れ、対応方式に分けて書きます。
- 連携内容：送受信データ、方向、頻度、障害時の扱い、費用、仕様変更時の責任を記します
- 対象先：OTAの在庫・料金・予約、決済、会計、スマートロックを含めます
- 現場通知：セルフチェックイン、清掃、厨房への通知が対象です
- 対応方式：各連携先を、標準連携、有償オプション、個別APIのいずれかに分類します
顧客名や住所、電話番号を含む情報を扱うため、役割別の権限を設定する必要があります。宿泊履歴や同行者、決済情報も、この対象に入ります。
そのうえで、操作ログや暗号化、バックアップについても確認します。MFA、脆弱性対応、再委託、契約終了時の削除・返却も、確かめておきます。
個人情報保護委員会の「個人情報保護法ガイドライン（通則編）」は、委託先の安全管理措置を事前に確認するよう示しています。あわせて、委託契約には、合意した安全管理と取扱状況の把握を盛り込むことが望ましいとしています。
契約形態の使い分け：請負・準委任・SaaS利用
契約形態は、成果物と責任範囲をどこまで確定できるかで選びます。
開発会社に一括で任せる場合でも、要件定義と開発、保守、SaaS利用を同じ契約にまとめるのは避けます。検収や変更管理の単位を分けておくと、問題が起きたときに責任の所在を追えます。
請負契約：合意した成果物の納品
請負契約では、成果物と変更時の扱いを事前に決めます。
- 契約の中心：合意した仕様のシステムを完成させて、検収後に納品する形
- 成果物：契約書に画面、API、帳票、移行データ、操作マニュアル、テスト結果を明記する
- 仕様変更：追加費用と納期変更の決め方を、契約前に合意しておく
検収は、予約登録・変更・キャンセル、在庫反映、決済失敗のシナリオで定めます。二重送信や権限エラーのシナリオも、同じように検収の対象に含めます。瑕疵対応期間や障害の優先度、必要なログ、修正期限は、契約書や仕様書に残しておきます。
要件が変わるプロジェクトの準委任契約
準委任契約は、要件を進めながら具体化する作業に向いています。一方で作業時間を提供する契約になりやすいため、成果の確認方法も定めます。
- 依頼する内容：専門家の作業やプロジェクト推進を、一定期間任せる形
- 適する場面：現場ヒアリング、業務整理、RFP作成、ベンダー比較、PoC、アジャイル開発
- 進捗管理：成果の確認方法、会議体、担当者、月ごとの到達点を決めます
発注側の意思決定が遅れると、期間と費用がそのぶん伸びます。そのため、週次の課題一覧や決裁期限、未決定事項の扱いを決め、優先順位を変える権限者も定めておきます。受託側に任せきりにせず、現場代表と経営判断者を一人ずつ置くと、使いやすさと投資判断を両立させられます。
SaaS利用契約のサービス範囲とデータの扱い
SaaS利用契約では、サービスの提供範囲、料金単位、データの扱いを確認します。
- 提供範囲：月額・年額で利用し、サーバーや更新、標準機能の保守は提供会社が担う
- 料金単位：施設数、客室数、ユーザー数、予約件数のどれで決まるか
- 年間総額：初期設定、連携、サポート、解約、データ出力まで含めた金額
- 追加料金：月額定額でも、PMSやセルフチェックイン連携が別料金になる場合がある
契約書では、停止通知や障害連絡、バックアップの扱いを見ます。保管場所や再委託、海外移転に加えて、解約後の保存期間と返却方法も確かめます。予約データには個人情報が含まれるため、委託先の監督と事故対応も契約に盛り込みます。
宿泊予約管理システムの費用相場と見積の内訳
費用は、利用料や初期設定、追加連携に分けて考えます。機器、移行、教育、保守の費用も、別々に確かめます。クラウドの公開価格は、比較の起点として使えます。
個別開発の費用は、施設数や客室数、連携数によって変わります。料金ルールやセキュリティ、移行量、運用時間も影響するため、一律の金額では示せません。
クラウド導入の公開価格と追加費用
公開価格の例は次のとおりです。これらから、クラウド導入の初期費用と継続費用の幅を確かめられます。
- ねっぱん！サイトコントローラー＋＋：公開料金を比較の材料として扱う
- PMS連携：月額1,100円から6,600円です
- セルフチェックイン連携：月額3,300円または6,600円です
- OMOTENASHI：室数に応じた料金体系です
ねっぱん！の料金表では、初期設定料が55,000円、月額が6,600円または10,780円です（出典: 楽天トラベルサービス株式会社「料金一覧」、2025年5月以降）。OMOTENASHIは1〜10室の場合、初期280,000円、月額30,000円です。11室以上は、1室ごとに加算する方式です（出典: 株式会社OMOTENASHI「宿泊予約システム・PMS」）。
小規模施設の公開料金は、初期5.5万〜30万円、月額1万〜5万円程度が比較の入口です。機能やサポート条件が違うため、一律の相場とは扱いません。また、これはサイトコントローラーの料金で、PMS本体や決済手数料、端末代、設置工事は、この金額に含まれていません。
要件で変わる個別開発の費用幅（300万円台から3,000万円超）
個別開発の公開料金は少ないため、次の金額は、施設・現場サービスの相場と、予約、PMS、OTA連携の要件から整理した推定です。
- 300万〜700万円程度：予約台帳、客室割り、顧客管理を中心とするMVPです
- 700万〜1,500万円程度：自社予約エンジン、PMS、主要OTA連携、決済、帳票を含みます
多施設や複雑なレベニューマネジメント、会計・鍵・清掃・多言語API、24時間監視まで含むと、1,500万〜3,000万円超となる可能性があります。期間も9〜18か月以上になる場合があります。
この推定には、要件定義、UI設計、API連携、データ移行、テスト、教育が含まれます。固定の市場価格ではなく、要件を前提にした推定として扱います。ただし、機器購入、決済手数料、OTA側の審査、保守・クラウド費用は、別見積もりになる場合があります。
初期費用と3年間の総保有コスト
費用項目をそろえたうえで、3年間の総額と、変更時の単価を確かめます。
- 導入費：初期開発、データ移行、現地作業、教育の金額
- 継続費：月額利用料、保守、サポート、クラウド、連携オプションを含めます
- 機器費：端末、鍵、セルフチェックイン機器の費用を確認します
- 変更単価：施設やユーザーの追加、仕様変更、障害対応にかかる費用
標準機能に業務を合わせる範囲と、差別化に必要な追加機能は、分けて考えます。また、1施設で効果を測る段階導入も有効です。加えて、RFPでは必須、任意、将来拡張を分け、同じ条件で見積もってもらいます。
委託先の選定と見積比較の確認ポイント
委託先は、知名度や営業資料の印象だけでなく、宿泊業の例外処理と運用を理解しているかで選びます。
候補を3〜5社程度に絞り、同じRFP、同じデモシナリオ、同じ費用項目で提案してもらうと、会社ごとの得意領域と前提条件が見えます。
宿泊業の実績：施設規模と担当範囲
実績は、施設条件、担当範囲、導入効果に分けて確認します。
- 施設条件：導入社数、客室数、施設形態、OTA数を聞きます
- 担当範囲：導入期間、データ移行量、稼働後の支援体制
- 導入効果：予約入力時間、転記作業、重複予約、フロント対応がどう変わったか
事例の効果は施設条件に左右され、自社の効果と同じとは限りません。
予約管理だけでなく、セルフチェックイン、カードキー、清掃・調理場との情報共有までつなぐ提案が増えています。たとえば、株式会社クリップサイトは2026年3月、新苫小牧プリンスホテル「和〜なごみ〜」で連携開始を公表しました。
連携したのは、支配人くんNEXTとUSEN-ALMEX社の自動チェックイン機です（出典: 株式会社クリップサイト「USEN-ALMEX社自動チェックイン機との連携」、2026年3月12日）。機器連携だけでなく、故障時の代替手順も確かめます。
見積の工数・前提・除外項目
見積は、内訳、算定条件、除外項目をそろえて比べます。
- 内訳：要件定義、設計、開発、API連携、テスト、移行、教育、PM、保守ごとの金額
- 算定条件：工数・数量、単価、期間、成果物、担当範囲の前提
- 除外項目：「別途相談」「標準外」「実費」が発生する条件と上限を質問します
提案機能は、稼働に必須のもの、現場の効率化、将来の施策に分けて見ます。必須機能の価格と納期をそろえたうえで、他の機能を追加したときの差額をもとに、優先順位を判断します。
セキュリティ・保守・障害時の体制
セキュリティと障害対応では、確認する項目と、運用の責任者を決めておきます。
- 安全管理：脆弱性対応期限、バックアップ、復旧テスト、権限、監査ログを確認します
- 委託管理：データセンター、再委託先、個人情報の取扱い
- 障害対応：受付時間、一次回答、復旧目標、宿泊者案内、手作業への切替を定めます
提案書だけでなく、契約と運用手順にも対応方法を書き込みます。複数社に委託する場合は、どの担当がどの仕組みを監視するかを決めます。対象にはPMSやサイトコントローラー、決済、鍵、予約エンジンが含まれます。
観光庁の2026年公開資料が示すように、一つの仕組みに集めて管理することは省力化の手段になります。ただし、連携が増えるほど、障害時の原因を切り分けるのは難しくなります。そのため、連絡先やログの所在、復旧権限は、一枚の運用表にまとめておくと、現場が止まりにくくなります。
導入スケジュールと受入れテスト
導入工程は、要件定義、設計・設定、連携開発の順に進めます。そのうえで、移行、教育、稼働後支援を分けて行います。移行や教育を後回しにすると、初日に予約情報が合わず、スタッフが紙へ戻る恐れがあります。そのため、工程ごとに完了条件を設定しておきます。
要件定義からパイロットまでの段階
要件定義からパイロットまでは、段階ごとに工程と期間の目安を置きます。
- 0〜1か月で現状業務、データ、連携、権限、KPIを整理します。
- 1〜3か月でクラウド設定、画面設計、API確認、移行テストを進めます。
- 4か月目以降、実施設でパイロットを行う段階です。
個別開発や多施設展開は、4〜9か月、9〜18か月以上かかる場合があります。期間は、機能範囲と連携の難易度で変わります。
パイロットでは、実予約に近いデータを使い、取込、変更、キャンセルを試します。在庫や部屋割り、決済、帳票、清掃通知も、同じデータで確かめます。あわせて、連泊や団体、同名顧客、日付変更、通信断も確認できるよう、匿名化データや再現シナリオを用意します。
データ移行と教育
移行前には、対象データを決め、変換と照合の方法や旧台帳の扱いも定めておきます。
- 対象：未来の予約、顧客台帳、客室マスタ、料金・プラン、会員、未収金、宿泊履歴を整理します
- 変換と照合：出力・取込項目の差を確かめ、変換ルールと欠損の扱いを決めます
- 旧台帳：件数、金額、日付、在庫の照合と、保存期間・参照方法の決定
教育では、担当ごとに操作を分けます。対象は、予約担当、フロント、清掃、経理、管理者です。動画や画面付きの手順書に加えて、通信障害、決済失敗、二重予約、端末故障に備えた、紙と電話による代替手順も用意します。
稼働後30日、60日、90日にKPIを見直し、追加開発を判断します。
業務シナリオと合格基準による受入れテスト
画面の見た目だけでなく、予約後に現場が動けるかを確かめます。受入れテストは、予約から現場対応までの業務シナリオで行います。
- 自社サイトで予約し、OTAから別の予約を取り込みます。
- 部屋を割り当て、料金変更とキャンセルを行います。
- 決済・帳票に反映し、清掃や厨房へ通知します。
テスト結果は、担当者と再テストの期限とあわせて記録します。合格基準には、必須シナリオがすべて完了することを含めます。
予約情報の欠落がなく、在庫が意図せず増減しないことも、確かめておく必要があります。加えて、権限外の情報が見えず、障害時に手動で復旧できることも条件になります。
重大な未解決課題が残っている段階で繁忙期に切り替えることは避け、閑散期に稼働させて並行運用を行います。そのうえで、責任者のサインオフを経て、本番へ進みます。
よくある質問
宿泊予約管理システムの発注では、費用だけでなく、施設規模や現場の使いやすさも判断の材料になります。さらに、既存サービスとの連携、データの持ち出し、導入後の支援も含めて見ます。
発注前によく寄せられる質問について、実務上の判断の目安を先に示します。
小規模旅館はシステム開発を外注するべきですか？
10室前後までの施設で標準的な予約、在庫、顧客管理が中心なら、まずクラウドPMSとサイトコントローラーを比較する方法が現実的です。
一方で、独自の料金計算や複数施設の会員統合、特殊な予約受付が経営上の差別化になる場合は、標準サービスに追加開発を組み合わせます。また、最初から大規模なスクラッチ開発に進むより、1施設で検証してから広げるほうが、投資リスクを抑えられます。
RFPには最低限何を書けばよいですか？
まず、施設数や客室数、予約経路、月間予約件数を書きます。そのうえで、既存システムや必須機能、連携先、データ移行の条件を示します。希望時期と予算の考え方、保守・サポート条件も添えます。
団体予約や連泊、部屋変更などの業務シナリオも示します。キャンセル料や決済失敗、通信断の場面も含めます。特に、機能名だけを並べたRFPより、現場が何に困り、導入後に何を改善したいかが伝わるRFPのほうが、提案と見積の精度が上がります。
見積書の金額が会社ごとに違うときはどう比べますか？
まず、同じ要件と対象範囲で再見積もりを依頼し、内訳を並べます。内訳は、開発、設定、連携の費用から分けて見ます。移行、教育、保守、機器、クラウドの費用も、項目ごとに分けてもらいます。次に、見積に含まれない項目や、追加変更の単価、納期の前提、検収条件、障害対応を確かめます。
安さだけでなく、3年間の総保有コストや現場の操作時間まで含めて比べると、選定理由を社内で説明しやすくなります。将来の施設追加や契約終了時のデータ返却も、この比較に加えておきます。
発注契約で特に注意する項目は何ですか？
成果物や検収条件、仕様変更、納期遅延、瑕疵対応を確認します。あわせて、保守範囲や再委託、個人情報の扱いも確かめます。障害時の連絡、バックアップ、データ返却・削除は、契約前に決めておきます。
SaaSでは利用料の改定やサービス終了、請負では追加開発の扱い、準委任では月ごとの作業範囲と成果の確認が、特に注意したい点です。口頭の説明で済ませず、提案書や仕様書、契約書、運用手順に同じ内容を記載します。
まとめ
宿泊予約管理システムの発注では、最初にPMS、サイトコントローラー、予約エンジンの役割を整理し、現場の業務と例外処理をRFPに反映します。
標準業務はクラウドやパッケージで整え、独自性の高い部分だけ追加開発する方法なら、費用・納期・運用リスクのバランスを取りやすくなります。
発注前に決める業務範囲と責任範囲
費用と相見積もりは、次の条件をそろえて比較します。
- 費用項目：月額、初期設定、PMS・OTA連携、決済、機器、移行、教育、保守を含めます
- 個別開発の推定額：300万〜700万円、700万〜1,500万円、1,500万〜3,000万円超です
- 推定の前提：要件から算出した推定であり、固定の市場価格ではありません
- 相見積もり：施設規模と連携範囲を示して依頼します
小さく検証してからの本番展開
最後に、PoCや1施設のパイロットで検証します。予約取込や在庫反映、変更・キャンセル、部屋割りは、実予約に近いデータで確かめます。決済、帳票、現場通知についても同じ方法で検証し、導入前後のKPIを比べます。
委託先には、実績や見積の前提、契約条件を質問します。セキュリティや障害時の代替運用、契約終了時のデータ返却まで聞いたうえで、現場が使い続けられる体制かを確認します。
▼全体ガイドの記事
・宿泊予約管理システム開発の完全ガイド
▼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を創業。