Java EEのシステム開発は、現行資産の棚卸しから始め、移行方式を選んで段階的に開発と移行を進め、運用定着まで見届ける流れで進みます。
具体的には、要件整理から定着までを6つのフェーズに分けて進めます。
▼全体ガイドの記事
・Java EEのシステム開発の完全ガイド
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
Java EEのシステムの全体像
Java EEは、企業向けのWebアプリや業務システムを作るための標準仕様群で、アプリケーションサーバーと組み合わせて使います。認証やトランザクション、DB接続などを扱うほか、非同期処理やREST API、入力検証、監視にも関わります。開発には、業務・インフラ・運用の計画も必要です。
Java EEとJakarta EEの違い
Java EEのシステムには、Java EE 6〜8の既存システムと、Eclipse FoundationのJakarta EEで新規開発・刷新するものがあります。両者は名称や仕様の扱いが異なるため、まず自社がどちらに当たるかを押さえます。
- API名の変更：Jakarta EE 9以降は
javax.*からjakarta.*へ変わりました。 - 互換性の確認：コードや設定、ライブラリ、テスト、外部連携について、互換性を調べます。
- 移行先の比較：Java EE 8で延命する案、Jakarta EE 8へ移す案、10・11へ段階的に移る案を比べます。
JDKやサーバーを新しくするだけでは動かず、コードや設定の調整も必要になります。Jakarta EE 11は2025年6月に正式リリースされ、Java 17以上をサポートします。
Jakarta EE 11には、Java 21の仮想スレッドやJakarta Data、TCKの近代化などが含まれます（出典: Eclipse Foundation「Jakarta EE 11 Release」、2025年）。移行を判断するときは、業務停止のリスクと保守期限を基準にします。
システム構成と棚卸し対象
典型的な構成は、ブラウザや外部システムから、ロードバランサーまたはAPIゲートウェイを経てJava EEサーバーに至り、その先にRDBやメッセージングが続きます。認証やログ・監視基盤も、構成の一部として押さえます。
- 画面と業務処理：Servlet・JSPとCDI・EJBが、それぞれどこまでを受け持つかを確かめます。
- データと連携：JPA、JAX-RS、JMSの利用箇所を洗い出します。
- 基盤と運用：JDK、サーバー、DB、帳票、バッチ、ファイル連携を一覧にします。
- 統制と障害対応：認証・権限、監査ログ、依存ライブラリ、手順・切り戻しの状況を見ます。
どの機能がどの層にあるかを押さえておくと、開発とテストの範囲を取り違えにくくなります。また、JDKの起動オプションやjavax.*・jakarta.*の利用状況も記録しておきます。
棚卸しの対象には、画面だけでなく、夜間バッチや月末締めの処理も含めます。例外処理や連携先への再送処理も、対象に入れます。
Java EEのシステムの進め方
開発は6つのフェーズで管理します。要件整理から始め、技術・製品の選定、設計・開発、テストを経て、稼働と定着に進みます。各フェーズには成果物と判断基準を置き、次へ進む条件を関係者と合意しておきます。
既存移行では、開発を急ぐより初期調査で不確実な点を減らすほうが、後工程の追加費用を抑えやすくなります。
フェーズ1：目的と現状をそろえる要件整理
現行業務の流れや不満、守るべきルールを、まず確かめます。
- 業務と関係者：成果と条件を定めたうえで、現場、情シス、セキュリティ、運用、経営側から課題を聞き取ります。
- 対象業務：申請・承認、登録・請求、受注・出荷の流れを整理します。
- 成果物：業務フロー、機能・データ・連携、非機能、移行をまとめます。優先順位や前提、課題・リスク台帳も含みます。
- 完了条件：利用部門が優先順位を承認し、開発会社が対象外の範囲を説明した時点で完了とします。
要件には画面だけでなく、帳票やバッチも含めます。データ連携や権限、例外処理も、要件として書き出しておきます。
非機能要件には、同時利用者数、ピーク処理件数、応答時間を数値で記載します。バッチ完了時刻や可用性も、同じく数値で示します。RTO・RPOとバックアップ保持期間も、数値で定めます。
監査ログと個人情報の保管場所も定めておきます。「高速」「安全」「止まらない」といった言葉を数値や条件に置き換えておくと、見積もりや受入判定の根拠になります。
未確認のソースや設定、DB定義があれば、その旨を明示します。ジョブや連携仕様、運用記録についても、確認の状況を書き添えます。ブラックボックスの部分は、調査用のPoCや追加分析を別の見積もりに分けておくと、後からの大幅な増額を防ぎやすくなります。
フェーズ2：技術・製品の比較と移行方式の選定
発注先やサーバーは、Java EEという名称より業務要件を基準に選びます。新規開発ならJakarta EE、既存のSpring資産ならSpring Boot、軽量なサービスやコンテナ運用ならQuarkusも候補になります。
判断では、人気よりも業務要件を優先します。担当者の経験や仕様、保守期間、障害対応体制も、あわせて見ます。大規模な基幹系ではJakarta EEが適しやすい一方で、小さなサービスを短期で分割する場合は別案が有効なこともあります。
既存資産の方式は、次の4案を比較します。
- 現行環境を延命：現行サーバーを保守しながら使い続けます。
- サーバーを移行：同じJava EE系の仕様を持つ別サーバーへ移す方式です。
- 仕様を変換：
javax.*からjakarta.*へ変えながら移行します。 - 段階改修：Spring BootやQuarkusなどへ、少しずつリファクタリングします。
比べるのは、修正箇所や回帰テスト量、停止時間です。加えて、ライセンスや運用スキル、人材確保、切り戻しも比較軸に入ります。一度にマイクロサービス化するより、モジュラーモノリスとAPI分離から始めるほうが、影響を抑えられる場合もあります。
サーバーが仕様に対応しているかは、製品名ではなくバージョンとプロファイルで確かめます。たとえば、IBM資料ではLibertyが、Java EE 8、Jakarta EE 8、9.1、10、11をサポートすると示されています。
同資料は、26.0.0.5以降のJakarta EE 11対応についても説明しています（出典: IBM「LibertyにおけるJakarta EEおよびJava EE 8」、2026年確認）。
JBoss EAP 8.1はJakarta EE 10に対応します（出典: Red Hat「JBoss Enterprise Application Platformでサポートされる標準」、2026年更新）。候補製品の認定状況と、アプリが使う仕様への対応状況は、別々に確認します。
Azul PayaraはBMW GroupのGlassFishからPayara Serverへの移行事例を公開しています（出典: Azul Payara「Payara Server」公開事例）。移行計画には、製品の交換だけでなく、互換性や性能、運用手順、サポート体制も含めます。代表的な機能を候補サーバーで動かし、差分を測って方式を決めます。
フェーズ3：標準化と運用性を組み込んだ設計・開発
設計・開発では、実装の仕様から稼働後の運用までを見通して準備します。
- 業務設計：データモデルと処理仕様、障害時の動作を決めておきます。
- 開発標準：JDK・ビルドのバージョン、依存管理、レビュー、テストのルールを統一します。
- 移行検証：互換性を調べ、変換の前後で業務結果を比べる作業です。
- 運用準備：構成を再現できるか、監視や復旧手順、納品物がそろっているかを確かめます。
画面、API、バッチ、帳票をデータモデルに結びつけて設計します。そのうえで、トランザクションや排他制御、再送、タイムアウトを決め、エラーコードとログの扱いも定めます。
設計書では、標準APIとサーバー固有の機能を分けて書いておくと、将来サーバーを変えるときの影響を把握できます。加えて、ブランチの運用や静的解析、自動テストも、開発の決まりとして定めます。
設定は暗号化し、秘密情報の保管場所を決めておきます。移行では、javaxからjakartaへの置換に加えて、非標準APIやXML、認証、クラスローダーの扱いを確認します。さらに、JPA方言や文字コード、日時処理も、動きが変わらないかを見ます。
業務シナリオは、実データに近いテストデータで再現します。ソースと設定はリポジトリで管理し、第三者がIaCやデプロイを再現できるかを確かめます。
監視・アラートの担当者を決め、復旧手順を実際に試します。ビルド環境やDB定義、証明書更新、ジョブ、Runbookも納品対象に含めます。
フェーズ4：業務結果と非機能要件を検証するテスト
テストは、種類をこなすことより、業務シナリオをケースに分けて検証することを中心にします。機能の正しさに加えて、性能や復旧、情報保護の観点も確認します。
- 業務・回帰：シナリオをケースに分け、既存の結果と一致するかを確かめます。
- 性能・復旧：負荷の指標を測り、必要に応じて復旧と切り戻しの時間も実測します。
- セキュリティ：認証・認可、最小権限、セッション、入力の扱いを確認します。暗号化、監査ログ、依存ライブラリの脆弱性も確認します。
試験は単体、結合、システム、受入の順に進めます。ケースには、正常系や権限不足、二重送信を含めます。
特に、通信断やDB障害、連携遅延、月末・年度末の処理は、確かめておく必要があります。バッチの再実行も、そのなかに含めます。
既存移行では、重要な業務から順に回帰テストを設計します。性能は、ピーク時の同時接続数や毎分の処理数、95パーセンタイル応答時間で測ります。
バッチの処理時間や、CPU・メモリ・DB接続プールも測定します。試験は本番に近いデータ量で行い、キャッシュやログ、外部連携の遅延も含めます。
RTO・RPOを定める場合は、バックアップからの復旧と切り戻しを実測し、所要時間を記録します。なかでも、SQLインジェクションやXSS、CSRFは、試験で実際に確かめます。
OWASP Top 10の2025年版には、アクセス制御の不備、設定の不備、サプライチェーンの失敗、暗号化の失敗、インジェクションなどが含まれます（出典: OWASP Developer Guide「OWASP Top 10」、2025年版）。
個人情報を扱う場合は、個人情報保護委員会の指針に沿って、アクセス記録や委託先の管理、漏えい時の連絡と復旧手順を受入条件に入れます。
フェーズ5：切り替えと切り戻しを管理する稼働
移行では、移行時間と業務凍結の時期を先に決めておきます。利用者への案内も、切り替えの前にそろえます。
- 事前準備：対象データや停止時間、連携先への通知、窓口、本番切り替えの判定者を決めておきます。
- 移行確認：本番前のリハーサルで、データと業務の整合性を点検します。
- 切り替え方式：一括、段階、並行稼働を、業務への影響で比べます。
- 稼働後：監視・復旧体制を動かしたうえで、初期の課題を定期的に確認します。
移行リハーサルは少なくとも一度行い、件数や欠損、重複、文字化け、採番、権限を確かめます。残高や在庫の数字が業務として合っているかも、あわせて見ます。
一括移行は短期で済みますが、障害時の影響が大きくなります。段階移行は部門や業務を分けてリスクを下げられる一方で、旧新間の連携が増えます。
並行稼働は比較検証に有効です。ただし、二重入力や照合作業が発生します。方式は、費用だけでなく、業務停止をどこまで許容できるかと切り戻しの時間で評価します。
当日は、監視やログ、バックアップの状態を確かめます。そのほか、ジョブや証明書、外部連携、権限も確認します。
障害に備えて、重大障害の基準や一次切り分け、エスカレーションを決めておきます。復旧目標や経営報告のひな形も、準備しておきます。
稼働後30日程度は、開発会社と利用部門が日次または週次で課題を確認します。確認の対象は障害だけでなく、処理時間や問い合わせ数、利用率も含みます。
フェーズ6：運用と改善を仕組みにする定着化
稼働後も利用と保守を続けられるように、教育・運用・改善の仕組みを整えます。
- 利用者教育：役割ごとの手順書や研修、実践の機会を用意します。
- 運用管理：製品の期限や更新責任、脆弱性対応の優先度、保守手順を管理します。
- 運用予算：初期開発に含まれない保守費用を、契約や社内の運用費で別に確保しておきます。
- 継続改善：稼働後90日で指標を評価し、改善テーマを決めます。
定着を進めるには、業務の変更や操作の時期、エラー時の連絡先を利用者に伝え、実データに近い環境で練習を重ねます。
管理者には、ユーザー登録や権限変更、ログ・バックアップの確認を実演してもらいます。障害連絡や月次の棚卸しも、実演の対象に含めます。
Javaやサーバー、DBなど基盤のサポート期限と更新責任は、台帳にまとめます。OSやコンテナ、依存ライブラリも、台帳の対象に入れます。
パッチ適用のSLAや脆弱性対応、定期バックアップ、復旧訓練を定めます。証明書更新や容量監視、ログ保持、再委託先の連絡網は、契約や手順に含めます。
指標には、利用率や入力漏れ、問い合わせ、処理時間を使います。手作業の削減時間や復旧時間、パッチ適用日数も、指標に含めます。そのうえで、機能・権限・帳票・連携の改善を決めます。
Java EE標準仕様の利点を長く活かすために、更新を続けられる運用体制を残しておきます。
Java EEのシステム開発にかかる費用相場
2026年時点でも、Java EE固有の全国統計やサーバーの一律価格表は多くありません。そのため、業務システムとJava開発の公開相場を組み合わせて考えます。
ここで示すのは、リサーチノートと2025年公開のJava相場をもとにした目安です。ライセンスやクラウド、移行、性能試験、診断の有無で金額は変わるため、同じ条件で複数社に見積もりを依頼します。
規模別の初期開発費と期間の目安
初期費用と期間の目安は、開発や移行の範囲によって変わります。
- 小規模：社内申請・顧客管理など単一業務のWeb化は300万〜800万円、2〜6か月が目安です。
- 中規模：複数部門の受発注・販売管理等は800万〜5,000万円、6〜12か月程度です。
- 大規模：複数拠点・24時間運用等は5,000万円〜3億円超、12か月〜2年以上の場合があります。
- 既存移行：変換・試験・移行等を含め1,000万〜1億円超、6〜24か月程度です。
小規模は画面・API・RDB中心で、外部連携や複雑な権限が少ない場合を想定しています。中規模では、外部API、バッチ、帳票、データ移行が加わります。
大規模には、大量処理や複雑な連携、冗長化が含まれます。既存移行では、調査やjavaxからjakartaへの変換、サーバー更新を考慮します。加えて、回帰試験、クラウド化、データ移行も考慮します。
これは公開相場からの推定にすぎず、金額は画面数や連携、移行の条件を整理してから判断します。
エン・ジャパン公表の2025年4月Java月額平均単価は68.4万円です（出典: エン・ジャパン「フリーランススタート 開発言語別の月額平均単価」、2025年4月）。5人が6か月稼働する30人月の場合、単価だけで単純計算すると約2,052万円になります。ただし、PMや要件定義、テスト、会社経費、環境、ライセンスは含まれておらず、発注額ではありません。
費用内訳と稼働後のランニングコスト
初期開発後の負担も見通せるよう、工程費と維持費を分けて確認します。
- 工程配分：要件定義10〜12％、設計・環境構築22〜24％、実装48〜50％、テスト15〜17％を仮置きします。
- 保守費の目安：初期開発費の年15〜25％、または月15万〜80万円程度です。
- 比較期間：初期費だけでなく3〜5年の総額で判断します。
工程の比率は、資産の品質や画面・帳票の数、移行方式、品質基準によって変わります。要件定義が極端に少なく実装費が大きい場合は、仕様変更や追加調査があるかを確かめます。
初期費用以外にも、商用サーバーのライセンスやサポート、クラウドの常時稼働費がかかります。DBやWAF、監視も、費用の対象です。
バックアップやログ、証明書を確認します。加えて、データ転送や脆弱性診断、Javaやミドルウェアの更新も見ておきます。保守費は、24時間監視や障害対応、追加開発の有無で変わります。
契約前に、保守と追加開発の境界を確かめます。3〜5年の総額には、ライセンス更新やクラウドの増強、サポート終了後の移行、教育、障害時の業務損失も含めます。そのため、安価な初期見積もりが必ずしも有利とは限りません。
会計やワークフロー、勤怠などは、SaaSやパッケージとも比べます。独自の審査や計算、製造、連携のロジックへの投資と分けて考えると、予算を調整しやすくなります。
Java EEのシステムの見積もりを取る際のポイント
見積もりは、業務の複雑さや連携数、移行データの量をそろえて比べます。品質基準や運用体制も、同じ条件にします。
RFPには、現行と目標の環境、範囲、納期、予算を記載します。加えて、非機能要件や納品物、契約条件も書き込みます。情報が不足している場合は、開発と調査・PoCの見積もりを分け、未知のリスクを見える形にします。
同じ資料での要件と前提条件の提示
前提条件をそろえると、各社の見積もりを同じ条件で比べられます。
- 対象範囲：現行と目標の環境、業務、データ、利用条件を資料に示します。
- 非機能条件：性能、可用性、保全、監査を数値にして渡します。
- セキュリティ条件：認証、個人情報、委託先、脆弱性対応の決まりを定めます。
既存システムの場合は、JDKやサーバー、DB、コードを資料に記載します。テスト資産やジョブ、非標準API、ライセンス、保守期限も、同じ資料に書き添えます。対象外は明示し、データ整備や端末・ネットワークの更新、利用者教育の担当を決めます。
同時接続や応答、バッチ時間、稼働率を数値にします。RTO・RPO、バックアップ、監査ログも、同じく数値で示します。数値がないと、後からの追加が設計・開発・テストのやり直しにつながるおそれがあります。
認証方式や権限モデル、個人情報の項目を決めます。ログのマスキングや保管場所、委託先のアクセス範囲、脆弱性パッチの期限も、あわせて決めます。
開発会社の担当体制と成果物の比較
提案を評価するときは、金額の背景にある担当者や成果物も確かめます。
- 実績：同等のJDK・サーバー・データ量・業界規制について、経験を確かめます。
- 担当体制：主要な担当者が誰で、どの工程に入るかを示してもらいます。
- 見積もり・成果物：工程費と納品範囲が、分けて示されているかを見ます。
「Javaに詳しい」との説明に加えて、要件定義や移行診断、テスト、稼働後の一次対応を誰が担うかも確かめます。担当者の経歴や再委託の範囲、国内拠点、夜間の連絡体制、障害時の代替要員も、金額と同じ重さで評価します。
見積書では、工程別の工数と単価、前提、除外項目を分けて示してもらいます。ライセンスやクラウド、移行の費用が別々の欄に切り分けられているかも見ます。テストや教育、保守も、項目ごとに分けて書かれているかを確かめます。
RFPでは、変換対象と非標準APIの調べ方を質問します。性能試験のデータ量と合格基準、切り戻し時間も、あわせて聞きます。
コードやIaC、設定、テスト資産については、納品の範囲を確かめます。脆弱性が見つかったときの修正期限も確認します。
見積もりと一緒に確認する契約とリスク分担
追加の変更が出たときに費用や責任が曖昧にならないよう、契約とリスクを整理しておきます。
- 契約形態：要件がどこまで確定しているかに合わせて、工程ごとに検討します。
- 契約条件：変更・検収・権利・再委託の扱いを、文書で明確にします。
- リスク対応：不確実な点を一覧に登録し、調査・PoC・段階移行のどれで扱うかを振り分けます。
要件が確定しないまま全工程を請負にすると、変更の扱いが争点になりやすくなります。そのため、調査や要件整理は準委任、仕様が確定した後の設計・開発は請負などを検討します。
変更手順や追加単価、納期延長、検収基準を契約書に記載します。瑕疵対応や著作権、再委託先の責任、秘密情報の管理も、同じ契約書に書きます。
仕様不明やテストデータ不足、連携環境の未確定を、リスク台帳に登録します。サポート期限や短い停止時間、人員不足も、同じ一覧に加えます。
リスクはゼロにできないので、発生確率や影響度、回避策、対応者を決め、予備費や予備期間も設定します。早く見つけて対処することが、コスト管理につながります。
よくある質問（FAQ）
発注や刷新の場面で、よく確認される質問を紹介します。技術の選び方や既存資産、費用、移行時期、運用体制について取り上げます。
Java EEは古い技術なので、採用しない方がよいですか？
Java EEは旧称にあたり、標準仕様はJakarta EEとして発展しています。既存のJava EE 8やjavax.*は、すぐには廃棄せず、保守期限やセキュリティ更新、人材確保、移行効果を見て段階的に計画します。
新規開発では、Jakarta EE、Spring Boot、Quarkusを業務要件と運用体制で比べます。判断は、名称の新しさではなく、業務要件と運用体制を基準にします。
既存Java EEシステムをJakarta EEへ移行する費用はいくらですか？
公開相場では、1,000万〜1億円超、期間6〜24か月程度が検討の幅になります。金額は、コード量や非標準API、テスト資産、DB・連携の状況で変わります。さらに、停止時間やサーバー・クラウドの変更の有無も、金額に影響します。
先にアセスメントと小規模PoCを行い、変換対象と回帰テスト量を確認してから本開発の見積もりを決めます。
WebLogicやWebSphereなどのサーバーはどう選びますか？
比較するのは、必要なJakarta EEのプロファイルと仕様、アプリの拡張機能、JDK、サポート期間です。ライセンスやクラウド・コンテナ運用、障害対応も比べます。継続利用の場合でも、保守期限と更新費用を確認します。
別製品へ移す場合は、実際のアプリでPoCを行います。デプロイや認証、トランザクション、JPAを確かめ、バッチや外部連携、性能も試します。得られた差分は、見積もりに反映します。
Java EEのシステムはクラウドへ移行できますか？
移行できます。クラウド化には、現行環境を活かす方法から、構成そのものを見直す方法まであります。
- リフト：現行サーバーをVMへ移す方法です。
- リホスト：サーバーをコンテナやマネージド基盤へ載せる方法です。
- リファクタリング：Jakarta EE・MicroProfileで構成を見直します。
短期の継続を優先するならリフトやリホスト、自動スケールやデプロイ速度が重要なら段階的なリファクタリングを選びます。また、ネットワークやDB、認証から、監視、バックアップ、RTO・RPOまで含めて検証します。
まとめ
Java EE開発は、要件整理から定着までの6段階で進めます。業務結果と運用の継続性を基準に、方式を判断します。
まず、javax.*やjakarta.*、JDK、サーバー、DBを一覧にし、連携やバッチ、権限、運用手順も洗い出します。そのうえで、延命やサーバー移行、変換、別基盤への段階移行を比べます。
発注前に確認するチェックポイント
発注前は、条件と費用の前提を確認します。
- 発注条件：目的や範囲、未確認の資産、性能・可用性・セキュリティの数値を確かめます。
- 移行と費用：移行・切り戻し、工程別費用、ライセンス、クラウド、保守の扱いを見ます。
- 体制と契約：担当体制、納品物、契約と追加変更の条件を見ておきます。
- 小・中規模の公開相場：小規模300万〜800万円、中規模800万〜5,000万円です。
- 大規模・既存移行の公開相場：大規模5,000万円〜3億円超、既存移行1,000万〜1億円超です。
案件固有の条件で調整します。特定の金額をそのまま予算に置くのではなく、調査やPoCを含めて見積もりを分けて考えます。
最初の一歩は現状調査と小さなPoC
構成図や仕様、コード、設定を集め、未知の範囲を整理します。連携やデータ、運用記録も加えて、現状を把握します。
代表的な画面やAPI、認証、JPAを、小さなPoCで動かします。バッチや連携も、可能な範囲で試します。
候補サーバーとJDKの互換性、性能、移行工数を確かめます。結果を、RFPとフェーズ別の見積もりに反映します。そのうえで、利用部門や運用担当と合意して、設計開発へ進みます。
▼全体ガイドの記事
・Java EEのシステム開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。