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

JSPのシステム開発費用は、画面数や業務ルールだけでなく、既存JSPを活用するかJakarta EEへ移行するか、外部連携やセキュリティ要件をどこまで含めるかで大きく変わります。目安は小規模な改修で100万〜500万円、部門向けの新規開発で500万〜1,500万円、中規模以上の刷新で1,500万〜5,000万円程度です。

この記事では、「JSPのシステム」にかかる費用相場を、初期費用・保守運用費・移行費用に分けて解説します。見積もりの内訳、価格が上がる変動要因、開発期間、コストを抑える考え方、発注時の確認項目まで整理しますので、自社の予算計画やRFP作成にお役立てください。

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

JSPのシステム費用はどのくらいですか?

JSPのシステム開発費用を検討する担当者

JSPのシステム費用は、JSPという技術名だけで決まるものではありません。JSPはサーバー側で動的なWebページを生成する表示技術であり、認証、業務ロジック、データベース、バッチ、外部サービス連携、運用基盤と組み合わさって一つの業務システムになります。そのため、見積もりでは技術名よりも、実現する業務の範囲と残す資産の量を確認することが大切です。

JSPは画面を表示する技術で、費用は周辺機能で広がります

JSPでは、ServletやSpring MVCのControllerが受け取ったリクエストに対して、Serviceやデータアクセス層が処理した結果をHTMLとして表示します。ログイン、権限別メニュー、一覧検索、登録・更新フォーム、入力エラー、CSV出力、帳票、承認ワークフローなどが加わると、画面そのものだけでなく、状態管理、権限判定、テスト、監査ログの工数も増えます。JSTLやEL、共通タグを使って表示処理を標準化するか、古いスクリプトレットを読み解いて改修するかでも費用は変わります。

費用を考えるときは4つの開発ルートを分けます

JSPのシステムでは、まず「既存画面を保守する」「実行環境だけを更新する」「画面を段階的に刷新する」「パッケージやSaaSへ置き換える」という4つのルートを分けて考えます。既存JSPの小さな改修なら初期費用を抑えやすい一方、古いJavaやコンテナの脆弱性を残す可能性があります。Jakarta Server Pages 3.1は動的なWebコンテンツを生成する技術として仕様化されていますが、Java EE時代のjavax.*からjakarta.*へ移行する場合は、ライブラリ、コンテナ、設定、テストの互換性確認が必要です(出典:Eclipse Foundation「Jakarta Server Pages Specification, Version 3.1」、2022年)。

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

JSPのシステム開発費用の相場を確認する資料

JSP専用の公開見積もりは多くないため、以下は2026年時点の一般的なJava業務Webシステム開発相場と、JSPの既存資産・移行作業を組み合わせた目安です。実際の金額を断定するものではなく、画面数、利用者数、既存DBの状態、外部連携、データ移行、可用性、セキュリティの条件によって上下します。

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

小規模な画面追加・保守改修は、5〜20画面程度で既存の認証、データベース、運用環境を利用できる場合、100万〜500万円、期間は1〜4か月が目安です。中には一覧、登録、CSV出力だけの改修で100万円台に収まる場合もありますが、古いJSPの解析、テスト環境の再構築、脆弱性対応が必要なら上限側に寄ります。

部門向けの新規業務システムは、20〜60画面、複数の権限、帳票、承認、外部連携1〜3本を含めて500万〜1,500万円、期間は3〜8か月が目安です。販売管理、在庫管理、勤怠管理などの業務系Webシステムについて、2026年の公開相場にも小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円〜数千万円以上という整理があります(出典:SIA株式会社「システム開発の費用・相場【2026年版】」、2026年7月)。

複数部門・複数拠点で使う販売、在庫、ワークフローなどは、1,500万〜5,000万円、期間は6〜12か月程度を見込みます。大量データの移行、会計や認証との連携、監査ログ、障害時の復旧、段階的な切替が必要になると、開発費だけでなく移行・テスト・運用設計の費用も増えます。全社基幹の刷新やレガシー資産の大規模移行は5,000万〜1億円超、12〜24か月以上となることもあります。

