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

SAP Commerce Cloudのシステム開発を発注・外注するなら、先に販売業務と連携範囲を整理し、標準機能で対応する領域と独自開発する領域を分けてから、段階的に委託する方法が適しています。

SAP Commerce Cloudは、高機能なECサイトを作るだけの製品ではありません。商品、顧客、価格、在庫、受注、出荷、請求などの業務をSAP ERPや物流・決済システムとつなぐ、企業向けの販売業務基盤です。そのため、発注先の知名度や見積総額だけでなく、要件定義、データ移行、連携テスト、稼働後の運用まで含めて委託条件を設計する必要があります。この記事では、SAP Commerce Cloudのシステム開発を外注する際の発注形態、RFPと要件のまとめ方、契約形態、費用相場、委託先の選び方、見積比較のポイントを順番に解説します。

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

SAP Commerce Cloudの発注・外注の全体像

SAP Commerce Cloudの発注では、画面を作る作業だけを切り出すと、後から連携や業務ルールの抜けが見つかりやすくなります。最初に「何を販売し、誰が、どの価格で、どの在庫を使い、どの経路で出荷するのか」を業務フローとして整理し、システムの責任範囲を決めることが大切です。

SAP Commerce Cloudは、B2Cの会員・検索・プロモーション・決済・チェックアウトだけでなく、B2Bの企業組織、ユーザー権限、購買承認、得意先別価格、見積、再注文などにも対応できるコマース基盤です。SAP S/4HANAやSAP ERPと連携すれば、商品マスタ、得意先、価格、在庫、受注、出荷・請求の情報を一貫させやすくなります。一方で、WMS、配送、決済、PIM、CMS、CRMなどの周辺システムが関係するため、委託先にはフロントエンドの開発力だけでなく、業務データの設計力と連携の運用力が求められます。

発注前には、販売チャネル、対象国・拠点、ブランド数、商品点数、取引先数、ピーク時のアクセスや注文数、既存システム、移行対象データを洗い出します。たとえば「ECを刷新する」という一文でも、B2Bの承認ルートを残すのか、店舗受取を追加するのか、在庫をリアルタイム表示するのかによって、必要な開発とテストの量は大きく変わります。

発注の成否を分けるのが、標準機能に業務を合わせる範囲と、競争力のために作り込む範囲の線引きです。商品登録や一般的なカート、受注、コンテンツ管理まで独自仕様にすると、初期費用だけでなく、アップデートや障害対応の負担も増えます。逆に、得意先別価格、複雑な商品構成、独自の受注ルールなど、営業上の優位性に直結する領域は、無理に標準へ合わせると現場がExcelや手作業へ戻る可能性があります。

委託先には、各要件について「標準機能で対応」「設定で対応」「拡張開発が必要」「周辺システムで対応」「業務を変更して対応」のいずれかを記載してもらいます。Fit to Standardの判断理由が見えると、見積の差額が単なる人月差なのか、対応範囲の差なのかを比較できます。SAP Commerce Cloudの公式資料でも、Composable StorefrontはAngularベースのJavaScriptフロントエンドで、Commerce REST APIを介してバックエンドと通信すると説明されています（出典: SAP Help Portal「SAP Commerce Cloud, composable storefront」、2026年確認）。フロントを独自化する場合も、API、認証、キャッシュ、検索、在庫整合性を含めて評価する必要があります。

発注形態は一括請負・準委任・段階発注から選びます

発注形態は、要件が固まっているか、業務変更を伴うか、社内にプロジェクトを管理できる人材がいるかで選びます。大規模なSAP Commerce Cloudでは、すべてを一つの契約に詰め込むより、企画・要件定義、設計・開発、移行・テスト、運用改善を分けたほうが、責任範囲と予算を管理しやすい場合があります。

請負契約は、成果物と完成条件を定め、その成果に対して対価を支払う発注形態です。画面一覧、機能仕様、API仕様、移行対象、テスト項目、納品物が明確な開発や、決められた範囲の追加機能に向いています。納期と予算を見通しやすい一方、契約後に要件を追加すると、変更管理と追加見積が必要になります。

