相談する

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

Gradleのシステム開発の発注は、対象範囲の整理、RFPと契約の合意、PoC、開発・運用の順に進めると、業務システムを安全に届けやすくなります。発注形態の選び方から、要件整理、費用の見方、委託先の選び方、開発後の運用までを、発注担当者の目線で順に見ていきます。

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

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

Gradleのシステムの概要

アプリ、ビルド、インフラ、運用を上下4層に分けたGradleシステムの図解
層ごとに担当範囲を分けると、見積もりの抜けを防ぎやすくなります。

Gradleのシステムとは、Gradleをビルド基盤にして、Java・Kotlinなどで業務アプリを開発・テスト・リリースする仕組みです。Gradleは、コンパイル、テスト、外部ライブラリの依存関係解決を自動化し、JAR・WAR・コンテナイメージなどの成果物も作成します。ただし、顧客管理や在庫管理といった業務機能そのものは、Gradleでは提供しません。

Gradleが担当する範囲と業務システム本体の範囲

発注時は、業務システム本体とビルド基盤を分けて要件として書き出します。担当範囲をこのように切り分けておくと、各社の見積もりを同じ土台で比べられます。

  • 業務システム本体：画面、API、DB、権限、帳票、外部連携、監査ログ
  • Gradle側：Wrapper、build.gradleまたはbuild.gradle.kts、プラグイン、依存関係、テストタスク
  • 周辺基盤：成果物リポジトリ、CI/CD接続、Spring Boot、PostgreSQL、GitHub ActionsやJenkins、コンテナ基盤

周辺基盤をどこまで委託するかも、RFPで明示します。対象を分けないと、要件定義、データ移行、受入テスト、運用手順が見積もりから抜けることがあります。

反対に、CI/CDや依存関係の統制をアプリ開発費に含めると、会社ごとの提案範囲を比較しにくくなります。そこで、RFPではアプリ、ビルド、インフラ、運用の4層に分けます。

発注者が確認したいメリットと注意点

Gradleの利点と注意点を分けて確認し、採用後の効果や運用上のリスクを判断します。

  • ビルド処理の標準化：増分ビルド、並列実行、キャッシュで、複数サービスやチームの共通処理をそろえられます。
  • 複数サービスへの展開：マルチモジュール、Kotlin DSL、Convention Pluginを活用できます。
  • 設定の保守：build.gradleの肥大化、Groovy DSLの属人化、プラグインの互換性が課題になります。
  • 依存関係と環境：予期しない更新や、ローカルとCIの環境差が問題になることがあります。

効果はコード構成、テスト量、キャッシュの使い方、CI環境によって変わるため、採用前にPoCで測定します。大規模なJava・Kotlinシステムでは、開発者の待ち時間やCI実行時間を減らせる可能性もあります。

Gradle公式は、依存関係のチェックサムや署名を記録するdependency verificationを案内しています（出典: Gradle公式「Verifying Dependencies」、2026年確認）。再現性、脆弱性対応、アップグレード責任も、利点と注意点を見比べたうえで委託範囲に含めます。

Gradleのシステム開発の発注形態

一括委託、ラボ型・伴走型、部分委託を並べたGradleシステム開発の発注形態図
社内の技術力と委託したい範囲が、選択の分かれ目になります。

発注形態は、社内の技術力と開発対象の範囲、納期を中心に、障害時の責任や将来の内製化の方針も含めて選びます。

Gradleだけを導入するのか、業務システムを新規に開発するのかで、適した会社は変わります。Maven移行とCI整備だけを任せる場合は、候補と契約の組み合わせがまた別になります。

設計から開発・運用移管までの一括委託

社内にJava、Gradle、クラウド、CI/CDを横断して判断できる人が少なく、業務システムも新規に作るなら、一括委託が現実的な選択になります。