新規開発と既存JSP改修では費用の出方が違います

新規開発では、要件定義から設計、実装、テスト、移行、教育までを積み上げます。一方、既存JSPの改修では、仕様書に書かれていない画面遷移やSQL、バッチ、権限の挙動を調べる現行解析が最初に発生します。改修対象のコードが整理され、テストデータと開発環境が揃っていれば短期間で進められますが、担当者の記憶だけで運用されている場合は、解析・ドキュメント化が新規費用として加わります。

2026年の別の公開相場では、小規模システムが50万〜300万円・1〜2か月、中規模が300万〜1,000万円・2〜6か月、大規模が1,000万〜5,000万円・6か月〜1年と整理されています(出典:株式会社みんなシステムズ「システム開発の費用相場」、2026年6月)。このように相場に幅があるのは、同じ「JSP対応」でも新規画面、機能追加、基盤移行、全面刷新が混在するためです。

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

JSPのシステム開発費用の内訳を整理する場面

見積書は「開発一式」ではなく、工程別・成果物別に分けて確認します。費用の基本式は「人月単価×必要工数+サーバーやライセンスなどの付帯費用」です。人月単価だけを下げても、要件の不確実さやテスト不足が残れば、追加開発や障害対応によって総額が増えるため、内訳の透明性を重視します。

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

企画・現状分析では、現行JSP、ServletやController、Javaのバージョン、コンテナ、DB、バッチ、外部連携、利用者と権限を棚卸しします。要件定義では業務フロー、画面一覧、帳票、入力ルール、エラー処理、監査ログ、非機能要件を決めます。設計では、画面遷移、データモデル、API、認証・認可、共通レイアウト、例外処理、ログ方針を文書化します。

既存システムの移行案件では、要件定義の前にアセスメントを設けると、後工程の手戻りを抑えやすくなります。JSPファイルの数だけでなく、実際に利用されるURL、共通タグ、画面から呼ばれるSQL、使われていない機能、外部システムとの接続方式まで確認することが重要です。調査を省略した見積もりは安く見えても、開発後に未把握の仕様が出て追加費用になりやすいです。

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

実装費には、JSP画面、ControllerやService、DBアクセス、バリデーション、権限、帳票やCSV、外部API連携などが含まれます。テスト費には、単体・結合・総合・受入テストの設計と実施、テストデータ作成、障害修正、再テストが含まれます。特に販売や在庫のように業務ルールが多いシステムでは、正常系だけでなく、締め処理、取消、権限変更、同時更新、通信失敗などのケースが増えます。

移行費には、データの抽出、変換、クレンジング、投入、移行リハーサル、現行と新システムの照合、切替当日の作業が含まれます。移行対象のデータ量だけでなく、欠損・重複・コード体系の違い、過去データを何年分残すかで工数が変わります。大規模移行では並行稼働や現新一致テストを設けるため、開発期間と費用が大きくなります。

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

サーバーやクラウドの構築、ネットワーク、バックアップ、監視、ログ保管、証明書、コンテナ、CI/CD、ライセンスが付帯費用になります。高い可用性や災害対策が必要な場合は、冗長構成、別リージョン、復旧訓練、24時間監視が必要になり、初期費用と月額費用の両方が増えます。開発環境・検証環境・本番環境を分けるか、テストデータをどう管理するかも見積書に明記します。

JSPを含むWebシステムでは、出力時のXSS対策、SQLのプレースホルダー、CSRF対策、セッション固定化対策、URLごとの認可、Cookie属性、依存ライブラリの脆弱性管理が必要です。脆弱性診断、ソースコードレビュー、ペネトレーションテスト、監査ログの要件を後から追加すると費用が跳ね上がるため、RFPの段階で含めます。初期開発後の保守改修、Java・コンテナ・ライブラリ更新、脆弱性対応、クラウド利用料は、初期費用とは別に年間で初期費用の15〜25%程度を見込む考え方がありますが、SLAや対応時間によって変動します。

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

