Vert.xのシステム開発の発注/外注/依頼/委託方法について

Vert.xのシステム開発を発注するなら、フレームワークの採用だけでなく、対象業務、非同期処理の範囲、性能目標、運用体制、契約上の責任分界まで先に決めることが成功の条件です。

Vert.xはJVM上で動くリアクティブなアプリケーション用ツールキットで、API、WebSocket、メッセージ処理、マイクロサービスなどを柔軟に構成できます。一方で、単に「高速なJavaフレームワーク」として外注すると、要件の抜けやイベントループのブロッキングが原因で、費用だけが膨らむおそれがあります。本記事では、Vert.xのシステムを発注・外注・委託するときの進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較、リリース後の保守まで順番に解説します。

▼全体ガイドの記事
・Vert.xのシステム開発の完全ガイド

Vert.xのシステムを発注・外注するときの全体像

Vert.xの発注は、技術名を指定して開発会社に丸投げする手続きではありません。まず業務上の成果と適用範囲を定め、次に技術要件と非機能要件を整理し、その条件を満たせる委託先と契約する流れです。Vert.xはオープンソースで、公式サイトではEclipse Public License 2.0とApache License 2.0のデュアルライセンスで公開されていますが、ライセンス費用が抑えられても設計、テスト、監視、保守の費用は発生します。

発注前に整理する最初の項目は、「何をVert.xで作るか」です。APIゲートウェイ、リアルタイム通知、IoTやセンサーのデータ受信、外部サービスとの大量連携、決済や予約の高並行処理、イベント駆動のマイクロサービスは、Vert.xの特性を生かしやすい領域です。目標は「Vert.xを導入すること」ではなく、「同時接続が増えても応答を保ちたい」「外部イベントを遅延なく業務へ反映したい」といった業務成果で表現します。

反対に、帳票中心の業務、単純なCRUD、複雑なトランザクションを一括処理する基幹機能では、Spring BootやJakarta EEなど、人材を確保しやすい選択肢のほうが総合的に適する場合があります。既存のJavaモノリスをすべて置き換えるのではなく、高並行なAPIや外部連携部分だけをVert.xへ切り出す方法もあります。RFPでは、Vert.xを採用する理由と、採用しない代替案を比較したうえで、対象範囲を明記すると見積もりの前提が揃いやすくなります。

一般的な進め方は、(1)業務課題とKPIの整理、(2)RFP作成とPoC、(3)委託先選定と契約、(4)要件定義・設計・開発、(5)負荷試験・受入試験・段階リリース、(6)保守運用と改善の6段階です。Vert.x案件では、通常の画面開発だけでなく、イベントの順序性、重複配信、タイムアウト、再試行、障害時の復旧まで確認する必要があります。

最初から大規模な完成形を請負契約で約束するより、代表的なAPIや一つの業務シナリオを対象に2〜8週間程度のPoCを置くと、技術リスクと見積もりの不確実性を減らせます。PoCでは、単純なベンチマーク値ではなく、実際のDB、外部API、メッセージブローカー、認証、ログ、監視を含む業務シナリオで比較します。JUASの「企業IT動向調査2026」でも、品質や予算に影響する要因として要件定義の不足、現行業務・システムの複雑さ、IT人材やベンダーのスキル不足が示されているため、発注前の整理に工数をかけることが重要です（出典: 一般社団法人日本情報システム・ユーザー協会、企業IT動向調査2026）。

Vert.xのシステム開発を発注する進め方

Vert.xのシステム開発では、企画段階で業務と性能のゴールを定め、設計段階で非同期処理の境界を決め、試験段階で本番に近い負荷と障害を再現します。特に「高速にしたい」という要望だけでは委託先が工数を見積もれないため、同時接続数、1秒あたりのリクエスト数、P95やP99の応答時間、許容エラー率、復旧時間などへ変換します。