一括委託では、委託範囲と、発注者・受託会社それぞれの役割を分けて整理しておきます。

  • 委託範囲：要件定義、設計、開発、テスト、リリース、運用移管
  • 発注者の役割：業務上の優先順位付けと受入判断
  • 受託会社の役割：技術選定と開発チームの組成
  • 契約で定めること：成果物の所有権、ソースコード・IaC・CI設定の引き渡し、利用OSS一覧、アカウント管理者、保守終了時の引き継ぎ

ベンダー環境でしかビルドできない状態や、特定の担当者しか直せないbuild logicが残ると、将来、別の会社へ乗り換える際の費用が高くつきます。

ラボ型・伴走型による内製チームとの共同開発

社内に業務知識やプロダクト責任者がいて、GradleやSpring Bootの技術を補いたい場合は、ラボ型・伴走型が候補です。

共同開発では、仕様変更にどう対応するかと、役割や完了条件を事前に合意しておくことが欠かせません。

  • 優先順位：月次または短いイテレーションで見直し、発注者も設計・コードレビューに参加
  • 向いている局面：仕様変更が多く、完成物を一度に固定しにくい段階
  • 体制の合意：責任者、意思決定期限、レビュー対象、スプリント成果物、技術負債の扱い
  • Gradle設定の完了条件：Wrapper固定、依存関係ロック、CI再現性、運用文書

作業範囲が曖昧なまま人数を増やすと、稼働時間は増えても業務成果に結びつきにくくなります。

Mavenからの移行やCI改善の部分委託

既存システムが安定していても、MavenからGradleへ移行したい場合や、ビルドが遅い場合は部分委託が候補です。CIの失敗原因を追跡しにくい場合にも適しています。

まず、pom.xmlと依存ライブラリ、社内プラグインを中心に現行の構成を調べます。JDKやCIイメージ、成果物の保管先も対象に含めます。そのうえで、1サービスまたは1モジュールでPoCを行い、そこから全体移行へ進みます。

Mavenに大きな問題がない場合は、移行そのものを目的にしないよう注意します。移行で何を得たいかは、ビルド時間やCI費用などの数値で、先に決めておきます。

  • 構成・機能：マルチモジュール化、Kotlin DSL、Android対応、共通プラグイン
  • 実行効率：キャッシュの活用、開発者の待ち時間削減

移行で得たい効果は、現行環境のビルド時間やCI費用、失敗率、開発者の待ち時間と比較して確かめます。

ポイント

発注形態は、社内に技術力があるか、どこまでを任せたいかで決めるのが基本です。Gradleだけを導入するのか、業務システムを新規に開発するのかによって、候補となる会社や契約の組み合わせが変わります。

RFPと要件整理の進め方

RFPは、事業目的とシステム要件を候補会社に同じ条件で伝える提案依頼書です。技術資料だけでなく、事業の目的まで含めて伝える点が特徴です。

IPAの資料では、導入の背景・目的、求めること、提案と契約の手続き、業務フローなどを記載すると説明されています（出典: IPA「ストーリーで学ぶ要件定義実践入門」、2026年確認）。加えて、要件一覧、課題一覧、現行システムの構成図も記載項目に含まれます。

業務側の言葉で書く背景・目的・対象範囲

候補会社が同じ条件で判断できるよう、業務側の言葉で次の内容をまとめます。

  • 業務目的：受注の二重登録解消、月次締めを5営業日から3営業日に短縮、リリース手順の標準化
  • 対象範囲：利用者数、拠点数、対象部署、データ量、現行課題、対象外業務
  • 技術環境：言語・ビルドツール、フレームワーク、構成、CI、成果物、デプロイ先
  • 未確定事項：候補会社への提案依頼として分け、現状不明なら要件定義・アセスメントを先行

技術情報では、Java・KotlinとGradle・Mavenの各バージョン、Spring BootやAndroidの有無を整理します。モジュール数やリポジトリ構成も記載します。

何を改善するためにGradleを採用するのかを伝えます。業務目的が、候補会社の提案の前提になるためです。

Gradle固有の要求のチェックリスト

