旅行・観光業向け行程管理システム開発の発注/外注/依頼/委託方法について

旅行・観光業向け行程管理システムの発注は、社内の業務を整理し、RFPで依頼条件をそろえ、候補会社の提案を比べる流れで進みます。そのうえで、必要な部分から段階的に導入すると、現場に定着しやすくなります。

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

行程管理システムの発注前に知るべき全体像

行程管理システムは、企画から予約・手配、変更、請求・精算までを一つの案件として追跡します。そのため発注時は、行程表を出力できるかだけでなく、関係者と情報がつながるかも判断の対象になります。

対象業務の範囲の決め方

業務フローは、問い合わせから実績分析まで、実際の作業の順番どおりに並べます。紙やExcel、FAXといった手段のほか、電話や個人メールで回っている箇所も記録します。業務を分解しておかないと、各社の見積の前提が食い違い、金額や納品範囲を比べられません。

業務フローは、問い合わせ、企画、見積の順に並べます。受注後は、予約、手配、日程表作成と続きます。さらに、参加者案内と関係者共有を経て、変更・取消、請求、精算に進み、実績分析で終わります。

  • バスツアー:車両、乗務員、運行情報との連携の範囲
  • インバウンド:多言語の情報、パスポート、通訳・ガイド、決済の扱い
  • 業態の範囲:旅行会社、ランドオペレーター、DMO、教育旅行、MICEなどのうち、主力と将来分の切り分け

必要な画面は業態によって異なるため、対象とする業態を先に決めてから画面を並べます。

「情報の流れ」で見る要件の整理

発注要件では、データのつながりと、現場で情報を使う場面を整理しておきます。行程を変更した後まで確認できる設計にしておくと、変更の前後で何が変わったかを見返せます。

  • データ関係:顧客・参加者から料金・原価、帳票・連絡、変更履歴までの関係
  • 変更記録:変更前後の内容、承認者、通知先と時刻。手配書や添乗員への通知にも反映します。
  • 現場利用:スマートフォンでの表示、写真や書類の添付、通信断時の確認と再送、緊急連絡網の扱い
  • 計画外の事態:欠航や渋滞、休館、天候、事故の日にも記録が残せるかどうか

添乗員は外出先や通信が不安定な地域でも使うため、平常時の入力効率に加えて、通信断や移動中の使い勝手も判断材料にします。

パッケージ・個別開発・段階導入の選び分け

パッケージ、個別開発、段階導入の特徴を3枚のカードで示した図解
業務の共通性と独自性が選択の分かれ目になります。

標準機能で業務を進められるならパッケージ、独自業務が競争力に直結するなら個別開発が候補になります。多くの企業では、必要な部分だけを追加する段階導入も検討できます。

価格だけで決めると、3年後の変更費用や運用負担が比較から漏れます。そのため、契約後の変更費用と運用の負担まで並べて比べます。

追加範囲には、データ移行や特殊帳票があります。モバイル画面や会計・予約連携も、あわせて書き出しておきます。

標準パッケージ・SaaSを選ぶ場合

顧客管理や見積、予約などの共通機能を、短期間で使いたい企業に向きます。初期費用を抑えやすいうえ、法改正や製品更新を提供会社に任せやすい点も特徴です。

  • 標準外の帳票:追加費用か、運用上の割り切りが必要です。
  • 特殊な精算:個別ルールが標準機能に合うかどうか
  • 支店間承認・基幹連携:複雑な場合は、追加対応の範囲

日本システム開発のTabieは初期費用0円です。顧客管理の基本使用料は5ユーザーまで月額1万円、年額12万円です(出典:日本システム開発「Tabie 料金」、2026年確認)。さらに、団体旅行管理は月額3,000円、GDS XML連携は月額3万円です(出典:日本システム開発「Tabie 料金」、2026年確認)。

顧客データのみの移行は10万円から、3時間の研修は5万円です(出典:日本システム開発「Tabie 料金」、2026年確認)。ただし、公開料金は比較の起点なので、対象データや連携条件、追加設定の範囲は契約前に確かめます。

