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

Adobe Experience Managerのシステムを発注・外注するなら、ライセンスだけでなく、要件整理、コンテンツ移行、外部連携、運用定着までを含む全体計画で委託先と契約することが重要です。

Adobe Experience Manager（AEM）は、高機能な企業向けCMS・DAM基盤であるため、安さだけで開発会社を選ぶと、標準機能と追加開発の境界が曖昧になり、後から費用や納期が膨らみやすくなります。この記事では、発注形態の選び方、RFPと要件のまとめ方、契約形態、費用相場、委託先の選定、見積書の比較ポイントを、2026年時点の公開情報と導入事例を踏まえて解説します。

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

Adobe Experience Managerの発注・外注で最初に決めること

最初に決めるべきなのは、製品を導入するかどうかではなく、AEMでどの業務とチャネルを変えるかです。AEM Sitesだけを使うのか、AEM Assetsで画像・動画・文書を統合するのか、FormsやAdobe Analyticsなどの周辺製品まで連携するのかで、必要な専門性と費用が変わります。

発注前には、「サイトを刷新したい」という表現を、業務上の目的に置き換えます。たとえば、複数ブランドのページ更新を共通化したい、海外販社へ承認済み素材を配布したい、商品情報をPIMから各チャネルへ再利用したい、マーケティング部門だけで更新できる状態にしたい、といった形です。目的が明確になると、必要な機能と不要なカスタマイズを区別しやすくなります。

対象範囲は、Webサイトの数、国・言語、ページ数、アセット数、月間の更新件数、利用者の権限、承認経路、外部システム、旧URLの引き継ぎまで書き出します。ヤマハ株式会社はAEMで約10万点のアセットを管理し、世界の販社や特約店との共有に活用しています（出典: Adobe公式「ヤマハ株式会社のユーザー事例」、2020年掲載）。このような規模では、CMS構築だけでなく、メタデータ設計や権利管理も発注対象になります。

AEMの発注では、すべてを開発会社へ任せるか、すべてを自社で行うかの二択にしないことが大切です。企業側が決めるべきなのは、ブランド・コンテンツの責任者、承認ルール、移行対象、運用KPI、個人情報の扱いです。一方、AEMのアーキテクチャ、Cloud Manager、コンポーネント開発、Dispatcherや配信設計、データ移行自動化などは、経験のある委託先へ任せるほうが安全です。

現場の編集者が使わない高機能な仕組みを作らないため、発注前に実際の更新担当者を交えたデモを行います。ニュース掲載、翻訳依頼、画像差し替え、承認、公開後の修正という日常業務を試し、誰がどの画面で何をするかを確認します。デモを省略して機能一覧だけで決めると、稼働後に操作教育や追加改修が増え、当初の想定より外注依存が強くなります。

AEMの発注形態はどの方法が適していますか？

AEMの発注形態は、要件が固まっている範囲は請負型、変化が大きい範囲は準委任型、専門家を一定期間確保したい場合はラボ型や常駐型を組み合わせる方法が適しています。AEMの導入全体を一つの契約と一つの金額に押し込めるより、企画・設計・開発・移行・運用改善の性質に合わせて分けるほうが、変更時の判断がしやすくなります。

一括請負型は、要件定義書や基本設計書をもとに、決められた機能を決められた納期と金額で納品してもらう契約です。ページテンプレートの種類、コンポーネント一覧、権限設定、連携仕様、移行件数、テスト項目などを確定できる場合に向いています。発注側は、成果物の受け入れ条件と、仕様変更が発生した場合の追加見積ルールを必ず確認します。

ただし、旧CMSのデータ品質や現場の運用が分からない段階で、移行を含むすべてを一括請負にすると危険です。調査後にページ数が増えたり、URLの例外が見つかったりすると、変更契約になりやすいためです。最初に現状診断と小規模な移行検証を準委任で実施し、その結果をもとに本開発を請負へ移す段階契約が現実的です。