Gradle固有の要求は、更新、依存関係、供給網の管理方法まで含めて定めます。

  • Gradle Wrapper：版のGit固定、配布ファイルの検証、JDKとの互換性
  • 更新計画：Configuration Cache、Kotlin DSL、プラグイン互換性の確認
  • 既存環境の移行：古いJDKの場合、フレームワークとCIイメージも含めた計画
  • 依存関係：Maven Central・社内リポジトリ、バージョン固定、Version Catalog、ロック、推移的依存の指定
  • 検証と記録：脆弱性・ライセンス・SBOMの確認、検証メタデータの管理とレビュー

Gradle公式リリースノートは、2026年時点で9.6.1への更新方法を示しています（出典: Gradle公式「Release Notes」、2026年確認）。

dependency verificationでは、チェックサムで内容の完全性を、署名で公開者の真正性を確かめます。その検証メタデータであるverification-metadata.xmlは、リポジトリで管理します。また、自動生成したメタデータは無条件に信頼せず、重要なライブラリをレビューする運用も成果物に含めます。

非機能要件・成果物・KPIの事前合意

非機能要件、受入条件、導入前後を比べるKPIは、発注側と候補会社が一緒に合意しておきます。

  • ビルド・CI指標：ビルド時間、同時実行数、成功率、カバレッジ測定方法、CI待ち時間、失敗率、調査時間
  • 運用要件：復旧時間、ログ・監査証跡、アクセス権、バックアップ、秘密情報、脆弱性報告期限
  • 受入条件：クリーン環境での再現、自動テストの実行、承認済み成果物だけのリリース
  • 効果測定：開発者の待機時間、リリース頻度、脆弱性対応までの日数を導入前後で比較
  • 参考事例：Tableauは約500人・1日25,000ビルドの環境で、重いビルド担当者が2週間で15時間を回収

この事例の出典は、Gradle公式の紹介ページです（出典: Gradle公式Tableau事例、2026年確認）。ただし、自社で同じ効果が出るとは限りません。PoCで測る際の基準として使います。

ポイント

迷ったときは、候補会社が同じ条件で見積もれるだけの情報がRFPにそろっているかで判断します。未確定の事項があれば、要件定義やアセスメントを先に行うかどうかも考えます。

契約形態とGradleのシステム開発費用の相場

契約は、要件の確定度と成果物の明確さで使い分けます。たとえば、要件定義、技術調査、アセスメント、運用支援は、作業の遂行を委託する準委任契約が候補になります。

仕様、成果物、納期、検収条件を明確にできる設計・開発では、請負契約が候補になります。また、要件定義を準委任、基本設計以降を請負、保守を準委任とするように、段階ごとに組み合わせることもあります。

経済産業省のモデル契約資料は、契約類型、再委託、損害賠償、知的財産、RFPの用語定義などを扱います（出典: 経済産業省「情報システムのモデル契約書」、2026年確認）。

ひな形はそのまま使わず、成果物、変更管理、検収、未確定要件、障害対応を法務担当者と確認します。加えて、OSSライセンスとソースコードの利用権も確認対象に含めます。

Gradleの導入・移行と業務システム本体の費用目安

初期予算を組む際の目安は、次のとおりです。ライセンス費、作業範囲、規模は分けて比べる必要があります。

  • Gradle基盤：OSSの基本ライセンス料は不要で、Wrapper、ビルド設計、CI/CD、社内リポジトリ、審査、教育、運用移管には人件費がかかります。
  • 初期作業の目安：単一〜数モジュールの整備・CI・基本テストは50万〜200万円程度、Maven移行・標準化は100万〜500万円程度
  • 業務システム本体：部門向け中規模は300万〜5,000万円程度、全社基幹は5,000万円〜1億円以上の可能性
  • 国内相場情報：人月単価と開発規模別の費用目安を参照
  • 商用サービス：Develocityなどは機能・利用規模・構成ごとの個別見積もり。ライセンス範囲と更新条件を確認

