テスト自動化ツール開発の発注/外注/依頼/委託方法について

テスト自動化ツールの発注は、現状診断、対象選定とPoC、実装と連携、運用移管の順に進めます。この流れで進めると、品質確認を開発チームの日常に定着させやすくなります。

発注形態や要件整理、契約、費用相場、委託先の選び方を順に扱います。全体像は、テスト自動化ツール開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・テスト自動化ツール開発の完全ガイド

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

テスト自動化ツールの発注・外注の全体像

テスト自動化ツールは、テストケースを再実行できる形で定義し、画面操作、API呼び出し、データ投入、結果判定を繰り返すソフトウェアやクラウドサービスです。

スクリーンショットや動画などの証跡を保存する機能も持ちます。

外注では、ツールの選定だけでなく、テスト設計や自動化コードも依頼できます。

CI/CD連携、レポート、保守手順の整備も、一体で任せられます。

内製・外注・併用の使い分け

内製・外注・併用の選び方は、社内の経験と必要な導入速度によって変わります。主な違いは、ノウハウがどこに蓄積されるかと、初期設計を誰が担うかです。

• 内製：コードを自社の資産として育てられ、変更の意図を反映しやすい方法です。
• 外注：専門知識や複数ブラウザ・実機環境を、短期間で取り入れやすい方法です。
• 併用：初期設計とPoCを外注し、標準化したあとのテスト追加を内製する進め方です。

内製には、フレームワーク設計やCI/CD設定、失敗原因の切り分けの経験が必要です。一方で、併用はノウハウと導入速度のバランスを取りやすい進め方です。

発注範囲の定義

発注範囲は、契約から保守まで工程ごとに分けて定義します。

成果物ごとに、納品後の操作範囲も確認します。

• 設計・実装：対象ケースとブラウザを指定し、データと実行環境も決めます。
• 運用準備：CI/CDとレポートを含め、教育や保守手順も決めます。

見積書に「自動化一式」とだけ書かれていると、ケース数やブラウザ数が曖昧なままになります。その結果、あとから追加費用が生じやすくなります。

発注形態の選び方

短期間で効果を確かめたいなら、SaaSや小規模PoCが候補になります。また、既存システム固有のAPI・バッチ・権限を扱うなら、OSSと受託開発の組み合わせも候補になります。

パッケージ・SaaSを選ぶケース

複数ブラウザやモバイル実機を検証する場合は、クラウド実行基盤を使うと、端末環境の維持負担を抑えられます。

候補を比べるときは、料金だけでなく契約条件も確認します。

• BrowserStack Automate：一部のプランは、年払いで月額59米ドルです。
• Large Team：表示価格は月額99米ドルです。

1ドル150円で単純換算すると、月額およそ9,000円から1万5,000円程度になります。ただし、金額は並列数や実機、ユーザー数で変わります。企業契約や為替によっても変動し、エンタープライズは個別見積もりです。

データの保管場所と接続方式を確認し、ログの保存期間やサポート範囲も見ておきます。

OSSとスクラッチ開発を組み合わせるケース

Selenium、Playwright、Cypressなどのほか、AppiumやJUnitも、ライセンス料をかけずに始められます。

ライセンス料が0円でも、運用の人件費は発生します。

• 必要な作業：テスト設計と共通部品の作成に加え、認証とデータ生成にも人件費がかかります。
• 継続運用：CI環境を保ち、ブラウザ更新や失敗テストの修正を担います。

社内システムを横断して検証する場合は、自社向けの実行基盤で柔軟性を確保できます。

対象には、APIやバッチのほか、ERPや外部連携も含まれます。

設計・実装・運用を分けて発注するケース

要件が未確定なら、まず現状診断とPoCを発注し、効果と保守性を確かめてから本開発へ進みます。

分業する場合は、担当範囲を事前に合意しておく必要があります。

• 設計・実装：専門の会社へ依頼できます。
• ケース追加：社内で担う方法があります。
• 実機環境：クラウドサービスへ委託できます。

