「SAPの保守費用が毎年膨らんでいるが、移行コストを考えると踏み切れない」「20年以上稼働してきた基幹システムを刷新したいが、業務を止められない」――CIOやERP管理者がこのジレンマに直面するのは、基幹システムのリアーキテクチャが通常のシステムリアーキテクチャとは根本的に異なる難しさを持つからです。ガートナーの2025年調査では、ERPシステムを保有する企業の68%が「現行ERPアーキテクチャが将来のビジネス変化に対応できない」と回答している一方、実際にリアーキテクチャに着手できているのはわずか23%に留まっています。その最大の理由が、業務継続性の担保と複雑なカスタマイズ・アドオンの扱いです。

基幹システムは会計・人事・生産管理・購買といった企業の根幹業務を支えており、1日でも止まれば経営への打撃は計り知れません。さらにSAPやOracleのERPは、10〜20年にわたる業務改善の過程で積み重なったカスタマイズやアドオンが無数に存在し、それらの暗黙知は移行先でどう扱うかが最大の課題です。本記事では、SIパートナーとして多数のERP・基幹システム移行プロジェクトを支援してきた知見をもとに、業務を止めずに進めるリアーキテクチャの具体的な手順と、ERP特有の課題への対処法を体系的に解説します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・基幹システム/ERPリアーキテクチャの完全ガイド

基幹システム/ERPリアーキテクチャとは

基幹システム/ERPリアーキテクチャとは、会計・人事・生産管理・購買・販売管理といった企業の中核業務を支えるシステムの根本的なアーキテクチャ構造を再設計するプロセスです。単に新しいERPパッケージに乗り換える「リプレース」や、バグを修正する「メンテナンス」とは異なり、業務ロジックの境界設計、データモデル、外部システムとの統合パターン、そしてカスタマイズの扱い方そのものを根本から見直す取り組みです。ERPリアーキテクチャが一般的なシステムリアーキテクチャと大きく異なるのは、ビジネスロジックの複雑性の質と量にあります。ECサイトや社内ツールのリアーキテクチャとは異なり、ERPには会計基準（IFRS・J-GAAP）に準拠した仕訳ロジック、税務上の要件を組み込んだ計算処理、工場ラインの稼働スケジュールと連動した生産計画ロジックなど、外部規制・業界慣行・企業固有の業務ルールが三重に絡み合った複雑な処理が無数に存在します。

ERPリアーキテクチャが特に難しい理由として、大きく三点が挙げられます。第一に「カスタマイズ・アドオンの問題」です。SAPやOracleなどの大型ERPパッケージは、標準機能だけでは業界固有の要件や企業独自の業務フローをカバーできないため、ABAPやPL/SQLによる膨大なカスタムコードが積み重なります。経産省の2023年調査によれば、国内大手製造業のSAP環境では平均で5,000本以上のカスタムプログラムが存在し、そのうちの約30%は開発当初の仕様書が存在しないと報告されています。これらの「暗黙知化したビジネスロジック」をどう移行先に引き継ぐかが最大の課題です。第二に「業務カレンダーによる制約」です。月次決算、四半期報告、年次決算、税務申告といった業務上の締め処理は、特定の日時に行わなければならず、その前後には大規模な移行作業を行うことが事実上不可能です。ERPリアーキテクチャのタイムラインは、このカレンダー制約に強く縛られます。第三に「データモデルの複雑性」です。ERPのデータベースはSAPだけでも数万テーブルを持ち、テーブル間の参照整合性が高度に複雑に絡み合っています。このデータ構造をそのまま移行するか、新しいモデルに正規化するかによって移行難易度が大きく変わります。

