Magentoのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Magentoのシステム開発は、業務整理から運用定着まで6つのフェーズを順に進めます。各フェーズで決めたことを次の工程へ引き継ぐと、業務に沿ったEC基盤を構築できます。

全体像は、Magentoのシステム開発の完全ガイドでも確認できます。

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

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

Magentoのシステム開発の全体像

Magento開発は、業務整理から製品・構成選定、設計・開発、テスト、公開を経て定着へ進みます。各工程で決めたことと、その判断材料を成果物にまとめ、次の工程へ渡します。たとえば、要件整理で決めたデータの正を設計書に反映し、テストで検証したうえで運用マニュアルへ引き継ぎます。

販売業務を動かす基盤としてのMagento

Magentoを検討するなら、まず製品の役割を押さえ、そのうえで開発対象を決めます。

• 業務基盤：MagentoはPHPベースで、商品・価格・在庫・注文・顧客から、販促、コンテンツ、決済、配送までを扱います。
• 開発範囲：一つの基盤にまとめる自社業務を、先に決めておきます。

加えて、顧客別価格や複数ブランド・言語・通貨、外部システムとのAPI連携も扱えます。商品点数が多い企業や、取引先ごとに販売条件が違うBtoB企業では、業務ルールをシステムに落とし込む基盤としてMagentoが検討されます。

無償版はMagento Open Source、商用版はAdobe Commerceです。また、Adobe CommerceはBtoBとBtoCを一つの基盤で扱い、複数のブランドや市場へ広げる用途が示されています（出典: Adobe Commerce公式製品情報、2026年8月確認）。

対象業務を明確にしておくと、見積もりと設計が安定しやすくなります。

Open SourceとAdobe CommerceのTCOによる比較

比較では、ライセンス費に加えて、5年間の運用費を含む総保有コスト（TCO）で見比べます。

• Magento Open Source：ライセンス費を抑えやすい一方、運用を自社か委託先が担います。
• Adobe Commerce：BtoB機能やクラウド、サポートを組み込みやすく、費用は個別見積もりになります。

Open Sourceを選んでも、運用の作業は残ります。サーバーや監視、バックアップ、脆弱性対応に加え、拡張や更新、障害対応も、ライセンス費とは別に発生します。

Adobe Commerceでは、会社階層や権限、共有カタログを標準機能として使えます。顧客別価格や見積、承認も、そこに含まれます。そのため、BtoB向けの機能を個別に作り込む場面が減ります。

比較対象には、5年間のライセンス、インフラ、保守、拡張、パッチ、更新の費用に加えて、社内人件費も含めます。無料版だからといって、総額が必ず安くなるとは限りません。

標準化できる業務が多く、専門人材を確保できる企業では、Open Sourceの自由度が役立つ場合もあります。要件表は「必須」「できれば」「今回は対象外」に分けます。

最初に決めるKPIとデータの責任範囲

KPIは売上だけに絞らず、現場の課題に合うものを選びます。導入前の数値を測っておくと、公開後の投資効果を示せます。

• 業務時間：受注処理や商品登録にかかる時間を見ます。
• 業務品質：在庫差異率や営業への引き継ぎ率を把握します。
• 販売成果：CVRやリピート率を候補に挙げます。

現場の課題には、商品登録の遅さや在庫差異、受注処理などのほか、営業への引き継ぎや問い合わせ対応もあります。

データの正は、商品名や価格、在庫など、対象ごとに決めます。正とするシステムは、PIMやERP、WMSなど、構成によって異なります。各システムの責任を決めたうえで、必要なデータだけをMagentoへ同期します。

Magentoのシステム開発の進め方｜6つのフェーズの順序

6つのフェーズは、要件整理と製品・構成選定から始まります。設計・開発とテストを経て、稼働・公開、定着へと順に進みます。工程は省かず、標準機能の利用と意思決定の明確化で期間を短縮します。