障害時にアプリ、テストコード、実行環境のどこを誰が一次切り分けするかは、契約と手順書に明記します。

自動化対象の決め方

自動化の対象は、頻度が高く判定が明確なテストから選びます。手動テストのすべてを置き換える必要はありません。仕様が比較的安定し、失敗時の業務影響が大きいものが候補になります。

たとえば、回帰テストやログインが該当します。権限別の主要操作や、注文や申請の代表的な業務フローも該当します。

頻度・判定・影響の3点による優先順位

まず候補を洗い出し、月に何回実行するか、機械で判定できるかどうかを点数で評価します。そのうえで、失敗したときに売上、顧客、業務継続へどれだけ影響するかも評価します。

判断の基準をそろえておけば、委託先の提案も効果の順に比べられます。

• 自動化候補：毎週のリリースで行う注文登録テストです。
• 手動に残す候補：文言の自然さを見る探索的テストです。

ケース数を増やす提案が出たときも、明文化した優先順位に照らして評価できます。

画面に加えたAPI・バッチ・権限の対象候補

E2Eテストは成果が見えやすい一方で、遅く、画面変更の影響も受けます。

テストは、レイヤーごとに役割を分けて構成します。

• 画面：主要なシナリオを、少数のE2Eでつなぎます。
• API・データ：APIのステータスや応答、データベースの更新を検証します。
• バッチ・権限：夜間バッチの結果と、管理者・一般・承認者の権限を検証します。

下位レイヤーの検証は、画面操作よりも速く安定しやすいものです。

この構成をRFPに示すこともできます。

PoCで試す成功系・異常系・権限違い

PoCは、代表的な成功系、異常系、権限違いを含めて実施します。簡単な1ケースだけで終えると、確かめられる範囲が狭くなります。確認項目を記録しておくと、導入の可否を判断できます。

• 実行品質：実行時間と初回成功率を記録します。
• 保守性：原因特定時間と変更後の修正量を見ます。
• 報告品質：レポートの分かりやすさを確認します。

リサーチノートの推定レンジは、5〜15ケースで50万〜150万円、期間は2〜4週間です。相場は全国共通の数字ではないため、環境と成果物を定めて個別に見積もりを取ります。

RFP・要件整理で伝える内容

RFPで伝えるのは、ツール名よりも、業務課題と納品後に達成したい状態です。ケース数やリリース頻度、手動工数を示し、システム構成や環境、データ制約も書きます。

CI/CD、セキュリティ、運用担当者も記載しておけば、各社の提案条件をそろえられます。

• 業務状況：ケース数、リリース頻度、手動工数を示します。
• システム構成：環境、データ制約、CI/CDを記します。
• 運用条件：セキュリティ要件と担当者を明記します。

現状のテストとシステム構成の棚卸し

棚卸しは、構成、運用、既存資産に分けて進めます。

既存コードは、再利用する案と、全廃して作り直す案を比べます。

• 構成：フロントエンドやAPI・バッチを確認し、認証と外部連携も見ます。
• 環境：ブラウザや端末、リリース頻度、テスト管理方法を整理します。
• 資産：手動時間と月間の実行回数、頻出する不具合、Selenium等を調べます。

Playwrightなどの既存コード資産も、段階的に移行できるかを決める材料になります。

ケース数と合否条件による機能要件

機能要件では、対象業務とテストレベルを定義します。ブラウザ・OS・実機と並列数も決めます。加えて、データの作り方と合否判定を決め、画像・動画・トレースの保存先や通知先も含めます。

「主要画面」とだけ書くと、対象の範囲が曖昧になります。

• 注文登録：正常系10ケースを対象にします。
• 入力エラー：異常系5ケースを含めます。
• 権限差：承認者と一般利用者の期待結果を示します。

ケースの種類と期待結果まで書いておけば、見積もりと受入判定の前提がそろいます。

非機能・セキュリティ要件の記載

非機能要件とセキュリティ要件は、実行、記録、保護の3つに分けて書いておきます。