部門向け中規模の目安は、画面・DB・権限・外部APIを含む想定です。全社基幹の目安は、複数サービスやデータ移行、高可用性を含む場合のものです。

2026年7月公開の国内相場情報では、人月単価はスキル・地域により60万〜200万円程度です（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。また、SIAの一般的な開発規模別相場は、小規模ツールが100万〜300万円、中規模が500万〜1,000万円、大規模が1,000万円〜数千万円以上です。

ここで示す金額は、Gradle単体の公定価格とは別に、対象範囲と工数から算出する推定レンジです。市場記事の金額もGradle案件にそのまま当てはまらないため、RFPの工数内訳と前提条件で補正します。

保守運用・クラウド・商用サービスの費用の切り分け

初期費用とは分けて、継続費用と商用機能の必要性を見積もります。

  • 継続費用：JDK・Gradle・プラグイン更新、脆弱性対応、CIランナー、キャッシュ、成果物リポジトリ、監視、ログ、クラウド、商用サポート
  • 保守体制：初期開発費の年15〜25％程度を暫定基準にできるが、固定相場ではない
  • 対応時間：平日日中の問い合わせのみか、夜間の一次切り分け・障害復旧も含むかで体制が変わる
  • 商用機能：失敗分類、CIキャッシュ、成果物の昇格統制

Develocity 2025.4は、ビルド・テスト失敗をAIで分類します。また、Artifact CacheやSetup Cacheは、CIのコールドスタートを抑えます。

Provenance Governorは、信頼できる成果物だけを昇格させます。こうした機能は、大規模CIの待ち時間や供給網の統制に効果が見込めます（出典: Develocity公式「2025.4」、2026年確認）。

費用対効果は、導入費、運用設計、データの取り扱いを含めて判断します。

ポイント

契約は、要件の確定度と成果物の明確さで選ぶのが目安です。費用は、導入費、保守運用、商用サービスを分けて見積もり、人月単価と工数の前提がそろっているかで比べます。

委託先の選び方と見積比較のポイント

委託先は、Gradleの経験に加えて、業務システムを本番運用まで届けた経験で評価します。Java・Kotlin、Springなどの周辺技術も確認します。

CI/CD、クラウド、DB、セキュリティの経験も見ます。ただし、公開実績だけでは、対象規模や担当工程、保守体制、再委託の有無までは分からないことがあります。

実績は候補を絞る材料とし、提案の場で足りない点を追加で確認します。

実績・体制・技術責任者の確認

実績に加えて、実運用の経験と契約後の担当体制を具体的に確認します。

  • 担当実績：Gradleの版、モジュール数、Java・Kotlin比率、CI環境、依存関係、テスト自動化、リリース後の更新
  • 技術説明：匿名構成図、Wrapper、Convention Plugin、Version Catalog、失敗調査、脆弱性対応
  • 体制：提案後の責任者、引き継ぎ、PM・アーキテクト・Gradle/CI・アプリ・テスターの役割と稼働率
  • 運用窓口：再委託先、問い合わせ先、障害時の連絡経路。経験者が提案時だけなら教育や手戻り費用も考慮

実運用の深さは、「導入経験がある」という回答よりも、具体的な運用の話で確かめます。

見積書の比較：前提・工数・除外範囲

各社の見積もりは、工程・前提・除外範囲をそろえて、同じ土台で比べられる形にします。

  • 工程別の内訳：要件定義、基本・詳細設計、Gradle標準化、アプリ開発、テスト、移行、CI/CD、セキュリティ、教育、運用移管
  • 工数と前提：人月単価、工数、担当ロール、期間、前提条件。作業一式なら分解を依頼
  • 含有確認：データ移行、外部API調整、テストデータ作成、性能試験、脆弱性診断
  • 追加費用：クラウド、商用ライセンス、CIランナー、監視、休日対応、リリース後の不具合修正
  • 各社の比較：「標準機能」「別途見積」「発注者作業」「対象外」を揃え、3社程度へ同じRFPを渡す