個別開発・スクラッチを選ぶ場合

既製品に業務を合わせると、利益率や対応速度、顧客体験が損なわれるような場合に検討します。法人旅行の独自見積や複数手配先の原価管理、特殊承認などが、その例です。

  • 顧客ポータル:業務に合わせた独自のマイページの設計
  • 複雑な連携:バス運行や会計との接続要件の整理
  • 仕様の曖昧さ:開発中の追加要求を抑えるための、要件の先行確定

要件が曖昧なまま依頼すると、開発の途中で仕様が増え、納期と費用が膨らみます。そのため、成果物と引き継ぎの条件も先に明確にしておきます。

成果物には、要件定義書や画面一覧、データ項目のほか、外部連携仕様を含めます。受入条件や移行手順、操作マニュアルも、成果物として決めておきます。さらに、ソースコードやデータの返却条件も、契約に含めます。

AI駆動開発や短納期をうたう会社には、生成物の検証責任と著作権を契約で確認します。脆弱性への対応や、担当者が替わった後の保守方法も、契約に書き込んでおきます。

段階導入とパイロットを組み合わせる場合

全社一括での導入に不安があるなら、1支店や1商品群、1旅行タイプに絞り、過去案件を使って試します。

  • 作業時間:日程表の作成にかかる時間
  • 手配品質:手配漏れの件数と、確認の往復回数
  • 現場利用:操作の負担と、実際の利用状況

問い合わせから精算まで、業務を一巡させて試します。実際の添乗員や手配担当にも使ってもらいます。現場が使わないと、機能が多くてもExcelに戻ってしまうからです。

終了条件は、測れる形で決めておきます。たとえば、日程表の作成時間を何分以内にするかを定めます。ほかにも、変更履歴を全件残すことや、権限外の閲覧をゼロにすることを基準にできます。

移行データの不備を何件以下にするかも、あらかじめ定めます。最後に、試行の結果を本契約の要件と追加開発の優先順位に反映します。

ポイント

発注形態は、業務の共通性と独自性で迷ったときの判断材料になります。標準機能で足りる業務はパッケージ、独自性が競争力に直結する業務は個別開発を候補にし、迷うときは段階導入で試す方法もあります。

行程管理システムの発注・外注の進め方

行程管理システムの発注を社内整理から運用開始まで4つのまとまりで示した図解
同じ資料を候補会社に渡すと提案を比べやすくなります。

まず社内で業務を整理し、RFPを作って候補会社に説明します。提案と見積を比べて契約したあとは、要件定義、開発・設定、受入テストと進みます。続けて、移行と教育を行い、運用を開始します。

先に社内の判断基準を作り、同じ資料を複数社に渡して比べると、提案の差を見極めやすくなります。

社内の業務と成果指標の洗い出し

経営者や現場の担当者、経理、情報システムまで、関係する部署の代表者で現行業務を追います。そのうえで、国内団体旅行や海外旅行など、代表案件を3件から5件選びます。

見積から精算までの流れで、入力元と転記先、承認者を記録し、困っている例外も書き出します。担当者ごとのExcelでは、全体の流れを把握しにくくなります。

  • 作業時間:行程表の作成と粗利の把握にかかる時間を測ります
  • 品質:手配漏れと二重予約の件数
  • 応答と利用:見積回答までの日数、連絡の往復数、現場での入力率を確認します

観光DX推進事業の優良事例でも、データを一か所にまとめること、業務の自動化、UI・UXの改善が主要な論点になっています(出典:観光DX推進事業「優良事例」、2025年度公開情報)。

RFPによる依頼条件と提案範囲のそろえ方

RFPには、背景や目的、対象業態・拠点、利用者を書きます。対象業務や必須・将来機能、連携、移行も、あわせて示します。

さらに、セキュリティや日程、予算も記載します。納品物や保守、提出形式も、RFPに書いておきます。