• 実行：時間、並列数、可用性、失敗通知を決めます。
• 記録：ログ期間、監査証跡、保存地域を指定します。
• 保護：社内接続、秘密情報、権限を明記します。

本番データをコピーして使う場合は、個人情報のマスキングとテスト用アカウントの権限を定めます。

認証情報をどこに保管するかも、明確にしておきます。

機能テストは脆弱性診断の代わりにはならないため、必要な基準と専門家の役割を別に定義します。

請負と準委任の使い分け

契約には、要件が固まった成果物の納品と、専門家の伴走が混在します。そのため、何を完成品とみなすか、作業時間に対して支払うか、仕様変更をどう扱うかを確認します。

検収と保守の境界は、法務・調達部門とともに、契約条件に沿って決めます。

請負契約が向く範囲

請負は、範囲と成果物、完成条件を定義できるPoC後の構築やケース実装に向いています。その際は、成果物と変更条件を明確にします。

• 成果物：ソースコード、テスト設計書、ケース一覧を含めます。
• 環境：構築手順、CI設定、データ生成スクリプトが対象です。
• 引き継ぎ：実行レポートと引き継ぎ資料も対象にします。

画面仕様が頻繁に変わる案件では、追加費用と納期調整のルールを先に定めておきます。

準委任契約が向く範囲

準委任は、診断や選定、PoC評価に適しています。改善や内製化支援にも向いています。

新しい画面や仕様が増え続ける案件では、支援時間と役割、報告方法を定めます。

• 支援時間：月ごとの稼働時間を決めます。
• 体制：職種や定例会、報告方法を定めます。
• 対応：対応時間帯を明確にします。

指定Q&Aでは、業務システム開発の傾向として、請負が準委任より1.3〜1.5倍高い場合があるとされています。これは一般的な目安で、テスト自動化案件の価格を保証するものではありません。

混合契約による段階的な進め方

段階ごとに契約を分けると、未検証の技術や範囲を固定価格で抱え込まずに進められます。

• 診断・PoC：準委任で実施します。
• 初期構築：標準基盤とケース実装を請負にします。
• 運用・追加：保守とケース追加を準委任にします。

各段階には、終了条件と次へ進む基準を定めます。中止した場合の成果物やソースの引き渡し条件も、決めておきます。

発注後の開発・導入の順序

工程は、次の順に進めます。

各工程の移行条件を決め、件数だけでなく安定性と保守性を確かめます。

全機能を一度に扱うと、失敗の原因がツール、データ、アプリのどれにあるか分かりにくくなります。

1. 現状を分析して、自動化の対象を選びます。
2. PoCで効果と保守性を検証します。
3. 共通基盤を設計し、ケースを実装します。
4. CI/CDへ連携し、運用を移管します。

共通部品とテストデータの先行設計

ケースを増やす前に、画面部品と共通処理をそろえておきます。画面部品はPage Objectなどで、共通処理にはAPIクライアントやログイン処理が入ります。共通フィクスチャや待機・再試行方針も、そろえる対象です。

• 基盤：環境変数と失敗時の証跡保存を標準化します。
• データ：ケースごとに作成・初期化できるようにします。

個人情報は匿名化し、認証情報をコードやログに出さないことを、受入の条件にします。

CI/CDの実行タイミングと失敗通知

CI/CDでは、速度と目的に応じて、テストの実行タイミングを分けます。通知がすべて同じだと、製品の不具合、テストの不安定さ、環境の障害を区別できません。

• プルリクエスト時：高速なスモークテストを行います。
• 夜間：回帰テストを実行します。
• リリース前：総合テストを実施します。

通知には、環境とケース、ログを含めます。画像や動画、トレース、担当者も入れると、再現と一次切り分けにかかる時間を短くできます。

運用移管と効果測定による定着

運用では、追加、修正、ブラウザ・OS更新の担当を決めておきます。

効果と安定性は、月次で測ります。

• 自動化ケース：件数と成功率を記録します。
• 安定性：フレーク率と原因特定時間を測ります。
• 工数：手動回帰の削減時間を確認します。