準委任型は、稼働時間や役割を定め、設計・開発・移行支援などの業務を一定期間委託する形です。AEM Cloudへの移行方式、標準コンポーネントの採用範囲、Headlessと従来型配信の使い分けなど、調査しながら決める課題に向いています。毎月の作業時間、参加する職種、成果物の定義、報告方法を契約書や作業計画書で明確にします。

準委任型は柔軟である一方、成果が見えにくくなることがあります。月次で、決定事項、未決事項、消化工数、リスク、次月の成果物を報告してもらい、定例会で承認します。AEM導入の判断を先延ばしするための契約ではなく、次の請負範囲を確定するための調査契約として使うと、費用を管理しやすくなります。

おすすめしやすいのは、(1)現状診断・RFP支援、(2)要件定義・基本設計、(3)開発・移行、(4)テスト・教育、(5)運用改善という段階発注です。各段階の終了条件と次段階へ進む判断基準を決めます。たとえば、移行対象の一覧、サイト構造、コンポーネント方針、連携先、非機能要件が承認されたら開発へ進むという形です。

この方式では、発注側が各段階で意思決定でき、受託側も不確定な要件を含めた過大なリスク費用を見積もらずに済みます。反対に、段階ごとに責任の境界が曖昧だと、要件定義の抜けを開発会社同士が押し付け合うため、設計書、移行仕様、テスト計画、ソースコード、運用マニュアルの所有者と納品時期を最初から定めます。

AEMのRFPと要件整理は何を書けばよいですか？

RFPでは、機能要件だけでなく、移行・運用・セキュリティ・納品物までを一つの案件情報として示します。Adobe公式のAEM Sites価格ページは定額表ではなく、機能やアドオンを確認したうえで導入相談を受ける形式です（出典: Adobe公式「Adobe Experience Manager Sitesの機能と価格」、2026年参照）。そのため、RFPの情報量が少ないほど、各社の見積条件がばらばらになり、価格比較が難しくなります。

機能要件は「AEM Sitesを導入する」ではなく、利用者が何をできる必要があるかで書きます。編集者がテンプレートを選び、コンポーネントを配置し、プレビューを確認して承認依頼を出すこと、承認者が差し戻し理由を記録すること、公開後に更新履歴を追えることなどです。Assetsを使う場合は、登録時のメタデータ、タグ、権利期限、派生画像、ダウンロード権限、外部共有の期限まで決めます。

連携要件は、CRM、PIM、MA、分析、翻訳、検索、会員基盤などのシステム名だけでなく、データの向き、更新頻度、失敗時の再送、認証方式、責任分界を記載します。GraphQL APIやイベント、Webhookを使う場合は、誰がデータモデルを管理し、APIの変更をどの手順で通知するかも必要です。連携先の担当者をRFP説明会へ招くと、後工程の想定外作業を減らせます。

非機能要件には、表示速度、可用性、ピーク時のアクセス、バックアップ、災害復旧、監査ログ、脆弱性対応、データ保持、サポート時間を含めます。「大規模アクセスに対応」と書くのではなく、通常時とキャンペーン時のPV、同時接続の想定、復旧目標時間、許容できるデータ損失を記載します。数値を決められない場合は、受託側に前提条件と測定方法を提案してもらいます。

AEM as a Cloud Serviceは、Cloud ManagerによるCI/CD、標準CDN、容量の自動拡張、継続的な製品アップデートなどを備えます（出典: Adobe Experience League「Introduction to Adobe Experience Manager as a Cloud Service」、2026年6月更新）。ただし、クラウド側の機能があることと、企業側の設定・権限・コンテンツ運用が自動で安全になることは別です。SSO、製品プロファイル、IP制限、ログの確認者、インシデント時の連絡ルートをRFPへ落とし込みます。

移行では、現在のページ数をそのまま移す前提を置かないことが重要です。URL、タイトル、説明文、見出し、画像のalt、構造化データ、公開日、言語、権利期限、リンク切れを棚卸しし、移行、統合、再作成、廃棄に分類します。ページ数が少なくても、表記揺れや古い画像が多いとクレンジング工数が増えるため、サンプルデータで実際の変換を検証します。