JSPのシステム費用の変動要因を検討する会議

同じ画面数でも、業務ルール、連携方式、利用者数、性能や可用性の目標が違えば費用は変わります。見積もりを受け取ったときは、総額の大小ではなく、どの変数が金額に影響したのかを質問できる状態にします。

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

古いJSPでは、画面内のスクリプトレットに業務ロジックが混在していたり、同じSQLや権限判定が複数画面に分散していたりします。担当者が退職して仕様が分からない場合は、コードを読むだけでなく、利用者へのヒアリング、ログ分析、画面操作による挙動確認が必要です。仕様書、ER図、テスト仕様書、環境構築手順、外部連携の契約情報が揃っているほど、現行解析の工数を抑えやすいです。

Java EEからJakarta EEへの移行では、javax.*とjakarta.*の名前空間差分、JSP・Servlet・EL・JSTLのバージョン、アプリケーションサーバーの設定、認証方式、依存ライブラリを確認します。単純な文字列置換だけで動くとは限らないため、対象画面を絞ったPoCを先に実施し、互換性とテスト工数を確認してから全体見積もりに進むと安全です。

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

画面数が増えるほど、実装だけでなく、権限の組み合わせ、画面遷移、入力パターン、ブラウザ差異、テストデータの準備が増えます。利用者数が少ない社内システムでも、部門や役職ごとにメニューや承認経路が違う場合は、単純な画面数以上の工数になります。一般利用者向けでアクセスが集中する場合は、負荷試験、キャッシュ、冗長化、監視、障害時の切替まで必要になります。

会計、販売、認証、ファイル保管、電子契約、通知、外部APIなどの連携は、相手システムの仕様とテスト環境にも左右されます。APIが整備されていても、タイムアウト、再送、重複登録、仕様変更、障害時のリカバリを設計しなければなりません。連携が1本増えるたびに、接続設定・エラー処理・結合テスト・運用監視が増えるため、見積書では本数だけでなく方式と責任分界を確認します。

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

開発費が大きく変わるのは、画面機能より非機能要件である場合があります。個人情報や決済情報を扱うなら、アクセス制御、暗号化、監査ログ、脆弱性診断、バックアップ、インシデント対応を設計します。月間の稼働率、復旧時間、許容できるデータ損失、ピーク時の同時接続数を数値で決めないと、各社が異なる前提で見積もることになります。

短納期も費用を押し上げる要因です。納期を前倒しするために人員を増やすと、設計の共有、レビュー、環境準備、テストの調整が増え、単純に人数を足した効果が得られないことがあります。2026年の公開相場でも、費用は人月単価と工数に加えて、ハードウェア、ライセンス、外注部品、保守契約などの付帯費用で決まると整理されています(出典:イー・ジーシステム株式会社「システム開発の費用相場と見積書の読み方(2026年版)」、2026年6月)。

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

JSPのシステム開発の工程を確認する担当者

費用を管理しやすい開発では、最初に不確実な部分を見つけ、段階ごとに成果物と判断基準を置きます。JSPを残す場合でも、現行解析、要件定義、設計、PoC、実装、テスト、移行、運用という流れを崩さないことが大切です。

現状診断と資産の棚卸し

最初に、JSPファイル、URL、画面数、共通タグ、Servlet・Controller・Service、SQL、DB、バッチ、外部連携、認証、権限、ログ、運用手順を一覧化します。利用頻度、障害履歴、改修頻度、業務上の重要度も付けると、残す機能と廃止する機能を分けやすくなります。仕様書と実装が食い違っている場合は、その差分をリスクとして見積もりに記載します。