BrowserStackのCarousell事例では、リリースごとの手動回帰が約35時間から約5時間になったと説明されています。ただし、これは公表された事例で、自社で同じ成果を保証する数字ではありません。

効果は、自社の実行頻度と工数をもとに測定します。

テスト自動化ツールの費用相場

費用は、ライセンス料よりも対象ケース数やシステムの複雑さで大きく変わります。

テストデータやブラウザ・実機、CI/CDも影響します。加えて、セキュリティや保守体制も費用に関わります。

以下に示すのは、業務システム開発の単価と対象範囲から算出した推定レンジで、定価ではありません。

PoCから大規模導入までの初期費用の幅

初期費用は、ケース数と対象システムの規模に応じて幅があります。規模ごとの推定レンジを、PoCから大規模までの4区分で示します。

• PoC：5〜15ケースでツール評価と代表画面を確認し、50万〜150万円です。
• 小規模：Web回帰20〜50ケースとCI連携で100万〜300万円です。
• 中規模：100〜300ケースで300万〜800万円です。
• 大規模：ERP・基幹等を含む場合、800万〜2,000万円以上の可能性があります。

中規模では、APIや画面を扱い、テストデータや複数ブラウザも対象になります。

大規模では、実機や外部連携が対象に入ることがあります。

権限や性能、運用設計まで含む場合もあります。

金額は全国共通の一律の数字ではありません。

ケース数に加えて、既存資産とデータ制約を見積もりに反映します。

ツール利用料と実行環境の費用

OSSはライセンス料が発生しない場合がありますが、実行環境や運用の費用は必要です。SaaSでは、利用量や追加機能を確認します。サポートやデータ保管も見ておきます。

• OSS：CIランナーやコンテナ、実機が必要で、ログ・動画の保存や監視、保守要員も含みます。
• SaaS：ユーザー数や並列数、実行回数を確認し、実機や追加機能、サポートも見ます。

mablの公式価格ページでは、クラウド実行は月500クレジットからです。

クレジットは、ブラウザやモバイルUI、APIの検証で共有されます。

性能やアクセシビリティの検証も、同じクレジットを使います。

ローカル実行は無料です（出典：mabl Pricing、2026年確認）。

定価を公開せず個別見積もりとするサービスもあるため、見積もりを依頼する際は月間の実行回数を提示します。

保守費と追加開発費

構築後も、画面やAPIの変更、ブラウザの更新が続きます。

データの更新やCIの変更、失敗の調査も発生します。

保守と追加開発は、別々に見積もります。

• 保守費：初期費用の年20〜40％を仮置きする場合があります。
• 追加開発：新機能や性能・セキュリティの検証、実機の増加を分けて見積もります。

保守費は、変更の頻度とSLAによって変わります。見積もりでは、月間の想定時間と超過単価を確認します。

見積書を比較する観点

見積もりは、金額が安いからといって最良とは限りません。ケース数が少ない場合もあるためです。

データ作成やCI/CD、失敗調査が別料金だと、運用後の費用が増えます。

同じRFPを各社へ渡し、見積もりの項目をそろえて比べます。費用は、いつ発生するかで3つに分けて比べます。

• 初期費用：構築、ライセンス、環境を、項目ごとに分けます。
• 継続費用：保守、追加変更、教育を確認します。
• 終了費用：契約終了時の引き渡し費用を聞きます。

工数・単価・前提条件の内訳

見積もりは、プロジェクト管理やテスト設計、基盤設計を分けて見ます。コードやデータ、環境構築も分けておきます。

CI/CDやレポート、教育、保守も内訳に含めます。そのうえで、工数と担当、対象範囲を確認します。

• 工程：設計と実装、環境、CI/CD以降の作業を分けます。
• 工数：人月・人日、役割、レビュー回数を聞きます。
• 前提：ケース数やブラウザ、並列数を確認し、レビュー回数も聞きます。

業務システム開発の人月単価は、80万〜120万円程度が目安とされています。ただし、専門性や会社規模、契約によって変わるため、自動化案件にそのまま当てはめることはできません。

