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

Webpackを使うシステムの発注は、業務要件の整理、PoC、契約・引き継ぎ条件の合意の順に進めると、運用可能な業務システムにつながります。

発注形態や費用相場、RFP、委託先の選び方も、この流れの中で判断する項目です。全体像はWebpackのシステム開発の完全ガイドもご覧ください。

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

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

Webpackのシステムの定義

「Webpackのシステム」は、Webpackをフロントエンドのビルド工程に組み込んだWeb業務システムを指す実務上の呼び方です。なお、Webpackは業務機能を販売する製品ではありません。

開発会社は、画面やAPI、データベースを作ります。認証と権限、インフラ、テストも担当し、フロントエンドはWebpackでビルドして配信します。

Webpackは業務システム製品ではなくビルド基盤

Webpackは、entryから依存関係をたどり、ブラウザ用のファイルに変換します。対象はJavaScriptやTypeScript、CSSのほか、画像やフォントなどです。

Webpack公式の説明では、ES ModulesやCommonJS、AMDを扱います。アセットも扱います。

loaderを使えば、TypeScriptやSassも処理できます（出典: Webpack公式「Modules」、2026年8月確認）。

• 変換：ファイル種別ごとの処理を、loaderが受け持ちます。
• 追加処理：ビルド時に行う作業を、pluginが担います。
• 業務要件：「営業担当が案件を登録し、上長が承認する」など、画面数ではなく業務の流れで書く内容です。
• 利用範囲：基幹システムとのAPI連携も含め、Webpackを使う範囲を決めます。

導入効果と限界の切り分け

Webpackの効果と、業務側で別途設計が必要な内容は、分けて考える必要があります。

たとえば、管理画面や帳票画面を必要なときに読み込む設計にすると、初回表示の負荷を抑えられる場合があります（出典: Webpack公式「Code Splitting」、2026年8月確認）。

• 最適化：コード分割やtree shaking、minifyを組み込めます。環境別の設定も、あわせて扱えます。
• キャッシュ：更新の扱いを考えたファイル名を設定できます。
• 業務設計：業務フローやAPI品質、DBは、別途対応します。認証認可やバックアップ、現場への定着も、別途対応が必要です。
• 運用の目的：変更しやすく安全で、他社にも引き継げるシステムを目指します。

Webpackのシステムの発注形態

発注形態は、自社に残す設計・判断・運用と、外部に任せる実装や専門作業をどう分けるかで決まります。

SaaSやパッケージで要件を満たせるなら、Webpackで全面開発する必要はありません。一方で、独自業務や高い操作性が競争力になる場合は、カスタム開発を検討します。

SaaS・パッケージ＋部分開発の進め方

勤怠や会計、顧客管理、ワークフローはSaaSやパッケージを使い、足りない申請画面やポータルだけをWebpackで開発します。

標準機能を使えるぶん、初期費用と納期を抑えられます。さらに、法改正への対応もサービス側に任せられます。

発注前に、API公開範囲と認証方式、データ持ち出しの可否を確かめておきます。画面カスタマイズの限界も、あわせて把握します。それが分からないと、部分開発の範囲を決められません。

スクラッチ開発による独自業務のシステム化

承認ルールや料金計算、在庫ロジックを既存パッケージで表せない場合は、スクラッチ開発が候補になります。顧客ごとの権限や複数サービス連携も、判断の材料になります。

ReactやVue、TypeScriptの画面をWebpackでビルドする場合は、業務画面とentry・chunkの単位をそろえます。このため、権限管理や段階リリースを説明しやすくなります。

WebpackとViteの小さなPoCによる比較

Webpackを指定する前に、Viteなど別のビルドツールも同じ代表画面で比べます。

• 開発サーバーの起動とビルド時間
• 初回表示、バンドルサイズ、ブラウザ対応
• CIでの再現性、デプロイ、ロールバック