この段階で、既存JSPの保守継続、Javaとコンテナの更新、画面刷新、パッケージ化のどれが妥当かを比較します。すべてを一度に新しくするのではなく、業務影響の大きい処理、技術者が確保しにくい部分、脆弱性が残る部分から優先順位を付けると、予算とリスクを同時に管理できます。

要件定義と小さなPoC

要件定義では、誰が、どの業務で、どのデータを使い、どの結果を得るのかを業務フローとして整理します。画面一覧には、利用者ロール、入力項目、必須条件、エラー表示、保存タイミング、戻る操作、同時更新の扱いまで記載します。非機能要件は、利用者数、同時接続、応答時間、稼働時間、バックアップ、復旧目標、ログ保存期間を数値で示します。

Java EEからJakarta EEへ移行する場合や、古いJSPを新しいコンテナへ載せ替える場合は、代表的な数画面でPoCを行います。ログイン、共通レイアウト、一覧・登録、DB接続、帳票、外部連携のように技術リスクが高い機能を試し、変換できないタグ、設定差分、依存ライブラリ、テストの不足を洗い出します。PoC費用を先に投じることで、全体の追加工数を予測しやすくなります。

段階開発とテスト

実装では、画面と業務ロジックを分離し、共通レイアウト、入力チェック、例外処理、ログ、認証・認可を先に標準化します。画面ごとに独自実装を繰り返すと、改修時の影響範囲とテスト範囲が広がるためです。最初のリリースでは、最も重要な業務に必要な画面と帳票に絞り、利用状況を確認してから追加機能を開発する方法もあります。

テストは単体、結合、総合、受入の順で進めます。JSPの表示確認だけでなく、権限ごとの画面表示、入力エラー、二重送信、セッション切れ、DB障害、外部API停止、帳票の再出力、監査ログの記録を検証します。テストの省略は短期的な節約に見えても、本番障害、緊急修正、業務停止のコストを招くため、見積もり段階から十分な工数を確保します。

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

本番切替前に、データ移行を複数回リハーサルし、件数、金額、ステータス、更新日時、関連キーを現行と新システムで照合します。切替当日の作業時間、停止可能時間、戻し方、問い合わせ窓口、障害時の判断者を決めておくと、移行費用と業務リスクを把握しやすくなります。必要に応じて一定期間は現行と新システムを並行稼働させます。

大規模なJava移行では、開発よりも現行と新システムの結果を一致させるテストが長期化することがあります。TISの公開事例では、JR東海の約250万ステップのCOBOLをJavaへ移行し、プロジェクト期間は約2年10か月、その大部分を現新一致テストに充てています。最終的に3か月の並行稼働を経て、運用保守コストを約4割削減した事例です(出典:TIS株式会社「東海旅客鉄道株式会社様/ジェイアール東海情報システム株式会社様」)。規模は異なりますが、移行費をソース変換だけで判断しないという示唆になります。

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

JSPのシステムの見積もりを比較する担当者

見積もりの比較では、金額を並べる前に前提条件を揃えます。JSPの保守、Jakarta移行、画面刷新では、同じ「開発会社」でも対応できる工程が違うため、RFPに含める範囲を明確にします。

要件と見積もり範囲を先に整理します

最低限、現行システムの目的、利用部門、利用者数、画面数、主要な業務フロー、DB、外部連携、データ量、希望時期、稼働時間、セキュリティ要件を整理します。既存JSPを改修する場合は、ソースコード、設計書、テスト仕様書、環境情報、障害履歴、保守契約、ライセンスの所在も提示します。情報が不足している場合は、調査・アセスメントを別工程として見積もるよう依頼します。

見積書には、要件定義、現行解析、基本設計、詳細設計、実装、単体テスト、結合テスト、総合テスト、移行、教育、リリース、保守を分けて記載してもらいます。成果物、対象外、前提、想定工数、追加変更の扱い、検収条件、納品後の保証期間まで確認します。「開発一式」とだけ書かれた見積もりは、各社の含む範囲が異なり、単純比較できません。

