Vert.xのシステム開発の完全ガイド

Vert.xのシステム開発は、多数の接続やイベントを同時に扱い、待ち時間を抑えたい業務に向いた選択肢です。採用を判断するには、性能だけでなく、開発の進め方と費用、開発会社の選び方まで含めて見ることが大切です。

特性や適した業務から、工程、費用、会社選び、運用、RFPまでを、発注側の視点で順に見ていきます。

▼関連記事一覧
・Vert.xのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Vert.xのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Vert.xのシステム開発の見積相場や費用/コスト/値段について
・Vert.xのシステム開発の発注/外注/依頼/委託方法について

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

Vert.xの概要

Vert.xは、リアクティブなアプリケーションを作るためのツールキットで、JVM上で動く業務パッケージとは性格が異なります。HTTP API、WebSocket、メッセージ処理、マイクロサービスを、JavaやKotlinなどで実装できます。

公式情報によると、Vert.x 5は2025年5月15日にリリースされ、4系からの移行を意識して進化したと案内されています（出典: Vert.x公式ブログ、2025年）。

ツールキットとしての位置づけ

フルスタック型では、画面やデータアクセス、認証の構成があらかじめ定まっている場合があります。一方、Vert.xではCore、Web、DB、メッセージング、認証、監視を選んで組み合わせます。

自由度が高い分、サービス間の責務やエラー処理はチームで設計しなければなりません。再試行やタイムアウト、ログの取り方も、あらかじめ決めておくと、障害が起きたときに対応を迷わずに済みます。

主なモジュールと業務システムでの役割

業務システムでは、API、データ連携、運用それぞれの役割に応じて、モジュールを組み合わせます。

• 基礎機能：Vert.x Coreが、HTTP・TCP、イベントループ、Future、タイマーなどを担います。
• Web・API：Vert.x WebがREST APIやWebSocketなどのWeb機能を受け持ちます。
• データ・メッセージ連携：DBクライアントやJDBC、メッセージ連携機能を使えます。
• 運用機能：ヘルスチェック、Micrometer、OpenTelemetry、分散トレーシング、クラスタリングなどを組み合わせて使います。

Vert.x Coreでは、ファイル操作やVerticleのデプロイも行えます。

Vert.x Webでは、ルーティングやフォーム、静的ファイル、リクエストタイムアウトも扱えます。さらに、OpenAPI 3を使えば、API境界を先に定義できます。

データ連携では、PostgreSQL、MySQL、Oracle、SQL Server、MongoDB、Redisのクライアントを候補にできます。さらに、Kafka、RabbitMQ、AMQP、MQTT、gRPCとも連携できます。

バリデーション、OAuth 2、JWT、LDAPも利用できます。ただし、部品を有効にするだけでなく、業務要件に合わせて組み立てる必要があります。

データの整合性や監査ログ、権限は、部品とは別に設計します。また、障害時の復旧方法も事前に決めておきます。

Vert.xのシステムが向く業務

接続数やイベント数が多く、応答の待ち時間を短くしたい業務では、Vert.xの特性が生きます。

APIゲートウェイやリアルタイム通知のほか、IoT・センサー連携や予約・決済連携も挙げられます。外部サービスの呼び出しが多い業務や、イベント駆動のマイクロサービスにも適用できます。

帳票や複雑な一括処理が中心の場合は、標準的な別構成とも比べて判断します。

API・リアルタイム通知・外部連携

短い処理を大量に受け付ける業務では、イベント駆動の設計が効果を発揮します。

• 対象業務：会員API、在庫・予約照会、決済連携、通知配信
• 連携方式：WebSocketの状態通知、メッセージブローカー経由の非同期連携
• 外部APIの遅延対策：タイムアウト、再試行回数、サーキットブレーカーを組み合わせて備えます。
• 障害への備え：失敗したイベントを保管しておき、障害の後で処理内容を確かめられるようにします。

既存Java資産の一部切り出し

