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

Struts2のシステムを発注・外注するときは、既存のJava資産を調査したうえで、保守継続・バージョン更新・Springへの段階移行・再構築のどれを選ぶかを決めることが重要です。

Struts2は業務システム製品ではなく、JavaのWebアプリケーションを構築するMVCフレームワークです。そのため、発注先の選定では「Struts2を使えるか」だけでなく、画面・Action・JSP・データベース・外部連携を読み解き、安全な更新や移行まで設計できるかを確認する必要があります。この記事では、発注形態の選び方、RFPと要件整理、契約形態、2026年時点の費用相場、委託先と見積書の比較ポイントを順番に解説します。

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

Struts2のシステムとは何ですか？発注前に押さえる全体像

Struts2のシステムとは、Struts2を土台にして構築された社内業務システム、会員サイト、申請・予約・販売管理システムなどを指すことが多いです。発注前にフレームワークだけを見てしまうと、実際の工数を左右する認証、帳票、バッチ、データ移行、外部APIを見落としやすくなります。

Apache Strutsは、設定より規約を重視し、プラグインによってREST、AJAX、JSONなどを拡張できるオープンソースのMVCフレームワークです。一般的な構成では、ブラウザからのリクエストをActionが受け、Interceptorで認証や入力検証などの共通処理を行い、業務サービスを呼び出して、JSPまたはJSONをResultとして返します。周辺にはTomcatなどのアプリケーションサーバ、SpringやSpring Security、MyBatisやHibernate、Oracle・SQL Server・PostgreSQLなどのデータベースが組み合わされます。

したがって、見積依頼では「Struts2で開発してください」と一言で終わらせないことが大切です。利用中のStrutsのバージョン、JavaとTomcatのバージョン、JARやプラグイン、Action数、JSP画面数、DB、バッチ、連携先、利用者数、ピーク時のアクセス数まで分かる範囲で提示します。設計書が残っていない場合も、ソースコードやサーバ内の設定ファイルを調査対象として明記すれば、発注先が調査工数を見積もりやすくなります。

Struts2のシステムを外注する場合、最初から全面的な作り直しを前提にしないことが重要です。短期的に脆弱性を解消し、Javaやアプリケーションサーバを更新する「保守・延命」、Struts 6系などへ上げる「バージョン更新」、Struts2の画面や業務ロジックをSpring MVC・Spring Bootなどへ移す「段階移行」、業務要件から見直す「再構築」を比較します。

2026年8月時点でApache公式にはStruts 6.10.0と7.2.1が掲載され、2.5系を含む一覧外のバージョンはEOLで、Apache Strutsチームから追加のセキュリティパッチを受けられないと案内されています（出典: Apache Struts公式、2026年）。ただし、最新番号へ機械的に上げればよいわけではありません。Java、ServletまたはJakarta、JSP、プラグイン、アプリケーションサーバの互換性を調べ、テストと切り戻しを含めて判断します。

Struts2のシステム発注・外注はどのように進めますか？

発注は、相談先を探すところから始めるのではなく、自社の判断材料をそろえるところから始めます。現行調査、対応方針の比較、RFP作成、提案依頼、技術ヒアリング、契約、設計・開発、受け入れテストという順番にすると、価格だけでなくリスクと成果を比較できます。

社内にStruts2の有識者が少なく、現行構成も把握できていない場合は、いきなり開発契約を結ばず、現状調査・脆弱性診断・移行計画だけを先行発注する方法が適しています。既存ベンダーがコードと運用を理解している場合は保守契約を継続しつつ、別会社から移行方針のセカンドオピニオンを取る方法もあります。

一方、要件と対象範囲が固まっていて成果物を明確にできる場合は、要件定義や開発を請負契約で発注しやすくなります。調査しないと画面数や依存関係が分からないレガシー案件では、調査・要件整理は準委任、確定した改修や移行単位は請負という組み合わせが現実的です。