Webpackは自由度が高いぶん、既存資産や特殊な変換処理を引き継ぐ場面で力を発揮しやすいです。一方で、単純な新規SPAでは、別の選択肢が適することもあります。

Module Federationの複数チームでの段階開発

複数の事業部やプロダクトが独立してリリースしつつ、一つの画面として動かす場合は、Module Federationが候補になります。

Module Federationでは、複数の独立したビルドが実行時にモジュールを提供・利用し、単一のアプリを構成します（出典: Webpack公式「Module Federation」、2026年8月確認）。

• 運用負担：共有ライブラリの版、remoteの可用性、障害時の表示を、あらかじめ確かめておく内容です。
• 責任分界：デプロイの順番と監視の担当を決めます。
• 採用判断：必要なチーム数、更新頻度、障害時の切り離しをRFPに書き、PoCで確かめます。

Webpackのシステム開発を外注する進め方

外注では、発注者と受託会社が判断材料をそろえて、不確実性を減らしていきます。詳細仕様は最初から完璧でなくてかまいません。

ただし、発注者側で目的、利用者、対象業務を整理しておく必要があります。期限と予算上限、既存資産と成功条件も、事前に押さえておきます。

業務棚卸しと目的の共有

まず、業務を棚卸しして、紙やExcel、メール、FAXのやり取りを洗い出します。二重入力や属人的な承認、例外処理も同じように書き出し、なくす対象を決めます。

発注側は、成果を「入力時間を半分」「月末集計は翌営業日まで」「担当者が申請状況を追える」などのように、置き換えて書きます。

業務の整理を後回しにして画面だけ作ると、手作業の混乱をそのままシステム化し、開発後に仕様変更が膨らみがちです。

要件定義での画面・API・非機能要件の決定

要件定義では、画面数だけでなく、機能の詳細と技術条件を発注先に伝えます。Webpackに関わる部分では、Node.jsとWebpackの版、package manager、lockfileを確かめます。

loader・plugin方針とsource mapの扱いも決めます。成果物の保存先、CI/CD、バンドルサイズ上限も、この段階で決めておきます。

• 業務機能：利用者と権限、業務フロー、画面を整理します。入力項目、帳票、APIも書き出します。
• 運用条件：保持期間、同時利用者数、ブラウザを定めます。表示速度や復旧時間も決めておきます。監査ログ、バックアップ、移行範囲も含みます。
• ビルド環境：Webpackの設定と成果物の条件を決めます。
• 見積条件：検索やCSV、権限、承認で工数が変わります。APIタイムアウトや履歴も影響します。画面数が「10枚」と分かっても、見積の前提は定まりません。
• 未確定事項：一覧にして、調査、PoC、追加見積のどれで決めるかを記録します。

代表画面のPoCと概算見積

不確実性が大きい案件では、代表画面1〜3枚のPoCや要件定義から始めます。

• 対象画面：ログインや検索・一覧、登録・承認など、難所を含む画面を選びます。
• 確認項目：Webpackのビルド時間やバンドルサイズ、キャッシュ、CI、デプロイ、ロールバックを確かめます。
• 契約への記載：PoCの成果物と、本開発への引き継ぎ条件を、契約書に記載します。

画面選びでは、APIエラーや権限別表示も対象になります。

開発・移行・リリースの段階的な進め方

開発と移行、納品、リリースの確認事項は、段階ごとに決めます。

API契約や画面設計を並行して進め、DBやテスト、権限、監視も同時に進めます。移行時は、マスタの重複や欠損、表記ゆれを確認し、移行の対象とデータのクレンジング、リハーサル、切り戻し条件を決めます。移行後の業務上の正しさは、発注者が判断します。

部門限定、並行稼働、段階展開でリリースする方法もあります。納品では、ソースコードやpackage.json、lockfileに加えて、Webpack設定とNode.js版、CI/CD、テスト結果も受け取ります。インフラ設定や操作マニュアル、障害対応手順、SBOMの有無も確認します。

Webpackのシステム開発の契約形態