各フェーズに完了条件を置き、未決定の事項を曖昧なまま次へ送らないことが、後戻りの防止につながります。

フェーズ1：要件整理での業務とデータの洗い出し

要件整理では、画面の一覧より先に、受注から出荷、請求、返品、顧客フォローまでの業務の流れを描きます。

業務は、担当部署と使用システムを添えて一つずつ並べます。商品登録や価格改定、在庫引当から、返金と問い合わせ対応まで含めます。

BtoBでは、会社登録と購入担当者の関係から見積、再注文までを業務に含めます。発注承認と掛け払いも、この流れに入ります。

• 業務フロー：業務ごとに、担当部署と使用システムを結び付けます。
• データ要件：要件表に、利用者や使用時期、完了条件まで書き込みます。
• 対象範囲：どの業務まで含め、どれを外すかを確定します。

顧客別価格を扱うなら、作成者や適用開始日、税区分など、価格の決め方を先に固めます。ERPとの同期頻度も、そこに含めます。価格が未登録のときの表示と、変更履歴の保持期間も定めておきます。

ここまで決めると、項目ごとに標準機能、拡張、個別開発のどれで対応するかを分けられます。KPIは3〜5個に絞り、商品や受注などのデータごとに責任者を決めます。

現行データの件数と欠損を把握し、対象外の業務も書き残します。例外処理は、経営と営業、EC運営の代表者に聞き取ります。さらに、CSと物流、経理と情報システムの代表者にも聞き取ります。

フェーズ2：製品・構成選定での5年間の運用比較

候補の製品と構成は、5年間の運用負担も踏まえて比べます。

• 業務規模：BtoB機能やサイト数、SKUを見たうえで、注文数と海外展開も確認します。
• 連携と体制：ERPなどとの接続や、PHPやクラウドを運用できる人材の有無を確かめます。
• 運用責任：パッチ対応を担う人と、保守・更新の方針を決めておきます。

候補は、Magento Open SourceとAdobe Commerceに加えて、自社クラウドやマネージドクラウドを含む構成です。機能表だけで決めず、代表業務をプロトタイプで操作して、現場が迷わないかを確かめます。

Adobe公式では、Magento Open Sourceは基本的なコマース機能を備えた無償版と説明されています。

一方で、Adobe Commerceは、クラウド基盤やホスティング、AIを活用したマーチャンダイジングや分析などを含む製品として案内されています（出典: Adobe「Magento Open Sourceを使い始める」、2026年8月確認）。

商用版でも、要件定義や独自連携、現場教育は必要です。データのクレンジングも、欠かせない作業です。採用製品と不採用理由を記録し、費用の負担や追加サイト、更新方針も合意します。

ヘッドレスやPWAは、表示体験や多チャネル展開に有効です。ただし、保守対象も増えます。採用する場合は、効果を測るKPIと担当人材を確かめます。

フェーズ3：設計・開発での標準機能の優先

設計では画面に加えて、データの構造や権限、連携を定めます。非機能要件も決めておきます。商品属性や会社階層のほか、注文や返品の状態遷移も図にします。

• 連携仕様：方式と送受信元を定め、同期頻度や重複時の扱いも決めます。
• 開発順序：まず標準機能で足りるかを見て、次に設定や検証済みの拡張、最後に個別開発を検討します。
• 納品範囲：どこまでを納品に含めるかを、契約で明記します。

ERP、PIM、CRM、MA、WMS、OMSなど周辺システムとの連携では、APIとファイルのどちらを使うかを選びます。そのうえで、エラー時の再送と監視の方法も決めておきます。

コアコードを直接書き換えると、更新や脆弱性対応の負担が増えます。そのため、拡張機能やAPIで実現できるかを先に調べます。

個別開発では、利用者や入力項目、権限などを仕様に残します。例外処理やログ、将来の削除条件も含めます。管理画面は、登録件数やCSVの利用などを現場に聞いたうえで設計します。

