ライブコマースシステム開発の発注/外注/依頼/委託方法について

ライブコマースシステムの発注・外注では、動画を配信できるかだけでなく、商品・在庫・注文・決済・顧客データを安全に購入へつなげられるかを基準に委託先と費用を判断することが重要です。

ライブコマースを始めたい企業のなかには、SaaSを導入するのか、自社ECへ機能を追加するのか、外部プラットフォームで検証するのか、最初から独自開発するのかで迷うケースが少なくありません。この記事では、発注形態の選び方、RFPと要件の整理、契約形態、費用相場、委託先の選定、見積書の比較方法まで、発注前に決めるべきことを順に解説します。

▼全体ガイドの記事
・ライブコマースシステム開発の完全ガイド

ライブコマースシステムを発注する前に知るべき全体像

発注先を探す前に、ライブ配信を一つの機能ではなく、販売業務を含む業務システムとして捉える必要があります。視聴者が配信を見て、コメントし、商品を選び、在庫を確認し、決済して、注文後の配送や返品まで進むためです。

ライブコマースの構成は、配信映像を取り込んでCDNへ届ける配信基盤、視聴画面、コメントやリアクションを扱うリアルタイムイベント基盤、商品・在庫・カート・注文・決済を扱うEC領域、CRMやアクセス解析、運用管理画面に分けて整理できます。どこまでを既存サービスに任せ、どこからを新規開発するかが発注範囲です。

たとえば、映像とコメントは表示できても、配信中に商品をピン留めした際の価格や在庫が古いままだと、購入機会の損失や注文キャンセルにつながります。発注時は「ライブ配信機能一式」ではなく、商品マスタの正、在庫引当の責任者、注文の連携先、障害時の問い合わせ窓口まで明記することが大切です。

選択の軸は、企業規模だけではありません。既存ECやShopify、モール、POS、WMS、CRMを残すのか、必要な同時視聴者数は何人か、社員が配信やコメント対応を担えるか、外部チャネルから自社サイトへ顧客データを戻したいかを確認します。視聴者数の大きさだけを根拠に高額な独自開発を選ぶと、配信内容や商品選定の改善に予算を回せなくなる場合があります。

リサーチノートで確認した事例では、Live cottageの掲載事例に通常EC比で購入単価が約1.4倍になったケース、Tailor Appの掲載事例に同時視聴者数5万1,000人、総視聴者数45万人、ライブ中200万円以上、アーカイブ合計560万円以上のケースがあります。いずれもベンダー公表値であり、商品・出演者・集客・配信内容などの条件に依存するため、発注先に再現を保証させる数字ではなく、計測項目を考える参考値として扱います。

ライブコマースシステムの発注形態はどれを選ぶべきですか？

結論として、初回からフルスクラッチに決めるのではなく、検証の速さ、顧客データの所有、既存ECとの整合性、独自体験の必要性を比較して選びます。4〜8週間で2〜4回の配信を行い、購入率や在庫連携の課題を把握してから拡張する進め方は、発注リスクを抑えやすい方法です。

配信回数がまだ少なく、商品や出演者の勝ち筋を試したい企業には、ライブコマースSaaSやTikTok Shopなどの外部プラットフォームが向いています。公式料金が公開されている「ライコマ」は、ツール利用料が月額3万円で、別途ストリーミングサーバー代が発生すると案内しています。初期費用無料や1か月無料トライアルの条件も掲載されていますが、カートの種類によって初期費用が発生する場合があるため、契約前に確認します（出典: 株式会社The Unit「ライコマ料金プラン」、2026年8月確認）。

TikTok Shopは、Shopifyの公式ヘルプによると、商品カタログ、在庫、フルフィルメント、注文をShopifyと同期できます。日本も利用対象国として案内されていますが、返品ポリシーの表示や商品要件の確認が必要です（出典: Shopify Help Center「TikTok Shopの設定」、2026年8月確認）。集客を外部チャネルに任せる方式は導入が速い一方、手数料、規約変更、データ取得範囲、アカウント停止時の代替策を契約・運用計画に含めます。

