JSPのシステム開発の見積相場や費用/コスト/値段について

JSPのシステム開発費用は、小規模な改修の100万円から、全社規模の基幹刷新の1億円超まで幅があります。金額は画面数、業務ルール、既存資産や移行の範囲、外部連携で変わります。

規模別の相場と費用の内訳、変動要因の順に見ていきます。全体像はJSPのシステム開発の完全ガイドもご覧ください。

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

JSPのシステム費用の目安

JSPは、サーバー側で動的なWebページを生成する表示技術です。

業務システムは、JSPに業務ロジックやデータベースを組み合わせ、バッチや外部サービス連携、運用基盤とも組み合わせて作られます。

そのため、費用は技術名だけでは決まりません。見積もりでは、実現する業務の範囲と、残す既存資産の量を確認します。

JSPの役割と周辺機能の費用

JSPの場合、必要な作業はリクエスト処理、業務機能、表示方式によって変わります。

  • リクエスト:ServletやSpring MVCのControllerからJSPへ渡される処理。
  • 画面表示:Serviceやデータアクセス層の処理結果を、HTMLで表示する部分。
  • 業務機能:ログイン、権限別メニュー、検索、登録・更新、入力エラー、CSV、帳票、承認が作業の対象です。
  • 関連作業:機能が増えると、状態管理や権限判定、テスト、監査ログへの対応も必要になります。

表示処理をJSTLやEL、共通タグで標準化する場合と、古いスクリプトレットを解析して改修する場合とでは、費用が異なります。

4つの開発ルートの違い

JSPの対応方針は、4つのルートに分けて検討します。

  • 既存画面を保守:小さな改修なら、初期費用を抑えやすい方法です。
  • 実行環境を更新:既存画面は残したまま、基盤だけを更新する方法。
  • 画面を段階刷新:業務に合わせ、画面を順番に置き換えていく方法です。
  • パッケージやSaaSへ置換:既製のサービスを使う選択肢です。

既存のJSPを保守し続けると、古いJavaやコンテナの脆弱性が残る可能性があります。

Jakarta Server Pages 3.1は、動的Webコンテンツの生成技術として仕様化されています(出典:Eclipse Foundation「Jakarta Server Pages Specification, Version 3.1」、2022年)。

Java EE時代のjavax.*からjakarta.*へ移行する場合は、ライブラリやコンテナ、設定、テストの互換性を確認する必要があります。

JSPのシステム開発費用相場

小規模改修から全社基幹刷新まで、4つの案件規模別に費用相場を横棒で示した図。
対象範囲が大きくなるほど、費用帯も上がります。

JSP専用の公開見積もりは多くありません。そのため、2026年時点の一般的なJava業務Webシステムの相場に、JSPの既存資産や移行作業を加味して費用を示します。

実際の金額は、画面数や利用者数、既存DBの条件で上下します。

外部連携やデータ移行、可用性、セキュリティの条件でも、金額は変わります。

案件規模別の費用と開発期間

費用と期間は、対象範囲が広がるほど大きくなります。規模ごとの目安は、4つの区分に分けて並べます。

  • 小規模改修:100万〜500万円、期間は1〜4か月が目安です。
  • 部門向け新規開発:500万〜1,500万円で、期間の目安は3〜8か月。
  • 複数部門・拠点:1,500万〜5,000万円、期間は6〜12か月程度。
  • 全社基幹刷新・レガシー資産の大規模移行:5,000万〜1億円超、期間は12〜24か月以上となる場合も。

小規模改修は、5〜20画面程度で既存の認証やDB、運用環境を使える場合の目安です。たとえば、一覧、登録、CSV出力だけなら100万円台に収まることもあります。

費用は、古いJSPの解析やテスト環境の再構築、脆弱性対応が必要になると、小規模改修の上限に近づきます。

部門向け新規開発は、20〜60画面で複数権限や帳票、承認などを含む想定です。さらに、外部連携は1〜3本を含む想定です。

公開されている相場では、小規模は100万〜300万円、中規模は500万〜1,000万円、大規模は1,000万円〜数千万円以上と整理されています(出典:SIA株式会社「システム開発の費用・相場【2026年版】」、2026年7月)。