納品物には、画面一覧やデータ項目定義、連携仕様、権限一覧、テスト計画が入ります。インフラ構成図や移行仕様書も、そこに加えます。

フェーズ4：テストと移行リハーサルによる公開リスクの低減

テストでは、業務の正常系と異常系を一連の流れで確認します。

• テスト：単体から脆弱性までの各段階を確認します。
• データ移行：項目の対応と、欠損や重複、表記揺れを確かめます。
• 公開判定：所要時間やエラー、再実行の方法を記録し、切り戻し条件も残します。

商品登録、検索、カート、決済を確かめたうえで、受注連携、出荷、メール、返品、返金まで、主要な業務を通して確認します。テスト担当者の役割も、あらかじめ分けておきます。

旧商品コードとMagentoのSKU、顧客IDなど、データ項目の対応を一覧にします。価格と税区分、在庫、注文履歴も、同じ一覧に入れます。画像、カテゴリ、URLも対象です。件数の一致だけでなく、データの意味も照合します。

データの責任者が不明のままだと、価格や在庫が再び不整合になるため、移行前にデータオーナーを定めます。

公開前には、本番相当データで移行を試しておきます。

公開時の検索関連の設定も確認します。対象は、301リダイレクト、robots.txt、サイトマップ、canonicalです。

計測タグと決済の本番設定も検証します。受入条件は、重大な未解決の不具合がないこと、業務責任者が操作できること、障害時に戻せることです。

フェーズ5：稼働・公開での監視と切り戻しの前提

公開日は、注文が少ない時間帯や、決済会社・物流会社の対応時間、社内承認者の待機可否を踏まえて決めます。

• 公開手順：バックアップから監視開始まで、時系列で書き出します。
• 稼働監視：注文と決済を中心に、在庫や速度、エラーを重点的に見ます。
• 切り戻し：重大障害の条件と注文の扱いを、事前に合意します。

手順書には、バックアップやメンテナンス表示、DNSやCDNの切り替えを順に書きます。決済や配送、初回注文、監視、連絡先も、同じ手順書に記します。さらに、画面画像と確認記録欄も用意します。

稼働直後は、ログインから決済、在庫引当、注文連携、メールまでの流れを見ます。速度やエラー率も併せて確認します。BtoBでは、会社権限、承認前の出荷、顧客別価格の表示を優先して見ます。

決済は、カード情報をMagentoに保持しないトークン化方式も含めて確認します。決済代行会社の要件と、PCI DSS v4.0.1の対応範囲も確かめます。

決済ができないことや在庫の二重引当、価格の誤表示は、切り戻しを判断する例です。基幹へ注文が未連携のままの場合も、切り戻しを判断する例になります。切り戻し後に、注文をどう扱うかも決めておきます。

フェーズ6：定着・改善による導入効果の向上

公開後は、問い合わせ対応に加えて月次レビューを行います。導入前の値とKPIを比べ、改善施策に優先順位を付けます。

• 業務改善：登録手順や権限、価格更新などを、見直しの対象にします。
• 更新計画：次の版に向けて、予算と担当者を先に決めます。
• 引き継ぎ：手順書やアカウント、コードや設計書の管理者を決めます。

商品登録時間や受注処理時間、在庫差異率、問い合わせ件数などのほか、CVRやリピート率も確認します。そのうえで、日々の負担が大きい箇所から改善します。

Adobeのライフサイクル情報では、Adobe Commerce 2.4.8の標準サポート終了は2028年5月31日、2.4.9は2029年5月31日とされています（出典: Adobe Commerce Software lifecycle policy、2026年8月確認）。

導入時の最新版への対応だけでなく、次の更新に必要な作業も見ておきます。その更新に備えるには、検証環境や回帰テスト、拡張機能の互換性確認が必要です。

引き継ぎでは、管理者マニュアルや障害対応表、パッチ適用の手順を用意します。バックアップと復旧、権限申請、データ修正の承認手順も含めます。

