旅行・観光業向け団体旅行管理システム開発の完全ガイド

旅行・観光業向けの団体旅行管理システムは、問い合わせから請求・精算までを案件単位でつなぎ、業務と収支を管理する業務システムです。業態、必要な機能、連携範囲に分けて検討すると、自社の目的に合うかを見極められます。

詳しい内容は、関連記事もご覧ください。

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

旅行・観光業向け団体旅行管理システムの全体像

案件単位で情報を共有すると、担当者間の引き継ぎにも役立ちます。

システムの中心は、案件の情報を一か所にまとめて動かす仕組みです。団体旅行管理システムは、問い合わせから見積、行程、手配、参加者、請求・精算までを案件情報につなぎ、変更と原価を管理する業務システムです。

案件情報には、団体名や旅行目的、人数、日程のほか、予算と仕入条件を入れ、参加者や対応履歴も同じ案件に残します。売上と原価も同じ案件単位で結び付け、担当者が状況と次の作業を確認できるようにします。一方で、個人旅行向けの予約管理や宿泊施設向けのPMSだけでは、複数の人・日程・仕入先にまたがる収支や変更を追いきれない場合があります。

案件カルテを中心にした情報のつなぎ方

案件カルテは、問い合わせから精算までの経緯を担当者間で共有する土台で、主に次の情報を集めます。

依頼内容：団体名、代表者、旅行目的、希望日、人数、国籍・言語、予算、宿泊・交通・食事の希望
手配と参加者：行程案、仕入先への依頼、回答期限、参加者名簿、変更履歴
請求・収支：請求書、仕入支払、売上、原価

情報をこの形で共有すると、担当者の受信箱や手帳に頼らずに済み、休暇や異動の際にも引き継ぎやすくなります。さらに、案件の状態を「問い合わせ」「見積中」「仮押さえ」「催行決定」「旅行中」「精算待ち」「完了」のようにそろえておけば、管理者は滞留している案件を把握できます。

団体旅行で導入効果が出やすい理由

団体旅行では、1件の受注に複数の担当者と仕入先が関わり、人数や日程が確定後も変わります。そのため、変更管理が重要になります。

変更の把握：最新版、変更者、変更日時、承認状態を残し、確認すべき差分を追う
原価の比較：見積時点の予定原価と催行後の実績原価を比べる
収支の判断：案件別の粗利やキャンセル損失を確認する

変更をメール本文や添付だけで管理すると、古い名簿で手配してしまったり、キャンセル条件を見落としたりするおそれがあります。

業態ごとの向き不向き

選定では、会社の規模よりも、どの業態の案件をどう処理するかで見るとよいです。業態によって、必要な項目と現場の責任分担は異なります。

想定するのは、訪日団体や修学旅行、社員旅行です。ほかに、募集型企画旅行、観光バスの団体営業、宿泊施設の団体営業も扱います。デモでは、自社の代表案件を最初から最後まで再現できるかを確認してください。

訪日団体・DMCの多言語対応とシリーズ運用

訪日団体では、言語や地域をまたぐ行程を扱うとともに、シリーズ案件の変更と手配状況をまとめて管理します。

多言語対応：海外エージェントの依頼、英語などの帳票、国籍・言語、食事制限、ガイド
行程とシリーズ：複数地域の行程と、複製した行程・タリフの日付や人数変更
依頼状況：依頼、回答待ち、確定、変更、キャンセルの一覧管理

シリーズ案件では同じ内容のツアーを複数回催行するため、行程やタリフを複製して日付と人数だけを変えられるかどうかで、造成の負担が変わります。

実務では、メールやFAXで届く依頼を保存するだけでなく、状態を一覧で追えるかが問われます。

修学旅行・社員旅行の名簿と安全情報の扱い

名簿や安全情報は、必要な担当者が必要な情報だけ参照できるようにします。