既存のJavaモノリスは一度に作り直さず、課題のある境界から順に移行できます。

• 切り出す領域：高負荷API、外部連携、通知やイベント配信など、並行性が課題の部分
• 既存構成に残す領域：販売管理やマスタ管理などの安定した部分
• 移行の進め方：APIやイベントで境界を定義し、範囲を小さくして業務を止めずに効果を検証します。

単純CRUD・帳票中心の業務と比較検証

登録・検索・更新・削除が中心の業務では、非同期の仕組みが費用対効果につながるとは限りません。

• 比較が必要な条件：同時接続が少ない、帳票の一括生成や複雑なトランザクションが主な課題
• 比較する候補：Spring Boot、Quarkus、Node.js、Jakarta EEなど
• 比較条件：業務、データ量、負荷をそろえたうえで、開発者確保、デバッグ、監視、保守まで評価します。

採用は、性能の数字だけで決めず、ほかの観点も含めて判断します。

Vert.xのシステム開発の進め方

Vert.x開発では、設計の不足や運用要件の抜けが実装後に見つかると手戻りが大きくなります。そのため、工程は次のとおり順に進めます。

1. 要件定義で処理量と業務目的を固める。
2. PoCでVert.xと他候補を比較する。
3. API・イベントの境界を設計し、実装する。
4. 負荷・障害試験を経て、段階的にリリースする。
5. 保守と更新の手順を整え、運用する。

特に、「何件を何秒以内に処理するか」と「失敗イベントをどう再処理するか」は、早い段階で決めておきます。

▶ 詳細はこちら：Vert.xのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

要件定義とPoCによる採用理由の数値化

採用理由を確かめるPoCでは、まず業務目的を数値にし、候補を同じ条件で比べます。

• 目的と負荷条件：業務効果と性能条件を数値で定めます。
• 業務上の条件：許容できる重複とRTO・RPOを決めておきます。PoCは2〜8週間程度が目安です。
• 候補の比較：代表シナリオと実データに近い負荷で、性能・開発生産性・障害対応を比べます。
• 合格条件：処理件数に加え、イベントループのブロック、外部API遅延時の枯渇、重複時の冪等性、トレースによる原因追跡を確認します。

目的は高速化だけに限らず、離脱率の低下や、通知遅延・連携失敗・運用工数の削減に置き換えられます。目標RPSや同時接続数、P95・P99遅延などの指標も定義します。データ量やピーク時間、処理順序も、あらかじめ決めておきます。

不採用になった場合でも、要件の曖昧さやボトルネックが分かれば、後工程の手戻りを防げます。

API・イベント・データの境界設計

実装の前に、API・イベントの仕様と、許容するデータ不整合の範囲を関係者で合意しておきます。キューとタイムアウトの扱いも、あらかじめ決めておきます。さらに、DB接続数、キュー滞留、ネットワーク、CPU・メモリも設計対象です。

• API契約：OpenAPIなどで、入力・出力、認証、エラーコード、ページング、版の方針を定義します。
• イベント契約：名前、スキーマ、発行者、購読者、順序性、保持期間、再送、重複排除、隔離先を決めておきます。
• 処理方式：同期JDBCや重いファイル変換、長時間の外部API呼び出しを、イベントループ上で動かさない設計にします。
• 実行環境：非同期クライアントとワーカープールを使い分けて設計します。

DBのトランザクションとメッセージ配信保証は別物として扱い、利用部門と許容範囲を合意します。ブロッキングを検出するテストも組み込みます。

負荷・障害試験と段階的リリース

試験では障害時の動作を確かめ、個人情報の扱いと段階リリースの条件も整えておきます。

• 障害試験：API結合に加え、タイムアウト、再試行、順序逆転、重複配信、途中停止を再現します。
• 依存先の障害：DB、メッセージブローカー、外部APIで障害や異常応答が起きた場合の動きを見ます。
• 負荷試験：平均値だけでなく、P95・P99遅延、エラー率、CPU、メモリ、イベントループ遅延、キュー滞留を測ります。
• 本番移行：対象業務と利用者を絞り、ロールバック、二重書き、旧API互換期間、アラート、緊急連絡先を決めておきます。