既存のECサイトやShopifyを活用し、視聴画面、コメント、商品ピン留め、カート連携、基本分析を追加する方式です。顧客が見慣れた自社ドメインの購入導線を使えるため、外部チャネルに完全移行するよりも商品・注文・顧客データの管理を統一しやすくなります。外部の映像配信基盤を使えば、自社でCDNやエンコード基盤を一から保有せずに済みます。

一方で、APIの制限、商品バリエーション、クーポン、会員ランク、在庫引当、返品処理など、既存ECの仕様を正確に調査する必要があります。発注先には、連携方式をリアルタイムAPI、一定間隔のバッチ、Webhookのどれにするか、同期失敗時に再送できるか、エラーを誰が確認するかまで提案書に書いてもらいます。

複数ブランド・複数チャネルをまたぐ販売体験、厳密な在庫引当、独自の会員施策、POSやWMSとの深い連携、社内業務に合わせた運用権限が競争力の中心になる場合は、独自開発を検討します。自由度は高いものの、配信の安定性、セキュリティ、監視、障害対応、機能追加を継続して負担する必要があります。

フルスクラッチを選ぶ場合でも、最初からすべてを独自実装する必要はありません。映像配信や決済は専門サービスを利用し、商品・注文・会員データや独自の接客ロジックに開発予算を集中する構成もあります。RFPには「独自開発する範囲」と「外部サービスを利用する範囲」を分けて記載し、将来の乗り換え条件も確認します。

RFPと要件整理はどこまで準備して発注すべきですか？

RFPは、機能一覧だけを並べる資料ではありません。事業目的、対象顧客、販売チャネル、配信・受注の現状、実現したいKPI、予算と期限、既存システム、運用体制、委託範囲を一つの前提として示し、各社が同じ条件で提案できるようにする資料です。

目的は「ライブを配信する」ではなく、「新商品の理解を高める」「店舗スタッフの接客をオンラインへ広げる」「既存顧客の再購入を増やす」など、事業上の変化で表現します。KPIは同時視聴者数だけにせず、視聴維持率、コメント数、商品クリック率、カート投入率、購入率、客単価、ライブ起点売上、アーカイブ経由売上、リピート率まで定義します。

運用面では、企画、台本、出演、撮影、配信監視、コメントモデレーション、受注処理、問い合わせ、返品対応、配信後の分析を誰が担当するかを決めます。社員配信で始めるのか、ライバーやインフルエンサーを起用するのかでも、必要な管理画面や契約が変わります。業務分担表をRFPに添付すると、システム開発と運用代行の見積範囲が分かれやすくなります。

機能要件は「コメント機能あり」ではなく、視聴者、配信者、モデレーター、受注担当、管理者の行動で書きます。視聴者なら、配信を視聴して商品をタップし、バリエーションを選び、カートへ追加して決済する流れです。配信者なら、商品をピン留めし、在庫切れを確認し、固定コメントを更新する流れです。

管理者向けには、番組・台本・配信スケジュール、出演者権限、配信監視、商品登録、クーポン、売上確認、通報・ブロック、監査ログを整理します。各機能に「初回リリースで必須」「試験後に追加」「今回は対象外」の優先順位を付けると、見積もりの膨張を防げます。

同時接続数、映像の遅延、再接続、画質、配信開始までの時間、CDN障害時の切り替え、アクセス急増時の負荷試験を定義します。セール配信では、視聴者が増えた瞬間に商品詳細や決済へアクセスが集中するため、平均値ではなくピーク時の想定を提示することが重要です。目標値は業務上必要な水準として発注者と委託先で合意します。

また、商品マスタ、在庫、注文、顧客情報、視聴ログ、コメント、アーカイブ動画のそれぞれについて、正となるシステム、保持期間、利用目的、出力方法、障害時の復旧方法を決めます。配信会社が保有するデータを解約後に返却できるか、API利用を止められた場合にどの業務が止まるかまで、RFPの確認項目に含めます。

ライブコマースシステム開発の発注はどの順番で進めますか？