移行ツールを使う場合も、変換が正しいかを確認する責任者を決めます。旧URLから新URLへのリダイレクト、検索エンジンへの影響、公開状態、権限、翻訳、リンク先の引き継ぎを本番前に検査します。移行仕様書に対象外のコンテンツと例外処理を明記すると、「自動移行できると思っていた」という認識違いを防げます。

AEM開発の契約形態と契約書で確認する項目

契約形態は、発注側が負うリスク、受託側が負う責任、仕様変更の扱いを決める基礎になります。名称だけで判断せず、作業範囲、成果物、検収、再委託、知的財産、秘密保持、個人情報、損害賠償、契約終了時の引き継ぎまで確認します。Adobeのライセンス契約と開発会社との委託契約は別物であるため、どちらに何が含まれるかを分けて管理します。

検収条件には、画面が表示されることだけでなく、権限別の操作、承認・公開、レスポンシブ表示、連携データ、移行後のURL、性能、ログ、エラー時の挙動を含めます。受け入れテストのシナリオ、実施者、期限、重大度ごとの未解決不具合の扱いを決めると、稼働直前の「完成したかどうか」の議論を避けられます。

仕様変更は、変更内容、影響範囲、追加費用、納期、承認者を記録する変更管理票で管理します。標準コンポーネントを独自仕様へ変更する場合は、今後のAEMアップデートや別サイト展開への影響も評価します。要望をすべて追加するのではなく、目的に対する効果と、標準機能で代替できるかを定例会で判断します。

納品物は、画面だけではありません。要件定義書、サイトマップ、画面仕様書、コンポーネント仕様、コンテンツモデル、連携仕様、移行仕様、テスト結果、Cloud Managerの設定、運用手順書、教育資料、ソースコード、ライセンス一覧を対象に含めます。納品形式と更新責任者が決まっていない資料は、稼働後に使われなくなります。

ソースコードや設定ファイルを誰が利用・改修できるか、第三者へ引き継げるか、再委託先の成果物を受け取れるかも重要です。特定の開発会社しか保守できない設計になっていないかを確認し、AEMの標準機能と自社固有の成果物を分けて一覧化します。契約終了時に、アカウント、環境、リポジトリ、ドキュメント、未解決課題を引き渡す条項も追加します。

保守契約では、障害の受付時間、一次回答、復旧目標、対象環境、定期点検、脆弱性対応、AEMのアップデート検証、バックアップ確認、問い合わせ対応を分けて記載します。AEM Cloudでは基盤の一部をAdobeが管理しますが、コンテンツの誤公開、権限設定、独自コード、外部連携の障害までAdobeが責任を負うわけではありません。Adobe、開発会社、自社の責任分界表を作成します。

内製化を目指す場合は、運用開始後に何を自社で担うかを契約へ含めます。編集者向けの操作教育だけでなく、開発者向けのリポジトリ運用、テスト、デプロイ、ログ確認、障害切り分けまで対象にします。電通デジタルの公開事例では、AEM導入により専門知識を持たないスタッフでも更新でき、オウンドメディアの更新頻度が1.2倍になったとされています（出典: Adobe公式「株式会社電通デジタルのユーザー事例」、2026年参照）。

AEMの費用相場はいくらですか？

AEMの費用は、公式の一律料金ではなく、ライセンス構成と案件条件に応じた個別見積です。2026年時点のAdobe公式ページも、Sitesの機能、アドオン、SLAなどを示したうえで「導入の相談」を受ける形式で、定額の日本円価格を公開していません。したがって、以下の金額は公式定価ではなく、公開情報に基づく記事用の試算として扱います。

費用は、AEM SitesやAssetsなどのライセンス、要件定義・設計、コンポーネント開発、外部連携、コンテンツとアセットの移行、テスト、教育、運用改善に分けます。ノートで参照した海外実装パートナーの2026年市場推定では、AEMの年額ライセンスはエントリー層で約3万ドル、Sites・Forms・Assetsを組み合わせる構成では10万ドル超、実装費は初年度ライセンスの2〜4倍が目安とされています（出典: scandiweb「Adobe Experience Manager for eCommerce in 2026」、2026年）。これはAdobe公式価格ではなく、為替や契約条件で変わる推定です。