最初に、利用者、業務フロー、既存システム、データの所在、外部サービスとの接点を一覧化します。そのうえで、Vert.xへ移す機能、既存システムに残す機能、SaaSやパッケージで代替する機能を分けます。販売管理、予約、顧客管理、IoTなど同じ業務名でも、リアルタイム性やデータ量が違えば適切な構成は変わります。

非機能要件には、可用性、性能、拡張性、セキュリティ、監査、バックアップ、RTO、RPO、運用時間を含めます。APIでは、認証方式、権限の単位、入力値検証、レート制限、監査ログ、個人情報のマスキング、外部APIのタイムアウトを明文化します。Vert.xのWeb機能に認証やセキュリティ用の部品があっても、業務上の認可やデータの取り扱いまで自動的に安全になるわけではありません。

Vert.xの設計で重要なのは、イベントループを止めないことだけではありません。DB、外部API、キュー、ファイル、キャッシュとの接続方式を業務の整合性と一緒に設計します。同期的なJDBC処理、重いファイル変換、長時間の外部API呼び出しをイベントループ上で実行すると、他のリクエストまで待たせることがあります。そのため、Vert.x SQL Clientなどの非同期クライアント、ワーカープール、キュー、タイムアウト、サーキットブレーカーをどこに使うかを設計書に残します。

API契約には、エンドポイント、リクエストとレスポンス、エラーコード、冪等性、バージョン管理、認証、レート制限を含めます。イベント連携には、イベントID、発生時刻、スキーマのバージョン、順序性、重複時の扱い、再送方法、デッドレターキューを定義します。KafkaやRabbitMQなどを使う場合も、採用実績の有無だけでなく、障害時にどのメッセージをどの担当者がどの手順で再処理するかを受入条件まで落とし込みます。

試験は、単体テスト、結合テスト、API契約テスト、負荷テスト、セキュリティテスト、障害復旧テスト、受入テストに分けます。Vert.xでは、処理が成功するケースだけでなく、外部APIの遅延、DB接続枯渇、キューの再送、同じイベントの二重受信、イベント順序の逆転、イベントループのブロッキングを再現することが重要です。性能試験の結果には、負荷条件、データ量、インスタンス数、JDK、Vert.xのバージョン、DBやネットワークの条件を添付します。

リリースは、いきなり全社へ切り替えるより、対象部署や一つのAPIから段階的に進めます。監視には、可用性、レイテンシ、エラー率、キュー滞留、イベントループの遅延、CPU、メモリ、DB接続数を含め、ログと分散トレースをリクエストIDで追える状態にします。Vert.x公式ブログでは、2026年8月5日に5.1.6が公開され、バグ修正と脆弱性修正が含まれると案内されています。案件では「最新版」と書かず、Vert.x、JDK、Nettyなどのバージョンと更新手順を固定して確認します（出典: Eclipse Vert.x公式ブログ、2026年8月）。

Vert.xのシステムを発注するRFP・要件整理のポイント

RFPは、会社に「良いシステムを作ってください」と依頼する資料ではなく、複数の委託先が同じ条件で提案・見積もりできるようにする資料です。技術要件だけを詳しくするのではなく、業務の背景、現状の問題、対象範囲、優先順位、予算の考え方、納期、運用体制、成果物、選定基準まで揃えます。要件が曖昧なまま相見積もりを取ると、安い会社と高い会社で作るものが違い、価格比較が成立しません。

RFPの冒頭には、解決したい経営・業務課題と、導入後に測るKPIを書きます。続いて、対象ユーザー、業務フロー、画面やAPIの一覧、既存システムとの連携、移行するデータ、対象外の機能を整理します。Vert.x案件なら、API数、同時接続数、ピーク時のリクエスト数、許容レイテンシ、処理の順序性、データの重複許容、停止可能時間を具体化します。実測前の数値は推定値と明記し、PoCで確定する項目を分けます。