契約形態は、要件の確定度と変更リスクで選びます。成果物と納期を合意できる範囲は請負契約、要件定義や調査のように作業内容が変わる範囲は準委任契約が候補になります。

契約名だけでは中身が決まらないため、成果物や検収の条件、変更管理、責任分界は、契約書の文面で確かめておきます。

請負契約の完成物と検収条件

請負契約では、合意した成果物を受託会社が完成させ、発注者が検収します。検収の条件には、画面動作や本番ビルド、対応ブラウザを含めます。さらに、バンドルサイズやエラー時の挙動、テスト結果も入れます。

ソースコードと設定ファイルも納品対象に含めます。そうすれば、設定不足や本番ビルドの失敗を防げます。

準委任契約が向く要件定義と継続改善

準委任契約では、合意した期間と体制で専門家が業務を遂行します。たとえば、Webpack設定の解析や依存更新、要件定義は、調査で次の作業が変わる領域です。

PoCや運用改善も、こうした領域に含まれます。ただし、時間を使うだけの契約にならないよう、週次成果物と課題一覧、意思決定記録を定めます。稼働予定と品質指標も、あわせて決めておきます。

変更管理と知的財産の帰属

変更時の手続きと、開発物の権利や契約終了後の扱いを定めます。

• 変更対象：追加画面や権限、APIは、費用と納期に影響します。ブラウザやModule Federationを変える場合も、費用と納期に関わります。
• 変更記録：要求票に、目的や影響、追加工数を書きます。納期と承認者も含めます。
• 契約形態：要件定義を準委任、本開発を請負に分ける方法もあります。
• 権利・引き継ぎ：コードや設定ファイル、CI/CDを確認します。テストや設計、画像・デザインも確かめます。OSSや再委託、終了後の扱いも対象です。
• OSS条件：WebpackはMITですが周辺パッケージの条件は異なるため、OSS一覧を納品物に含めます（出典: npm「webpack」、2026年8月確認）。

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

WebpackはMITライセンスのオープンソースで、通常はライセンス購入費がかかりません。費用の中心は、業務要件や画面・API・DB、認証認可です。

テストやインフラ、移行も費用に含まれます。教育や保守も、あわせて見込みます。

2026年の公開相場では、小規模自動化ツールは10万〜100万円、単一業務システムは100万〜500万円です（出典: Cataly Design「業務システム開発の費用相場」、2026年）。

複数業務を統合する基幹システムは、1,000万〜3,000万円以上が目安です（出典: Cataly Design「業務システム開発の費用相場」、2026年）。

規模別の費用レンジ

下のレンジは、公開相場に設定・移行・CI作業を加味した推定で、Webpack単体の価格ではありません。

金額は、要件や画面数、外部連携の有無で変わります。利用者数やセキュリティ、既存資産の状態によっても変わるため、初期の予算の目安として使います。

• ビルド基盤整備・移行：既存SPAに、Webpack 5とTypeScriptを導入し、LintとCIを組み込みます。
• 小規模業務Webシステム：ログインと権限、一覧・検索・登録、API連携を含みます。費用は150万〜500万円程度です。
• 中規模ポータル：帳票とファイル、監査ログを含みます。外部SaaS連携も含め、500万〜1,500万円程度です。
• 大規模案件：SSOや複数システム統合、移行を含みます。

ビルド基盤整備・移行は、画面追加が少なければ、30万〜100万円程度です。大規模案件は、Module Federationや可用性設計も含むと、1,500万〜5,000万円以上の可能性があります。

見積書での工程とWebpack固有作業の区分

工程別の費用とWebpack固有の作業を分けて、各社の前提を比べます。

• 見積区分：要件定義と設計、開発に分けます。テストや移行、教育も区別し、導入と保守も別にします。
• 工程配分：要件定義10〜15%、基本設計15〜20%、詳細設計10〜15%を目安にします。
• 工程配分：開発・単体テスト30〜40%、結合・総合テスト15〜20%、移行・導入5〜10%が目安です。
• Webpack作業：設定解析やloader・plugin更新、バンドル分析を分けます。互換性やコード分割、source mapも、分けて書きます。
• 運用作業：CIキャッシュや成果物保管は、分けて書きます。ロールバックや脆弱性確認も、分けます。一式の中に隠れると、別請求になり得ます。