この推定を1ドル=150円で機械的に換算すると、ライセンスだけで年450万円程度から、複数モジュールでは年1,500万円超が一つの目安になります。ただし、為替を固定した試算であり、実際の契約価格を保証しません。ライセンスが安く見える見積でも、移行、環境数、ストレージ、追加モジュール、監視、保守が別料金なら、3年間の総支払額は大きく変わります。

公開推定と一般的な企業システムの費用感を組み合わせた場合、単一サイトのPoCや小規模導入は、ライセンス・設計・開発・少量移行を含めて1,000万〜3,000万円程度、中規模の企業サイト刷新は3,000万〜1.2億円程度、大規模なグローバル基盤は1.2億〜5億円以上が試算レンジになります。これはAEMの公式相場ではなく、ページ・アセット数、言語数、PV、連携、環境数、カスタム開発の条件を置いた推定です。

期間も、PoCなら3〜8か月、中規模なら8〜18か月、大規模なら18〜36か月以上が一つの検討目安です。電通デジタルの公開事例では、サイト制作に約5か月、旧サイトからのデータ移行に約2か月を要しています（出典: Adobe公式「株式会社電通デジタルのユーザー事例」、2026年参照）。ただし、既存コンテンツの品質や承認体制が異なるため、この期間をそのまま自社案件へ当てはめてはいけません。

見積比較では、初期費用だけでなく、ライセンスの3年分、保守・改善、追加環境、監視、翻訳、アセット整理、セキュリティ診断、教育、社内担当者の工数を合算します。初期開発費の年10〜20%を改善・保守枠として確保する一般的な考え方もありますが、AEMの公式料金ではありません。Cloud Serviceの基盤運用が含まれる部分と、自社が別途負担する運用作業を分けて確認します。

たとえば、見積Aは初期費用が安くても、移行対象が少なく、追加ページや連携が時間単価となっているかもしれません。見積Bは初期費用が高くても、移行リハーサル、教育、運用改善、アップデート検証が含まれている可能性があります。総額だけでなく、含まれる作業、除外条件、単価、再見積の条件を同じフォーマットへ揃えて比較します。

AEMの委託先を選ぶときのポイント

委託先は、Adobeの販売代理店かどうかだけでなく、実装・移行・連携・運用を自社案件として管理できるかで選びます。AEM Sitesの画面を作れる会社でも、Assetsの権利管理、Cloud Managerのデプロイ、PIMやCRM連携、SEO移行、編集者教育を経験しているとは限りません。提案書で担当領域と実績の範囲を確認します。

実績は「AEMの導入実績があります」という一文だけでなく、サイト数、言語数、ページ・アセット数、採用した製品、移行量、連携先、制作期間、運用体制を聞きます。公開事例と提案会社の実績が同じ内容か、実際に担当した範囲がどこかも確認します。守秘義務で社名を出せない場合でも、規模と課題を匿名化して説明できる会社は比較しやすいです。

提案時の営業担当者だけでなく、アーキテクト、AEM開発者、移行責任者、運用設計者が誰になるかを確認します。契約後に別のメンバーへ交代する場合の条件、必要なAEM経験、Cloud ServiceとAEM 6.5系の対応実績、再委託の有無も質問します。技術者が早い段階から参加すると、見積の前提と実装上の制約が一致しやすくなります。

良い提案は、要望をすべてカスタム開発へ置き換えません。編集可能テンプレート、コアコンポーネント、スタイルシステム、コンテンツフラグメント、標準の翻訳・承認機能で実現できる範囲を示し、独自コンポーネントや連携アプリが必要な理由を説明します。標準を活用すると、アップデート時の検証範囲や別サイトへの展開負担を抑えやすくなります。

カスタム開発が必要な場合は、開発費だけでなく、テスト、保守、将来のAEMアップデート、性能、アクセシビリティ、他ブランドへの再利用性を評価します。見積書に「画面一式」や「機能一式」としか書かれていない場合は、コンポーネント数、状態数、入力項目、権限、エラー処理、デザイン調整回数を明細化してもらいます。