個人情報を含むテストデータは、匿名化やマスキングを施し、アクセス権も本番と分けます。

CI/CD、コンテナ、IaC、バックアップ、脆弱性スキャン、依存ライブラリの更新手順も受入条件に含めます。そうすると、開発完了から運用開始までのリスクを抑えられます。

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

Vert.x単体には、国内で標準となる開発価格表はありません。Vert.xはOSSのため、席数ライセンスが主な費用になるわけではありません。総額を左右するのは、要件定義や非同期設計、テストのほか、クラウド、監視、保守、人材確保です。

次に示すのは、2026年公開の一般的な業務システム相場に、Vert.xのAPI・イベント処理やコンテナ運用の工数を加えた推定です。正式な見積ではありません。

▶ 詳細はこちら：Vert.xのシステム開発の見積相場や費用/コスト/値段について

規模別の開発費と期間の目安

費用は、開発規模と含める機能によって、50万円から1億円以上まで幅があります。

• PoC・性能検証：1〜2個のAPI、外部APIまたはメッセージ処理、負荷試験が対象になります。目安は50万〜300万円、1〜2か月です。
• 小規模業務システム：1〜3業務、認証、DB、管理画面、API、基本監視を含み、300万〜800万円、2〜5か月程度です。
• 中規模連携基盤：複数サービス、イベント連携、基幹・SaaS接続、可用性設計を含み、800万〜2,400万円、5〜10か月程度が目安です。
• 大規模・高可用性基盤：多拠点・大量アクセス、個人情報・決済、移行、冗長化、24時間運用まで含み、2,000万〜1億円以上、10か月〜2年以上の場合があります。

PoCや小規模の額は、範囲を限った目安であり、Vert.xの最低価格を示すものではありません。

また、単一業務であれば数百万円ほどで、複数業務をまたぐ基幹連携は1,000万〜3,000万円以上になります。複雑なフルスクラッチ開発は、数千万円から億単位に達します（出典: 2026年公開の国内システム開発費用調査）。

人件費・設計費・テスト費の考え方

見積書では、人月単価や人数だけでなく、誰がどの成果物を作るのかも確かめます。

• 工程の内訳：要件定義と設計、環境構築、実装を含みます。さらに、各種テストや移行、教育、リリース支援も対象です。
• 一般的な配分：要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%
• Vert.x固有の試験：非同期処理、負荷、障害復旧、分散トレーシングの工数を別枠で示します。
• 担当と成果物：アーキテクトはイベント設計、アプリ担当はAPI、インフラ担当は監視・デプロイなどを担います。

PoCや運用設計が抜けると、本番の前に追加費用が生じがちです。そのため、総工数と前提条件も比べます。

クラウド・監視・保守のランニングコスト

初期開発とは別に、基盤や保守、バージョン更新にかかる費用も見積もっておきます。

• 基盤・監視：計算資源、DB、メッセージ基盤、ストレージ、通信、バックアップ、監視、ログ保存、脆弱性スキャン
• 従量課金：外部サービスの利用上限を、費用の管理対象として扱います。
• 保守運用：初期開発費の年15〜25%、または月15万〜80万円程度を仮置きし、対応時間や監視範囲などで調整します。
• バージョン更新：Vert.x 5.1.5は2026年7月13日に公開されています。

APIの呼び出し回数や保存データ量で課金される外部サービスでは、レート制限も併せて確かめます。

公式リリース一覧では、5.1.5をバグや脆弱性の修正を含む更新として案内しています（出典: Vert.x公式リリース一覧、2026年7月）。

Vert.x、JDK、Nettyの版や、検証環境、緊急パッチの期限、サポート期間は、あらかじめ固定しておきます。更新を保守範囲から外す場合は、別費用と判断期限を決めます。