管理する情報：参加者、代表者、部屋割り、座席、食事制限、アレルギー、緊急連絡先
権限と帳票：営業・手配・添乗・請求の役割に応じた権限、名簿の差分、確定版の出力
運用ルール：個人データの安全管理、委託先の監督、漏えい時の報告体制

個人情報保護委員会のガイドラインは、安全管理措置として、組織体制や従業者・委託先の監督を示しています。取扱状況の把握と漏えい対応体制も、そこに含まれます。そのため、機能だけでなく運用ルールも要件に含めます。

バス会社・宿泊施設の業務境界

業態ごとに既存システムとの境界を整理しておくと、導入範囲を決めやすくなります。

観光バス会社：旅行商品の造成・見積と、車両・乗務員・配車との関係
宿泊施設：客室在庫、部屋タイプ、食事、団体条件、回答期限、請求
システム範囲：運行管理やPMSを置き換えるか、団体営業の案件管理を加えるか

置き換えか追加かによって、導入範囲と費用は大きく変わります。そのうえで、どちらのシステムを正データにするかを決め、二重入力を避ける連携方式を設計します。

ポイント

業態によって必要な項目と現場の責任分担が変わるため、会社の規模ではなく、自社の代表案件がどの業態に近いかで機能を絞ってください。

必要な基本機能とデータのつながり

団体旅行管理システムの良し悪しは、機能一覧の数では判断できません。

見るべき点は、問い合わせで入力した情報が見積や手配に再利用され、参加者や請求、分析まで届くかです。また、変更が関連箇所へ伝わる設計になっているかも確かめます。

要件定義の最初に最低限整理しておきたい機能を、業務の流れに沿って説明します。

見積・商品造成で原価と販売価格を同時に扱う設計

見積機能では、商品部品と価格・条件を結び付けておくと、変更があったときの再計算範囲を確かめられます。

商品部品：宿泊、交通、食事、ガイド、観光施設、オプション
見積条件：人数区分、税込・税抜、仕入条件、販売価格、キャンセル条件
比較項目：売上合計、予定原価、粗利、粗利率、未回答の手配

たとえば人数が20名から18名に変わったときは、食事数や部屋数を含め、料金と粗利まで再計算されるかをデモで確かめます。

行程・手配の回答待ちと変更履歴の見える化

行程と手配先ごとの状況を結び付けておくと、変更が参加者や関連する手配へどう響くかを追えます。

行程：日付、時間、場所、移動経路、滞在時間、担当者、注意事項
手配状況：依頼日、回答期限・内容、仮押さえ、確定、変更、キャンセル
出力帳票：行程表、手配書、バウチャー、運行指示書

ホテルの回答が遅れたり航空便の時刻が変わったりした場合、参加者への影響を送迎や食事、ガイドまで一覧で確認できれば、電話での確認を減らせます。

参加者・請求・収支をつないだ完了の判断

催行後の請求と支払を案件に戻して、予定と実績を比べられるようにします。

参加者管理：名簿、代表者、部屋割り、座席、食事制限、緊急連絡先と確定帳票
精算：顧客請求、仕入先支払、入金・支払の消込、追加料金、キャンセル料
分析：販売先別、商品別、担当者別、月別の売上と粗利

集計すると、忙しいわりに利益が残らない案件の原因を見つけやすくなります。

旅行・観光業向け団体旅行管理システムの進め方

導入は画面を作るだけで終わらず、業務と責任の持ち方を整えるプロジェクトです。要件を急いで確定すると、帳票と例外処理、移行や権限の追加が後から重なり、予定外の費用や納期の遅れにつながります。そのため、まずは代表案件を一つ選び、現場と管理者が業務フローを確かめます。

▶ 詳細はこちら：旅行・観光業向け団体旅行管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

要件定義で現状業務とMVPを分けること

工程ごとに担当者、承認者、参照者を決めたうえで、確定データや例外処理を洗い出し、紙やメールが今も残っている理由を整理します。