RFPでは「古いので新しくしたい」という表現だけでなく、何を守り、何を変えたいのかを記載します。たとえば、月末の請求処理を停止させない、申請履歴を引き継ぐ、外部の会計システムと連携する、権限の棚卸しを容易にする、といった業務目的です。技術面では、Strutsのバージョン、Java、Tomcat、DB、JSP、Action、Interceptor、利用中のプラグイン、外部連携、バッチ、帳票、設計書の有無を項目化します。

対象範囲が不明な項目は、未確定のまま「調査して見積もる」と明記します。公開環境の有無、個人情報や決済情報の扱い、利用者数、稼働時間、許容停止時間、希望リリース時期、予算上限、納品後の保守体制も早めに共有します。情報を隠して安い見積もりを取るより、前提条件と除外条件を開示したほうが、契約後の追加費用を抑えやすくなります。

現状調査では、pom.xmlやGradle設定、WAR、JAR、struts.xml、Action、Interceptor、JSP、OGNL、認証・認可、DBスキーマ、バッチ、外部API、ログ、バックアップ、運用手順を一覧化します。画面数だけではなく、1画面から呼ばれるActionや複数の外部連携、独自タグ、手作業の運用があると工数は増えます。調査の成果物として、構成図、依存ライブラリ一覧、脆弱性影響、難易度、移行候補、未確定事項を受け取るようにします。

脆弱性の確認では、Apacheのセキュリティ情報とIPAのApache Struts 2対策情報一覧を照合します。IPAは、Strutsの脆弱性は基本的に修正パッチの適用とアップデートが必要であり、事前に動作確認を行うこと、組み込まれたライブラリの一覧を管理することを案内しています（出典: IPA、2026年1月13日更新）。診断結果だけを納品して終えるのではなく、修正、回帰テスト、リリース、監視までを発注範囲に含めるか決めます。

Struts2の外注ではどの契約形態を選びますか？

契約形態は、作業内容がどれだけ確定しているかと、成果物・品質・責任範囲をどこまで合意できるかで選びます。Struts2のレガシー案件では、調査前には見えない依存関係や仕様が残っているため、全工程を一括請負にすることが必ずしも安全とは限りません。契約書には、対象システム、成果物、検収条件、変更管理、再委託、知的財産、脆弱性対応、障害時の連絡方法を具体的に記載します。

準委任契約は、一定期間の作業や専門人材の稼働を依頼する形です。現行コードの解析、脆弱性の影響調査、移行方式の比較、開発会社との技術検討、リリース支援など、作業を進めないと成果の形や工数が確定しにくい業務に向いています。月単位または人月単位で費用を管理しやすい反面、成果物の完成責任が請負と同じ意味にならないため、作業報告、レビュー、調査結果、次月の計画を契約上の提出物として定めます。

準委任で発注する場合は、担当者の人数だけでなく、誰がどの成果を担当するかを決めます。たとえば、リーダーが構成図とリスク一覧を作り、Java担当が依存ライブラリを調べ、業務担当者が画面と帳票を確認する、といった役割分担です。作業時間だけが積み上がり、意思決定に必要な資料が残らない状態を避けられます。

請負契約は、合意した成果物を完成させ、検収を受けることを中心に進める契約です。Struts2の特定画面の改修、テスト仕様書に基づく回帰テスト、決められたデータ移行、合意済みのJava・サーバ更新など、範囲と完了条件を言語化できる作業に適しています。要件定義が曖昧なまま請負にすると、想定外のActionや連携が見つかった際に、追加費用や納期変更の協議が発生しやすくなります。

検収では「納品されたか」だけでなく、主要業務のシナリオ、権限別の操作、異常系、性能、ログ、バックアップ、脆弱性対応、切り戻し手順を確認します。受け入れ条件にテストデータ、判定基準、未解決課題の扱いを含めると、発注者と受託者の認識違いを減らせます。

おすすめしやすいのは、現状調査と移行計画を第1段階、優先度の高い改修や更新を第2段階、残りの移行と運用改善を第3段階に分ける方法です。第1段階の成果物をもとに、次の段階の対象画面、工数、納期、リスクを更新できます。全面移行の見積もりを最初から一つの数字で固定するより、事業停止リスクと追加要求を管理しやすくなります。