開発環境は、JavaまたはKotlin、JDK、MavenまたはGradle、Vert.xの採用バージョン、DB、キャッシュ、メッセージング、クラウドまたはオンプレミス、コンテナ基盤を記載します。さらに、OpenAPIによる契約管理、CI/CD、IaC、脆弱性スキャン、ログ、メトリクス、OpenTelemetry、バックアップ、ロールバック、障害時の連絡体制を成果物に含めます。ソースコードだけでなく、設計書、テストコード、IaC、運用手順、依存ライブラリ一覧の引き渡しも明記すると、委託先変更のリスクを抑えられます。

提案依頼では、Vert.xの利用経験を年数だけで判断しないことが大切です。Vert.x 5.1.6や対象JDKを使った実装例、イベントループをブロックさせない設計、非同期DBクライアント、Kafkaなどのメッセージ連携、テスト戦略、OpenTelemetry、Kubernetesの運用経験を確認します。可能であれば、匿名化した設計書や負荷試験報告書、障害対応の事例を提示してもらい、公開できない場合はどの範囲なら説明できるかを確認します。

体制については、プロジェクトマネージャー、業務責任者、Vert.xの設計担当、JavaまたはKotlinの実装担当、インフラ・SRE、セキュリティ担当の役割と稼働率を聞きます。再委託の有無、担当者の交代条件、国内外拠点の役割、レビュー方法、週次報告、課題管理、エスカレーション経路も確認します。「詳しいエンジニアが一人だけ」という体制では、その人が離れたときの継続性が弱くなります。複数人でレビューできるか、発注者側へ知識移管する計画があるかが重要です。

Vert.xの採用可否に不安がある場合は、PoCを本開発の前段に設定します。PoCの対象は、代表的な一つの業務シナリオに絞ります。例えば、認証済みユーザーがAPIを呼び出し、DBを参照し、外部APIと連携し、イベントをキューへ送るまでを一連の処理として再現します。単なるHello Worldや、DBを使わないベンチマークだけでは、発注後に起きる難しさを評価できません。

成功条件には、P95応答時間、同時接続数、エラー率、CPUやメモリの上限、復旧時間、開発者が変更を反映する時間、監視の可視性などを含めます。Spring Bootなどの代替構成と比較する場合は、同じ業務、同じデータ量、同じクラウド条件で測ります。PoCの成果物は、ソースコードだけでなく、性能結果、ボトルネック、残課題、採用判断、正式見積もりの前提条件とします。PoC後に本開発へ進まない場合のデータ・成果物の扱いも契約で定めます。

Vert.xのシステム開発で選ぶ契約形態

Vert.x案件の契約形態は、要件の確定度、技術検証の必要性、納品物の明確さ、発注者が担えるプロジェクト管理の範囲で選びます。契約の名称だけでなく、何を成果物とし、どの時点で検収し、仕様変更や障害対応の費用を誰が負担するかを具体化することが大切です。PoCと本開発で契約を分けると、技術リスクを整理しながら段階的に判断できます。

請負契約は、合意した成果物を完成させ、検収を受けることを中心に設計します。画面一覧、API仕様、データ移行、テスト項目、性能基準、運用手順などが比較的明確で、納期と完成条件を管理しやすい部分に向きます。例えば、要件定義とPoCを終えて、対象APIの仕様と受入条件が固まった後の実装・テストを請負にする方法があります。

ただし、請負だからといって要件変更や追加要望が無償になるわけではありません。Vert.xの採用範囲、負荷条件、外部サービスの仕様、データ移行の品質など、発注者と受託者の前提が違えば、完成条件を巡って紛争になりやすくなります。変更管理の手続き、追加見積もり、納期の再設定、第三者サービスの障害時の扱い、瑕疵や保証の範囲を契約書と別紙仕様書に定めます。

準委任契約は、専門家が一定期間にわたり、善管注意義務をもって業務を遂行する形です。PoC、要件定義、アーキテクチャ検討、性能改善、既存システムとの段階的な統合、運用保守など、作業内容を完全には固定しにくい局面に適しています。Vert.xのように、実データや本番に近い負荷を調べて設計を調整する案件では、準委任で共同チームを組む選択肢が現実的です。