Vert.xのシステム開発会社・ベンダーの選び方

会社を比べるときは、技術名だけで判断せず、公開実績や担当者の経験を確かめます。非同期DBやイベント駆動のテスト、Kubernetes、OpenTelemetryを説明できるかも見ます。認証認可や障害対応についても、具体的に語れるかが大切です。

Vert.xの専門会社を公的に一覧できる資料はありません。候補の数より、業務に近い実績の証拠と提案の具体性で比べます。

成果物で見る実務経験

実務経験は、成果物と質問の両方で確かめます。

• 実績の条件：実装した規模、負荷、障害の条件を確かめます。
• 成果物：構成図、API仕様、負荷試験計画、イベントスキーマ、監視画面の例を見ます。
• 技術経験：イベントループのブロック検出方法、Vert.x 4から5への移行、JDK、Java・Kotlin比率、Maven・Gradle管理を尋ねます。

提案・見積・契約の透明性

提案や見積の前提、段階的な契約、成果物と契約条件を、発注前に確かめます。

• 提案と見積：採用理由、PoC条件、性能・保守範囲を明確にします。
• 契約の段階：要件定義とPoCを分けておけば、検証のあとに本開発へ進むかを判断できます。
• 成果物と権利：コード、設計書、API仕様、IaC、CI/CD、テスト、翻案権を含む知的財産の帰属を確かめます。
• 保守と契約方式：一次・夜間対応、脆弱性、依存更新、再委託、終了時の引き継ぎを定め、請負・準委任の方式と成果物を対応づけます。

Vert.xを使わない領域についても、提案書に明記させます。

性能面では目標RPSやP95・P99遅延、同時接続数を書きます。運用面では、RTO・RPO、データ移行、SLA、監視、保守費も記載します。

機能一覧だけでは、再試行や障害復旧、ログ、セキュリティレビューが抜けやすくなります。

請負か準委任かによって、変更管理と費用の考え方が異なります。

保守・障害対応の体制

イベント駆動の仕組みでは、画面に出たエラーだけで原因を特定しにくい場合があります。

• 原因の追跡：リクエストIDやトレースIDをログ・メトリクス・分散トレースでつなぎます。
• 再処理と整合性：再試行上限、隔離メッセージの確認者、手動再送権限、復旧後の確認を決めます。
• 対応基準：一次判断の担当者と時間、脆弱性情報の確認頻度、本番性能劣化の検知指標を尋ねます。
• 継続体制：コード・設計レビュー、知識共有、後任体制、文書更新を続けられる仕組みがあるかを確かめます。

API、DB、メッセージ、外部サービスのどこで遅延や失敗が起きたかを追える体制を整えます。

▶ 詳細はこちら：Vert.xのシステム開発でおすすめの開発会社/ベンダー6選と選び方

セキュリティと運用の確認事項

認証と認可は分けて考え、利用者が見られるデータや実行できる機能、操作できる項目を、業務ごとに定めます。

個人情報や決済情報、従業員情報を扱う場合は、安全管理の方針を設計、実装、運用、委託先の管理に反映します。

認証・認可・入力制限のAPI設計への組み込み

認証だけでなく、データへの権限確認と、入力や処理量の制限も設けます。

• 認証・認可：OAuth 2やJWTを使う場合も、認証と認可を個別に確かめます。
• 権限照合：URLや本文のIDのみに頼らず、サーバー側で業務上の関係を確認します。
• 入力・処理の上限：型・文字数、配列数、容量、ページサイズ、処理時間、同時実行数を制限します。
• 資源の保護：処理量を制限し、停止や従量課金の増加を防ぎます。

トークンを検証するだけでなく、対象データの所有者や所属、役割、操作の種類を、毎回確かめます。