複数部門の販売、在庫、ワークフローでは、大量データ移行や会計・認証連携が費用を増やします。監査ログや復旧、段階切替も費用を押し上げます。さらに、開発に加えて移行、テスト、運用設計も必要です。

新規開発と既存JSP改修の費用の違い

新規開発と既存改修では、費用が発生する工程も前提も異なります。

  • 新規開発:要件定義、設計、実装、テスト、移行、教育を積み上げます。
  • 既存改修:画面遷移、SQL、バッチ、権限などを、先に解析する必要があります。
  • 資料や環境の状態:整っていれば期間を短くでき、不足していれば解析・文書化の費用が加わります。

別の公開相場では、小規模が50万〜300万円・1〜2か月、中規模が300万〜1,000万円・2〜6か月、大規模が1,000万〜5,000万円・6か月〜1年とされています。

(出典:株式会社みんなシステムズ「システム開発の費用相場」、2026年6月)

同じ「JSP対応」でも、対象が新規画面なのか、機能追加や基盤移行、全面刷新なのかによって、相場には幅があります。

ポイント

規模の判断は、画面数だけでなく、既存資産や移行、外部連携の範囲も含めて行います。既存の認証やDB、運用環境を使えるなら、小規模改修の幅で考えられます。

JSPのシステム開発費用の内訳

JSPシステム開発費用の見積もり対象を、企画・設計、実装・テスト・移行、インフラ・セキュリティ・保守の3領域に分けた図。
工程の費用に加えて、基盤と運用も見積もりに含まれます。

見積書は「開発一式」とまとめず、工程別・成果物別に確認します。

費用は、人月単価に必要な工数を掛けた金額に、サーバーやライセンスなどの付帯費用を加えて考えます。

要件の不確実さやテスト不足が残ると、追加開発や障害対応が必要になり、総額が増えます。見積もりでは、人月単価だけでなく内訳の透明性も重視します。

企画・要件定義・設計にかかる費用

企画から設計までの3工程では、それぞれ決めておく内容が違います。作業の中身を工程ごとに見ると、費用の前提が分かります。

  • 企画・現状分析:JSP、Servlet、Java、コンテナ、DB、バッチ、連携、利用者、権限を洗い出す作業。
  • 要件定義:業務フロー、画面、帳票、入力、エラー、監査ログ、非機能要件を決める工程。
  • 設計:画面遷移、データモデル、API、認証・認可、共通レイアウト、例外、ログを文書にまとめる。

移行案件では、要件定義の前にアセスメントを行うと手戻りを減らせます。実際に使われているURLや共通タグ、画面が呼ぶSQLも調べます。未使用の機能や外部接続方式も、あわせて確かめます。

この調査を省くと、把握していない仕様が後から見つかり、追加費用になりやすいです。

実装・テスト・移行にかかる費用

実装、テスト、移行の費用には、次の作業が含まれます。

  • 実装:JSP画面、Controller・Service、DB、入力検証、権限、帳票、外部APIなどの作成。
  • テスト:各種テストの実施、データ作成、障害修正、再テスト。
  • データ移行:抽出、変換、投入、照合、切替の作業。

テストでは単体、結合、総合、受入の各段階を行います。販売や在庫では、締めや取消、権限変更のケースが増えます。さらに、同時更新や通信失敗のケースも加わります。

移行の工数は、データ量に加えて、欠損や重複、コード体系によって変わります。また、保存する過去データの年数も影響します。

大規模移行では、並行稼働や現新一致テストが加わるため、期間と費用が増えます。

インフラ・セキュリティ・保守の費用

費用は、基盤、セキュリティ、保守の3領域に分けて確認します。

  • 基盤:サーバー、クラウド、ネットワーク、バックアップ、監視、ログ、証明書、コンテナ、CI/CD、ライセンス。
  • セキュリティ:XSS、SQL、CSRF、セッション、認可、Cookie、依存ライブラリへの対策。
  • 保守:改修、Java・コンテナ・ライブラリ更新、脆弱性対応、クラウド利用料。