請負で発注する場合は、「SAP Commerce Cloudを導入する」ではなく、「商品検索、得意先別価格、在庫照会、注文登録、ERPへの受注連携が、定めたテストデータと受入条件を満たす状態」のように完成を定義します。受入条件に性能、権限、異常系、ログ、障害時の再送まで含めると、公開直前に見つかる問題を減らせます。

準委任契約は、専門家が一定の業務を遂行することに対して対価を支払う形態です。現行業務の調査、Fit/Gap、アーキテクチャ検討、アジャイル開発、運用改善のように、発注時点で最終仕様を固定しにくい領域に適しています。委託先の作業時間や体制を管理しやすい反面、完成責任をどこまで負う契約なのかを誤解しやすいため、成果物、会議体、報告内容、品質指標を別途明記します。

準委任であっても、作業を任せきりにしてよいわけではありません。発注側にプロダクトオーナーや業務責任者を置き、優先順位、仕様の決定、受入判断を社内で行います。委託先の提案を聞きながら決める場合でも、業務ルールの最終承認者が不在だと、会議だけが増えて予算と納期が膨らみやすくなります。

不確実性が高い場合は、最初から全機能を本番構築するのではなく、PoCやMVPを先に発注します。商品検索、価格表示、在庫照会、ログイン、カート、注文、ERP連携という一連の業務を、実データに近い条件で動かしてから、本番範囲を確定する方法です。正常に注文できるだけでなく、在庫不足、決済失敗、APIタイムアウト、二重送信、権限不足が起きたときの扱いまで検証します。

段階発注では、PoCの成果を本番開発へ引き継げる契約にしておきます。検証用コードを捨てるのか、設計・テスト資産を本番へ流用するのか、データやAPI仕様を誰が所有するのかを明確にします。MVPの成功条件を「画面が表示できた」ではなく、「営業担当が指定された得意先価格で注文し、ERP側で受注・出荷に進められた」のように業務成果で定義すると、次の発注判断がしやすくなります。

RFPと要件整理は発注前にどこまで進めますか？

結論から言えば、RFPは詳細設計書まで完成させる必要はありませんが、業務目的、対象範囲、連携先、データ、非機能要件、納期、予算の前提は発注前に整理します。SAP Commerce Cloudでは、見積金額を左右する要素が画面数よりも、価格・在庫・受注の連携方式やデータ品質に隠れているからです。

RFPには、誰が何を買うのかを最初に書きます。B2Bであれば、得意先ごとの価格表、見積から注文へ進む流れ、購買承認、担当者と請求先の権限、再注文、納期回答が必要になります。B2Cであれば、会員登録、ゲスト購入、プロモーション、決済、返品、問い合わせなどを整理します。複数国・多言語・多通貨の場合は、税、通貨換算、在庫の引当単位、タイムゾーン、法令対応の前提も加えます。

次に、商品、顧客、価格、在庫、注文、出荷、請求の各データについて、正となるシステムと更新タイミングを決めます。価格と在庫はリアルタイム連携が必要でも、分析データは夜間バッチで足りる場合があります。すべてをリアルタイムにすると連携障害の影響範囲が広がるため、業務上の許容時間と整合性を基準に方式を選びます。

ECの繁忙期やキャンペーン時に注文を受けられる性能、障害時の復旧目標、運用時間、監視、バックアップ、ログ保存、権限、個人情報の取り扱いを非機能要件に含めます。特に注文処理では、決済は成功したのに受注が作成されない、在庫引当前に二重注文が発生する、連携失敗を検知できないといった異常系を受入条件にします。

データ移行では、商品画像や説明文だけでなく、得意先、契約価格、在庫、注文履歴、返品、会員、権限、検索用属性まで対象を決めます。移行前の重複・欠損・コード不一致を何件まで許容するのか、クレンジングを発注側と委託先のどちらが担当するのか、移行リハーサルを何回行うのかを明記します。移行と連携テストを最後にまとめると、稼働直前に大量の不整合が見つかるため、早い段階から実データに近いサンプルで検証します。