ソースコードやリポジトリ、クラウドアカウントなどの保管場所と権限を確認します。対象には、IaCや拡張機能ライセンス、設計書も含めます。そのうえで、四半期ごとに改善項目を見直します。

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

Magentoの費用は、エディションや商品・顧客・注文の数、BtoB機能によって変わります。デザインや連携、移行、クラウド、保守範囲でも差が出ます。要件ごとの幅と前提を並べて比べます。

Adobe Commerceのライセンスやクラウド料金は、売上規模などに応じた個別見積もりです。公開されている構築費だけでは総額は判断できないため、この見積もりを構築費と合わせて確認します。

要件別の初期費用の幅

初期費用は、規模と連携範囲によって300万円台から3,000万円超まで変わります。

• 小規模BtoC：初期300万〜600万円、1〜2か月程度が目安です。
• 中規模BtoB：初期500万〜1,500万円、3〜6か月程度を仮置きします。
• 中〜大規模：初期1,000万〜3,000万円、6〜12か月程度を想定します。
• 大規模・高負荷：3,000万円〜1億円超、9〜18か月以上の可能性があります。

小規模の目安は、標準テーマと既存の拡張を使う構成です。ACROVEの2026年の料金例では、国内BtoCが300万円・1か月、越境BtoCが400万円・1.5か月です。

同じ料金例では、国内BtoBが500万円・1.5か月、越境BtoBが600万円・2か月です。月額費用は15万〜20万円とされています（出典: ACROVE「Magento導入費用とスケジュール」、2026年6月公開情報）。

この料金例には標準構成や素材準備などの前提があり、個別要件は別途確認が必要です。中規模の仮置きは、会社階層や顧客別価格、基幹連携を含みます。見積、承認、掛け払いも対象です。

コウェルのAdobe Commerceスターターパックは、最短3か月、初期1,000万円からです。ただし、Adobe Commerceのライセンスは別途です（出典: コウェル「Adobe Commerce（Magento）構築サービス」、2026年8月確認）。

この価格は、標準機能を活用する場合の比較の目安で、個別案件の確定額ではありません。高負荷やヘッドレス、個別拡張などを含むと、さらに費用が増える可能性があります。

3,000万円〜1億円超の幅は、Magento固有の公表統計ではなく、要件を積み上げて考える仮説です。災害復旧や段階リリースを含む場合も、想定に入れます。

見積もりの工程別比率と対象外

工程ごとの配分を仮に置くと、見積もりの抜けを見つけやすくなります。

• 要件定義：初期費用の10〜15%を仮説として置きます。
• 設計：25〜35%を目安に抜けを確認します。
• 実装・設定：30〜40%を仮置きします。
• 連携・移行・テスト：15〜25%、教育・公開は5〜10%です。

これらは案件ごとに変わる比率の仮の値で、相場の断定値ではありません。設計費が極端に少ないときは、後工程の仕様変更や追加開発に計上されていないかを確認します。

データのクレンジングや画像移行、旧URLの転送は、別項目として確認します。決済審査や税・インボイス、配送接続に加えて、メールと計測も対象に入れます。

脆弱性診断や負荷試験、移行リハーサル、研修などは、対象の範囲を確かめます。「連携一式」や「テスト一式」は、件数や方式を聞いて中身を把握します。回数やエラー対応、完了条件も確認します。

月額費用とアップデート費を含めたTCO

月額費用だけでなく、更新や障害対応を含む総保有コストで判断します。

• 毎月の費用：基盤と監視、保守、サービス利用料を確認します。
• 定期・臨時費用：更新と脆弱性対応、回帰テストを分けて見積もります。
• 契約条件：受付時間、復旧目標、緊急作業費を確認します。

ランニング費には、クラウドやサーバー、CDN・WAFといったインフラのほか、監視やバックアップ、SSL、保守、拡張も含まれます。さらに、決済・配送やメール、分析、改善開発も対象になります。