高可用性や災害対策を求める場合は、冗長構成や別リージョン、復旧訓練、24時間監視が必要になります。そのため、初期費用と月額費用が増えます。

開発・検証・本番環境の分け方や、テストデータの管理も、見積書に明記しておきます。

JSPを含むWebシステムでは、出力時のXSS、SQLのプレースホルダー、CSRFへの対策が欠かせません。

セッション固定化やURLごとの認可、Cookie属性を確かめるほか、依存ライブラリの脆弱性も確認します。

脆弱性診断や侵入テストは、後から加えると費用が増えます。コードレビューや監査ログも、後付けにすると高くつきます。こうした要件は、RFPの段階で含めておきます。

保守費は、初期費用とは別に考えます。年間で初期費用の15〜25%程度を見込む考え方もありますが、SLAや対応時間によって変わります。

ポイント

内訳は、工程ごとの作業と、インフラ・セキュリティ・保守の費用に分けて見るのが基本です。初期費用と保守費を分けて比べると、会社ごとの条件の違いが見えてきます。

JSPのシステム費用を左右する変動要因

同じ画面数でも、業務ルールや連携方式、利用者数、性能、可用性の目標によって費用は変わります。見積もりでは、どの変数が金額に影響したかを確認します。

既存JSPの古さとドキュメントの有無

解析の負荷は、既存コードや資料の有無、移行対象の互換性によって変わります。

  • 古いJSP:スクリプトレットに業務ロジックが混ざり、SQLや権限判定が画面に分散している場合があります。
  • 資料の有無:資料が不足していれば、聞き取りやログ分析、画面操作で確認します。資料が揃うほど、解析工数を抑えやすくなります。
  • Jakarta EE移行:確認項目はjavax.*とjakarta.*、仕様の版、サーバー設定、認証、ライブラリ。

単純な文字列置換だけで動くとは限りません。そのため、代表画面のPoCで互換性とテスト工数を確かめてから、全体を見積もると安全です。

画面数・利用者数・外部連携の数

画面、利用形態、外部連携の範囲が、開発とテストの工数を左右します。

  • 画面数:権限、遷移、入力パターン、ブラウザ差異、テストデータの量が増えていきます。
  • 利用形態:部門・役職別の承認や、集中アクセスへの性能対策が工数に影響します。
  • 連携先:会計、販売、認証、ファイル保管、電子契約、通知、外部APIなど。

部門や役職によってメニューや承認経路が異なると、利用者が少なくても工数は増えます。また、一般向けでアクセスが集中する場合には、負荷試験やキャッシュ、冗長化、監視、障害時の切替が必要になります。

連携は、相手先の仕様やテスト環境にも左右されます。そのため、タイムアウトや再送、重複登録の扱いを設計します。仕様変更や障害時の復旧も含め、方式と責任範囲を見積書で確認します。

連携が1本増えるたびに、接続設定とエラー処理、結合テスト、運用監視の作業が増えます。

セキュリティ・性能・可用性などの非機能要件

非機能要件は、画面機能以上に費用を左右する場合があります。個人情報や決済情報を扱う場合は、条件を数値や仕様として決めておきます。

  • セキュリティ:アクセス制御、暗号化、監査ログ、脆弱性診断、バックアップ、事故対応。
  • 性能・可用性:稼働率、復旧時間、許容データ損失、ピーク時の同時接続数。
  • 納期:納期を前倒しして増員すると、設計共有やレビュー、環境準備、テスト調整の作業が増えます。

これらを数値で定めないと、各社はそれぞれ異なる条件で見積もることになります。さらに、増員しても、人数を単純に足し合わせた効果が得られないことがあります。

イー・ジーシステム株式会社は、2026年6月に「システム開発の費用相場と見積書の読み方(2026年版)」を公開しました。

同資料では、機器やライセンス、外注部品、保守契約も費用に含めて示しています。

ポイント

同じ画面数でも費用が変わるため、既存JSPの状態や外部連携、非機能要件の条件を見て判断します。見積書で、どの変数が金額に効いたかを確認しておくと、比較の根拠が残ります。

JSPのシステム開発を進める手順