発注後は、要件定義、設計・開発、テスト・リリース、運用改善の順に進みます。ただし、ライブコマースでは本番配信を経験しないと分からない課題があるため、開発完了まで配信を待つのではなく、SaaSや仮設環境で早い段階から小さく検証することが有効です。

最初に、対象商品、配信頻度、商流、顧客、販売チャネル、社内の担当者を確定します。次に、MVPとして配信、視聴、コメント、商品ピン留め、ECカート連携、基本分析、管理権限に絞るのか、レコメンド、AIによる台本支援、複数ブランド、アーカイブ編集まで含めるのかを決めます。

この段階で、発注者側のプロジェクト責任者を一人決めることも重要です。営業、EC、情報システム、物流、法務、マーケティングの意見を集めても、優先順位を決める責任者がいなければ、要件が増え続けます。候補企業には、要件定義で追加費用が発生する条件と、想定成果物を先に確認します。

設計では画面だけでなく、商品同期、在庫の表示・引当、注文の作成、決済失敗、キャンセル、返品、コメントの通報・ブロック、配信終了後のアーカイブ登録を業務フローとして確認します。特に在庫が残り1個の商品へ複数人が同時に購入操作を行った場合の処理は、デモ画面では分からないため、状態遷移図とエラー時の画面で確認します。

外部サービスを使う場合は、障害や仕様変更の責任分界も設計書に反映します。映像配信会社、ECカート、決済会社、開発会社、運用代行会社のどこが一次対応するのか、復旧目標時間、ログの保存場所、緊急連絡先、変更通知の方法を契約と運用手順に落とします。

テストでは、通常の画面操作だけでなく、同時接続数、映像の遅延、再接続、急激なアクセス増加、在庫競合、決済エラー、二重注文、売り切れ表示、コメント荒らし、出演者アカウントの権限誤りを確認します。配信開始前のリハーサルでは、台本に沿って商品を切り替え、クーポンを出し、注文が正しい倉庫や受注システムへ渡ることまで確認します。

リリース後は、1回の配信の売上だけで評価せず、商品クリック率から購入、配送、リピートまでのファネルを分析します。小さな配信を複数回行い、商品・出演者・時間帯・台本・導線のどれを改善したかを記録すると、独自開発を継続するか、SaaSで十分かの判断もしやすくなります。

契約形態は準委任と請負のどちらを選ぶべきですか？

契約形態は、要件が固まっているか、発注者と委託先がどれだけ一緒に検証するかで決めます。開発部分だけでなく、配信運用、企画、分析、保守、追加改修を同じ契約に詰め込まず、成果物と責任を分けて整理することがトラブル防止になります。

準委任は、専門家の作業や支援を受ける契約で、要件を一緒に整理しながら段階的に開発したい場合に向いています。ライブコマースのように、実際の配信で運用課題を見つけ、優先順位を変えながら改善するプロジェクトでは、要件定義、プロトタイプ、データ分析、継続改修を準委任で進める方法があります。

ただし、作業時間や体制に対して費用を支払う形になりやすいため、成果物、稼働時間、会議体、報告方法、追加作業の承認手順を明確にします。売上や購入率など、外部要因が大きいKPIを委託先の成果保証として扱わず、システム品質と運用改善の責任を分けて合意します。

請負は、合意した仕事の完成や成果物を前提にする契約で、要件、納期、受入条件が比較的固まっている開発部分に向いています。画面、API、管理機能、テスト仕様書、操作マニュアルなどの納品物と受入基準を明確にし、検収後の瑕疵対応や保証期間を契約書に記載します。

ライブコマースでは、外部APIの仕様変更や決済会社の審査、在庫データの品質など、委託先だけでは制御できない条件があります。請負にする範囲は、外部要因で納期や費用が変わる条件、発注者の回答遅延、追加要件の変更管理、再見積もりの手続きまで含めて明記します。

ライブコマースシステムの費用相場はいくらですか？