PoCで比べる提案の品質と保守性

提案の価値は、自社環境で再現できるか、内製担当が理解できる設計かで比べます。可能であれば、各社に同じ代表ケースで短い有償PoCを依頼します。

• 実装：見た目に依存しないセレクタで、部品を再利用できるかを見ます。
• データ：テストデータを初期化できるかを見ます。
• 結果：証跡、実行時間、成功率、修正量を比べます。

営業資料に書かれたケース数よりも、レポートと保守性を重視します。

所有権・SLA・撤退条件

成果物の権利、障害対応、契約終了時の扱いは、契約に含めます。また、ベンダー独自のサービスから移行できる形式かどうかも確認します。

• 所有権：コード、設計、データ生成、設定、履歴、レポートが対象です。
• SLA：応答、調査、修正、ブラウザ更新への対応。
• 撤退：漏えい報告、削除、引き渡し、移行形式。

コードが委託先のリポジトリだけにあると、契約後に自社で保守できなくなります。

委託先の選び方

委託先は、ツールの知名度だけでなく、対応範囲や業務システムの経験を確認して選びます。

CI/CDやセキュリティへの理解は、選定の材料になります。内製化支援や失敗時の体制も、確認しておきます。

候補には、テスト専門会社や総合SIerがあります。ツールベンダーやクラウド実行基盤会社も候補になります。まず、困っている工程と任せたい工程を分けて、候補を絞ります。

業務システムと対象技術の実績

Web画面が中心の案件と、ERP・基幹・バッチ・外部連携を含む案件では、必要な経験が異なります。公開されているサービスの範囲と、自社案件での実施体制も確かめます。

• 実績：業界、類似構成、テストレベルを尋ねます。
• 技術：ブラウザ、データ、CI/CD連携を確認します。
• 移管：運用体制と引き継ぎ後の支援を聞きます。

SHIFTは、計画や実現可能性調査、基盤導入を掲げています。テスト量産やCI、保守、スキル移転も打ち出しています。個別案件での実施体制は、別に確認します。

会社ごとの役割

ここで挙げる会社の公開情報は、役割を理解するための例です。価格や適合性の順位を示すものではありません。

• NTTデータ先端技術：UFT系、Selenium、Sahi等を扱います。
• NTTデータ：大規模SIや基幹接続、AIテスト情報を公開しています。
• NTTアドバンステクノロジ：検証や環境管理の自動化を扱います。

問い合わせの際は、実装と品質保証の担当を分けて聞きます。保守窓口や内製化支援も、それぞれ確認します。

AI対応の評価観点

2026年には、AIで計画やコード生成、失敗の要約や修復を支援するサービスが増えています。そのうえで、生成内容と運用を統制できるかを評価します。

• Playwright Test Agents：planner、generator、healerを紹介しています。
• DevCond.AI：SCSKは、成果物・履歴の管理と統制を取り上げています。

Playwrightの公式リリースノートは、Test Agentsを紹介しています（出典：Playwright Release notes、2026年確認）。

SCSKは2026年発表のDevCond.AIで、要件定義から保守まで、AI活用を打ち出しています。

成果物や履歴の管理、セキュリティとガバナンスも掲げています（出典：SCSK「AI駆動型開発基盤 DevCond.AI の導入開始」、2026年）。

AIの期待結果や権限の境界、個人情報を含むデータは、無条件に信頼しない前提で扱い、レビューと監査の仕組みを確認します。

発注・外注で起きやすい失敗と対策

失敗は、ツールの選定より、目的や運用条件を決めないままケース数を増やすことで起こります。

短縮したい作業や保守担当、使うデータを、事前に合意します。失敗を調べる時間も、あらかじめ決めておきます。

見るべきは自動化率よりも、変更に耐える設計と、定着までの体制です。

全件自動化と壊れやすいテスト

画面操作だけで全件を自動化すると、実行時間が延びます。レイアウトの変更で多数が失敗することもあります。対象の層とセレクタを選びます。