複数社を同じ条件で比較します

相見積もりは2〜3社程度に同じRFPを渡し、金額だけでなく、提案の前提、工数の根拠、プロジェクト体制、移行方法、テスト計画、保守窓口を比較します。JSP対応を掲げていても、実際には古い画面の軽微な改修だけが対象の場合があります。Javaの新しいLTS版、Jakarta EE、コンテナ、クラウド、CI/CD、脆弱性対応まで支援できるかを確認します。

実績を聞くときは、単に「JSPの経験がありますか」と尋ねるのではなく、「既存JSPの現行解析を何画面程度行ったか」「javax.*からjakarta.*への移行経験があるか」「DBや外部APIの移行をどこまで担当したか」「テスト証跡と運用設計を納品できるか」と具体化します。実績を守秘義務で開示できない場合も、業種、規模、画面数、担当工程、課題と解決方法を匿名で説明できるかを確認します。

契約と追加費用の条件を確認します

請負契約か準委任契約かで、成果物、作業責任、変更管理、検収の考え方が変わります。要件定義は準委任、実装・納品は請負とするなど、工程で契約を分ける場合もあります。仕様変更が出たときの見積もり方法、単価、承認フロー、納期への影響をあらかじめ合意しておくと、予算超過の原因を追跡しやすいです。

ソースコード、設計書、テスト証跡、環境設定、IaC、アカウント情報、第三者ライブラリのライセンス、著作権や再利用の範囲も契約書で確認します。特にJSPの保守を将来別会社や内製チームへ移す可能性があるなら、引き継ぎ資料、教育、問い合わせ対応の期間まで含めます。安い初期見積もりでも、成果物や保守範囲が限定されていれば、後から追加費用が発生します。

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

JSPのシステム開発費用を最適化する計画

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

使える既存資産は残し、危険な部分から直します

既存の認証、マスタ、共通レイアウト、安定稼働している帳票などをそのまま使えるなら、すべてを作り直す必要はありません。一方で、脆弱なライブラリ、スクリプトレットに混在したSQL、重複した権限判定、担当者しか分からないバッチは、保守継続のリスクが高い部分です。資産を「再利用」「修正して再利用」「廃止」に分け、重要度とリスクの高い順に予算を配分します。

既存JSPを保守する場合も、共通タグ、入力チェック、例外処理、ログ、認可の標準を少しずつ整えると、次回改修の工数を抑えられます。改修のたびに個別対応を重ねると短期的には安くても、同じ問題が複数画面に広がり、将来の移行費用が増えます。最小限のリファクタリングを開発範囲に含めるか、別の改善計画として積み上げます。

優先順位を付けて段階リリースします

最初のリリースに、すべての帳票、細かな検索条件、例外的な承認経路、将来使うか分からない連携を詰め込むと、初期費用と納期が膨らみます。業務を止めないために必須のログイン、権限、登録、検索、承認、最低限の出力から始め、利用部門のフィードバックをもとに二次開発へ分けます。JSP画面を残す場合も、重要な業務から段階的に新しい画面へ置き換えられます。

標準機能で足りる業務はパッケージやSaaSを使い、独自性が高く競争力に直結する業務だけをスクラッチで作る方法もあります。パッケージのカスタマイズが増えすぎると、ライセンス、導入支援、バージョンアップの費用がかさむため、初期費用だけで判断しません。5年程度の利用期間を置き、開発・導入、月額、保守、追加改修、データ移行、終了時の切替費を比較します。

共通化と運用設計を先に行います