ただし、分割によって会社間の責任が曖昧にならないよう、設計書、ソースコード、設定ファイル、テストデータ、課題一覧、意思決定記録を次の会社へ引き渡すルールを決めます。既存ベンダーから新しい移行会社へ切り替える場合は、引き継ぎ期間、質問への回答期限、環境へのアクセス方法、秘密情報の取り扱いも契約に含めます。

Struts2のシステム発注費用・相場はいくらですか？

Struts2だけを対象にした公的な平均価格は確認できないため、費用は画面数、Action数、外部連携、データ移行、設計書の有無、テスト資産、求める停止時間で個別に変わります。2026年版のSIAの解説では、システム開発の人月単価はスキルや地域によって変動するものの、60万〜200万円程度とされています（出典: SIA「システム開発の費用・相場 2026年版」）。以下はこの単価レンジと作業量をもとにした推定であり、Struts2案件の統計的な平均ではありません。

小規模な構成確認と依存ライブラリの確認だけなら、数人週程度で終わる場合があります。一方、複数の環境、数百のJSPやAction、設計書の欠落、外部連携、運用担当者へのヒアリングまで含めると、調査は大きくなります。リサーチノートの作業量推定では、現状調査・脆弱性診断・移行計画は60万〜600万円程度、期間は2〜6週間が目安です。

この段階では、単に脆弱性の有無だけでなく、影響を受けるJAR、公開範囲、修正方法、回帰テストの対象、リリース可能な時間帯、代替案を確認します。調査費用を惜しんで本開発の見積もりだけを比べると、後から「実は独自Interceptorが多数ありました」「帳票サーバの仕様が不明です」と判明し、予算と納期が膨らむ可能性があります。

脆弱性修正、Javaやアプリケーションサーバの更新、設定変更、主要画面の回帰テストを行う案件は、120万〜1,000万円程度、期間は1〜3か月が目安です。この幅が大きいのは、パッチを適用するだけの案件と、互換性のないライブラリや独自プラグインまで修正する案件が同じ「更新」に見えるためです。見積書では、対象バージョン、変更するJAR、修正画面、テストケース、環境構築、リリース支援を分けて記載してもらいます。

Apache公式では、CVE-2025-68493について少なくともStruts 6.1.1への更新、CVE-2025-64775についてStruts 6.8.0または7.1.1への更新が緩和策として案内されています（出典: Apache Struts公式セキュリティ情報、2026年確認）。ただし、対象環境が本当に影響を受けるか、修正版へ上げた後に業務が動くかは個別確認が必要です。脆弱性番号だけを根拠に特定の金額を断定せず、実際の依存関係とテスト量から見積もります。

Struts2からSpring MVCやSpring Bootへ移行する場合、画面とControllerだけでなく、認証・認可、業務ロジック、バリデーション、セッション、帳票、API、テスト、運用を移します。リサーチノートの推定では、600万〜6,000万円程度、期間は6〜18か月です。業務単位の段階移行なら範囲を抑えられますが、複数部署と外部連携を一度に切り替える場合は上振れしやすくなります。

業務システム全体の再構築は、要件定義からデータ移行、教育、運用設計まで含めると1,000万〜5,000万円以上、期間は8〜24か月以上が目安です。SIAの人月単価レンジで考えると、10人月なら600万〜2,000万円、20人月なら1,200万〜4,000万円となりますが、これは工数を仮定した計算です。発注時には「移行対象の人月」と「新規機能の人月」を分離し、根拠を確認します。

公開後は、脆弱性情報の確認、パッチ適用、OS・Java・ミドルウェアの更新、障害調査、バックアップ確認、ログ監視、問い合わせ対応が発生します。一般的な業務システムの保守・運用は、初期開発費の年15〜25％、または月15万〜80万円程度が目安とされますが、Struts2の脆弱性監視、24時間監視、第三者診断、緊急リリースを含める場合は個別に上振れします。これは一般的な相場であり、Struts2固有の平均価格ではありません。