業務の流れ：問い合わせ、見積、仮押さえ、催行決定、手配、変更、旅行中、請求、精算、分析
初期リリース：案件カルテ、団体見積、行程、手配状況、請求・収支
後から追加：参加者向けアプリや需要予測など

参加者向けアプリや需要予測は、基本データが整い、利用率を確かめたうえで追加します。

設計・開発での例外処理と連携の先行確認

通常案件から外れる例外と外部連携を設計し、どこまでを誰が担うかを文書にまとめます。

例外：人数・日程・部屋タイプ変更、回答期限切れ、重複予約、キャンセル料、日またぎ、異なる税率、英語帳票
連携先：会計、決済、PMS、在庫、航空・交通、地図・経路、メール・SMS、BI
連携方式：APIの有無、同期頻度、障害時の再送、認証、個人情報の扱い

画面を埋め込む方式でも、認証や個人情報の扱いは変わります。そのため、外部サービスとの責任分界点を文書化してください。

公開事例には、45年間運用してきた独自の旅行業務基幹システムを刷新し、複数仕入先との連携とWeb顧客対応、ペーパーレス化を進めた例があります。

約300名が利用する規模まで展開し、商品造成、予約、仕入を同じ情報基盤で扱いました。在庫と入出金、帳票も含めています。刷新の目的は、現場の作業時間を顧客対応へ振り向けることでした（出典：旅行業務基幹システムの公開導入事例、2026年確認）。

効果は企業ごとに異なるため、公開事例の数値を自社の成果として見積もらず、同じKPIを導入前に測定してください。

移行・テスト・リリースと繁忙期の回避

移行対象を洗い出し、代表データでテストしたうえで、段階的に展開します。

移行対象：顧客、施設、仕入先、料金マスタ、タリフ、商品、過去案件、未精算、帳票テンプレート
整理事項：表記揺れと重複データ
テスト例：20名の修学旅行、海外エージェントからの人数変更、ホテル回答遅延、キャンセル料計算

まず、現場が合格と判断する受入基準を作っておきます。そのうえで、1部署・1商品・1拠点のパイロットを行ってから展開すると、紙や旧Excelへ戻るリスクを下げられます。

ポイント

要件を急いで確定せず、代表案件で業務フローと例外を確かめてから範囲を広げると、予定外の費用や納期の遅れを避けやすくなります。

費用相場と開発期間の目安

初期費用だけでなく、月額や保守などを含めた5年TCOも比較対象になります。

団体旅行管理システムだけを対象にした公的な料金統計は見当たりません。この数字は、2025〜2026年に公開された旅行業務システムや予約管理の相場をもとにした試算です。PMSやCRM、外部連携の相場も含みます。

費用は、利用者数や拠点数で変わります。個人情報の項目と在庫の持ち方も、金額に影響します。

さらに、API連携や移行データの量、SLA、カスタマイズの範囲も金額を左右します。金額は予算を組むときの目安とし、同じ要件で見積を比べてください。

▶ 詳細はこちら：旅行・観光業向け団体旅行管理システム開発の見積相場や費用/コスト/値段について

導入方式別の初期費用の幅

この一覧は、公開相場をもとにした方式別の初期費用と期間の目安です。団体旅行に固有の統計ではありません。

標準SaaS：初期0〜50万円、月額2〜15万円程度、導入2〜8週間
旅行業向けパッケージ：設定・データ移行を含め初期50〜300万円、1〜3か月程度
個別機能を追加：団体見積、帳票変更、会計・PMS連携を加え、初期300〜800万円、3〜6か月程度になる場合がある
スクラッチ開発：800〜2,000万円。複数拠点・代理店ポータル・多言語・複数APIを含むと2,000〜5,000万円以上の場合がある

スクラッチ開発の期間は、6〜18か月以上を想定します。金額と期間は、いずれも公開相場からの推定です。

標準SaaSの公開料金の例では、初期費用と保守サポート料が0円で、1アカウントあたり月額5,500円（税込）、2アカウントからとされています。