ライブコマースだけを対象にした公的な費用統計は確認できないため、以下は公開料金とEC・動画配信に近い案件から整理した目安です。正確な費用は、同時視聴者数、配信時間、配信回数、連携するEC・POS・WMS・CRMの数、決済方式、権限・監査要件、運用代行の範囲で変わります。見積書では、金額だけでなく前提条件を必ず確認します。

外部プラットフォームへの出店・運用開始は、システム開発ではなく、初期0〜100万円程度を一つの検討レンジにできます。クリエイター費、撮影、広告、運用代行、販売手数料は別に見積もります。ECカート連携型SaaSの導入は、初期0〜300万円程度、月額3万〜10万円程度に、配信量・サーバー費を加える想定です。商品同期、タグ設置、デザイン調整、研修を含めると初期費が上振れします。これらの初期費用レンジは類似案件からの推定であり、月額については「ライコマ」などの公開料金を比較材料にしています。

自社EC向けのMVPは、500万〜1,500万円程度、3〜6か月程度が検討レンジです。配信埋め込み、コメント、商品ピン留め、カート連携、基本分析に絞り、独自決済や複雑な在庫引当を含めない前提です。中規模の独自システムは1,500万〜5,000万円程度、6〜12か月程度、複数チャネル、POS・WMS・CRM連携、権限、監査ログ、負荷試験、アーカイブ分析まで含める場合を想定します。いずれもライブコマース固有の公的統計ではなく、類似するEC・動画システムの要件からの推定です。

比較の基準として、Shopify Japanは2026年5月公開の記事で、フルスクラッチECの初期開発費を小規模1,000万〜3,000万円、中規模3,000万〜8,000万円、大規模8,000万〜2億円、構築期間を小規模6〜9か月、中規模9〜15か月、大規模12〜18か月と整理しています。ライブ配信の同時接続、リアルタイム在庫、コメント、配信監視を追加すると上限側へ寄りやすいため、自社要件を当てはめて考えます（出典: Shopify Japan「フルスクラッチとは」、2026年5月）。

ランニングコストには、SaaS月額、ストリーミング・CDN従量費、決済手数料、売上連動手数料、監視・保守、クラウド費、配信スタッフ、コメントモデレーション、出演者、撮影、編集、広告、問い合わせ対応が含まれます。「月額無料」でも、配信量や注文数に応じた費用、外部チャネルの販売手数料、追加サポート費が発生することがあります。

フルスクラッチや大規模連携では、保守費を初期開発費の年15〜20％程度とする業界一般則が参考になりますが、これはライブコマースの公的な基準ではありません。障害対応の時間帯、セキュリティ更新、脆弱性診断、追加開発、クラウド費の増加を含むかで変わるため、年額と作業範囲を分けて確認します。初期費用だけでなく、3〜5年のTCOでSaaSと独自開発を比較します。

ライブコマースの委託先は何を基準に選べばよいですか？

委託先は、ライブ配信の実績だけでなく、EC・基幹連携、運用体制、障害対応、データの扱いまで同じ物差しで比較します。システム開発会社、SaaSベンダー、配信・制作会社、運用代行会社は得意領域が異なるため、「ライブコマースに詳しい」という一言だけで同列に評価しないことが重要です。

候補企業には、似た業種の導入実績だけでなく、同時接続数、配信時間、商品点数、注文数、利用したEC、在庫やPOSとの連携方式を確認します。実績を聞くときは「何人見たか」だけでなく、商品クリック率、購入率、アーカイブ売上、障害件数、運用人数、改善回数も質問します。成功事例の数字は、ベンダー公表値か第三者調査か、測定期間と条件を確認して一般化しません。

自社ECを残したい場合は、視聴画面を自社ドメインへ埋め込めるか、顧客IDを既存会員と結び付けられるか、注文・返品・問い合わせが既存業務へ戻るかを確認します。外部プラットフォームを使う場合は、規約変更、手数料、データのエクスポート、アカウント停止時の代替チャネルについて質問します。

ライブコマースは公開して終わりではありません。番組企画、台本、商品登録、出演者の教育、配信当日の監視、コメント対応、受注・返品、レポート作成までが毎回発生します。開発会社が保守だけを担当するのか、配信現場まで支援するのか、運用代行会社と連携するのかを見積書と体制図で分けます。