見積書では、月額保守に含まれる問い合わせ時間、障害の優先度、対応開始時間、修正の上限、定例報告、脆弱性対応、休日対応を分けます。特に「軽微な改修」の定義が曖昧だと、画面変更や帳票追加が保守外になりやすいです。将来の予算化のために、通常保守、緊急対応、機能追加、環境更改の単価と承認手順を確認します。

RFPと要件整理では何を決めればよいですか？

RFPは、受託会社に同じ条件で提案してもらうための資料です。すべてを発注者が決め切る必要はありませんが、現行システムの事実、業務上の目的、守るべき制約、提案してほしい範囲を分けて記載します。最低限の情報がそろうと、安価に見えるが調査を含まない提案と、移行・テスト・保守まで含む提案を比較できます。

画面の一覧には、利用部署、利用頻度、権限、入力・出力、帳票、エラー処理、業務上の重要度を付けます。コードの一覧には、Action、Interceptor、Result、JSP、独自タグ、設定ファイル、依存JAR、テストコードを付けます。データでは、テーブル、件数、保持期間、個人情報、マスタ、移行先、移行後の照合方法を確認します。運用では、ジョブ、バックアップ、監視、障害連絡、手作業、リリース手順、開発・検証・本番環境の差分を整理します。

設計書がない場合は、コード解析だけでなく業務担当者へのヒアリングを行います。コードに存在していても使われていない画面、担当者だけが知る締め処理、表には出ないCSV連携が見つかる場合があります。発注前に不明点をゼロにするのではなく、不明点を一覧化し、調査で解決する項目と、発注者が判断する項目を分けることが大切です。

機能要件には、申請、承認、検索、登録、集計、帳票、通知、API、バッチ、データ移行など、システムが何をするかを書きます。非機能要件には、稼働時間、停止可能時間、レスポンス、同時利用者数、バックアップ、復旧目標、監視、ログ保存、認証、権限、暗号化、脆弱性診断、監査を記載します。Struts2の更新では、画面が表示できても性能や権限の挙動が変わる可能性があるため、非機能要件を後回しにしないことが重要です。

新しいフレームワークを採用する場合は、Javaのバージョン、ServletまたはJakartaへの対応、コンテナ化の方針、クラウドまたはオンプレミス、データベースの継続利用、認証基盤との接続を決めます。Struts2を残す提案も排除せず、今後のサポート、担当者の確保、脆弱性対応、機能追加のしやすさ、移行の難しさを同じ評価表で比べます。

RFPには、脆弱性情報の監視担当、緊急パッチの評価期限、診断の実施者、公開前の承認者、インシデント発生時の連絡経路を入れます。認証・認可、CSRF対策、入力値検証、秘密情報の管理、監査ログ、個人情報の取り扱い、再委託先の管理も確認します。Apache公式は、Struts2自体は純粋なWebフレームワークで、認証や認可などのセキュリティ機構そのものを提供する製品ではないと説明しています（出典: Apache Struts公式セキュリティガイド）。

受け入れ条件には、正常系だけでなく、権限のない利用者が操作できないこと、想定外の入力を受けても情報を露出しないこと、旧システムと新システムで残高や申請状態が一致すること、障害時に切り戻せることを含めます。委託先に丸投げするのではなく、発注者側の業務責任者が判定できる形式にしておくと、納品後のトラブルを減らせます。

Struts2の委託先と見積書はどこを比較しますか？

委託先は、Struts2の記載がある会社を並べるだけでは選べません。「そのまま保守できる会社」「Struts 6系などへ更新できる会社」「Springへ移行できる会社」「クラウドやDB更改、運用まで任せられる会社」は重なりますが、必要な経験は異なります。候補会社には同じRFPを渡し、提案内容、調査方法、体制、成果物、費用、契約条件を比較します。

保守を依頼するなら、現行バージョンの解析、障害の再現、緊急パッチ、アプリケーションサーバやDBを含む切り分けの経験を確認します。移行を依頼するなら、Struts1・Struts2からSpring MVCやSpring Bootへの移行、画面と業務ロジックの対応付け、データ移行、並行稼働、回帰テストの実績を確認します。公式サイトにStruts2の実績が掲載されていても、現在の担当者が対応できるとは限らないため、担当予定者の経験と稼働時期を聞きます。