安い見積もりでは、要件定義、テスト、文書、保守が除外されていないかを確認します。

成果物・知的財産・契約終了時の引き継ぎ

納品物、知的財産、契約終了時の移管条件は、契約前に確認しておきます。

  • 文書とコード：要件定義書、設計書、ソースコード、build.gradle/build.gradle.kts、settingsファイル
  • ビルド・開発一式：Gradle Wrapper、Convention Plugin、Version Catalog
  • 検査・運用資料：テストコード・結果、脆弱性検査結果、SBOM、監視設定、運用手順、アップグレード計画
  • 納品条件：形式、保管場所、アクセス権、レビュー方法、受入基準、修正期限
  • 権利と移管：OSSの著作権表示・ライセンス条件、第三者ライブラリの利用範囲、生成物・コード・設計書の利用権、再委託成果物、管理者、引き継ぎ期間・窓口

検証メタデータ（verification-metadata.xml）、CI設定、IaCも納品対象に含めます。

契約終了時は、リポジトリ、CI/CD、クラウドの管理者を発注者に戻せるようにします。監視、証明書、秘密情報の管理者も、発注者に戻せる状態にします。

引き継ぎ期間を無償とするか有償とするか、移管後の問い合わせ窓口も決めておきます。

ポイント

委託先は、Gradleの実績だけでなく、本番運用までの経験と契約後の担当体制で判断します。見積もりは、金額より前提・工数・除外範囲をそろえて比べます。

発注後の開発・移行・運用の進め方

更新対象、供給網対策、契約上の対応、運用指標が循環するGradle本番運用の図解
定期的な指標確認が、更新やセキュリティ対応の見直しにつながります。

Gradleのシステム開発は、まず要件定義と技術検証を行い、設計・実装、テストへ進みます。その後、移行とリリースを経て、運用改善へ移ります。

各段階では、業務システムとビルド基盤の成果物を分けたうえで、次の工程へ進む条件を決めておきます。そうすると、Gradle設定の変更がアプリやリリース手順に与える影響を追いやすくなります。

PoCによる互換性・速度・再現性の検証

本開発前に代表的な1サービスまたは1モジュールでPoCを行い、結果を記録します。

  1. Wrapper固定、JDK選択、依存関係解決、単体テストを試す。
  2. 成果物発行、CIのクリーンビルド、キャッシュ、脆弱性検査、ロールバックを行う。
  3. Maven移行では同じコード・テストで、ビルド時間、成果物差分、テスト結果、CI失敗原因を比較する。
  4. 採用・不採用プラグイン、互換性問題、残課題、想定工数、運用ルールを成果物に残す。

Configuration Cacheは、互換性のないタスクやプラグインがあると再利用されない場合があります。速度よりも正しさを優先します。

測定結果を本見積もりに反映すれば、「Gradleなら必ず速くなる」といった根拠のない断定を避けられます。

供給網セキュリティとアップグレード窓口の運用

本番運用では、更新対象の決め方から、供給網の検査、脆弱性発生時の対応、運用指標までを、あらかじめ定めておきます。

  • 更新対象：依存ライブラリ、Gradleプラグイン、Wrapper、JDK、CIイメージ
  • 供給網対策：チェックサム・署名、信頼リポジトリの限定、脆弱性スキャン、SBOM、成果物署名、監査ログ
  • 契約上の対応：緊急更新手順、脆弱性公表時の一次調査・修正・報告期限、Gradle・JDKのメジャー更新対象、互換性検証費、保守終了時期、夜間対応の有無
  • 運用指標：ビルド時間、CI費用、失敗率、復旧時間、更新滞留数を定期確認し、改善継続・縮小・商用機能追加を判断

経済産業省の2026年公開資料は、更新や供給網を含むセキュリティ要件を調達時に確認する考え方を示しています（出典: 経済産業省「IT製品の調達におけるセキュリティ要件リスト Ver.2.1」、2026年）。

ポイント