RFPには、要件一覧だけでなく、提案書に回答してほしい項目を設けます。たとえば、標準・設定・拡張の判定、システム構成図、APIとバッチの一覧、移行計画、テスト計画、体制表、前提・除外事項、課題管理方法、納品物、保守の時間帯、SLA、追加開発の単価を指定します。提案側が自由に書いた見積を受け取るより、同じ質問に答えてもらうほうが比較可能性が高まります。

候補会社には、実際の業務シナリオを使ったデモやワークショップも依頼します。「在庫不足の注文」「得意先別価格の表示」「承認者不在」「決済失敗後の再注文」「ERP連携のタイムアウト」などを提示し、画面の見栄えよりも業務例外への対応を確認します。提案段階で難しい問題を質問できる会社ほど、稼働後のリスクを早く見つけられる傾向があります。

発注後の開発は要件定義・設計・テストの順で進めます

発注後は、要件定義で業務とデータの境界を固め、設計で標準機能・拡張・連携の責任分界を決め、開発とテストを繰り返します。SAP Commerce Cloudでは、バックエンドのコマース機能、フロントエンド、ERPやWMSなどの周辺システムが同時に動くため、工程の後半だけで統合テストを行う進め方は避けます。

要件定義では、現行の販売・受注業務を可視化し、目標KPIを決めます。売上だけでなく、受注処理時間、営業からの価格問い合わせ件数、在庫確認にかかる時間、返品処理時間、店舗受取率、再注文率などを設定すると、システム導入後の評価が可能になります。業務部門、情報システム部門、物流、経理、法務、セキュリティの代表者を早期に参加させ、部門ごとの前提を統合します。

Fit/Gapでは、差分を見つけるだけでなく、差分をどう解消するかを決めます。標準機能を使う、業務を変更する、設定で補う、API連携で補う、拡張開発する、対象外にするという選択肢を比較します。拡張を選ぶ場合は、アップデートへの影響、テストの追加量、将来の保守担当、撤去条件を記録します。要件定義書に判断理由が残ると、担当者が変わっても不要なカスタマイズが増えにくくなります。

設計では、Commerce Cloud本体、Composable Storefrontまたは独自フロント、検索、CMS、決済、SAP ERP、WMS、配送、会計、CRMなどの構成を図にします。各データの送信元、送信先、方式、頻度、エラー時の再送、重複防止、監視、照合方法まで定義します。画面だけを先に作ると、価格・在庫・受注の連携仕様が後回しになり、実装のやり直しが生じやすくなります。

2026年時点では、SAP Commerce Cloud 2211系のJDK 21・Spring 6への対応も発注条件に含めます。SAP Help Portalは、JDK 21とSpring 6への更新により、カスタム拡張やプロジェクト設定の調整が必要になると案内しています（出典: SAP Help Portal「Update Release 2211-jdk21.1」、2025年公開・2026年確認）。独自拡張に古いAPIや非推奨ライブラリを組み込まないこと、アップデート時の回帰テストを契約上の作業として確保することが重要です。

テストは、単体テスト、機能テスト、連携テスト、データ移行リハーサル、性能テスト、セキュリティテスト、ユーザー受入テストに分けます。商品登録から検索、価格表示、在庫確認、カート、決済、受注、出荷、返品までを一続きで確認し、正常系だけでなく例外系も再現します。とくに受注連携では、失敗したメッセージを再送したときに二重登録されないか、ERP側の受注番号とCommerce Cloud側の注文番号を照合できるかを確認します。

SAP公式のオンプレミス版2205の案内では、Mainstream Maintenanceの終了日は2026年7月31日で、SAPは新しいイノベーションをCommerce Cloudに集中すると説明しています（出典: SAP Help Portal「End of Mainstream Maintenance for SAP Commerce」、2026年確認）。既存のHybrisやSAP Commerceから移行する場合は、サーバー移設だけと考えず、独自拡張、非推奨モジュール、商品・画像・注文データ、回帰テスト、運用手順を棚卸しします。SAPのFAQでは移行期間の一般的な目安を4〜8か月としていますが、これは複雑度によって変わる推定であり、納期保証ではありません（出典: SAP Help Portal「End of Mainstream Maintenance for SAP Commerce」、2026年確認）。