準委任では、時間を投入したことだけで評価しないように、月次の成果、課題の解消状況、品質指標、レビュー記録、次月の計画を定例化します。作業時間の報告、稼働上限、担当者のスキル、追加作業の承認、セキュリティ事故の報告、ソースコードとドキュメントの管理場所も明確にします。請負と準委任を組み合わせ、PoC・要件定義は準委任、本番実装の一部は請負、リリース後は準委任とする構成もあります。

契約では、ソースコード、設計書、テストコード、IaC、設定ファイル、監視ダッシュボード、ログの保存、生成物の利用権、第三者ライブラリのライセンス、秘密情報、個人情報、再委託先の扱いを確認します。Vert.x本体はオープンソースでも、業務ロジック、設定、クラウド環境、外部サービスの契約は別の権利・責任になります。納品後に自社で修正できるよう、リポジトリの管理者権限やビルド手順を誰が持つかも決めておきます。

APIを扱うシステムでは、認可不備、機微な業務フローへの過剰アクセス、SSRF、リソース消費、危険な外部API利用などがリスクになります。OWASP API Security Top 10 2023でも、認可関連のリスク、リソース消費、機微な業務フローへの無制限アクセス、安全でないAPI利用が取り上げられています（出典: OWASP API Security Top 10 2023）。発注者は、脆弱性が見つかったときの報告期限、修正の優先度、依存ライブラリの更新、ログの保管、個人情報の安全管理、インシデント時の連絡と費用負担を契約書へ反映します。

Vert.xのシステム開発費用・相場とコストの内訳

Vert.x単体の国内標準価格表はありません。フレームワークがオープンソースであるため、費用はライセンス料よりも、業務要件を整理する人件費、APIやイベントの設計、実装、テスト、クラウド、監視、保守、技術者の確保に左右されます。以下は、リサーチノートに記載した一般的な業務システム相場と、Vert.xで必要になりやすい非同期処理・性能検証・運用設計を踏まえた推定レンジです。正式な見積もりではなく、要件と前提を揃えるための目安として利用します。

PoCや性能検証は、対象APIが1〜2本、外部APIまたはメッセージ処理、負荷試験を含む場合で、50万〜300万円程度が一つの目安です。小規模な業務システムは、認証、DB、管理画面、API、基本監視を含めて300万〜800万円程度、中規模の連携基盤は、複数サービス、Kafkaなどのイベント連携、既存基幹やSaaSとの接続、可用性設計を含めて800万〜2,400万円程度、大規模・高可用性基盤は2,000万〜1億円以上になる可能性があります。いずれもVert.x固有の定価ではなく、業務範囲と品質条件を置いた推定です。

一般的な2026年版のシステム開発相場では、小規模が100万〜300万円、中規模が500万〜1,000万円、大規模が1,000万円〜数千万円以上、人月単価が60万〜200万円程度とされています（出典: SIA株式会社「システム開発の費用・相場 2026年版」）。Vert.x案件は、この一般相場に対して、非同期処理の設計、負荷・障害試験、可観測性、専門人材の確保が加わる可能性があります。見積もりがこのレンジから外れる場合は、高い・安いと即断せず、対象機能、工数、体制、試験、クラウド、保守が同じ条件かを確認します。

費用の内訳は、要件定義・企画、アーキテクチャ設計、UIやAPI設計、環境構築、実装、データ移行、テスト、リリース、プロジェクト管理に分けます。Vert.xでは、API契約、イベントスキーマ、非同期DBアクセス、タイムアウトと再試行、負荷試験、分散トレース、障害訓練を独立した作業項目として出してもらいます。「開発一式」とだけ書かれた見積もりでは、どこまで含むかが分からず、後から追加費用になりやすいためです。

運用費には、クラウドのコンピュート、DB、ストレージ、ネットワーク、メッセージング、監視、ログ保管、バックアップ、証明書、商用サポート、脆弱性対応、夜間休日のオンコールを含めます。保守は初期開発費の年15〜25%または月15万〜80万円程度を仮置きする考え方がありますが、稼働時間、SLA、対象範囲によって変わります。金額は固定せず、保守時間、対応時間、障害レベル、性能改善、バージョンアップ、追加開発を分けて提示してもらいます。