PoCの結果をもとに採否を決め、本番後は更新の窓口と運用指標を定期的に見直すかどうかで判断します。移行の是非も、測定結果と現行環境の比較で決めます。

よくある質問

Gradleの発注・外注では、ツールの導入費と業務システムの開発費を分けて考えることが大切です。発注前によくある疑問を取り上げます。

Gradleのライセンス費用だけでシステム開発できますか？

Gradle Build ToolはOSSとして利用できますが、業務要件定義、アプリ開発、DB、テストにも費用が発生します。そのため、ライセンス費用だけで開発を完結させることは難しいです。

さらに、CI/CD、クラウド、セキュリティ、運用保守も別途必要です。商用のDevelocityなどは、ライセンスの個別見積もりと導入・運用を含めた総額で判断します。

MavenからGradleへ移行したほうがよいですか？

移行は、目的がはっきりしている場合に検討します。たとえば、マルチモジュール化、Kotlin DSL、共通ビルドロジックなどの目的があり、PoCで効果を確認できるときです。

キャッシュ、Android対応、CI時間の短縮も、移行の目的として候補に挙がります。

現行Mavenが安定しているなら、移行費用、互換性検証、教育、運用変更を含めて、得られる効果と比べます。

Gradleに詳しい委託先へ何を質問すればよいですか？

Wrapperの固定方法、JDK互換性、依存関係のロックと検証、社内リポジトリの扱いを質問します。加えて、CI再現性やテスト自動化、キャッシュ測定についても確かめます。

また、脆弱性対応、アップグレード責任、成果物の引き渡しについても聞きます。あわせて、同規模のJava・Kotlin業務システムで担当した工程も確認します。

現在の保守体制、再委託の範囲、障害時の連絡経路まで確かめておくと、見かけの経験に頼らずに判断できます。

Gradleのシステム開発費用はどのように抑えられますか？

対象業務と成果指標を絞り、PoCで技術リスクを確かめてから本開発へ進みます。RFPで除外範囲を明確にします。

複数社から同じ条件で見積もりを取り、業務システム本体、Gradle基盤、クラウド、保守を分けて比較します。

安さだけで選ばないよう、移行、テスト、セキュリティ、引き継ぎなど、追加費用になりやすい作業を初期計画に含めます。

まとめ

Gradleは、業務アプリを安全かつ再現性高くビルド・テスト・リリースするための基盤です。業務機能そのものは、Gradleでは提供しません。

発注形態は、社内の技術力と責任分担で選びます。RFPには、業務目的、対象範囲、現行環境、Gradle固有の要件を記載します。非機能要件、成果物、受入条件も、あわせて合意しておきます。

発注前に押さえるポイント

費用は、Gradle初期設定、Maven移行、業務システム本体に分けて見ます。データ移行、クラウド、商用サービス、保守運用も、それぞれ別に見積もります。

2026年時点の市場相場は幅が大きく、単一の金額として示しにくいのが実情です。人月単価や工数、対象範囲を揃えて比べ、除外項目と保守責任も同じ条件で並べます。

PoCのKPIでビルド時間、CI費用、失敗率、調査時間の改善を確認します。

発注・外注に向けた次の行動

現状の整理から委託先の選定まで、次の順に進めると発注条件を具体化できます。

  1. JDK、GradleまたはMaven、モジュール数、CI実行時間、依存ライブラリ、運用課題を一覧にし、業務目的と合わせて簡易RFPにする。
  2. Gradleの実績に加えて、業務システムの設計・運用体制も確認できる会社へ相談する。必要ならアセスメントやPoCを先行する。
  3. Wrapper、依存関係検証、CI再現性、脆弱性対応、JDK・プラグイン更新、ソースコード・設定・IaCの引き渡しを確認する。
  4. 要件定義から運用移管まで見通し、責任分担と成果物を明確にして、発注者に判断材料と運用能力が残る契約にする。

発注前に責任分担と成果物を明確にしておくと、追加費用や属人化を防ぎやすくなります。長期的なコストとリスクを抑えることにもつながります。

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

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