2024〜2026年にかけてERP業界で最も注目されているアーキテクチャの方向性が「コンポーザブルERP」です。これは、従来の一枚岩（モノリシック）なERPパッケージに代わり、会計・人事・生産管理・在庫管理といった業務領域ごとに最適なクラウドサービスを組み合わせて構築するアーキテクチャです。ガートナーはこのコンポーザブルERPを「2025年以降のERP戦略の主流」と位置づけており、実際にWorkday（人事・財務）、Anaplan（計画・予測）、Salesforce（顧客管理）、NetSuite（財務管理）といったBest-of-Breed型のSaaSを組み合わせることで、SAPのオールインワンパッケージへの依存度を段階的に低減していく企業が増えています。コンポーザブルERP移行の最大のメリットは、イノベーションのスピードです。全業務をカバーする大型ERPはリリースサイクルが年1〜2回に限定されますが、専業クラウドサービスは月次・週次での機能更新が可能です。また、特定のベンダーへの過度な依存（ベンダーロックイン）を分散できるリスクヘッジ効果もあります。ただし、複数のクラウドサービスを統合するための「統合基盤（iPaaS）」の設計と維持にはそれなりの技術投資が必要であり、すべての企業にとっての解答ではないことも理解しておく必要があります。

ERPリアーキテクチャの5つのフェーズ――業務影響を最小化する進め方

ERPリアーキテクチャを業務を止めずに成功させるためには、フェーズごとに目標と成果物を明確にし、業務カレンダーと整合させた計画が不可欠です。以下に示す5フェーズのアプローチは、月次決算・年次決算への影響を回避しながら段階的に移行を進めるための実践的なロードマップです。全体の所要期間は、規模によって異なりますが、中堅企業（売上500億〜2,000億円規模）で24〜48か月、大企業では36〜60か月が現実的な目安です。

ERPリアーキテクチャ最初のフェーズは、現行システムの「現状把握」です。このフェーズで最も重要かつ時間を要する作業が、カスタマイズ・アドオンの棚卸しです。SAPであればSAP Solution Manager、OracleであればOracle Enterprise Managerを活用してカスタムオブジェクトを一覧化し、各カスタマイズについて（1）何のためのカスタマイズか、（2）現在も利用されているか、（3）移行先でも必要か、（4）標準機能で代替できるか、の4点を評価します。この棚卸しには、現場の業務担当者とのヒアリングが不可欠です。IT部門だけで判断すると、実際には使われていないカスタマイズが「必要」と誤分類されるケースや、逆に業務上不可欠なカスタマイズが「不要」と誤判断されるケースが頻発します。棚卸しの結果、カスタマイズを「A：標準機能で代替可能」「B：移行先で再実装が必要」「C：廃止可能」の三区分に分類します。経験上、全カスタマイズの40〜60%がA（標準機能代替）またはC（廃止）に分類できるケースが多く、実際に移行先で再実装が必要なBの数を早期に確定することが工数見積もりの精度に直結します。また、このフェーズでは「業務カレンダーのリスクマップ」も作成します。月次決算の締め処理（月末から翌月5営業日）、四半期報告（四半期末から2か月）、年次決算（期末から3か月）、税務申告（法定期限前後2か月）を時系列でマッピングし、移行作業の「禁止期間」と「低リスク期間」を明確化します。これによって、カットオーバーのウィンドウを年間スケジュールに事前に確保することができます。

フェーズ2では、フェーズ1の棚卸し結果をもとに、移行先のアーキテクチャと移行戦略を決定します。ERPのリアーキテクチャにおける移行戦略は、大きく三つのパターンに分類されます。第一のパターンは「SAP S/4HANA等の最新版ERPへのアップグレード」です。既存のSAP ECC 6.0からSAP S/4HANAへの移行がその代表例で、同一ベンダーのプラットフォームを維持しながら技術基盤を刷新します。ベンダーのサポートを受けやすい反面、カスタマイズの多くが移行先で互換性の問題を抱えるリスクと、引き続きSAPへのベンダーロックインが継続するという課題があります。第二のパターンは「コンポーザブルERP移行」です。業務領域ごとに最適なSaaSを選定し、APIで統合するアプローチです。SAPを段階的に縮小しながら、財務はWorkday、製造実行はクラウドERPに段階移行するといった方法が典型例です。第三のパターンは「スクラッチ・クラウドネイティブ基幹システムの開発」です。業界特有の要件が非常に強く、既製パッケージでは対応困難な場合に選択される選択肢です。この場合、ドメイン駆動設計（DDD）に基づいて業務境界を明確に定義し、マイクロサービスまたはモジュラーモノリスとして開発します。どのパターンを選ぶかは、現在のカスタマイズ量、ベンダーロックインへの許容度、DX投資の優先度、社内の技術力によって決まります。技術選定に加えて、このフェーズではデータモデルの移行設計も行います。特にマスターデータ（得意先マスタ・品目マスタ・勘定科目マスタ）の正規化方針と、トランザクションデータ（受注・発注・仕訳）の移行スコープ（全件移行か直近N年分か）を決定することが、後工程のデータマイグレーション設計に大きく影響します。