この料金例は標準機能の場合で、団体旅行に固有の帳票や移行、外部連携は含みません。個別権限と教育費も、この例には入っていません。

公開価格があっても、条件は見積の段階で確かめてください。特に、追加ユーザーとデータ出力の条件や、導入支援と繁忙期のサポート、機能追加の条件を見ておく必要があります（出典：旅行業向けクラウドサービスの公式料金ページ、2026年確認）。

初期費用以外を含めた5年間のTCO

5年間の総所有コスト（TCO）を出すには、初期費用以外の項目も確認する必要があります。

見積の内訳：要件定義、設計、開発、テスト、移行、教育
継続費用：保守、クラウド、外部API、帳票変更、追加ユーザー、サポート時間
参考相場：保守は初期開発費の年12〜20％、小規模クラウド基盤は月2〜5万円
負荷対策込み：繁忙期の負荷対策や監視を含むと月10〜30万円以上が参考

初期費用が安くても、月額や最低利用期間、データ出力の料金が高い場合があります。解約時の移行や法改正対応、追加帳票の費用が高くなることもあります。

5年間の利用料と保守に、追加開発と社内運用の人件費を足したTCOで比べます。

見積の前提条件をそろえた比較

機能名ではなく同じシナリオを各社に渡し、標準でできる範囲と追加費用を比べます。

比較シナリオ：50名、3泊4日、宿泊3施設、バス2台、食事制限5名、参加者変更2回
出力と精算：海外エージェント向け英語帳票、顧客請求、仕入精算
確認項目：移行件数、教育日数、受付時間、復旧目標、バックアップ、データ返却、追加API単価

条件をそろえて見積を比べれば、導入後の想定外を減らせます。

ポイント

初期費用の安さだけで比べず、5年間のTCOに保守や追加開発、社内の運用費まで含めて、同じ前提条件の見積を並べて比べてください。

外部連携・個人情報・制度対応で確認すること

アクセス権限や操作記録は、定期的な点検と合わせて運用します。

団体旅行では、顧客情報に加えて、パスポート情報に関係する項目や緊急連絡先を扱います。さらに、食物アレルギーや同行者情報も扱います。

機能要件と同じように、権限や認証、暗号化を決めてください。また、監査ログやバックアップ、委託先の管理を決め、漏えい時の連絡体制も用意します。

連携先とデータの正しさの決め方

連携の優先順位は、転記の多さと変更漏れの影響で決めます。

候補：会計、決済、PMS、OTA、GDS・NDC、交通・バス運行、地図・経路、メール・SMS、BI
正データ：顧客、施設、商品、料金、案件、参加者の基幹データを決める
障害時：更新頻度、エラー時の再送、手動修正、連携停止中の業務継続を設計書に記載

すべてを一度につなぐ必要はありません。影響の大きい連携から着手します。

旅行業法と個人情報保護の要件化

制度上の業務をシステム要件と照合し、法令の判断をシステムだけに任せない体制を作ります。

旅行業法：業務の適正運営、取引の公正、旅行の安全、旅行者の利便を目的とする
対象制度：報酬を得て一定の行為を行う事業に登録制度がある
要件確認：契約条件、約款、取消料、変更補償金、帳票保存を現場運用と照合

観光庁が2026年4月1日に更新した「旅行業法及び省令等」には、旅行業法施行規則や旅行者との契約等に関する規則、標準旅行業約款などが掲載されています（出典：観光庁「旅行業法及び省令等」、2026年）。

個人情報保護委員会のガイドラインは、安全管理措置として、組織体制や従業者・委託先の監督を示しています。取扱状況の把握と漏えい対応体制も、そこに含まれます。

漏えい時の報告期限は事案ごとに判断されます。ただし、速報の目安は概ね3〜5日以内と説明されているため、事実確認や報告、本人通知の判断者を、あらかじめ決めておきます（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

アクセス権限を最小限にとどめ、操作ログとバックアップを定期的に確認してください。