各要件は、標準機能や設定で対応するのか、追加開発か、対象外かを回答してもらいます。必須要件と「あれば望ましい要件」は、分けて示してもらいます。

  • 実データのデモ:匿名化した過去データを使った操作の確認
  • 例外シナリオ:行程変更、欠航、参加者追加、施設料金変更の場面
  • 見積条件:前提、除外項目、追加単価、納期条件の統一

会社紹介だけでなく、実際の入力から帳票の出力までを見せてもらうと、提案の実現性を比べられます。

契約・開発・受入を分けた管理

要件が未確定なら、現状分析や要件定義は準委任で依頼できます。あるいは、仕様と成果物が固まった範囲から、請負契約に移す方法もあります。

請負では、完成の責任と検収の条件を定めます。一方で準委任では、作業範囲や稼働時間、意思決定の責任分担を明確にします。

  • 契約条件:納品物、検収期間、不具合対応、仕様変更の手順
  • データと委託:再委託の承認、所有権と返却、ソースコード、秘密保持
  • 運用継続:個人情報の扱い、障害時の連絡、バックアップと復旧、解約時の移行

受入では、正常系に加えて、取消や欠航、重複参加者の場面を確かめます。さらに、料金変更や権限外アクセス、通信断も、テストに含めます。安全性は、契約形態の名称よりも、受入でどこまで確かめたかで左右されます。

ポイント

進め方に迷ったときは、先に社内の判断基準を作り、同じ資料で複数社の提案を比べます。契約と開発、受入を分けて管理するかどうかも、この基準で判断します。

旅行・観光業向け行程管理システムの費用相場と内訳

3年TCOを利用・基盤、運用・追加作業、継続と終了に分けた図解
契約終了時のデータ出力まで費用範囲に含めます。

旅行・観光業向けシステムだけを対象にした公的な費用統計は、確認できていません。以下の金額は、NotebookLMリサーチノートの一般的な業務システム相場、公開料金、公開事例を分けた目安です。

費用は、利用者数や案件数、拠点数で変わります。連携本数や帳票数も、金額を動かす要因です。移行データの品質、モバイル対応、セキュリティ要件も、金額に差を生みます。

方式別の費用レンジの比較

方式ごとの費用と導入期間は、初期費用と合わせて見ることで、見積の範囲を比べられます。

  • 標準SaaS:初期費用は0円から50万円程度、月額は1万円から20万円程度です。
  • パッケージ追加:初期100万円から1,000万円程度、期間3か月から6か月程度です。
  • 個別クラウド開発:初期500万円から3,000万円程度、期間6か月から12か月程度です。
  • 大規模案件:複数拠点や基幹、外部連携を含む案件です。

SaaSでも、移行や外部APIは別費用になりやすく、研修や帳票を加えると、さらに費用が増えます。ただし、ここに挙げた金額は一般的な目安で、一律の公開料金ではありません。

こうした大規模案件では、3,000万円から数億円に達する可能性もあります。特に、予約・決済やバス運行、顧客ポータルまで含むと、規模が大きく広がります。

機能数や連携数で金額が変わるため、数字だけで予算を決めず、見積の前提条件と合わせて比べます。

公開料金と事例の見方

公開料金と個別事例は条件が異なるため、対象ユーザーや付帯作業をそろえて比べます。

  • Tabie:標準サービスの料金と、個別開発の相場の区別
  • 雲海設計の法人旅行事例:費用の構成と処理時間

Tabieは初期費用0円で、顧客管理の基本使用料は5ユーザーまで月額1万円、年額12万円です(出典:日本システム開発「Tabie 料金」、2026年確認)。

Tabieには機能オプションや追加ユーザーもあるため、移行や研修、API利用料は契約前に確認します。

雲海設計が2025年11月に紹介した事例は、従業員20名、年間約3,000件の法人旅行代理店向けです。開発費は1,650万円、月額運用は8万円でした(出典:株式会社雲海設計「旅行代理店向け予約・手配管理システム開発事例」、2025年11月公開)。