契約形態と委託範囲はどこまで明文化しますか？

契約書では、開発作業の範囲だけでなく、意思決定、情報提供、データ作成、環境準備、検証、教育、稼働後の支援を誰が担うかを決めます。SAP Commerce Cloudのように複数システムが関係する案件では、委託先が担当するのはCommerce Cloud部分だけなのか、ERPやWMSの改修、ミドルウェア、決済会社との調整まで含むのかで、見積と責任が大きく変わります。

成果物には、要件定義書、業務フロー、Fit/Gap一覧、システム構成図、画面・API・データ仕様、ソースコード、環境設定、テスト計画と結果、移行手順、運用手順、教育資料を含めるか確認します。設定変更やクラウド環境の構築を委託する場合も、設定値の一覧や再現手順を納品対象にします。納品物が「開発一式」だけでは、別会社への引き継ぎや障害調査が難しくなります。

要件変更の扱いも重要です。変更要求の起票者、影響調査の期限、追加費用の算定方法、納期への影響、承認者を決めます。要件定義の後に機能を増やす場合は、優先順位を下げる機能とセットで判断できるようにします。口頭の依頼をそのまま開発へ流すと、請負と準委任の境界が曖昧になり、想定外の作業費が発生しやすくなります。

ソースコード、設定、設計書、テスト資産、データ移行スクリプト、API仕様の利用権と引渡し範囲を契約前に確認します。委託先の既存部品や第三者ライブラリを使う場合は、ライセンス、改変可否、再利用条件、契約終了後の利用可否を明示します。法務担当と確認し、納品後に自社や別の保守会社が改修できる状態を確保します。

セキュリティでは、認証・認可、Backofficeへのアクセス制御、個人情報の保持・削除、決済情報の取り扱い、暗号化、ログ、脆弱性対応、インシデント時の連絡体制を決めます。SAPのSecurity Guideが扱う認証・認可、セッション、PCI、属性暗号化、HTTPヘッダー、ネットワーク、SSL/TLSなどをRFPの確認項目に落とし込みます。保守契約では、問い合わせ受付時間、障害の優先度、一次回答、復旧目標、アップデート対応、追加開発の料金を分けて記載します。

SAP Commerce Cloudの費用相場とコストの内訳

SAP Commerce Cloudの費用は、契約エディション、取引規模、サイト数、対象国、ユーザー、連携本数、カスタマイズ、データ移行、保守範囲によって変わります。日本向けの一律な公開価格表は確認できないため、以下は公式に公開された固定サービス価格と、第三者の公開ベンチマークを分けて示します。金額は発注額を断定するものではなく、RFPを作る際の予算仮説として利用します。

SAP Storeで公開されているSAP公式の「Accelerated implementation service for SAP Commerce Cloud」は、一回料金304,130ユーロです。1ユーロ160円で機械的に換算すると約4,900万円ですが、これは固定されたサービス範囲の価格であり、クラウド契約、複雑な個別連携、大規模な追加開発をすべて含む総額ではありません（出典: SAP Store「Accelerated implementation service for SAP Commerce Cloud」、2026年確認）。公式サービスの対象範囲と自社の要件が一致するかを確認し、価格だけをそのまま導入総額と解釈しないことが大切です。

第三者が2025年に公開したベンチマークでは、SAP Commerce Cloudの導入実装は15万〜50万米ドル、ERP・CRMなどの連携は5万〜20万米ドル、カスタマイズは5万〜30万米ドルとされています。1米ドル150円で換算すると、導入実装は約2,250万〜7,500万円、連携は約750万〜3,000万円、カスタマイズは約750万〜4,500万円です。これらはSAP公式価格ではないため、実際の見積の根拠ではなく、提案内容が相場から大きく外れていないかを見る初期材料として扱います（出典: TechGarçons「SAP Commerce Cloud Implementation Guide」、2025年公開）。