コストを抑えるときは、試験や監視を削るのではなく、最初のリリース範囲を絞ります。リアルタイム性が価値になるAPIやイベント連携をMVPに含め、帳票や細かな管理機能は既存ツールや次期開発へ分けます。PoCでVert.xを使う範囲を確認し、適さない単純業務まで同じアーキテクチャへ寄せないことも重要です。

見積もり段階では、要件定義を発注者側で完璧に仕上げる必要はありません。ただし、未確定項目を一覧にして、誰がいつ確定するかを合意します。データ移行の件数、外部APIの制限、ピーク負荷、監査要件、サポート時間など、後から費用が増えやすい条件を先に洗い出すだけでも、予算の精度は高まります。初期費用だけでなく、3〜5年のクラウド・保守・バージョンアップ費を含むTCOで比較します。

Vert.xの委託先選定と見積比較のポイント

委託先は、Vert.xという単語を知っている会社ではなく、業務・非同期処理・クラウド運用・品質保証を一つの体制で説明できる会社を選びます。公開事例が少ない技術であるほど、実績の件数だけでなく、担当者が設計上の失敗例やトレードオフを説明できるかを確認します。3社程度から同じRFPで提案を受けると、工数や単価の差を把握しやすくなりますが、会社数より比較条件の統一が先です。

技術面では、Vert.xのバージョン、JavaまたはKotlin、JDK、Vert.x CoreやVert.x Web、DBクライアント、KafkaやRabbitMQ、OpenAPI、認証、コンテナ、Kubernetes、OpenTelemetryまでの経験を確認します。特に、イベントループ上でブロッキング処理を避ける方法、ワーカープールを使う判断、タイムアウトと再試行の設計、負荷試験でどの指標を見るかを質問します。回答が抽象的であれば、PoCで実装・計測して評価する条件を提案します。

実績面では、自社の業務と近いデータ量、同時接続、外部連携、セキュリティ要件を持つ事例を確認します。体制面では、提案時の担当者が本番まで関与するか、レビュー担当がいるか、再委託先を含めて品質を管理できるかを見ます。代表者の経歴や技術一覧だけでは、プロジェクトの実装品質を判断できません。匿名化された構成図、テスト観点、障害対応手順、保守引き継ぎのサンプルを見せてもらうと、実務能力を比較しやすくなります。

見積書は、総額だけでなく、工程別の工数、担当ロール、単価、期間、成果物、除外項目、前提条件、リスク予備費、税、クラウド費、ライセンス費、保守費を並べて比較します。例えば、A社が300万円、B社が600万円でも、A社は負荷試験と監視を除外し、B社はPoC・移行・障害訓練まで含む可能性があります。機能一覧を同じ粒度で揃え、見積もり差分の理由を質問してから判断します。

工数の妥当性は、要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%という一般的な工程配分を参考にできます。ただし、Vert.x案件では非同期処理の検証、負荷試験、障害復旧、監視設計に追加工数が必要になる場合があります。数字を機械的に当てはめるのではなく、各工程の成果物と担当者を確認します。極端に安い見積もりは、要件定義、PM、テスト、運用設計、セキュリティ対応が抜けていないかを確認します。

Vert.xの外注では、技術者の離任、Vert.xやJDKのバージョン差、外部APIの仕様変更、クラウド費の増加、性能未達、データ移行の不備、監視漏れ、再委託の不透明さが主なリスクになります。対策として、リスク登録簿を作り、発生確率、影響度、予防策、発生時の対応、担当者、期限を管理します。PoCの段階で性能や人材の懸念を可視化し、本開発へ進む判断基準を設けます。

仕様変更は、口頭やチャットだけで進めず、変更票に目的、変更内容、影響範囲、追加工数、追加費用、納期、セキュリティ影響、承認者を記録します。委託先からの提案を拒むのではなく、同じ予算で何を残し何を次期へ回すかを合意します。受入時は、画面の完成だけでなく、性能基準、エラー処理、監査ログ、バックアップ、ロールバック、運用手順、ソースコードと設計書の引き渡しを確認します。