セキュリティを運用面で評価する項目

確認項目は、二要素認証やIP制限の有無に加えて、運用面も含めます。

アクセス：退職者の停止時期、ダウンロード可否、権限変更の承認者
記録と復旧：ログ保存年数、バックアップからの復旧時間
委託・返却：再委託の有無、解約時のデータ返却形式
外部ポータル：利用者登録・削除、閲覧範囲、ファイルのウイルス対策、誤送信防止

ポイント

個人情報の扱いと外部連携は、機能の有無よりも、権限や委託先、障害時の運用まで決めているかで判断すると、後の手戻りを減らせます。

開発会社/ベンダーの選び方

開発会社・ベンダーは、知名度や機能数だけでなく、団体旅行の業務への理解と、導入後に現場で使われるまでの支援で選びます。

見積から手配、変更、請求・精算までを一貫して実演できるかも確認します。さらに、標準機能と個別開発の境界が明確か、移行と教育を含む体制かを見てください。

団体旅行の実績の確認方法

「旅行業界の実績がある」という説明は、判断材料として不十分です。そのため、対象業態と、実際に管理した業務を確かめます。

業態：訪日団体、修学旅行、社員旅行、募集型企画旅行、バス、宿泊施設
変更シナリオ：50名から18名への変更とホテル回答の一部未確定
成果物：英語行程表、顧客請求、仕入先への支払予定

差分や未回答の扱い、粗利、帳票を、一連の流れとして確認します。途中の作業が見えなければ、別途Excelが残るおそれがあります。

費用・契約・サポートの境界の比較

提案書と契約書を並べて、費用の内訳と提供範囲を照合します。

見積内訳：標準機能、設定、追加開発、移行、教育、帳票、API、クラウド、保守
月額の範囲：ユーザー数、ストレージ、問い合わせ回数、アップデート、障害・法改正対応
契約終了：追加開発の単価・納期、データ出力・返却形式、削除証明、再委託先、SLA、障害連絡先

提供範囲と終了時の対応を明確にしてから契約します。

移行・教育・定着支援まで含めた選定

稼働日に完成しても、現場で使われなければ効果は出ません。そのため、導入後の担当者と測定方法を決めておきます。

定着支援：データ整備、旧帳票との並行運用、教育、マニュアル、質問受付、権限申請
利用状況：月次の利用状況確認とアクティブ利用率
支援期間：導入後30日・90日・180日の内容と見積回答時間
効果指標：転記回数、変更漏れ、粗利確定日数、紙・FAX件数

支援内容と、各指標をどう測るかも、提案に含めてもらいます。

▶ 詳細はこちら：旅行・観光業向け団体旅行管理システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：旅行・観光業向け団体旅行管理システム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は知名度ではなく、自社の業態での実績と、見積から精算までを実演できるか、移行と定着支援まで含むかで比べてください。

導入に失敗しないためのKPIと運用設計

導入の成否は、稼働したかどうかではなく、業務が安全に速くなったかで判断します。売上増だけを目標にすると、システムの影響を評価しにくくなります。

現場の負担と、管理者が状況を見渡せるかを同時に測る指標を設定してください。

時間と件数で測る現場の改善

導入前後を同じ条件で比べ、感覚だけに頼らず変化を捉えます。

時間：見積回答までの時間、案件の引き継ぎに要する時間
件数：案件あたりの転記回数、人数や日程の変更漏れ、仕入先の未回答件数、紙・FAXの件数
粗利確定：催行後に粗利を確定するまでの日数
比較時点：導入前1か月と、導入後30日・90日・180日

平均時間と中央値、繁忙期の最大時間を記録しておくと、改善の偏りも分かります。

対象範囲と責任者の曖昧さによる失敗

失敗は、対象範囲や要件定義への参加、移行準備が曖昧なときに起こりやすいものです。