国内での予算を考えるときは、ライセンスまたはサブスクリプション、導入支援、ERP・WMS・決済連携、フロントエンド、データ移行、性能・セキュリティ試験、教育を分けて積み上げます。単一国で標準機能中心の構成は4,000万〜8,000万円程度から検討し、複数国・複数ブランド・高度なB2B・ERP/WMS/決済連携を含む場合は1億〜数億円規模になる可能性があります。この国内レンジは公表価格ではなく、公式サービス価格、第三者ベンチマーク、一般的な大規模業務システムの相場から推定した予算幅です。

ランニングコストには、SAPのサブスクリプション、クラウド利用、監視、ヘルプデスク、障害対応、セキュリティ対応、アップデート、追加改善、社内運用人員が含まれます。第三者の2025年公開ベンチマークでは、年間ライセンスを10万〜25万米ドル、年間サポート・保守を5万〜10万米ドルと推定していますが、契約条件や取引規模で変わるため、SAPと委託先から個別に確認します（出典: TechGarçons「SAP Commerce Cloud Implementation Guide」、2025年公開）。初期開発費の年15〜25％を保守の目安にする一般論もありますが、サブスクリプションを含むかどうかで意味が変わります。

期間は、要件整理・Fit/Gap・アーキテクチャ設計に1〜2か月、標準機能中心の単一国サイトに4〜8か月、ERP・在庫・決済・データ移行・B2B業務を含む構築に6〜12か月、複数国・複数ブランド・既存Hybris移行に12〜24か月以上を置くと計画しやすくなります。SAP公式FAQの「多くの顧客は4〜8か月」という目安も、移行の複雑さや変更範囲で変動します。期間を短くしたい場合は、機能を削るだけでなく、標準機能の採用、データクレンジングの前倒し、意思決定者の確保、MVPの範囲限定を行います。

委託先の選定と見積比較で確認するポイント

委託先は、SAPの製品知識だけでなく、自社の販売業務と周辺システムを理解しているかで選びます。SAP Commerce Cloudの実績を確認するときは、社名や導入件数だけでなく、B2B・B2Cの別、対象業界、S/4HANA・ECC・WMS・決済との連携、データ移行の有無、稼働後の保守体制、担当チームの経験を質問します。

候補会社の比較では、公開事例の業界、取引モデル、サイト数、拠点数、データ量、連携方式が自社に近いかを見ます。製造業のB2Bで得意先別価格と見積が中心なら、一般消費者向けECの制作事例だけでは判断できません。海外拠点があるなら、多言語・多通貨、税、現地決済、タイムゾーン、拠点別在庫を扱った経験を確認します。

候補の一例として、SAP自身は標準機能中心の導入サービスを持ち、NTT DATAはSAP Commerce CloudとマーケットプレイスやERP・Emarsys連携に関する情報を公開しています。Capgeminiはオンプレミスからクラウドへの移行、Accentureは短期導入パッケージや大規模なコマース支援を案内しています。日本ソフトウエア株式会社のように国内窓口でSAP Commerce Cloudを扱う企業もありますが、認定状況、担当者、再委託の範囲、現在の保守体制は提案時に確認します。企業名だけで優劣を断定せず、自社要件に対する適合性で評価します。

見積書は、要件定義、設計、設定、拡張開発、フロントエンド、連携、データ移行、テスト、教育、リリース、保守に分解してもらいます。各項目について、担当人数、期間、成果物、前提、除外事項、再委託の有無、追加作業の単価を確認します。A社が連携費を含み、B社が別途としている場合、表面上の総額だけでは比較できません。

安い見積が出た場合は、何が含まれていないかを確認します。要件定義が短すぎる、移行対象が商品だけ、連携テストがモックのみ、性能試験が対象外、稼働後のハイパーケアがない、ソースコードや設計書が納品されないといった可能性があります。逆に高い見積でも、データクレンジング、実データでのリハーサル、異常系テスト、運用設計、アップデート対応まで含んでいれば、TCOでは妥当な場合があります。