OWASP API Security Top 10 2023では、オブジェクト・機能単位の認可不備や認証不備が、主要なリスクに挙げられています。さらに、機微な業務フローへの過剰アクセスも取り上げられています（出典: OWASP API Security Top 10、2023年）。

無制限の資源消費は、サービス停止だけでなく、外部APIの従量課金やクラウド費の増加にもつながります（出典: OWASP API Security Top 10 API4:2023）。

レート制限やタイムアウト、キュー上限、利用額アラートは、要件と受入テストに含めます。

暗号化・監査ログ・脆弱性対応の運用

暗号化や監査ログは設計段階で決め、脆弱性対応とAPI管理は運用手順に組み込みます。

• 暗号化・権限：通信はTLSを基本とし、保存データ・バックアップの暗号化、鍵管理、権限分離を決めます。
• 監査ログ：実行者、日時、API、対象データ、操作を記録し、マスキング、保存期間、閲覧権限、改ざん検知も設計します。
• API管理：API、ホスト、版、利用者、廃止予定を一覧で管理し、デバッグ用エンドポイントを本番に出しません。
• 脆弱性対応：依存ライブラリ確認、緊急更新、再ビルド、回帰試験、承認の手順を用意します。

個人情報保護委員会の安全管理の観点は、社内規程や委託先管理にも反映します（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」）。

可用性・性能・業務結果の3層による監視

インフラが動いていても、予約確定のイベントが失敗していることに気づかない場合があります。

• 可用性：ヘルスチェック、エラー率、再起動、コンテナ数
• 性能：P95・P99遅延、イベントループ、DB接続、キュー滞留
• 業務結果：未処理・重複イベント、決済・予約失敗、再送待ち

外部APIの応答時間も、性能指標に含めます。アラートは数を増やすより、担当者がすぐ動ける内容にすることが大切です。

キューが滞留したときは負荷を抑え、外部APIの失敗率が上がったときは呼び出しを遮断します。再試行待ちが増えた場合は、業務担当へ連絡します。

月次のレビューでは、実際のピークとPoCの前提を比べ、容量計画と保守費を見直します。

発注前にRFPへ書くべき項目

Vert.xを前提にする場合でも、技術名だけでなく、性能と運用の条件を具体的に書きます。別の構成の提案余地を残しておくと、業務要件に合った比較ができます。

Vert.xを指定する場合は、その理由と対象サービスを明記します。あわせて、バージョンやJDK、周辺ライブラリ、サポート方針も書きます。

▶ 詳細はこちら：Vert.xのシステム開発の発注/外注/依頼/委託方法について

機能要件と非機能要件の数値化

機能要件と非機能要件は分けて書き、受け入れ判定ができる内容にします。

• 機能要件：利用者、業務フロー、API、画面、データ、外部連携、通知、権限、帳票、移行対象
• 性能要件：目標RPS、同時接続数、P95・P99応答時間、ピーク時間、可用性
• 運用要件：RTO・RPO、バックアップ、保持期間、監査ログ、脆弱性対応、SLA

「大量アクセスに対応する」のような表現は判定の基準になりにくいため、数値で示します。

成果物・権利・移行条件の合意

納品の範囲や権利、移行の条件は、発注の前に合意しておきます。

• 納品物：要件・設計書、API仕様、イベントスキーマ、ソース・テストコード、試験結果
• 運用関連の成果物：監視・運用・障害対応手順、IaC、CI/CD定義、依存ライブラリ一覧
• 権利・引き渡し：コードの利用・改変・再委託、OSSライセンス、第三者部品、契約終了時の引き渡し
• 移行・段階展開：対象データ、変換、照合、停止時間、リハーサル、切り戻し、初回業務・利用者、旧API併用、MVP後の拡張条件

移行リハーサルの回数と、旧システムを停止する時期も、RFPに記載します。

機能を増やす前に成功指標と中止基準を決めておくと、PoC後の判断がぶれずに済みます。

同じ評価表による提案の比較

価格に加えて、技術・業務・運用の提案を、共通の評価軸で比べます。