ERPリアーキテクチャで最も工数がかかり、かつ最もリスクが高いのがデータマイグレーションです。このフェーズを軽視してプロジェクト後半に追い込まれるケースが、ERP移行プロジェクトの失敗の最大要因の一つです。IPAの2024年「情報システム・ソフトウェア取引に関する実態調査」によれば、ERP移行プロジェクトにおける工期超過の64%が「データ移行の問題」に起因していました。データマイグレーション設計の最初のステップは「データプロファイリング」です。現行ERPの全テーブルについて、レコード件数、Null値の割合、データ型の一貫性、参照先が存在しない外部キー（孤立レコード）、重複レコードの存在を調査します。このプロファイリングによって、現行データの品質問題が可視化されます。典型的な問題として発見されるのは、（1）Shift-JISとUTF-8が混在した文字列データ、（2）「9999/12/31」「0001/01/01」など業務上使われない日付で埋められたデフォルト値、（3）組織変更や事業売却などにより実態と乖離したマスターデータ、（4）会計期間をまたぐ処理の途中状態として残ったレコードなどが挙げられます。これらの問題は、ETL（Extract/Transform/Load）ツール（Talend、DataStage、AWS Glue等）を使って自動変換できるものと、業務担当者が判断しなければならないものに分類し、後者については業務責任者を巻き込んだデータクレンジング作業を計画に組み込みます。マスターデータの正規化については特に慎重な設計が必要です。例えば得意先マスタは、営業部門が管理する「商談先」、経理部門が管理する「請求先」、物流部門が管理する「配送先」が別々に管理されていることが多く、これらを統合CDM（Common Data Model）に集約する際の名寄せ（同一企業の異なる表記を統合する処理）だけで数週間を要するケースもあります。このフェーズでは同時に「業務検証環境」を構築します。新システムの動作を本番環境に近いデータで業務担当者が実際に確認できるサンドボックス環境を用意し、移行済みデータを使ったエンドツーエンドの業務シナリオテストを段階的に実施します。月次決算の業務フローを新システムで一通り実行するリハーサルを少なくとも3回は実施することが、カットオーバー時のリスクを大幅に低減します。

ERPの移行において「ビッグバン移行（全モジュールを一斉切り替える）」は最もリスクの高い選択肢です。しかし現実には、会計モジュールと販売管理モジュールがトランザクションを密に連携しているERPでは、単純な段階移行が難しいケースもあります。そこで実践的な選択肢として「会社コード別段階移行」または「モジュール別段階移行」を軸に設計します。会社コード別段階移行は、連結グループを持つ企業で有効なアプローチです。まず子会社や特定の事業セグメントを先行移行し、本社・主力事業は後続フェーズで移行します。先行移行した会社コードで問題を洗い出してノウハウを蓄積し、本番移行のリスクを低減できます。モジュール別段階移行は、業務間の連携を一時的にAPIブリッジで補完しながら、モジュールごとに順次切り替えるアプローチです。例えば、まず人事・給与モジュールを新システムに移行し、既存ERPの財務会計・購買管理は維持しながら両者をAPIで統合します。半年後に購買管理を移行し、さらに半年後に財務会計を移行するという段階的なアプローチです。カットオーバーのタイミングは、業務カレンダーの「低リスクウィンドウ」に必ず合わせます。多くの企業では第2四半期初頭（7〜8月）が最もリスクが低い時期です。年次決算・税務申告が終わり、次の決算期まで余裕があるこの時期を狙ってカットオーバー日を設定します。並行稼働期間は最低3か月を確保し、新旧両システムでのデータ突合を毎日または週次で実施する体制を整えます。並行稼働コストは一般に移行プロジェクト全体費用の20〜30%を追加で要求するため、予算計画に必ず組み込む必要があります。緊急時のロールバック手順も事前に確立し、本番環境に近い状態でロールバック訓練を実施しておくことが不可欠です。