提案会社が提示した事例では、対象規模、画面数、利用者数、移行先、担当範囲、期間、保守の有無を確認します。社名や導入効果だけでなく、どの課題をどの方法で解決したかを聞くと、自社との類似性を判断できます。ソース解析、自動変換、テスト自動化を訴求する会社でも、変換後の手修正と業務テストを誰が担うかは必ず確認します。

初回の技術ヒアリングでは、次のような質問をします。「利用中のStruts、Java、Tomcatのバージョンをどのように特定しますか」「依存JARと脆弱性の影響をどう確認しますか」「設計書がない画面の仕様をどう復元しますか」「Spring移行とStruts更新の判断基準は何ですか」「回帰テストの範囲と不足時の補い方は何ですか」「本番障害時の一次対応は誰が何時まで行いますか」といった質問です。

加えて、担当予定者の氏名と経験、再委託の有無、ソースコードと設定ファイルの管理場所、開発・検証・本番へのアクセス制御、脆弱性情報を受け取った際の対応期限、リリース後の保守窓口を確認します。発注者側が用意する業務担当者やテスト環境も明確にします。提案段階で答えが曖昧な項目は、契約前の確認事項として残します。

複数社の見積もりを比較するときは、要件定義、現状調査、設計、実装、データ移行、テスト、脆弱性診断、リリース、教育、保守を同じ項目にそろえます。見積もりに「開発一式」としか書かれていない場合は、画面数、Action数、帳票数、連携本数、テストケース数、想定人月、単価、期間、体制、前提条件を追加で確認します。

安い見積もりが悪いわけではありませんが、調査を含めず、データ移行や受け入れテストを発注者側に置き、保守を別料金にしている可能性があります。反対に高い見積もりでも、移行リハーサル、並行稼働、性能試験、教育、障害対応が含まれていれば、単純な総額比較はできません。金額と一緒に、納品物、リスク、発注者の作業、追加費用が発生する条件を比較します。

発注後の進行でStruts2システムの失敗を防ぐには？

発注が決まった後は、受託会社に任せきりにせず、発注者側で業務判断を止めない仕組みを作ります。週次の課題管理、月次の品質確認、変更要求の承認、環境ごとのリリース記録、経営層への報告を決めます。レガシーシステムでは、調査の途中で想定外の仕様が見つかるため、早い段階で小さな成果物を確認することが効果的です。

調査開始後の早い段階で、受託会社から構成図、依存ライブラリ一覧、画面・Action一覧、外部連携一覧、脆弱性影響、未確定事項を提出してもらいます。発注者の業務担当者は、使われていない機能や例外的な業務を確認します。ここで大きな前提違いがあれば、開発着手前に範囲や予算を見直せます。

移行案件では、代表的な画面や業務を一つ選び、調査から実装、テスト、リリース手順までを小さく検証する方法もあります。自動変換を使う場合でも、変換率だけで成功と判断しません。認証、入力検証、例外処理、帳票、性能、権限を含む業務シナリオで、実際に安全に動くかを確認します。

テストは、単体テスト、結合テスト、システムテスト、性能テスト、セキュリティテスト、受け入れテストに分けます。特にStruts2の更新やSpring移行では、URL、画面遷移、セッション、入力値、権限、エラーメッセージ、CSVや帳票、外部APIが変わらないかを確認します。旧システムと新システムを同じデータで実行し、結果を照合するテストを用意すると、目視だけでは見つけにくい差異を検出できます。

リリース前には、バックアップ、切り戻し条件、連絡先、作業手順、監視項目、障害時の判断者を確認します。業務停止が難しい場合は、段階リリース、並行稼働、時間帯を分けた移行、機能単位の切り替えを検討します。リリース後の安定稼働期間と、問題が起きた際の無償修正・追加契約の境界も、検収前に決めておきます。