• 安定化：役割やテスト用属性、API状態を使います。
• 手動で継続：探索的テストや体験評価を残します。
• 自動化：回帰や明確に判定できる処理を選びます。

画面の文言や位置に依存するセレクタは避けます。

失敗テストの所有者

失敗を放置すると、重要な不具合を見逃します。そのため、原因の区分と、調査・修正・再発防止の担当を定めます。

• 原因分類：製品、コード、データ、環境、偶発的な揺れ。
• 定期確認：揺れの割合と再実行後の成功率を、月次で見ます。
• 契約範囲：調査、修正、再発防止、廃止判断を含めます。

再実行だけで済ませず、一次切り分けの担当と期限を決めます。

個人情報とセキュリティ検証の別管理

本番データや認証情報を使う場合は、データ保護と委託先の管理を定義します。

• データ：匿名化、ログのマスキング、保存・削除期間。
• アクセス：最小権限、秘密情報、再委託先を確認します。

OWASP ASVS 5.0.0は、2025年5月公開の版です。Webアプリの検証観点を整理する基準として使えます（出典：OWASP Application Security Verification Standard、2025年）。

機能回帰と脆弱性診断は、目的が異なります。そのため、調達仕様では必要な検査と証跡を、レビューや是正確認とは別に定義します。

よくある質問

発注の前後によくある疑問に答えます。扱うのは、費用や外注範囲、保守、契約、ツール選定です。

テスト自動化ツールだけを購入すれば外注は不要ですか？

必ずしも不要とはいえません。導入後も、対象選定や設計を担う人が必要で、データやCI/CD、保守の担当も欠かせません。

社内に経験者がいれば、ツールだけを導入することもできます。初期診断やPoCだけを専門会社に頼む方法もあります。

発注費用にはどこまで含めるべきですか？

初期から運用までの費用を項目ごとに見積もり、別料金になる条件を確認します。

• 初期：診断やPoC、設計、コード、データ、環境。
• 運用：CI/CD、レポート、教育、保守。
• 変動：ライセンス、実行料、実機、追加ケース、更新、調査費。

初期費用だけでなく、1年または3年のTCO（総所有コスト）で比べると、条件を把握しやすくなります。

テストコードの所有者は誰にすべきですか？

自社で長期運用するなら、成果物を自社で利用できる状態にします。

• 自社で使う成果物：コード、設計書、実行設定、データ生成方法。
• 契約終了時：引き渡しやライセンス、第三者部品、移行支援、データ削除を定めます。
• 社内オーナー：外注を続けている間も少なくとも1人を置き、優先順位と受入を判断します。

まとめ

まず、自動化対象を頻度、判定の明確さ、業務影響の三つで選びます。そのうえで、成功系・異常系・権限違いを含むPoCにより、実行時間と保守性を確かめます。

RFPには、ケースや環境、データを記載します。CI/CDや証跡、セキュリティ、成果物も書き込みます。

契約・見積もり・保守の一体的な判断

契約形態と費用の推定レンジは、合わせて判断します。判断の材料は、契約の向き不向きと規模別の費用、そして見積もりで確認する比較項目です。

• 契約：請負は範囲と成果物が固まった実装に、準委任は診断や伴走、改善に向いています。
• PoC：初期費用は50万〜150万円です。
• 小・中規模：小規模は100万〜300万円、中規模は300万〜800万円です。
• 大規模：800万〜2,000万円以上を参考にします。
• 比較項目：ライセンス、環境、保守、追加変更、所有権、SLA、内製化支援、終了時の引き渡しを確認します。

最初の一歩は代表ケースの選定と見積もり

見積もりを取る前に、時間がかかる代表的な業務の条件を整理しておきます。

• 代表ケース：数ケースを選び、手動時間と失敗時の影響、利用データ、希望する実行環境を整理します。
• 見積もり：複数社へ同じ条件で相談し、PoCと保守体制を比較します。
• 運用：品質確認を開発チームの日常に定着させます。

▼全体ガイドの記事
・テスト自動化ツール開発の完全ガイド

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