旧ERPのシャットダウンを完了しても、移行プロジェクトの成果は自動的には維持されません。フェーズ5では、新システムを長期的に健全な状態で維持するためのガバナンス体制を確立します。最初の課題は「カスタマイズの再増殖防止」です。ERPの歴史が証明しているように、移行後に再び無秩序なカスタマイズが積み重なると、10〜15年後に再び同じ問題が再発します。これを防ぐために、カスタマイズの新規追加には「アーキテクチャ審査委員会（Architecture Review Board）」による事前承認プロセスを設けます。標準機能での対応可否を必ず検討した上で、カスタマイズが真に必要な場合のみ承認するルールを定め、承認されたカスタマイズはすべてADR（Architecture Decision Record）として記録します。また、「クリーンコア（Clean Core）」の概念をERPガバナンスに組み込むことも重要です。SAPが推奨するクリーンコアとは、ERPのコアシステムをできるだけ標準機能に近い状態で維持し、カスタマイズはSAP BTP（Business Technology Platform）等の外部プラットフォーム上に分離して実装するアーキテクチャ原則です。クリーンコアを維持することで、ERPの次のバージョンアップ時のコストを大幅に削減できます。SAPの試算では、クリーンコアを実現した企業はアップグレードコストが平均40〜60%削減されるとされています。リスキリングの観点からは、SAPアドミン（ABAPプログラマー）をクラウドネイティブなスキルへ転換させるための組織的な取り組みが必要です。具体的には、BTP開発・APIエコノミー設計・データ統合設計（iPaaS）のスキルを重点的に習得させる6〜12か月のリスキリングプログラムを設計し、実務時間の20%を学習に充てることを公式に認定します。

失敗しないためのポイント――ERP特有の課題と対策

ERPリアーキテクチャは、一般的なシステムリアーキテクチャと比べて失敗リスクが高く、失敗した場合の業務影響も甚大です。2023年にITRが実施した調査では、ERP移行プロジェクトの33%が当初予算を50%以上超過し、17%が計画期間の2倍以上を要したと報告されています。以下では、ERP特有の失敗パターンとその対策を解説します。

SAPやOracleのERPからの移行を検討する多くの企業が直面するのが、ベンダーロックインの「見えないコスト」です。SAP ECC 6.0の延長保守が2027年に終了することを受けて、SAP S/4HANAへのアップグレードを検討する企業が急増していますが、このアップグレードにかかるコストは中堅企業（ユーザー数500〜2,000名規模）で3億〜15億円に達するケースも珍しくありません。この高コストの背景には、ABAPによるカスタムコードの互換性問題（ABAP for S/4HANAでは多くのテーブル構造が変更されているため、既存カスタムコードの多くが修正を要する）と、ライセンスモデルの変更（S/4HANAはNamed User方式からSAPのPricing方式への移行を求めるケースがあり、ライセンス費用が増加しやすい）があります。ベンダーロックインから脱却するためのアプローチとして、完全移行ではなく「段階的機能移管（SAPコアを縮小しながらBest-of-Breed SaaSに機能を移す）」が現実的です。まず人事・給与機能をWorkdayに移管し、SAPの人事モジュールを廃止します。次に販売管理をSalesforce Revenue Cloudに移管します。最後に残った財務会計と購買管理だけをSAP S/4HANAに移行することで、移行対象規模を大幅に縮小できます。このアプローチでは、SAP依存度を段階的に低下させながら、各段階でROIを測定できるという利点があります。一方、複数SaaSの統合コスト（MuleSoft、Boomi等のiPaaSライセンスと構築・運用コスト）も現実的に試算に含める必要があります。統合基盤のTCOを5年で計算すると、多くの場合は年間3,000万〜1億円程度の追加コストが発生します。ベンダーロックイン脱却の「自由」には、統合管理の「複雑さ」という対価が伴うことを経営層と合意した上で進めることが重要です。