JSPシステム開発を、現状診断、要件定義とPoC、段階開発とテスト、移行リハーサルと運用引き継ぎの順に示す4枚のパネル図。
棚卸しと小さな検証を経てから、開発と切り替えへ進みます。

費用を管理するには、不確実な点を先に見つけ、各段階に成果物と判断基準を置きます。

JSPを残す場合も、解析から運用までの流れを保ちます。

現状診断と資産の洗い出し

最初に、確認すべき資産と業務情報を一覧にします。

  • システム資産:JSP、URL、タグ、Servlet・Controller・Service、SQL、DB、バッチ。
  • 利用・運用情報:連携、認証、権限、ログ、運用手順。
  • 優先度の材料:利用頻度、障害・改修履歴、業務上の重要度。

仕様書と実装が食い違う場合は、その差をリスクとして見積もりに記載します。

洗い出しのあとで、保守継続、基盤更新、画面刷新、パッケージ化を比べます。

利用状況や重要度も記録しておくと、残す機能と廃止する機能を分けやすくなります。

すべてを一度に刷新せず、業務への影響、技術者の確保、脆弱性の観点で優先順位を付けると、予算とリスクを抑えやすくなります。

要件定義と小さなPoC

要件定義とPoCでは、業務要件、非機能条件、移行時の技術リスクを順に明確にします。

  • 業務要件:利用者、業務、データ、結果をフロー化し、画面のロール、入力、必須条件、エラー、保存、戻る操作、同時更新を記載。
  • 非機能条件:利用者数、同時接続、応答時間、稼働時間、バックアップ、復旧目標、ログ保存期間を数値化。
  • PoC:代表画面でログイン、共通レイアウト、一覧・登録、DB、帳票、連携を試し、互換性やテスト課題を確かめる作業。

移行時は、変換できないタグや設定の差分、依存ライブラリ、テスト不足を洗い出します。

PoCの費用を先に投じておくと、全体の追加工数を予測しやすくなります。

段階開発とテスト

画面と業務ロジックを分けたうえで、共通化とテストの基準を先に整えます。

  • 共通化:画面、入力、例外、ログ、認証・認可の標準化。
  • 段階開発:重要業務からリリースし、利用が始まってから機能を足す方法。
  • テスト:単体、結合、総合、受入の順に実施。

画面ごとに独自の実装を重ねると、改修時の影響範囲やテスト範囲が広がります。そこで、最初のリリースは重要業務の画面や帳票に絞る方法もあります。

テストでは、権限表示や入力エラー、二重送信、セッション切れを検証します。さらに、DB障害やAPI停止、帳票の再出力、監査ログも確かめます。

テストを省くと、本番障害や緊急修正、業務停止のコストを招きます。そのため、見積もり段階から工数を確保しておきます。

移行リハーサルと運用引き継ぎ

切替前の検証、当日の判断、事例から見た期間の目安を順に整理します。

  1. データ移行は複数回リハーサルし、件数や金額、状態、更新日時、関連キーを新旧で照合します。
  2. 切替時間や停止可能時間、戻し方、問い合わせ窓口、障害時の判断者を決めておき、必要な場合は一定期間並行稼働させます。
  3. 大規模なJava移行では、現行と新システムの結果を合わせるテストが、開発よりも長くかかる場合があります。

TISの公開事例では、JR東海の約250万ステップのCOBOLをJavaへ移行しています。期間は約2年10か月で、その大部分を現新一致テストに充てました。

同事例では、3か月の並行稼働のあとに運用保守コストを約4割削減しました(出典:TIS株式会社「東海旅客鉄道株式会社様/ジェイアール東海情報システム株式会社様」)。

規模は異なるものの、移行費をソース変換だけで判断しないことを示す事例です。

JSPのシステムの見積もりを取る際のポイント

比較の前に、前提条件を揃えておきます。JSP保守やJakarta移行、画面刷新では、会社ごとに対応できる工程が異なるため、RFPの範囲を明確にします。

要件と見積もり範囲の整理

RFPに向けて、まず現行システムの目的や利用部門、利用者数、画面数を整理します。そのうえで、業務フローやDB、連携、データ量、希望時期も書き出します。