初期費用と分けた保守・運用費

保守費の割合は、含まれる作業と更新時期を契約で明確にしてから参考にします。

• 年間費用：初期開発費の15〜20%程度が目安です（出典: 2026年公開のシステム保守費用相場情報、複数社）。
• 変動要因：Webpack等の更新や脆弱性対応、監視で変わります。SLAや夜間対応、追加開発、クラウド費用も影響します。
• 契約範囲：問い合わせや障害修正、軽微改修を明記します。更新や調査、バックアップも、範囲に含めます。監視と月次報告も、契約書に入れておきます。
• 更新時期：後回しにすると、Node.jsやブラウザの変更時にまとめて対応することになり、単発の費用が高くなる場合があります。

RFP・要件整理で発注先に伝える内容

RFPは、開発会社から同じ前提で提案と見積を受けるための依頼書です。業務目的と対象、利用者、既存システムを書き、制約や時期も伝えます。予算や成果物、評価基準も、まとめておきます。

Webpackの採用が未決定なら、Webpackを含む代替案と採用理由も、提案してもらいます。

RFPの業務目的と対象範囲

業務範囲と品質条件を具体的に示し、提案と見積の前提をそろえます。

• 業務範囲：フローや課題、部門、利用者数を記載します。権限や画面・帳票・通知、連携を書きます。移行や運用、希望時期も盛り込みます。
• 業務ルール：顧客申請なら差し戻しや代理申請を示します。添付や通知失敗、取消、監査ログの扱いも、示しておきます。
• 非機能要件：同時接続や応答・稼働時間、バックアップを含めます。復旧目標やログ、個人情報も書きます。SSOや端末、アクセシビリティ、脆弱性診断も必要です。
• 法令・規程：業務に関わる法令や社内規程を、RFPの前提として示します。

会計・請求・顧客情報を扱う場合は、個人情報保護法や取引先のセキュリティ要求を確認します。必要に応じ、電子帳簿保存法やインボイス制度への対応も確かめます。

Webpackと開発基盤の要件

技術要件と納品物を具体化しておくと、開発後の保守を別の会社へ移しやすくなります。資料が不足すると、再調査の費用がかさみ、特定の会社への依存（ロックイン）も起きやすくなります。技術構成には、Node.jsやpackage manager、ブラウザ、ビルド環境も含めます。

納品物には、ソースやpackage.json、lockfileを含めます。Webpackやインフラの設定、CI/CDも、納品対象です。

環境変数や手順書、障害連絡先も指定します。OSS一覧も、あわせて求めます。

• 技術構成：フレームワークとTypeScript、Webpackの採用理由を記載します。
• 配信基盤：CI/CDやホスティング、環境変数を決めます。source mapやキャッシュ、成果物名の扱いも定めます。依存管理と更新責任も、決めておきます。
• 設計・試験資料：要件定義書、画面・API・DB設計、テスト仕様・結果を受け取ります。
• 実装・運用資料：コードと運用に必要な設定・手順を受け取ります。
• 移管性：可能であればSBOMも含めます。

提案評価の基準

提案は、業務理解や要件の漏れ、Webpackの必然性で評価します。代替案や設計・テスト、セキュリティも、評価の項目にします。移行や保守、引き継ぎ、担当者の経験も、同じ基準で見ます。

極端に安い場合は、要件定義やテスト、移行が含まれているかを確認します。監視や脆弱性対応も含まれるかを確かめます。高い場合は、過剰な提案になっていないかを確かめます。

委託先の選び方と見積比較

委託先は、Webpackを使えるかに加えて、要件定義から運用まで担えるかで選びます。