ERPリアーキテクチャにおいてAI活用コード解析ツールへの期待が高まっていますが、ERPアドオン特有の暗黙知はAIが最も苦手とする領域です。ABAPコードの静的解析ツール（SAP Readiness Check、SNP Transformation Backbone等）は、カスタムオブジェクトの一覧化とS/4HANAとの互換性チェックには有効ですが、「なぜこのロジックがここに存在するのか」という業務的背景まで解析することはできません。たとえば「得意先が特定の与信区分に属する場合、決算月の月末最終日は与信チェックをスキップする」というロジックがABAPに組み込まれていたとして、AIはこのコードを「与信チェックの条件分岐」として識別できますが、これが「特定の大口顧客との契約上の特例であり、移行先でも継続が必要な要件」であることは判断できません。この問題を解決するために必要なのが「ビジネスロジック発掘セッション」です。現役のERPアドミンや業務担当者を対象に、移行対象のカスタマイズについてAIが生成したコードサマリーを元にインタビューを行い、業務的背景と「移行後に必要かどうか」の判断を収集します。このセッションは、最低でも主要なカスタマイズ上位100件について実施することを推奨します。収集した情報は「ビジネスルール仕様書」として文書化し、移行後のシステムにおける要件定義の一部として活用します。また、ERPの暗黙知は多くの場合、特定のベテラン担当者（しばしば「ERPの神様」と呼ばれる人物）に依存しています。このような人物の退職リスクに備え、移行プロジェクトの初期からナレッジ移転を計画に組み込むことが不可欠です。具体的には、そのエキスパートをプロジェクトチームに専任で参加させ、業務知識を若手メンバーに伝える「シャドーイングセッション」を月20時間以上設けることを標準とします。

業務継続性の確保はERPリアーキテクチャの最大の制約条件です。特に財務会計モジュールの移行においては、決算処理の正確性が法的要件と直結しているため、一切の妥協が許されません。業務影響を最小化するための具体的な設計として、まず「会計年度の境目でのカットオーバー」を原則とします。期中での財務モジュール切り替えは、旧システムと新システムで期中のトランザクションが分断されるため、年度を跨ぐ期次比較ができなくなるリスクがあります。このため、財務会計モジュールは必ず期首（4月1日開始の場合は4月1日）でのカットオーバーを計画します。カットオーバー前の移行リハーサルは、本番データを使った「ドライラン」を少なくとも3回実施します。第1回ドライランは移行スクリプトの動作確認、第2回は実行時間の計測と業務検証、第3回はロールバック手順の確認とカットオーバー判定基準（Go/NoGo基準）の確認を目的とします。Go/NoGo基準は事前に明文化することが不可欠です。「マスターデータの件数が旧システムの99%以上移行完了している」「主要業務フロー20シナリオの業務検証が完了している」「前日比較テストで新旧システムの残高が一致している」など、定量的な合格基準を経営層・業務責任者・ITの三者で合意しておきます。カットオーバー当日は、IT部門と業務部門の合同オペレーションチームを編成し、24時間対応できる体制を整えます。問題発生時のエスカレーションパスと意思決定者を事前に確定し、「ロールバックを決断するのは誰か」「ロールバックの期限は何時か」を明確にしておくことが、有事の際の混乱を最小化します。