この事例からは、導入時の費用配分と、業務の処理時間がどう変わったかを判断材料として見られます。

  • 設計・開発:1,200万円です。
  • クラウド初期構築:150万円です。
  • 移行・導入支援:200万円です。
  • 研修・マニュアル:100万円。処理時間は平均4時間から45分に短縮

これは1社の事例なので、業界全体の相場とは言い切れません。導入に必要な費用項目を知るための材料として扱います。

3年TCOに含める費用の範囲

3年TCOには、初期費用に加えて、利用料から契約終了時のデータ出力までを含めます。

  • 利用・基盤:月額・年額、追加ユーザー、容量、API・決済・GDS、クラウド
  • 運用・追加作業:バックアップや保守などの運用作業、移行、研修、帳票の追加
  • 継続と終了:法改正への対応、繁忙期の試験、解約時のデータ出力

初期費用が低くても、連携やデータ出力、保守などが有料なら、総額が逆転する可能性があります。開発費の配分は、要件定義が10%から15%、基本設計が15%から20%です。また、詳細設計は10%から15%、開発は30%から40%を比較の目安にします。

  • 結合・総合テスト:開発費の15%から20%程度
  • 移行・導入:開発費の5%から10%程度
  • 保守:初期開発費の年10%から20%前後が目安

サービス内容によって配分は変わります。相場から外れた見積は、高いか安いかを決める前に、作業範囲と除外項目を確認します。

ポイント

費用は、利用者数や連携、移行の範囲で大きく変わるため、金額だけでなく見積の作業範囲と前提をそろえて比べます。公開料金や事例は条件が異なるので、対象と付帯作業を見て判断します。

RFP・要件整理で発注先に伝える内容

RFPは開発会社への依頼資料で、自社の認識をそろえる資料でもあります。機能一覧だけでなく、課題や業務、利用者、データを書きます。例外や成果指標、制約も、あわせてまとめます。

旅行業務への理解を確かめるため、実際の案件シナリオも含めます。

必須機能・例外運用・連携の記載

必須機能は、顧客・参加者から請求・精算、検索・集計までの業務を含みます。その間には、見積と原価、手配、帳票が入ります。連絡や承認も、そこに含まれます。手配の中身は、交通・宿泊・食事・施設です。

例外時の操作と履歴は、別に記載します。たとえば、参加者の追加や部屋割りの変更、欠航などが該当します。代替交通や休館、天候変更、同時編集も、例外に含めます。

  • 業務連携:会計、予約、CRM、PMS、OTA、決済、地図・ルート検索、バス運行などを含む連携先の範囲
  • 外部サービス:メールやOCR、GDSなど
  • 連携仕様:方向や頻度、再送の条件、API制限、CSV、停止時の手順

モバイルでは、写真や書類の扱いと、端末紛失時の遠隔ログアウトを決めておきます。オフライン時の確認手順も必要で、連携が止まったときの代替手順も書いておきます。

移行データとマスタ整備の責任者の決定

移行対象は、顧客や参加者、施設、交通、取引先などのマスタに加え、商品やコース、料金です。過去行程や請求履歴も、移行の対象になります。

列名や住所、電話番号の表記が揃っていないと、検索や手配を誤る原因になります。重複した顧客や古い料金、退職者の担当案件も、整理が必要です。

  • 移行範囲:対象と変換ルール、除外データ
  • 検証方法:件数の照合や抽出確認、再移行の回数(見積に含める)
  • 社内責任者:営業、手配、経理、情報システムから担当者を置く

サンプル移行後は、件数を照合したうえで、ランダム抽出と業務担当者による画面確認を行います。正確さの判断には、開発会社に加えて、社内の業務担当者の目も必要です。

安価な提案では、重複の除去や表記の統一が対象外になっていないかを確認します。あわせて、過去データをどこまで検索できるかも決めておきます。

個人情報・旅行業法・セキュリティの要件

参加者名簿や健康情報、パスポート情報、緊急連絡先を扱う場合は、管理の条件を確認します。

  • 個人情報:利用目的や権限、ログ、安全管理と委託先の扱い
  • 旅行業法:資格者の判断と、システム上の記録・共有の区別
  • セキュリティ:端末や通信、復旧、再委託を含む運用要件