公開情報から個別案件の品質や実績は判断しきれないため、質問で確かめます。Webpack 5やNode.js、lockfile・CI・SBOMについて尋ねます。脆弱性対応や障害時の分担も、質問に含めます。

自社の規模と業務に合う会社

案件の規模や既存資産に合う体制と、提案時の説明の具体性を確認します。

• 大規模・複数部門：管理やセキュリティ、インフラを確認します。保守体制も見ます。
• 小〜中規模：React・Vue・TypeScriptの設定やテストを説明できる会社を選びます。
• 既存システム移行：古いWebpack設定、依存、ビルド手順を読める担当者がいるか確認します。
• 初回面談：現行課題を聞くか、すぐ定型パッケージを勧めるかを見ます。
• 説明の姿勢：前提や未確定事項、調査方法が明確なら、後工程を予測しやすくなります。追加費用の条件も、あわせて確かめます。

3社以上への同じRFPによる比較

同じ条件で見積を集め、総額と作業範囲の差を分けて比較します。

• 依頼条件：可能なら3社以上へ同じRFPを渡し、回答期限と質疑方法をそろえます。
• 範囲と費目：開発範囲や画面・API・帳票数、要件定義を比べます。テストや移行・教育、保守期間も、対象にします。
• 契約条件：クラウドやライセンス、再委託を確認します。納品物と追加変更の単価も、そろえて見ます。
• 工程別比較：要件定義や設計、開発に並べ替えます。テストや移行、導入、保守も、同じ順に並べます。
• Webpack項目：設定や依存更新、CI/CDが含まれなければ、別見積にします。source mapとサイズ計測も、含まれるかを確認し、価格差の理由を聞きます。

npm依存と本番情報の安全管理

ソースコードに加えて、npm依存とCI権限の安全管理も、委託先と決めておきます。

OWASPは、lockfileの固定やnpm ci、ライフサイクルスクリプトの制御を推奨しています。

OWASPは、依存監査やSBOM生成、成果物署名も推奨しています（出典: OWASP「NPM Security Cheat Sheet」、2026年8月確認）。

• 依存対策：依存パッケージとビルド成果物の安全性を管理します。
• CI権限：CIトークンは最小権限にし、package.jsonとlockfileは同時に管理します。
• 更新管理：スキャン頻度と対応期限、承認済みパッケージを決めます。npm二要素認証や依存更新の検証担当も、あわせて決めます。
• 本番情報：秘密情報は成果物から外します。環境変数はリポジトリに保存せず、source mapも公開しません。

Webpackのシステム発注で起きやすい失敗と対策

失敗は、Webpackの知識不足に加えて、要件の曖昧さや責任分界の不足、移行漏れが重なって起きます。運用設計の後回しや納品物の不足も重なると、納期遅延や追加費用につながります。

発注前に失敗例を確認し、その内容をRFPと契約に反映します。

ビルド環境のブラックボックス化

担当者のPCでビルドが成功しても、別の環境やCIでは失敗することがあります。

• 版の固定：Node.jsやWebpack、loader・pluginの版を固定します。package managerの版も含めます。
• 納品対象：lockfileや実行コマンド、環境変数を含めます。OS・コンテナ条件や成果物も、対象に入れます。
• 検収：引き継ぎ担当者がクリーンな環境で再ビルドできることを確かめます。

巨大なバンドルと本番キャッシュの失敗

ライブラリを一つのJavaScriptに詰め込むと、初回表示が遅くなります。更新時にキャッシュが効かない場合もあります。

画面単位のコード分割や依存削除を設計します。ファイル名のcontent hashやgzip・Brotli、バンドルサイズの閾値も、設計に含めます。

代表端末と実データで計測します。数値目標がないと、ビルドが成功しただけで完了しがちです。

移行漏れとベンダーロックインの防止

移行データと、契約終了後に他社へ引き継ぐ条件を、漏れなく決めます。