稼働時間やセキュリティ要件もまとめておきます。既存改修なら、ソースや設計書、テスト仕様、環境情報を提示します。障害履歴や保守契約、ライセンスの所在も、あわせて示します。

情報が不足している場合は、調査やアセスメントを別工程として見積もるよう依頼します。見積書は、作業の区分ごとに分けてもらうと比べやすくなります。

  • 工程:要件定義、解析、設計、実装、各種テスト。
  • 移行と運用:移行、教育、リリース、保守。
  • 契約条件:成果物、対象外、前提、工数、変更、検収、保証。

「開発一式」の見積もりでは、各社の対象範囲が異なるため、単純に比べられません。

複数社の同条件での比較

相見積もりでは、2〜3社に同じRFPを渡し、価格以外の条件も比べます。

  • 提案内容:前提、工数の根拠、体制。
  • 実行計画:移行方法、テスト、保守窓口。
  • 技術対応:Java、Jakarta EE、クラウド、脆弱性対応。

「JSP対応」が、古い画面の軽微な改修だけを指す場合もあります。そのため、コンテナやCI/CDまで含めて、必要な支援範囲を確認します。

実績については、現行解析の画面数や、javax.*からjakarta.*への移行、DBやAPI移行の経験を具体的に尋ねます。さらに、テスト証跡や運用設計の納品経験も聞いておくとよいです。

守秘義務で社名を出せない場合は、業種や規模、画面数、担当工程、課題と解決方法を匿名で説明できるかを確認します。

契約と追加費用の条件

契約では、作業形態、変更条件、成果物、権利、引き継ぎの範囲を確認します。

  • 契約形態:請負か準委任かで、成果物や責任、変更管理、検収の考え方が変わります。
  • 工程分割:要件定義は準委任、実装・納品は請負とする場合もあります。
  • 変更条件:見積もり方法、単価、承認手順、納期への影響を、事前に合意しておく。
  • 成果物:ソース、設計書、テスト証跡、環境設定、IaC、アカウント、第三者ライセンスの有無。
  • 権利と移管:著作権、再利用範囲、引き継ぎ資料、教育、問い合わせ期間の取り決め。

保守を別会社や内製チームへ移す可能性も、あらかじめ踏まえておきます。成果物や保守範囲が限られていると、初期見積もりが安くても追加費用が発生します。

ポイント

会社ごとに対応できる工程が違うため、比較の前に前提条件を揃えることが出発点になります。RFPの範囲と契約条件がそろってはじめて、金額の差に意味が出ます。

JSPのシステム開発費用を最適化するポイント

コストの最適化とは、不要な開発と手戻りを減らし、保守費を含む総保有コストを抑えることです。JSPを継続するか置き換えるかは、初期費用だけでなく、技術者の確保や脆弱性、変更のしやすさ、業務停止リスクで判断します。

既存資産の残し方と危険箇所の修正

既存資産は、リスクと重要度を見て、次のように分けて扱います。

  • 再利用:認証、マスタ、共通レイアウト、安定稼働する帳票。
  • 修正して再利用:共通タグ、入力チェック、ログ、認可。
  • 廃止を検討:脆弱なライブラリ、重複判定、属人化したバッチ。

SQLが混在するスクリプトレットも、保守リスクになります。そのうえで、資産の重要度と危険度に応じて予算を配分します。

個別の対応を重ねると、問題が複数の画面に広がり、将来の移行費が増えます。

小さなリファクタリングは、今回に含めるか、別の計画にするかを決めます。

優先順位を付けた段階リリース

初期費用を抑えるには、開発範囲と方式を利用期間全体で決めます。

  • 初回範囲:全帳票や細かな検索、例外承認、未確定の連携を、一度に詰め込まないこと。
  • 段階導入:必須機能から始め、利用部門の意見を受けて二次開発に分ける。
  • 画面刷新:JSPを残す場合も、重要業務から新画面へ置き換える。
  • 開発方式:標準業務はパッケージやSaaS、独自性の高い業務はスクラッチも検討。
  • 長期費用:5年程度で導入、月額、保守、改修、移行、終了時の切替費を比較。