暗号化やバックアップ、削除の方法も、あわせて確認します。個人情報保護委員会のガイドラインは、委託先の選定や安全管理措置を示しています。再委託の事前報告や承認、定期監査も盛り込まれています(出典:個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年確認)。

旅行業法では、旅行業者等の登録や、営業所ごとの旅行業務取扱管理者、企画旅行の旅程管理が関係します。旅行サービス手配業の登録と管理者も、確認の対象になります。

法的な管理義務は、システムの導入とは別に、人が果たす必要があります。そのため、資格者や管理者の判断と、記録内容は分けて考えます(出典:観光庁「旅行業法概要」、2026年4月30日最終更新)。

IPAは2026年3月、中小企業向けガイドラインの第4.0版を公開しました。この版では、サプライチェーン全体に及ぶ攻撃を踏まえて対策を拡充しました(出典:IPA「中小企業の情報セキュリティ対策ガイドライン第4.0版」、2026年3月27日)。

発注先には、次の運用項目を質問します。

  • システム運用:ログインや権限、端末と通信、脆弱性への対応、バックアップと復旧
  • 委託先管理:復旧目標時間、バックアップ世代数、障害連絡の時間帯
  • 再委託・報告:外部に任せる範囲の一覧と、脆弱性を見つけたときの報告方法

ポイント

RFPに、業務と例外、連携、移行、セキュリティ、個人情報の扱いが書かれているかを判断の基準にします。各要件が標準機能、設定、追加開発、対象外のどれで対応するかも、回答で確かめます。

委託先の選定と見積比較の確認点

会社規模や知名度だけでなく、旅行業務の理解やデータモデルを比べます。現場導入や連携、保守、引き継ぎについても、あわせて確かめます。

委託先には、標準パッケージの提供会社や旅行業に強いSIer、クラウド連携に強い会社があります。独自業務を受託する会社もあり、得意な範囲や見積の出し方が会社ごとに違います。

業務シナリオで見る実績の確認

業界での実績だけでなく、業態や利用人数、対象業務を確かめます。期間や改善指標もあわせて聞きます。行程から請求までがつながっているかも、質問しておくとよいでしょう。

  • 利用状況:添乗員や外部の手配先が実際に使ったかどうか
  • 設計:変更履歴と権限の考え方
  • 導入後:匿名化した画面、受入テスト、運用体制

候補例には、Tabie、イーダッシュのFalcon、ナビタイムジャパン、ブロードリーフがあります。中でも、ブロードリーフには、旅行業務とバス運行管理の連携事例があります。

クラウド連携では、クレスコ・ジェイキューブの海外渡航手続きの事例が参考になります。法人旅行では、雲海設計の公開事例が役立ちます。ここに挙げた各社は、同じ条件で並べたランキングではなく、候補の分類です。

見積の前提と除外項目による比較

見積は、要件定義から予備費まで、作業の区分ごとに分けてもらいます。中心になるのは、設計や開発・設定、移行などの費用です。研修やマニュアル、保守の費用も、それぞれ確かめます。

「一式」と書かれた項目では、作業内容や成果物、回数、担当者、完了条件を質問します。

帳票やAPIの本数、移行件数は金額差になりやすい部分です。利用者数や同時接続数、繁忙期の性能も、金額に響きます。

  • 対応率と追加開発:必須要件を満たす範囲と、そのための追加開発
  • 総費用:3年TCOと社内の協力工数
  • 運用と引き継ぎ:保守の内容、導入期間、データ返却のしやすさ

標準機能を中心に、早く導入できる安価な提案は合理的な選択肢です。ただし、重要な例外が対象外になっている可能性もあります。

一方で、高額な提案にも、移行や研修、テスト、運用設計まで含まれている場合があります。開発費だけの提案と、同じ基準では比べられません。

失敗リスクと発注者側の対策