範囲の拡大：会社全体を一度に置き換えると要件が膨らみます。初期対象は一業態と代表案件に絞り、標準機能と個別開発を分けます
現場不在：要件定義に現場を呼ばないと、稼働後に帳票や例外処理が足りなくなります
責任者：営業、手配、添乗、請求、管理者から利用者を選び、決定権者を置きます
移行の後回し：施設名、料金、顧客名の表記揺れを早めに整理し、試験移行を繰り返します

よくある質問

料金や機能は、サービスと要件によって変わります。下の回答も、自社の代表案件に置き換えて確かめてください。

団体旅行管理システムはクラウドとスクラッチのどちらがよいですか？

標準的な業務が多く、早く導入して運用を業務に合わせられる場合は、クラウドが向きます。

独自の販売モデル、大規模な外部連携、厳格なデータ統制が必要な場合は、スクラッチが候補です。ただし、すべてを自社開発する必要はありません。

また、旅行業務のコアはパッケージやSaaSに任せ、代理店ポータルや分析など差別化の部分だけを追加する方法もあります。

小規模な旅行会社でも導入する価値はありますか？

担当者が複数案件を抱え、見積や変更履歴がメールとExcelに分散している場合、案件カルテと手配状況の共有だけでも効果が出やすくなります。

多機能な大規模システムから始めるより、利用者数や案件数を整理し、帳票と既存会計との連携を確かめるとよいです。

標準機能で始められる範囲と、将来の拡張にかかる費用を確かめます。

導入にはどのくらいの期間がかかりますか？

方式別の導入期間は、次のように見込まれます。

標準機能のSaaS：2〜8週間
設定・移行を含むパッケージ：1〜3か月
連携や帳票の個別開発：3〜6か月以上

データ移行や繁忙期の受入テストを含めると、開発期間より長くなります。現場教育や並行運用も、期間に加わります。

繁忙期の直前に切り替えるのは避け、代表案件でパイロットを行います。現場の合格基準を満たしてから、展開します。

参加者名簿やアレルギー情報は安全に管理できますか？

権限管理や二要素認証、暗号化を組み合わせ、監査ログとバックアップ、アクセス状況の点検を行うと、安全性を高められます。

機能を備えるだけでなく、必要な項目だけを取得し、閲覧者を限定します。

印刷やダウンロードの扱い、委託先の監督、退職者のアカウント停止を、運用に落とし込みます。加えて、漏えい時の報告と本人通知の手順も決めておきます。

まとめ

団体旅行管理システムは、予約の受付にとどまらず、問い合わせから見積、商品造成、行程までを案件単位でつなぎます。手配や参加者、変更の管理から、請求・仕入支払、粗利の把握まで、同じ案件情報で扱います。

業務の中身は業態で異なり、訪日団体や修学旅行、社員旅行などでは、求められる項目も違います。バス会社や宿泊施設を含め、自社の代表案件を基準に機能を定義してください。

5年TCOと業務KPIで比べる選び方

方式と初期費用だけで決めず、5年間の費用と導入後の業務指標を合わせて比べます。

費用：SaaS、パッケージ、スクラッチの初期費用、月額、保守、移行、教育、追加開発、データ返却
KPI：見積回答時間、転記回数、変更漏れ、粗利確定日数、紙・FAX件数、利用率
段階導入：案件カルテから請求・収支までをMVPとし、連携や高度な分析は定着後に広げる

導入前後でKPIを測ると、投資効果を判断しやすくなります。

最初の一歩は代表案件とRFPの整理

直近の団体案件を一つ選び、問い合わせから精算までの実務と例外を整理します。

確認するもの：画面、帳票、メール、Excel、電話、FAX、承認、例外処理
RFP項目：対象業態、利用者、必須項目、連携先、セキュリティ、移行範囲
条件：予算、希望時期、受入テスト
候補比較：同じシナリオでデモと見積を依頼する

機能数よりも、変更に強く、現場が使い続けられ、収支を確定できる仕組みかどうかを見極めます。

▼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を創業。