パッケージのカスタマイズが増えると、ライセンスや導入支援、バージョンアップの費用がかさみます。

共通化と運用設計

開発と運用では、共通化する基準や手順を先に揃えておきます。

  • 開発標準:画面、入力、認証・認可、エラー、ログ、テストデータ、デプロイを共通化。
  • 品質確認:CI/CD、コードレビュー、静的解析、依存ライブラリの脆弱性確認を整備。
  • 引き継ぎ:内製する場合はREADMEと運用手順を納品物に含める。
  • 運用条件:問い合わせ時間、一次切り分け、監視、バックアップ、復旧訓練、パッチ、定期診断を決定。

24時間対応が不要であれば、常時監視を外すこともできます。一方で、停止できない業務では、保守体制を確保し、業務への影響に合ったサービスレベルを契約します。

ポイント

コストを抑える判断は、初期費用だけでなく、技術者の確保や脆弱性、変更のしやすさ、業務停止リスクを合わせて行います。既存資産は、再利用する部分と直す部分、廃止を考える部分に分けて扱います。

よくある質問(FAQ)

費用は案件の条件で変わります。そのため、相場を見たうえで、対象範囲と変動要因を整理して開発会社へ相談します。

JSPで新規の業務システムを作る費用はいくらですか?

20〜60画面で、複数ロールや帳票、承認、外部連携を含む部門向けなら、500万〜1,500万円、期間は3〜8か月が目安です。

金額は画面数だけでなく、要件や非機能要件、移行、テスト、保守の範囲によっても変わります。JSPという技術だけでは、費用を断定できません。

既存JSPの保守改修だけなら安くできますか?

認証やDB、開発環境、テスト仕様を使え、改修範囲が明確であれば、新規開発より短期間・低コストに進めやすいです。

小規模改修は100万〜500万円が目安です。

仕様書不足や古いライブラリの更新、脆弱性診断、複雑な権限や帳票の修正があると、解析やテストの費用が加わります。

古いJSPをJakarta EEへ移行する費用はどう見積もりますか?

まずアセスメントとPoCで、互換性を確認します。確認する対象は、JSPやServlet、EL、JSTLと、ライブラリやサーバー、認証、DB、外部連携です。

その後は、画面数やコード量、データ量、テスト、並行稼働、切替条件をもとに見積もります。

単純な置換で済む案件もあります。一方で、設定の差や不明な処理が多いと、移行・検証費が新規開発に近づく場合があります。

JSPのシステム開発費用を抑えるには何をすればよいですか?

現行資産と要件を整理し、必須機能と後回しにする機能を分けて、段階的にリリースします。

標準機能で足りる業務は、パッケージやSaaSを使う手もあります。

複数社へ同じ条件で依頼し、工数やテスト、移行、保守を含む総額で比べます。無理な値下げに頼るより、安全な最適化につながります。

まとめ

小規模改修は100万〜500万円、部門向け新規開発は500万〜1,500万円が目安です。中規模刷新は1,500万〜5,000万円、全社基幹刷新は5,000万〜1億円超です。

これは、JSPの定価ではありません。画面数や業務ルール、既存資産、移行、連携、非機能要件を前提にした、金額の幅です。

費用を決める業務と運用の範囲

見積もりでは、人月単価と工数を工程ごとに分けて確認します。要件定義から移行までの開発工程に加え、インフラ、セキュリティ、教育、保守も対象になります。

古いJSPでは、未記載の業務ルールや、javax.*からjakarta.*への互換性が費用を左右します。そのため、代表画面のPoCやアセスメントが有効です。

相談前に整理する現行資産と優先順位

相談時には、現行資産と依頼する範囲、費用の見方を分けて伝えます。

  • 開発範囲:使える資産を再利用し、危険箇所を優先して直します。必須機能からの段階導入で費用を抑えます。
  • 相談内容:保守、Jakarta移行、クラウド化それぞれの範囲を明確にしておく。
  • 比較と予算:同条件で複数社を比べ、初期費用と年間保守費を合わせて判断。

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

会社紹介

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

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

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

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

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

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