障害時は、映像が止まった場合、決済が失敗した場合、在庫が不整合になった場合、コメントが荒れた場合で初動が異なります。一次受付、切り分け、顧客への告知、返金や注文訂正、原因報告の担当を決め、サービスレベル、対応時間、連絡手段、再発防止の報告期限を契約に含めます。

管理画面の多要素認証、最小権限、配信者・モデレーター・受注担当のロール分離、通信と保存データの暗号化、APIキーの秘匿、WAFやレート制限、監査ログ、バックアップ、脆弱性対応の有無を確認します。カード情報は自社に保持せず、トークン化された外部決済やホスト型チェックアウトを優先し、決済会社との責任分界を確認します。

視聴ログ、コメント、購入履歴などを扱う場合、委託先の安全管理措置、再委託先、保存場所、海外クラウドの利用、削除・返却、事故発生時の報告方法を確認します。個人情報保護委員会のガイドラインは、委託先の安全管理措置を事前に確認し、委託契約に取扱状況の把握を盛り込むことが望ましいとしています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。

ライブコマースの見積書はどこを比較すべきですか？

見積比較で見るべきなのは、総額の安さではなく、同じ前提で何が含まれ、何が含まれないかです。候補企業には同じRFPを渡し、機能、工数、単価、外部サービス費、ライセンス、テスト、移行、研修、保守、運用代行、追加変更の単価を分けて提出してもらいます。

比較表を作るときは、企画・要件定義、UI/UX設計、配信基盤、視聴画面、コメント、商品・在庫連携、カート・決済、管理画面、分析、インフラ、セキュリティ、テスト、データ移行、研修、保守を行に分けます。配信1回あたりの従量費、同時接続数の上限、保存できるアーカイブ容量、コメント管理の範囲も同じ欄で確認します。

安い見積に配信監視や受入テストが含まれていなければ、本番前に追加費用が発生する可能性があります。反対に、高い見積でも不要な独自機能や過剰なインフラが含まれていれば、検証段階には不向きです。各社の見積差が出た項目について「なぜ必要か」「削った場合のリスクは何か」を説明してもらい、価格ではなく優先順位で調整します。

受入基準は、機能が存在することではなく、業務シナリオが完了することにします。たとえば、配信者が商品をピン留めし、視聴者が在庫のあるバリエーションを購入し、注文が受注システムへ渡り、売上と分析に反映されるまでを一つの受入シナリオにします。負荷試験の条件、重大障害の定義、未達時の再試験も決めます。

開発中の仕様変更は、追加費用、納期、品質への影響を記録し、発注者が承認してから実施します。SaaSの場合は、解約時のデータ返却形式、動画やコメントの持ち出し、アカウント削除、契約更新、価格改定の通知期間を確認します。独自開発の場合は、ソースコード、クラウドアカウント、ドメイン、証明書、CI/CD、監視設定の所有権と引き継ぎ方法を契約に記載します。

候補は、SaaS型、自社EC・SI型、外部プラットフォーム運用型、制作・分析型など、異なる強みを持つ3〜5社に分けて依頼します。すべてを一社に任せることが最適とは限らず、システム開発会社と配信運用会社を分ける場合は、連絡系統と責任分界を先に決めます。

評価シートには、要件適合、既存システム連携、非機能要件、セキュリティ、運用支援、費用、期間、担当者の経験、データ移行、解約・引き継ぎを入れます。提案プレゼンでは、都合のよい成功事例だけでなく、想定する失敗、できないこと、発注者側に必要な作業を説明できる企業を高く評価します。

発注時に法務・個人情報・決済をどう確認しますか？

ライブ配信中の説明やコメントも、商品・サービスの内容や取引条件を伝える販売促進の接点になります。システムの仕様だけでなく、表示、権限、ログ、委託先の管理を法務・情報セキュリティと一緒に確認し、配信者個人の判断に任せない運用を設計します。