• 移行対象：顧客・商品マスタや過去履歴を確認します。権限と添付ファイルも、対象に含まれるかを見ます。
• 移行手順：件数や変換ルール、除外データを決めます。リハーサルや照合、切り戻しも、流れの中に入れます。
• 正確性確認：業務責任者が移行データを確認する日程を確保します。
• 引き継ぎ：コードやWebpack設定、lockfileを受け取ります。CI/CDやインフラ、テストも対象です。OSS一覧と運用手順も、あわせて受け取ります。
• 契約終了時：データの返却や、リポジトリ権限、クラウド名義を合意します。再委託先からの回収や、引き継ぎ期間と費用も決めます。

よくある質問

発注では、技術の選択に加えて、費用や契約、保守、移行も確認します。よくある質問に答えます。

Webpackの導入だけならいくらかかりますか？

Webpackはオープンソースのため、通常はライセンス購入費がかかりません。費用がかかるのは、設定や既存コードの解析、loader・plugin整理です。CI、テスト、移行の作業も、費用に含まれます。

既存SPAのビルド基盤整備だけなら30万〜100万円程度の推定レンジです。画面やAPI、認証、インフラを含めると、業務システムの規模別の費用になります。

WebpackとViteのどちらを発注すべきですか？

既存資産や複雑なloader・plugin、詳細な出力制御が重要なら、Webpackが候補です。Module Federationが重要な場合も、Webpackが候補に挙がります。

新規の小規模SPAで開発体験や起動速度を優先する場合は、Viteが適する可能性もあります。

代表画面のPoCでは、ビルド時間やバンドル、ブラウザを比べます。CI、運用負荷も比べ、採用理由をRFPと設計書に残します。

開発会社から何を納品してもらえばよいですか？

要件定義書、設計書、テスト仕様・結果を受け取ります。ソースコードやpackage.json、lockfileも納品対象です。Webpack設定やNode.jsの版、CI/CD定義も、受け取る対象になります。

環境変数一覧やインフラ設定、マニュアルが必要です。運用手順やOSS一覧も、あわせて求めます。

依存脆弱性への対応を重視するなら、SBOMやスキャン結果を含めます。対応期限や更新手順も、納品と保守の範囲に入れます。

Webpackに詳しくない会社へ発注しても問題ありませんか？

Webpack実績を公開していなくても、React・Vue・TypeScript開発とビルド基盤を説明できれば候補です。設定やテスト、CI/CD、保守を納品できるかを確認します。

Webpack 5や依存管理、バンドル分析を、提案段階で確認します。source mapや脆弱性対応、障害時の担当者も、同じ段階で見ます。

技術力に加えて、業務理解と引き継ぎ姿勢も比べます。

まとめ

発注では、Webpackの導入費だけでなく、業務システム全体の見積を取ります。業務要件や画面・API、認証を、その範囲に含めます。移行やテスト、インフラ、保守も、対象に入れます。

Webpackは依存関係を解決し、loaderやpluginで資産を変換し、コード分割や最適化を行うビルド基盤です。ただし、業務成果には、Webpackと業務システム全体を適切に設計・運用する体制が必要です。

発注前に押さえる要点

発注形態は、業務の独自性と変更頻度で選びます。RFPには、目的や対象、非機能要件を書きます。

WebpackやNode.js、依存管理、CI/CDも書きます。納品・保守・移行、評価基準も、RFPに含めます。

3社以上へ同じ条件で依頼し、費用レンジは目安として使いながら、要件と前提の差を比べます。

次に行うこと

業務の棚卸し、技術検証、契約条件の合意の順で準備を進めます。

1. 現行業務を棚卸しし、代表画面・API・移行データを一覧にします。
2. Webpackを採用する理由と代替案を整理し、PoCまたは要件定義で不確実性を減らします。
3. 契約と検収の条件を合意します。ソースコードやlockfile、CI/CDは、引き渡し方法を決めます。SBOMと脆弱性対応、引き継ぎも決めて、本開発へ進みます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【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を創業。