複数社へRFPを配るときは、回答フォーマットをそろえます。ライセンス、要件定義、設計、開発、移行、テスト、教育、保守、追加作業の単価、除外事項、前提条件、体制、期間を同じ項目で回答してもらいます。価格だけでなく、顧客側に必要な作業量、承認待ちの扱い、データ提供の期限、遅延リスクも確認します。

提案内容は、3年TCOと案件の適合度で評価します。大規模なグローバル案件の実績がある会社が、単一サイトの内製化支援に最適とは限りません。逆に、国内の運用定着に強い会社が、複雑なAdobe製品連携や大量アセット移行を単独で担えるとも限りません。案件の規模、変革範囲、社内人材、公開時期を評価軸にして、価格と技術のバランスを判断します。

AEMの発注から稼働までの進め方

AEMの発注は、候補会社を探す前の準備で成否が決まりやすくなります。発注側の意思決定者、業務責任者、IT責任者、コンテンツ責任者をそろえ、誰が何を決めるかを定めます。開発会社に任せるのは実装作業であり、業務の優先順位やブランド方針まで丸投げしないことが重要です。

RFPには、背景、目的、対象範囲、現状構成、利用者、ページ・アセット数、言語、更新量、連携先、希望時期、予算の考え方、非機能要件、納品物を記載します。予算を確定できない場合でも、PoC、中規模刷新、全社基盤のように複数の想定ケースを示すと、各社が前提を置いて回答しやすくなります。

評価基準は、価格、類似実績、AEMの技術力、移行方法、標準機能の活用、体制、運用・内製化支援、セキュリティ、契約条件に分けます。価格だけで決めると、必要な作業を除外した見積が有利に見えるため、事前に配点や最低条件を決めておきます。提案説明会では、同じ質問を全社へ行い、回答の具体性も記録します。

契約後は、最初にサイト構造、コンテンツモデル、権限、承認、テンプレート、コンポーネント、連携方式を設計します。画面デザインを先に増やすのではなく、編集者がコンテンツをどの単位で作り、どのサイトやチャネルへ再利用するかを決めます。AEM as a Cloud Serviceでは、Cloud Managerのパイプラインとコード品質チェックを前提に、開発・ステージング・本番の流れを設計します。

設計段階で、代表的なページ、複雑な承認、外部連携、移行データを使ったスパイク検証を行います。標準コンポーネントで足りない部分だけをカスタム開発し、実装後のアップデート検証や運用手順を確認します。技術的に作れる機能ではなく、業務上の効果、保守性、再利用性を基準に採用可否を判断します。

移行は最後に一度だけ実施するのではなく、サンプル、リハーサル、本番移行の順に行います。サンプルで変換ルールを決め、リハーサルで件数と時間、エラー、リダイレクト、権限、公開状態を検証します。本番移行では更新停止時間、差分データ、切り戻し条件、関係者への連絡を決めます。

テストは、開発会社だけでなく、編集者、承認者、IT部門、連携先の担当者が業務シナリオを実行します。公開後の検索、フォーム送信、分析計測、画像表示、権限、翻訳、モバイル表示も確認します。操作教育では、マニュアルを渡すだけでなく、実際のコンテンツを作成してもらい、運用開始後に質問が集中する箇所を修正します。

セキュリティと運用ガバナンスを契約へ入れる

AEMを外注する場合、Adobeのクラウド基盤に任せられる部分と、企業が設計・運用する部分を分けて考えます。AEM CloudではIMSやSSO、役割と製品プロファイル、ネットワーク、コード品質、監査、脆弱性対応、障害時の連絡を具体化します。個人情報を扱う場合は、データの保存場所、外部サービスへの提供、委託先・再委託先、保持期間、削除手順も確認します。

権限設計は、役職名ではなく業務で分けます。サイト全体を管理する人、ブランドごとに編集する人、翻訳を依頼する人、承認する人、公開を実行する人、Assetsを閲覧・ダウンロードする人を分け、異動や退職時の削除手順を定めます。管理者権限を開発会社へ恒久的に渡すのではなく、作業時の申請・承認・記録を残します。