ERPリアーキテクチャに伴う人材転換は、プロジェクトの技術的側面と同等に重要な課題です。ABAPを中心としたSAPアドミンのスキルを、クラウドネイティブな技術スタックに転換するためには、組織的な支援と十分な移行期間が必要です。現実的なリスキリングロードマップは3フェーズで設計します。フェーズ1（3〜4か月）では「クラウドとAPIの基礎」を習得します。AWSやAzureのクラウド基礎認定（AWS CLFやAZ-900相当）の取得を目標とし、REST API、JSON、OpenAPI仕様といったAPIエコノミーの基本概念を学びます。SAPのBTP（Business Technology Platform）の基礎も並行して学習することで、SAP知識を活かしたクラウド移行の具体的なイメージを持てるようにします。フェーズ2（4〜6か月）では「iPaaSと統合設計」を習得します。MuleSoft、Boomi、または AWS EventBridge等のiPaaSツールを使った実習を通じて、システム間データ連携の設計と実装を学びます。既存のSAP-周辺システム連携（IDocs/BAPIs等）を新しいAPIベースの統合に置き換える実践的なプロジェクトに取り組みます。フェーズ3（6〜12か月）では「クラウドネイティブ開発とDevOps」を習得します。Pythonまたは TypeScriptを用いたAPIサービス開発、Dockerによるコンテナ化、GitOpsワークフロー、DatadogやAWS CloudWatchによるオブザーバビリティの実践に取り組みます。重要なのは、このリスキリングを「SAPの知識を捨てる」プロセスではなく「SAPの深い業務知識を新しい技術で活かす」プロセスとして位置づけることです。ERPアドミンが保有する業務ロジックの理解とデータモデルの知識は、新システムのアーキテクチャ設計において代替不能の価値を持ちます。技術的な指導は新卒のクラウドエンジニアが担い、業務要件の整理はERPアドミンが主導するという「ペアでの開発」スタイルを採用することで、双方向のナレッジ移転が促進されます。

まとめ

本記事では、基幹システム/ERPリアーキテクチャの定義とERPならではの難しさ、5つのフェーズによる具体的な進め方、そしてERP特有の失敗リスクと対策を体系的に解説しました。基幹システムのリアーキテクチャを成功させる核心は、以下の四点に集約されます。

第一に、カスタマイズ・アドオンの棚卸しを徹底し、「A：標準機能代替」「B：再実装必要」「C：廃止可能」の三区分で全カスタマイズを分類することです。IPAの調査が示すように、適切に棚卸しを行えば全カスタマイズの40〜60%は廃止または標準機能への置き換えが可能であり、移行の真のスコープを大幅に縮小できます。第二に、業務カレンダーの制約を最優先に移行計画を設計することです。月次決算・年次決算・税務申告の時期を「移行禁止期間」として明確にマップし、カットオーバーウィンドウを年間スケジュールに事前確保します。財務会計モジュールは必ず期首でのカットオーバーを原則とし、本番データを使ったドライランを3回以上実施してGo/NoGo基準を経営層と合意した上で臨みます。第三に、データマイグレーションに十分な工数を確保することです。ERPプロジェクト全体の工期超過の64%がデータ移行問題に起因するという事実を真摯に受け止め、データプロファイリングと業務担当者を巻き込んだデータクレンジングのプロセスを計画に明示的に組み込みます。マスターデータの名寄せと正規化だけで数週間を要することを前提に計画を立てることが現実的です。第四に、AIツールを活用しつつも、ERPアドオンの暗黙知は人間が引き継ぐプロセスを設計することです。ビジネスロジック発掘セッションとシャドーイングによるナレッジ移転を計画の一部として明示し、ERPの「神様」に依存したプロジェクト運営からの脱却を図ります。SAPアドミンのリスキリングは、技術的なキャッチアップを支援しながら業務知識を新システムに転写する「ペア開発」で進めることが最も効果的です。

riplaは、基幹システム・ERPのリアーキテクチャにおいて、カスタマイズ棚卸しから段階的移行設計、データマイグレーション、カットオーバー支援、移行後のガバナンス確立まで一貫してサポートするSIパートナーです。「SAPのECC延長保守終了に向けてS/4HANAへの移行を検討している」「ERPの複雑なカスタマイズを整理して段階的に移行したい」「業務を止めない移行計画の設計から伴走してほしい」という方は、ぜひriplaにご相談ください。貴社の基幹システムの現状と業務要件に合わせた最適なリアーキテクチャ戦略をご提案します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・基幹システム/ERPリアーキテクチャの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。