通信販売に該当する場合は、販売業者の名称・住所・電話番号、販売価格、送料、支払時期と方法、商品の引渡時期、返品・解約条件、数量限定などの販売条件を購入者が確認できるようにします。消費者庁は、インターネット上のウェブサイトも通信販売広告に含まれ得ると説明しています（出典: 消費者庁「特定商取引法ガイド 通信販売広告について」、2026年8月確認）。配信画面から購入画面へ移る導線で表示が欠けないよう、画面遷移と受入テストに含めます。

「ライブ限定」「残りわずか」「通常価格から何％引き」「ランキング1位」などの訴求は、景品表示法上の表示と根拠を確認します。インフルエンサーやライバーを起用する場合は、広告主との関係や報酬・提供の有無を社内審査できるようにし、台本、固定コメント、クーポン表示を承認済みの素材として管理します。

コメント、アカウントID、視聴履歴、購入履歴、問い合わせ内容は、設計によって個人情報に該当し得ます。利用目的、第三者提供、委託先、保存期間、削除方法をプライバシーポリシーと社内規程に落とし、委託先の再委託、海外クラウド、ログの分析利用、AI学習への転用を確認します。

決済情報は、外部決済サービスと自社システムの責任範囲を明確にします。AIを使ってコメント返信、商品提案、台本作成、値引きや返金判断を行う場合は、入力データの利用目的と保存先を確認し、高額取引、返金、規約違反判定などに人の承認を挟みます。便利さを優先して権限を広げるのではなく、最小権限と操作ログを前提にします。

よくある質問

最後に、ライブコマースシステムの発注で特に多い疑問を整理します。費用、開発方式、発注先の選び方は、売上規模や既存システム、社内の運用体制によって変わるため、自社の条件を当てはめて判断します。

外部プラットフォームやSaaSを使う場合は、初期0〜100万円程度、月額数万円から始められる選択肢があります。自社EC向けにMVPを開発する場合は500万〜1,500万円程度、独自システムや基幹連携を含む場合は1,500万円以上を検討するレンジですが、いずれも要件による推定です。配信・広告・出演者・運用費を含めた総額で判断します。

配信や商品選定を短期間で検証したい企業にはSaaSや外部プラットフォームが向いています。既存EC・POS・WMS・CRMをまたぐ独自の購買体験や、厳密な在庫・会員施策が競争力になる企業は、既存基盤への拡張や独自開発を検討します。まず小さく配信して、独自開発で解決すべき課題が見えてから移行する方法も有効です。

外注できます。企画、台本、撮影、出演者のキャスティング、配信操作、コメントモデレーション、広告、分析、問い合わせ対応まで、企業によって支援範囲が異なります。システム開発の見積と運用代行の見積を分け、当日の責任者、売上や返品の処理、緊急時の連絡先を契約で明確にします。

相談できます。目的、対象商品、既存EC、配信回数、想定視聴者数、社内体制、予算感だけでも整理して伝え、要件定義支援の提案を依頼します。ただし、要件定義の成果物、期間、追加費用、要件定義後に開発を発注しない場合の扱いを先に確認すると、相談から開発までの条件が分かりやすくなります。

まとめ

ライブコマースシステムの発注では、動画配信の機能だけを比較せず、既存EC・POS・WMS・CRMとの連携、商品・在庫・注文・決済の責任分界、配信後の分析と運用まで含めて委託範囲を決めます。発注形態は、外部プラットフォーム、SaaS、既存ECへの拡張、フルスクラッチを、検証の速さと独自性の必要性で選びます。

RFPには、目的とKPI、利用者別の業務シナリオ、機能・非機能要件、法務・セキュリティ、データの所有と返却、運用体制、受入基準を記載します。費用は初期開発費だけでなく、配信従量費、決済・販売手数料、保守、配信スタッフ、出演者、広告、問い合わせまで含む3〜5年のTCOで比較します。3〜5社へ同じ条件で見積を依頼し、安さではなく、説明の透明性と公開後まで支えられる体制で委託先を選びます。

▼全体ガイドの記事
・ライブコマースシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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