画面テンプレート、入力チェック、認証・認可、エラーコード、ログ形式、テストデータ、デプロイ手順を共通化すると、開発者ごとのばらつきとレビュー工数を減らせます。手作業の環境構築やリリースを自動化するCI/CD、コードレビュー、静的解析、依存ライブラリの脆弱性チェックも、初期設定に費用をかける価値があります。将来の改修を内製するなら、開発者向けのREADMEと運用手順を納品物に含めます。

運用費を抑えるには、問い合わせの受付時間、障害の一次切り分け、監視項目、バックアップ、復旧訓練、パッチ適用、定期的な脆弱性確認を決めます。24時間対応が不要なシステムに常時監視を付ける必要はありませんが、業務停止が許されないシステムで保守体制を削るのも危険です。業務影響と対応時間を結び付けて、必要なサービスレベルだけを契約します。

よくある質問(FAQ)

JSPのシステム開発について相談する場面

ここでは、JSPのシステム費用を検討する担当者から寄せられやすい質問に回答します。金額は案件条件で変わるため、相場をそのまま予算に置くのではなく、対象範囲と変動要因を整理して開発会社へ相談します。

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

20〜60画面程度で複数ロール、帳票、承認、外部連携を含む部門向けシステムなら、500万〜1,500万円、期間3〜8か月が一つの目安です。画面数だけでなく、要件定義、非機能要件、データ移行、テスト、保守の範囲で変わるため、JSPだからこの金額と断定することはできません。

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

既存の認証、DB、開発環境、テスト仕様が利用でき、改修範囲が明確なら、新規開発より短期間・低コストにしやすいです。小規模な画面追加や改修は100万〜500万円程度が目安ですが、仕様書がない、古いライブラリを更新する、脆弱性診断を行う、複雑な権限や帳票を直す場合は、現行解析とテストの費用が加わります。

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

まずアセスメントとPoCを行い、JSP・Servlet・EL・JSTL、依存ライブラリ、アプリケーションサーバー、認証、DB、外部連携の互換性を確認します。その後、画面数、移行対象のコード量、データ量、テストケース、並行稼働、切替条件をもとに見積もります。単純な置換で済む案件もありますが、設定差分やブラックボックス化した処理が多い案件では、移行・検証費用が新規開発に近づくことがあります。

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

現行資産と要件を整理し、必須機能と後回しにできる機能を分け、段階リリースを検討します。パッケージやSaaSを使える業務は標準機能に合わせ、独自開発する範囲を絞る方法もあります。複数社に同じ条件で見積もりを依頼し、工数、テスト、移行、保守を含む総額で比較することが、無理な値下げよりも安全なコスト最適化につながります。

まとめ

JSPのシステム開発費用をまとめる場面

JSPのシステム開発費用は、既存画面の小規模改修で100万〜500万円、部門向けの新規開発で500万〜1,500万円、中規模の販売・在庫・ワークフローで1,500万〜5,000万円、全社基幹の刷新で5,000万〜1億円超が目安です。ただし、これはJSPという技術の定価ではなく、画面数、業務ルール、既存資産、データ移行、外部連携、非機能要件を前提にしたレンジです。

費用を決めるのはJSPではなく業務と運用の範囲です

見積もりでは、人月単価×工数に加えて、要件定義、現行解析、設計、実装、テスト、移行、インフラ、セキュリティ、教育、保守を分けて確認します。特に古いJSPでは、仕様書にない業務ルールやjavax.*からjakarta.*への互換性が費用を左右するため、代表画面のPoCやアセスメントを先に行うことが有効です。

まず現行資産と優先順位を整理して相談します

コストを抑えるには、使える資産を再利用しながら、危険な部分を優先して直し、必須機能から段階的にリリースします。開発会社へ相談する際は、JSPの保守だけを依頼するのか、Jakarta移行やクラウド化まで含めるのかを明確にし、同じ条件で複数社の見積もりを比較してください。初期費用と年間保守費を合わせて判断することで、業務を継続しながら将来の負担を抑えやすくなります。

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

会社紹介

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

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

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

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

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

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