監査ログは、誰がいつ何を変更し、誰が承認し、いつ公開したかを追跡できるようにします。フォームや会員情報を外部システムへ連携する場合は、AEM内に保存する情報を必要最小限にし、暗号化、マスキング、ログへの個人情報出力防止、テストデータの匿名化を確認します。個人情報保護委員会のガイドラインを踏まえ、海外の第三者や再委託先への提供がある場合の確認責任を契約へ記載します。

稼働後は、更新時間、公開リードタイム、差し戻し件数、検索利用、アセット再利用率、フォーム完了率、障害件数などを確認し、改善テーマを決めます。AEMの機能を増やすことを目的にせず、コンテンツの品質、公開速度、ブランドの一貫性、問い合わせやコンバージョンへの効果を見ます。

月次または四半期ごとに、運用担当者、IT部門、開発会社、Adobe製品の担当者が参加するガバナンス会議を開きます。新しいカスタム開発を採用する前に、標準機能、設定変更、運用ルール、外部ツールで代替できないかを検討します。継続アップデートに対応するため、リリース前の回帰テストと、変更履歴を残す運用を契約上の作業へ含めます。

よくある質問

AEMの発注では、価格、期間、開発会社、クラウドの選び方に関する質問が多くあります。最後に、発注前に判断しやすいよう、特に確認されやすいポイントをまとめます。

AEMの公式価格は一律公開されていないため、Adobeまたは販売・実装パートナーへ、Sites・Assets・Formsなどの範囲、利用規模、環境数、アドオンを伝えて個別見積を取ります。開発費は別途、要件定義、カスタム開発、移行、連携、教育、保守を分けて見積してもらい、3年TCOで比較することが重要です。

新規導入では、Adobeが継続アップデートや自動拡張、Cloud Managerを提供するAEM as a Cloud Serviceを第一候補にし、固定的なインフラ要件、既存資産、ネットワーク、データ所在、運用方針を照合します。AEM 6.5系が必ず安い、またはCloudが必ず適するとは限らないため、サーバー構成の自由度とアップデート対応の負担を含めて比較します。

比較可能なRFPを用意できる場合は、3〜5社程度へ同時に依頼すると、価格と提案の違いを把握しやすくなります。社数を増やすことより、AEM Cloud、Sites・Assets・Forms、移行、外部連携、運用内製化など、自社の重要条件に合う会社を選ぶことが大切です。最終候補には、実装担当者との技術確認と、過去案件の運用体制を質問します。

相談できますが、目的、対象サイト、ページ・アセット数、言語、既存システム、希望時期、困っている業務を最低限まとめておくと、提案の精度が上がります。RFP作成支援や現状診断を先に準委任で依頼し、その成果物を使って本開発の見積を取る方法もあります。相談段階で、調査の成果物と費用、作成した資料の利用範囲を確認します。

まとめ

Adobe Experience Managerのシステムを発注・外注するときは、ライセンスの安さではなく、実現したい業務、移行対象、連携、運用体制を明確にすることから始めます。AEM Sites、Assets、Formsの範囲と、AEM Cloudまたは6.5系の選択を整理し、RFPへ機能要件・非機能要件・移行要件・納品物を記載します。

契約は、調査・要件定義・開発・移行・教育・運用改善に分け、確定した範囲は請負型、検証しながら決める範囲は準委任型とする方法が適しています。見積は初期費用だけでなく、ライセンス、追加開発、保守、教育、社内工数を含む3年TCOで比較します。数字は案件条件で変わるため、公開推定を公式価格と混同せず、個別見積で検証します。

次は、現行サイトとアセットの棚卸し、関係者の整理、RFPの初稿作成、3〜5社への相談です。提案を受ける際は、標準機能とカスタム開発の境界、担当者、移行方法、検収条件、保守SLA、契約終了時の引き継ぎまで確認します。発注後も、編集者を含むチームでデモと受け入れテストを行えば、現場が使い続けられるAEMのシステムへ近づけます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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