月額15万〜20万円は、一部の運用プランの例です。Adobe Commerceのライセンスやクラウド、追加開発を含むとは限りません。

従量課金か別契約かは、見積書と保守契約で分けて確認します。保守費は、初期開発費の年10〜20%で仮に置く方法もあります。

年10〜20%は一般的な予算検討のための推定値で、Magentoの実費を保証するものではありません。費用は、SLAと実際の体制から積み上げます。

Magentoのシステム開発で見積もりを取るポイントとチェックリスト

見積もりの精度は、発注側が渡す情報の粒度でも変わります。各社に同じ資料と質問を渡すと、同じ条件で相見積もりを比べられます。

資料には、現行構成図や業務フロー、希望時期、予算上限を揃えます。商品・顧客・受注・在庫の件数や、サイト・言語・通貨、連携先、公開後の体制も含めます。

RFPの業務シナリオと非機能要件

RFPには、機能名だけでなく、利用者が業務を終えるまでのシナリオを記します。

• 業務シナリオ：法人注文から承認、決済、ERP連携まで示します。
• 非機能要件：性能や運用に関する条件を、要件として定めます。
• 販売表示：価格や送料、返品などの条件を要件に含めます。

たとえば、法人の購買担当者が顧客別価格の商品を注文し、上長の承認後に掛け払いで確定して、ERPへ連携する流れを書きます。

成功条件や例外、権限、ログ、手作業の代替手順も書き添えると、提案の違いが分かります。非機能要件では、通常時とセール時のアクセス数も決めます。

同時利用者数や表示時間、注文処理能力、復旧目標を定めます。バックアップ頻度や監視・保守時間も決めます。個人情報やログの保存期間も、要件に含めます。

決済では、PCI DSS v4.0.1と決済代行会社の条件を確認します。カード番号を保存しない方式も含めて、責任範囲を記します。

通信販売では、価格や送料、支払・引渡時期を要件に含めます。返品条件と事業者情報の表示も、要件に入れます。

開発会社の担当者と公開後の体制の比較

開発会社は、実績と技術対応に加えて、実担当者や公開後の移管条件を合わせて比べます。

• 実績と技術：同業案件の経験や、更新、試験の経験を見ます。
• 担当体制：実装者や国内外の役割分担を聞きます。
• 納品と移管：所有者や移管費を確認します。

稼働事例の規模や、ERPやWMSとの連携、移行、負荷試験、セキュリティ対応への取り組みを聞きます。

Adobeの資格や認定者数は、参考情報として扱います。実担当者と稼働率のほか、国内の意思決定者や海外拠点の分担も質問します。

標準機能の活用とコア改変の回避、追加費用の条件を比べます。納品範囲は、設計書やコード、IaC、テスト結果まで含めて比べます。

他社へ移す場合の費用や、アカウントと拡張ライセンスの名義、データの取り出し方も確認します。価格が安い場合は、前提と除外を必ず確かめます。

契約前に固定する追加費用と責任分界

追加費用の前提と対象範囲、承認方法は、契約前に決めておきます。運用上の責任者も、同じ時期に決めます。

• 変更管理：前提が崩れた場合の手順と承認者を決めます。
• 責任分界：どこまでを誰が受け持つかを決めます。
• 検収条件：業務から移行、性能、研修、復旧までを確認します。

追加費用の要因は、要件の追加やデータ欠損、連携仕様の変更などです。決済審査の遅れや拡張機能の互換性、性能不足、運用教育も、要因になります。

見積書には、前提条件と対象件数、対象外を明記します。対応ブラウザや連携回数、テストと修正の回数、納品物も記載します。前提が変わったときの手順も合意します。

商品や在庫などの正データの管理者、連携エラーの一次確認者、パッチの検証・適用者を決めます。