失敗には、現場を見ずに経営層だけで決めることや、要件定義の不足、帳票や例外の過剰な改修があります。

マスタ整備の後回しや、導入後の教育を担当者任せにすることも、失敗例として挙げられます。これらは、使われないことや手配ミス、予算超過、委託先を替えられないといった問題につながります。

  • 現場参加:要件定義と受入に加わる現場代表
  • 変更管理:目的や影響、費用、納期、優先度、承認者の記録
  • 運用責任:マスタ、権限、障害対応の担当

判断材料が足りないときは、要件定義だけを第三者や開発会社に頼む方法があります。その成果物をもとに、複数社から本開発の見積を取ります。

ポイント

委託先は、同じ業務シナリオで実績と提案を比べ、見積は金額よりも前提と除外項目で比べます。安い見積と高い見積は、必須要件を満たす範囲と含まれる作業をそろえてから判断します。

よくある質問

費用や会社選び、導入手順に関する疑問に答えます。業態やデータ量によって条件が変わるため、回答はそのまま使わず、RFPの確認項目に置き換えてください。

行程管理システムの発注費用はいくらですか?

方式ごとの費用と、見積もりに含める範囲を次に示します。

  • 標準SaaS:初期費用0円から50万円程度、月額1万円から20万円程度が目安です。
  • パッケージ:移行・帳票・連携を加える場合、初期100万円から1,000万円程度です。
  • 個別クラウド開発:初期500万円から3,000万円程度が検討レンジです。
  • 3年TCO:利用者数、移行、連携、帳票、保守を含めて見積もります。

パッケージと個別開発はどちらを選ぶべきですか?

共通業務が中心ならパッケージ、独自の手配や精算、顧客体験が競争力になるなら個別開発が向いています。

標準パッケージを1支店や1商品群で試し、不足する部分を後から追加する段階導入も検討できます。差別化に直結しない機能を作り込まないことは、費用と保守の負担を抑える助けになります。

開発会社へRFPで何を伝えればよいですか?

まず、目的や現状の業務、利用者を記載します。必須機能や例外、連携、移行データも書きます。セキュリティや日程、予算、納品物、保守条件まで含めます。

欠航時の変更や参加者の追加、添乗員のスマートフォン利用などのシナリオを入れると、提案を比べやすくなります。どこまでが標準機能で、どこからが設定や追加開発、対象外になるかも、明示してもらいます。

システムを導入すれば旅行業法への対応は完了しますか?

旅行業法上の義務は、システムを導入しただけでは完了しません。旅行業務取扱管理者や旅程管理主任者による判断と、記録・共有・帳票化する内容は、分けて考えます。

発注側は、最新の制度や契約、社内の管理体制を確認し、必要な記録や権限、承認、変更履歴を要件に入れます。

まとめ

まず、問い合わせから精算までの業務を洗い出し、行程を起点に情報の流れを整理します。そのうえで、業務と成長計画に合う発注形態を選びます。

費用は、開発費だけでなく、移行や連携、研修、保守、データ返却まで含めた3年TCOで比べます。

発注前に確認する項目の整理

RFPには、目的や業務フロー、例外、必須機能を含めます。連携や移行、セキュリティ、受入条件、保守、3年TCOも、あわせて書き込みます。

同じシナリオを候補会社に示し、対応方法や見積の前提、除外項目をそろえて回答してもらいます。

導入後の定着までを含めた発注範囲

導入後の定着は、現場での利用や運用責任、効果の確認まで、発注範囲に含めます。

  • 定着支援:現場教育やマスタ更新、権限管理、障害対応の決め方
  • 段階導入:小さく試し、行程表作成の時間や手配漏れを測ってから広げる流れ
  • 発注条件:例外や法令管理、受入条件、役割の分け方をRFPに記載
  • 委託先選定:同じ業務シナリオと見積前提による提案の比較

標準機能が定着してから、連携や個別開発に広げます。さらに、導入後も効果を測ることで、継続的な改善につなげられます。

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

会社紹介

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

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

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

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

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

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