Vert.xのシステム発注・外注でよくある質問

Vert.xのシステムを初めて発注する企業からは、費用、委託先、既存システムとの関係、ライセンス、保守について多くの質問が寄せられます。ここでは、発注判断の前に確認しておきたい質問へ直接回答します。

目安は、PoC・性能検証で50万〜300万円、小規模業務システムで300万〜800万円、中規模連携基盤で800万〜2,400万円程度です。大規模・高可用性基盤は2,000万〜1億円以上になる可能性がありますが、いずれもVert.xの定価ではなく、機能、連携数、性能、移行、保守の条件をもとにした推定レンジです。RFPで条件を揃え、工程別の工数と除外項目まで比較する必要があります。

Vert.xの記載がある会社を候補にしつつ、API、非同期DBアクセス、メッセージング、クラウド、コンテナ、監視、セキュリティを一体で扱えるか確認します。実績の件数だけではなく、対象案件に近い負荷、データ量、外部連携、障害対応の経験を質問し、必要ならPoCを依頼します。担当者の実装力、レビュー体制、再委託、保守と知識移管の方法まで確認すると、発注後の属人化を防ぎやすくなります。

Vert.x本体はオープンソースで、公式にはEPL 2.0とApache 2.0のデュアルライセンスで提供されています。そのため、商用ソフトウェアのようなフレームワークの利用料が発生しない構成は可能ですが、開発費が自動的に安くなるわけではありません。設計、非同期処理のテスト、脆弱性対応、クラウド、監視、商用サポート、保守の費用を含めた総額で判断します。

移行できる可能性はありますが、全体を一括で置き換える必要はありません。高並行なAPI、リアルタイム通知、外部イベント連携など、Vert.xの効果が出やすい境界から段階的に切り出し、既存のSpringやJakarta EEの業務処理を残すハイブリッド構成も選べます。移行前に、DBトランザクション、認証認可、データ整合性、性能、監視、ロールバックをPoCで確認し、Vert.x 4から5への移行を含める場合は非推奨APIや破壊的変更を確認します。

Vert.xのシステム発注・外注のまとめ

Vert.xのシステムを発注するときは、「高速だから採用する」のではなく、高並行処理、リアルタイム性、イベント駆動、外部連携の価値が、専門人材や試験・運用のコストを上回るかで判断します。発注の前に、業務課題、対象範囲、性能目標、既存システムとの境界、RFPの未確定事項を整理し、PoCで実データに近い条件を検証します。

発注前は、(1)Vert.xを使う業務上の理由、(2)対象機能と対象外の範囲、(3)同時接続数・RPS・P95やP99・エラー率、(4)DB・外部API・メッセージング、(5)認証認可・監査・個人情報、(6)RTO・RPO・SLA、(7)PoCの成功条件、(8)成果物と権利、(9)契約形態と変更管理、(10)開発後の保守体制を一枚にまとめます。これらが揃うほど、委託先の提案と見積もりを同じ基準で比較できます。

Vert.xの採用に迷う場合は、代表的なAPIやイベント連携を対象にPoCを実施し、性能・開発生産性・運用性・チームの習熟度を比較します。本開発では、請負と準委任を要件の確定度に合わせて使い分け、見積もりに試験、監視、セキュリティ、データ移行、保守を含めます。公開されているVert.xの最新バージョンや脆弱性情報を継続的に確認し、発注先と一緒に更新・障害・引き継ぎの計画まで作っておくことが、長く使えるシステムにつながります。

Vert.xのシステム開発を検討している場合は、技術選定だけでなく、RFP作成、PoC、委託先の比較、契約、保守まで一貫して相談できるパートナーを選ぶと進めやすくなります。自社の課題と将来の拡張を整理し、性能と費用のバランスを確認しながら、段階的な発注計画を作成します。

▼全体ガイドの記事
・Vert.xのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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