保守会社に長く依頼する場合でも、ソースコード、設定ファイル、構成図、データ定義、テスト仕様書、運用手順、脆弱性対応履歴、障害の原因と対策を発注者側で保管します。納品物の形式、更新頻度、リポジトリの権限、バックアップ、退職や会社変更時の引き継ぎを決めます。情報が会社の担当者だけに集中すると、将来の再発注や緊急対応で選択肢が狭くなります。

個人情報や機密情報を扱う場合は、再委託先、アクセスできるデータ、ログの保管、事故時の報告期限、監査、契約終了時の返却・削除を確認します。委託先の会社規模や知名度だけで判断せず、実際に作業する担当者、技術情報の管理、インシデント対応の実効性を確認することが、安全な長期運用につながります。

よくある質問（FAQ）

Struts2の発注では、「そのまま残すべきか」「すぐ移行すべきか」「予算をどう置くか」という相談が多くなります。ここでは、発注前に特に確認されやすい質問に、判断の順番が分かるように回答します。

バージョン、依存ライブラリ、公開範囲、脆弱性の影響、保守体制を確認し、安全に更新・運用できるなら、短期的に使い続ける選択肢はあります。ただし、EOL版は公式のセキュリティパッチを受けられないため、現状調査と移行計画を先延ばしにしないことが大切です。画面数や技術の古さだけで判断せず、業務停止リスク、開発者確保、予算、移行期間を合わせて判断します。

最初から全体の開発費を断定せず、まず現状調査・脆弱性診断・移行計画の費用を予算化する方法が安全です。目安は60万〜600万円程度ですが、これは構成規模と調査範囲から算出した推定です。その後、パッチ・小規模改修、バージョン更新、Spring移行、再構築の見積もりを分け、保守費用とデータ移行費用を別に確認します。

「Struts2対応」「レガシーJava移行」「Spring Boot移行」「Java業務システム保守」などの実績を確認し、候補会社に同じRFPを渡して比較します。重要なのは掲載実績の数ではなく、現行コードの解析、脆弱性対応、データ移行、テスト、リリース後の保守を担当予定者が説明できることです。担当者の経験、再委託、SLA、成果物、ソースコードの引き渡しを確認してから契約します。

クラウドへ移すだけでStruts2の脆弱性や古い依存ライブラリが解消されるわけではありません。Java実行環境、アプリケーションサーバ、JAR、認証、秘密情報、WAF、ログ、バックアップ、監視、切り戻しを別々に設計する必要があります。クラウド移行とフレームワーク更新を同時に行う場合は、変更点が増えるため、段階移行や検証環境でのリハーサルを計画します。

まとめ

Strutsのバージョン、依存ライブラリ、画面・Action・JSP、DB、外部連携、運用を棚卸しし、保守・更新・移行・再構築の選択肢を比べます。判断材料が不足している場合は、調査と移行計画を先に外注します。

RFPでは業務目的、非機能要件、セキュリティ、データ移行、受け入れ条件を明記し、見積書は工数・単価・前提・除外範囲をそろえて比較します。契約後は構成図やリスク一覧を早期にレビューし、ソースコードや運用知識を発注者側にも残します。

Struts2のシステムを発注・外注するときは、まずStrutsのバージョン、Java・サーバ・依存ライブラリ、画面・Action・JSP、DB、外部連携、運用を棚卸しします。そのうえで、保守・パッチ適用、Struts 6系などへの更新、Springへの段階移行、業務システムの再構築を比較し、自社の停止リスクと予算に合う方針を決めます。

発注形態は、調査や伴走には準委任、成果物と検収条件が固まった開発には請負を使い分けます。RFPでは、技術情報だけでなく業務目的、非機能要件、セキュリティ、テスト、運用、再委託、引き継ぎを明記します。見積書は総額だけでなく、工数、単価、前提、除外範囲、移行・テスト・保守の有無をそろえて比較することが大切です。

最初の一歩として、現行資産の一覧と不明点を作り、複数の委託先へ同じ条件で調査・移行計画を依頼します。Struts2を使える会社と、Struts2から安全に移行できる会社を分けて評価し、担当者の経験とリリース後の保守体制まで確認すると、将来のブラックボックス化を防ぎやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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