個人情報の委託先管理やアクセス権、漏えい時の連絡、国外拠点でのデータ取扱いも確認します。責任の所在が曖昧だと、障害時に判断が止まります。

検収では、画面が完成しているかだけでなく、受入や移行後の件数照合、注文から出荷までの確認も含めます。性能や診断指摘への対応も、検収の対象にします。

操作研修と復旧手順も確認します。保守契約では、通常対応と緊急対応、更新、改善開発を分けると、予算の管理がしやすくなります。

Magentoのシステム開発に関するよくある質問

費用や期間、製品選び、開発会社の選び方について、発注前によくある質問に答えます。

Magentoは無料でシステム開発できますか？

Magento Open Sourceはライセンス費を抑えられますが、開発まで無料になるわけではありません。

サーバーや設計、デザインの費用がかかります。さらに、拡張や移行、決済・配送連携の費用も必要です。監視やバックアップ、脆弱性対応も必要で、保守費も見込みます。

Adobe Commerceは、ライセンスやクラウドを含めた個別見積もりです。5年間のTCOで比べてください。

Magentoのシステム開発にはどれくらいの期間がかかりますか？

標準テーマ中心の小規模BtoCは1〜2か月程度、BtoBや国内基幹連携は3〜6か月程度が目安です。

多言語、複数ブランド、複数連携を含む案件は6〜12か月程度です。ACROVEは構成別に1〜2か月、コウェルは最短3か月の公開例を示しています。

いずれも、要件や素材、データ準備、ライセンス、審査などの前提があります。

Magento Open SourceとAdobe Commerceはどちらがよいですか？

PHPやインフラを運用でき、BtoB機能や高度なサポートを必須としないなら、Open Sourceが候補です。拡張を自社で管理したい場合も、Open Sourceが候補になります。

会社階層や顧客別価格、承認などを重視する場合や、クラウドやサポートを求める場合は、Adobe Commerceも比べます。最終的には、総額と責任分界で決めます。

Magentoの開発会社は何を基準に選べばよいですか？

同規模・同業種の事例や、ERP・PIM・CRMとの連携経験を確認します。移行や負荷試験、脆弱性対応、保守SLAについても、実績を確かめます。実装者や責任者、公開後の窓口は、誰が担当するのかを聞いておきます。

設計書やテスト結果、コードの所有権も、判断材料です。クラウドアカウントや拡張ライセンスについては、他社へ移せる条件も確かめます。

まとめ：Magentoの開発の6フェーズと運用責任の設計

Magento開発は、要件整理と製品選定から始まる6つのフェーズを順に進めます。設計・開発とテストを経て、稼働から定着へと進みます。KPIやデータの正、権限、連携などを一つの計画にまとめ、公開条件と保守責任も含めます。

標準機能を先に使い、必要な箇所だけ拡張すると、更新と運用が安定しやすくなります。

着手前に確認するチェックリスト

着手前には、目的のKPIや対象業務、主要データの件数と責任者を確認します。製品比較や連携先、公開時期、5年間のTCO、セキュリティ、公開後の担当者も含めます。

要件表は、必須、希望、対象外に分けます。業務シナリオと非機能要件を添えると、見積もりの前提をそろえられます。

最初の一歩は業務フローとデータフローの洗い出し

導入の準備では、現状を把握し、試作品を確認したうえで、Magentoで実現する範囲を判断します。

• 現行業務の把握：遅い業務、不正確なデータ、自動化したい処理を洗い出します。
• 試作品の確認：管理者や営業など現場が操作し、標準機能と個別開発を分けます。
• 適用企業の確認：商品数やBtoB条件が多く、複数ブランドや地域を扱う企業を検討対象にします。

初期費用は、小規模構成の300万〜600万円から、連携や大規模拡張を含む3,000万円超まで幅があります。前提付きの見積もりを比べます。

6フェーズを通じて運用責任と更新予算を決めておくと、公開後も事業の成長に合わせてMagentoを使い続けられます。

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

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