• 評価項目：経験、PoC、業務理解、API・イベント設計、セキュリティ、保守、移行計画、体制、成果物、契約条件
• 採点と足切り：各項目を5段階で採点し、性能要件を満たさない提案を除外するなど条件を決めます。
• 提案の具体性：質問に対し、具体的な試験や失敗時の扱いまで答えられるかを見ます。
• 見積と引き継ぎ：前提、除外、試験・移行範囲、保守時間、クラウド費を確認します。PoCのコード・計測・設計判断は次の発注先へ渡せる形にします。

技術の選択とベンダーの選定は、分けて評価できます。

Vert.xのシステムに関するよくある質問

Vert.xの導入では、技術、費用、体制、移行、セキュリティの各面で、事前に確かめておく点があります。

発注の前によく出る疑問に、順に答えます。

Vert.xはOSSなので開発費は無料ですか？

無料ではありません。OSSを使うことでライセンス費を抑えられる可能性はありますが、要件定義や設計、実装、テストには費用がかかります。さらに、クラウド、監視、保守、人材育成にも費用がかかります。

商用サポートや有償の基盤を使う場合は、対象範囲や対応時間、対象版、SLAを確かめます。

Vert.x 4から5へ移行できますか？

移行は可能ですが、互換性を確かめてから更新します。

• 事前確認：依存ライブラリや非推奨API、破壊的変更、JDK、試験、運用基盤を、先に確かめます。
• 採用版の管理：Vert.x 5は2025年公開で、2026年7月にも5.1.5が更新されています。新規案件は版と更新方針を固定します。
• 既存案件の検証：移行用ブランチと回帰試験を用意し、API、メッセージ、外部連携、性能を見ます。

Vert.xを扱えるエンジニアが少ない場合はどうしますか？

全社の標準にはせず、高並行のAPIや連携に絞って、PoCや小規模のMVPで知識を蓄えます。そのうえで、イベントループや非同期DB、Future、メッセージの再処理、トレースの扱いを、レビューや障害訓練で共有します。

外部の体制を使う場合も、コード、設計書、試験、運用手順を社内へ引き継ぐ条件を契約に含めます。

Vert.xを採用するか迷ったときの判断基準は何ですか？

同時接続やリアルタイム性、外部連携、イベント駆動による効果が、追加の費用に見合うかで判断します。採用の理由を数値にできない場合は、代表シナリオのPoCで、Spring Bootなどと同じ条件で比べます。

性能に加えて、人材の確保や障害復旧、セキュリティ、5年程度の保守計画も判断材料になります。

まとめ

Vert.xは、API、リアルタイム通知、IoT、予約・決済連携、高並行のマイクロサービスに向いています。一方、CRUDや帳票が中心の業務なら、標準的な人材が多い構成と比べて、採用理由を検証します。

性能・費用・運用をそろえた採用判断

PoC・性能検証は50万〜300万円、小規模は300万〜800万円です。中規模は800万〜2,400万円、大規模・高可用性は2,000万〜1億円以上となります。

ライセンスだけでなく、非同期設計や試験、クラウド、監視、保守、人材確保まで含めた総保有コストで比べます。

RFPとPoCの準備

まずRFPに性能と運用の条件をまとめておくと、候補会社との話し合いが具体的になります。

• 要件の記載：目標RPS、同時接続数、P95・P99遅延、RTO・RPO、移行、監視、セキュリティ、成果物、保守費を整理します。
• 候補会社への確認：Vert.x・JDKの版、イベントループ対策、負荷試験、障害時の再処理、脆弱性対応を質問します。
• PoC後の判断：代表業務で採用理由を検証し、結果を踏まえて段階的に本開発へ進みます。

▼関連記事一覧
・Vert.xのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Vert.xのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Vert.xのシステム開発の見積相場や費用/コスト/値段について
・Vert.xのシステム開発の発注/外注/依頼/委託方法について

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