スコープクリープを防ぐには、必須機能、初回リリース後に回す機能、対象外の機能を分けます。機能追加を禁止するのではなく、追加したときの費用、納期、テスト影響を見える化し、経営判断で優先順位を変えられる状態にします。月次の課題レビューと、段階ごとの予算消化・品質・リスクの報告を契約に入れると、問題が大きくなる前に軌道修正できます。

ベンダーロックインを避けるには、技術仕様を囲い込まないことが有効です。API仕様、データモデル、環境構成、CI/CD、監視設定、テストコード、障害履歴を引き渡し、社内担当者が読める形にします。保守会社を変更できるか、ライセンスや第三者部品の制約がないか、委託先が撤退したときに誰が復旧できるかまで確認します。引き継ぎ期間と費用をあらかじめ契約しておくと、稼働後の選択肢を残せます。

よくある質問（FAQ）

SAP Commerce Cloudの発注では、費用の出し方、内製と外注の分担、納期、既存SAPからの移行について質問が多くなります。ここでは、発注前に判断しやすいように、結論から回答します。

一律の価格はなく、標準機能中心の単一国サイトなら4,000万〜8,000万円程度から、複数国・ERP/WMS・決済連携・高度なB2Bを含む場合は1億〜数億円規模まで広がります。SAP公式の一回304,130ユーロの導入サービスや、第三者の公開ベンチマークは参考になりますが、クラウド契約や個別要件を含むかを確認し、自社のRFPに基づく見積で判断します。

仕様と受入条件が固まった領域は請負、業務調査やFit/Gap、アジャイル開発、運用改善のように変化する領域は準委任が適しています。大規模案件では、要件定義を準委任、確定した開発範囲を請負、稼働後の改善を準委任に分ける方法もあります。契約形態よりも、成果物、責任分界、変更手続き、受入条件が明文化されているかが重要です。

標準機能中心の単一国サイトは4〜8か月、ERP・在庫・決済・データ移行・B2B業務を含む場合は6〜12か月、複数国や既存Hybrisからの移行は12〜24か月以上が目安です。SAP公式FAQにも多くの顧客で4〜8か月という推定がありますが、要件の変更量、データ品質、意思決定の速度、テスト回数で変わります。短納期を希望する場合は、MVPの業務範囲と後続リリースを明確に分けます。

発注できますが、SAP ERPとの連携がない場合でも、商品、価格、在庫、顧客、受注、出荷、請求を管理するシステムとの接続設計が必要です。SAP製品を使っていること自体が導入条件ではなく、自社の販売業務に必要な機能とデータ連携を実現できるかで判断します。候補会社には、非SAPの基幹・WMS・決済との連携経験と、将来SAP ERPへ移行する場合の拡張方針も質問します。

まとめ

SAP Commerce Cloudのシステム開発を発注・外注するときは、まずECサイトの画面ではなく、商品・価格・在庫・受注・出荷を含む販売業務全体を対象にします。そのうえで、標準機能と独自開発の境界を決め、請負・準委任・段階発注を適切に組み合わせます。RFPには業務要件だけでなく、連携、データ移行、性能、セキュリティ、受入条件、納品物、保守を含めます。

発注前は、対象チャネルとKPI、商品・顧客・価格・在庫・注文の正となるシステム、ERP・WMS・決済などの連携、移行データ、標準と拡張の判定、非機能要件、テスト範囲を確認します。見積比較では、総額だけでなく、含まれる作業、除外事項、体制、成果物、追加単価、保守とアップデート対応を同じ粒度でそろえます。

最初から完璧な仕様書を作る必要はありません。得意先別価格で注文する、在庫不足の注文を受ける、決済失敗から再注文する、ERP連携が止まった注文を再送するなど、重要な業務シナリオを数本選び、候補会社とFit/Gapを確認します。業務の現実に基づくRFPと、将来のアップデート・運用を見据えた契約が、SAP Commerce Cloudの発注を成功へ近づけます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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