基幹システム・ERPリプレイスは、現状分析から本番切り替え・定着化までの7つのステップで進めるのが基本です。企業の中核業務を支えるシステムを入れ替えるため、一度失敗すると業務が止まりかねません。
ガートナーの調査では、ERPリプレイスプロジェクトの75%が進行中に何らかの失敗を経験しています。
▼全体ガイドの記事
・基幹システム/ERPリプレイスの完全ガイド
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
基幹システム・ERPリプレイスの全体像
基幹システム・ERPリプレイスとは、企業の中核業務を支えるシステムを、新しい製品やアーキテクチャに置き換える取り組みです。対象となるのは、財務・会計、販売管理、購買管理などの業務を担うシステムで、ほかに次のようなシステムも含まれます。
- 在庫管理
- 生産管理
- 人事給与
単なるバージョンアップやハードウェア更新（マイグレーション）とは異なり、業務プロセスそのものを見直して、新しいシステムの業務フローに合わせて組織全体を変えていくプロジェクトです。
プロジェクトの規模は、中小企業でも数千万円、大企業では数億〜数十億円に上ることも珍しくありません。そのため、経営判断として取り組む必要があります。老朽化したシステムへの対応やDX推進の一環として、刷新に踏み切る企業は増え続けています。
リプレイスの2つの目的：守りの投資と攻めの投資
基幹システムのリプレイスを検討する目的は、大きく「守りの投資」と「攻めの投資」の2軸に整理できます。守りの投資とは、老朽化したシステムの保守切れへの対応、ブラックボックス化した属人的な運用の解消、セキュリティリスクの排除など、現状を維持するために必要なリプレイスです。
2025年問題（レガシーシステムによるDX阻害）が広く認識される中で、「今すぐ動かなければならない」と切迫感を持つ企業も多くあります。
一方、攻めの投資は、AI・データ分析の活用、リアルタイムな経営情報の可視化、グローバル展開への対応など、競争力強化を目的としたリプレイスです。鹿島建設がERPによる文書管理一元化で年間100万枚以上の紙書類を削減し、現場と本社のリアルタイム情報共有を実現した事例は、攻めの投資の典型例といえます。
リプレイスを検討すべき5つのサイン
自社の基幹システムがリプレイスの時期かどうかは、次の5つのサインが目安になります。
- 保守・サポートの終了：ベンダーの保守が終わっている、または終わりが近く、セキュリティリスクと直結します。
- ブラックボックス化：改修が積み重なり、誰も全体像を把握できない状態になっています。
- 業務部門からの声：「使いにくい」「手作業が多い」「Excelで補完しなければならない」という不満が蓄積している状況です。
- 報告の遅れ：月次決算やレポート作成に過度な時間がかかり、経営判断が遅れています。
- 既存システムの制約：クラウドやAI活用など新技術への対応が、既存システムの構造上むずかしいことです。
担当者が退職するとシステムを動かせなくなる事態は、多くの企業で深刻な問題です。製造業A社では、月次決算に3週間かかっていたところ、ERPリプレイス後に1週間へ短縮されました。
これらのサインが複数当てはまる場合は、本格的に検討する段階に来ています。
基幹システム・ERPリプレイスの進め方 7ステップ
基幹システム・ERPリプレイスを成功に導くには、体系的なアプローチが不可欠です。進め方は、現状分析から本番切り替えと定着化支援までの7つのステップです。
7ステップに沿って進めることで、後工程での手戻りや想定外のコスト増を防ぐことができます。ステップごとのやることと注意点を、次に示します。
- Step1：現状分析・課題の棚卸し
- Step2：目的・ゴールの明確化とROI算出
- Step3：RFP作成とベンダー選定
- Step4：要件定義（現行踏襲の罠を避ける）
- Step5：設計・開発
- Step6：データ移行・クレンジングとテスト3段階
- Step7：本番切り替えと定着化支援
Step1：現状分析・課題の棚卸し
プロジェクトの第一歩は、現在の業務とシステムの実態を正確に把握することです。現行システムの機能一覧、業務フロー、データ構造、連携しているサブシステムを洗い出します。
特に大切なのは、設計書やドキュメントが最新化されていないケースが非常に多いという現実を認識することです。現行システムのドキュメントが5年以上更新されていない企業は、珍しくありません。だからこそ、この段階で資産を徹底的に棚卸しすることが、後工程での手戻りを防ぐ最大のポイントになります。
現状分析では、機能の一覧にとどめず、「業務上の痛み（ペイン）」を明確にすることも欠かせません。ヒアリングでは、「どの業務に何時間かかっているか」「どこでエラーが起きやすいか」「どの機能が実態に合っていないか」を把握します。この段階での情報収集の質が、後続の要件定義の精度を大きく左右します。
Step2：目的・ゴールの明確化とROI算出
現状分析を踏まえ、リプレイスで何を実現したいかを、具体的な数値目標として定義します。「月次決算を3週間から1週間に短縮する」「手作業の入力工数を月50時間削減する」「在庫差異を現在の2%から0.5%以下に抑える」のように、測定可能なKPIを設定することが大切です。
ERPの導入自体が目的になり、その先の経営課題の解決が見えなくなると、失敗リスクが高まります。ゼネラルリンクでは、複数システムの手作業集計を廃止し、月次決算を約3営業日短縮しました。こうした具体的な効果を事前に試算して示すことが、経営層の承認を得る鍵となります。
ROI（投資対効果）の算出も、この段階で経営層向けに整備しておく必要があります。人件費の削減額は、時給換算せず、社会保険料や福利厚生費を含めた実態コストで見るのが実務的な目安です。各役職の平均給与を2倍にした金額を使います。投資額（システム構築費＋移行コスト＋教育費）に対し、何年で回収できるかという損益分岐点を示すと、稟議が通りやすくなります。
Step3：RFP作成とベンダー選定
ROIの算出と経営承認を得た後は、ベンダー選定のためのRFP（提案依頼書）を作成します。RFPには、リプレイスの背景と目的、現行システムの概要、業務要件と機能要件を明記します。RFPの精度が低いと、ベンダーごとの提案内容がバラバラになり、適切な比較・評価ができません。
非機能要件（パフォーマンス・セキュリティ・可用性）、データ移行の要件、スケジュール、予算上限、評価基準も、RFPに盛り込みます。ベンダー選定では、同業種・同規模のERPリプレイス実績を重視することが大切です。技術力や価格だけでなく、「Fit to Standard（システムの標準機能に業務を合わせる考え方）」を積極的に提案できるかどうかも、評価のポイントになります。
また、プロジェクトマネージャー（PM）の質と担当体制を事前に確認することも欠かせません。ベンダー選定後にPMが入れ替わり、プロジェクトが混乱するケースは実際に多く発生しています。加えて、複数社（最低3社）から相見積もりを取り、金額だけでなく提案内容の質で比較評価することをお勧めします。
Step4：要件定義（現行踏襲の罠を避ける）
要件定義は、ERPリプレイス全体で最も重要で、失敗リスクも高い工程です。多くのプロジェクトが陥る「現行踏襲の罠」とは、現在の業務プロセスをそのまま新システムに移植しようとすることです。
「今やっているやり方をそのままシステムに反映してほしい」という要求は、現場からよく出てきます。しかし、これはERPの標準機能との乖離を生み、過剰なカスタマイズを招く原因になります。そのため要件定義では、「なぜその業務をその方法でやっているのか」という目的レベルまで遡って整理することが求められます。
長年の慣習で続けてきた業務には、合理的な理由がなく、標準機能で十分対応できるものが多く含まれています。この工程では現場のキーパーソンを積極的に巻き込み、業務の「あるべき姿」を描くことが欠かせません。Fit to Standardの考え方を採用すると、カスタマイズコストを大幅に抑えながら、標準的なベストプラクティスに沿った業務プロセスを実現できます。
Step5：設計・開発
承認された要件定義書をもとに、設計と開発を進めます。ERP（SAP、Oracle、Microsoft Dynamics、intra-martなど）では、基本設定（コンフィギュレーション）で対応できる範囲を広げ、残る部分だけをカスタマイズ（アドオン）開発するのが基本です。標準機能のFIT率を80%程度に保つことを目標にすると、開発コストと将来のバージョンアップへの対応コストを抑えられます。
設計フェーズでは、他システムとのAPI連携設計や、共通マスタの設計（取引先コード・品目コード・組織コードの体系統一）も重要な論点です。既存システムが複数あり、コード体系がそれぞれ異なる場合は、この段階でコード統一の方針を決めておかないと、後工程のデータ移行で多大な工数が発生します。
非機能要件（レスポンスタイム、同時接続数、バックアップ頻度など）を設計段階で定め、PoC（概念実証）で性能を検証することも大切です。性能見積もりが甘いと、本番稼働後に大容量データ処理や連携バッチの性能問題が浮上し、工期延伸と大幅な予算超過につながります。
Step6：データ移行・クレンジングとテスト3段階
データ移行は特に失敗リスクが高い工程です。旧システムのマスタと取引データを新ERPに移す前に、データクレンジング（品質向上作業）を徹底します。重複データの統合、表記ゆれの正規化（「株式会社ABC」と「（株）ABC」の統一など）、欠損値の補完、コード体系の変換を行います。
商社E社では、従業員200名規模にもかかわらず20年分の顧客データが3システムに分散し、統合とクレンジングだけで4ヶ月を要しました。データ移行の工数を過小評価すると、遅延につながる典型的なパターンです。テストは「サンプル移行→全件移行→移行リハーサル」の3段階が鉄則です。機能面のテストは、単体→結合→総合→ユーザー受入テスト（UAT）の順に進めます。
サンプル移行では少量のデータで流れを検証し、全件移行で変換精度を確認し、本番と同じ手順のリハーサルで時間と品質を検証します。会計データは、売掛金・買掛金の残高を新旧で照合し、1円単位で一致させます。端数処理の違いなどの微小な差異も、後の監査で問題になることがあるためです。
Step7：本番切り替えと定着化支援
カットオーバー（本番切り替え）は、プロジェクト全体のクライマックスです。切り替えの成功を左右するのは、「切り戻し（フォールバック）基準」の事前設定です。「カットオーバー後72時間以内に受発注データの不整合が発生した場合は旧システムに戻す」といった具体的な判断基準を、経営層を含む関係者全員で合意しておくことが欠かせません。
この合意がないまま本番稼働した食品メーカーAの事例では、新旧データの照合観点の定義不足と、切り戻し基準の未合意のまま稼働した結果、受発注・在庫の不整合が連鎖し、出荷・製造が長期停止しました。
- ハイパーケア期間：本番稼働後の最初の3ヶ月間は専任のサポート窓口を設け、現場からの問い合わせに即時対応できる体制を整えます。
- 定着化支援：教育は稼働前だけでなく、稼働後1〜2ヶ月も継続してフォローアップし、現場の習熟度を高めます。
ユーザーが新システムに慣れるまでの定着化支援も、プロジェクト成功の重要な要素です。フェーズ完了の判定基準には、ILUOフレームワーク（I：指導を受けながら実行できる、L：一人でできる、U：理解して教えられる、O：他者を改善指導できる）を使えます。検証メンバーが「U」レベルに到達しているかを確認する方法も有効です。
移行方式の比較と選び方
ERPリプレイスにおける本番移行の方式は主に4種類あり、自社の状況やリスク許容度に合わせて選ぶことが大切です。方式の選択を誤ると、業務停止リスクや移行コストが大幅に膨らむ可能性があります。
4つの移行方式の特徴とメリット・デメリット
4つの方式は切り替えの進め方が異なるため、リスクや業務負荷の出方も変わります。方式ごとの内容を、次に示します。
- 一括移行方式（ビッグバン方式）：特定の日付で旧システムを止め、新システムに一斉に切り替える方法です。
- 段階移行方式：部門別・機能別・拠点別に順に移行する方法で、たとえば会計、販売管理、生産管理の順に移します。
- 並行稼働方式：通常1〜3ヶ月程度、新旧を同時に稼働させて出力データを照合しながら移行する方法です。
- パイロット方式：1拠点や1部門で先にテスト稼働し、問題がなければ全社に展開する方法です。
一括移行方式は、移行期間が短くコストも抑えられますが、問題が起きると影響が全業務に及ぶため、最もリスクが高い方式です。段階移行方式は、リスクを分散できる反面、並行運用の期間が長くなり、運用コストが増えます。並行稼働方式は、安全性は高いものの、現場担当者が二重入力をこなさなければならず、業務負荷が大幅に増加します。
一括移行方式は、停止時間を確保できる業種（製造業の工場連休期間中に移行するなど）や、業務構造が比較的シンプルな企業に向いています。並行稼働方式は、会計データの整合性を重視する場合や、業務停止が許されない重要システムに適しています。パイロット方式は、多拠点の大企業や、リプレイス経験が少なくリスクを最小化したい企業に適しています。
選び方は、「業務停止許容時間」「移行予算」「組織のITリテラシー」「システムの複雑度」の4軸で判断するのがお勧めです。
Fit to Standardアプローチ：カスタマイズの妥協の決め方
ERPリプレイスでは、「Fit to Standard（システム標準に業務を合わせる）」か「Fit to Gap（業務に合わせてカスタマイズする）」かが、コストと期間を大きく左右します。Fit to Standardは、ERPの標準的な業務プロセス（ベストプラクティス）を採用し、業務をシステムに合わせて変えていくアプローチです。
導入コストを抑えやすく、将来のバージョンアップにも対応しやすくなります。一方で、最も難しいのは「どこを妥協するか」の意思決定です。「我が社の受注処理は差別化要素だから変えたくない」という声は、現場から必ず出てきます。しかし実際には、慣習にすぎない独自プロセスも多く、変えても競争力への影響は小さいことが少なくありません。
ある製造業の事例では、70%ものカスタマイズを行った結果、費用が当初予算の2.5倍に膨らみました。一方で業務はシステムに完全に適合し、生産性は30%向上しています。カスタマイズのコストと業務効果を経営レベルで比べ、「標準機能で対応できる業務は変える」と決めることが本質です。標準機能FIT率は80%を目標に、残り20%のカスタマイズは業務上の必要性と費用対効果を厳密に評価します。
失敗しないための5つのポイント
ガートナーの調査で「75%のプロジェクトが失敗を経験する」とされるERPリプレイスで成功をつかむには、技術面だけでなく、組織・人・契約・財務という多角的な視点からリスクを管理することが必要です。
実際のプロジェクト現場から得られた5つのポイントを、順に説明します。
ポイント1：チェンジマネジメント ― 現場の抵抗を克服する
ERPリプレイスの最大の障壁は、技術ではなく「人」の問題です。「今のExcel管理に慣れているから変えたくない」「新しいシステムになったら自分の仕事がなくなるのでは」「以前の導入で失敗した記憶がある」といった心理的な抵抗は、どの企業でも必ず発生します。
この抵抗を放置すると、テストへの非協力や要件定義への不参加、稼働後の旧システムへの回帰につながります。対策としては、まず要件定義の段階から現場のキーパーソン（影響力を持つ中堅社員）をプロジェクトメンバーとして巻き込むことが効果的です。「自分たちが作ったシステム」という当事者意識を持たせると、周囲への普及も進みやすくなります。
管理職には、業務の変化と期待される役割を示すワークショップを行い、変革リーダーとしての意識を醸成します。また、「なぜリプレイスするのか」という経営目線のメッセージを、経営トップ自らが繰り返し発信することも、組織全体の変革意欲を高めるうえで欠かせません。
ポイント2：ベンダーコントロール ― 選定後の主導権の握り方
ベンダーを選定した後も、発注者側が主体的にプロジェクトをコントロールし続けることが、成功の必須条件です。「あとはベンダーに任せる」という丸投げは、スコープの曖昧化、進捗の不透明化、品質低下を招きます。週次の定例会議では、課題管理台帳（課題番号・発生日・対応者・期限・ステータスを一覧化したもの）をもとに議論し、遅延の兆候を早く見つけます。
プロジェクト中に「これは仕様外なので追加費用が発生します」とベンダーから告げられるケースは、非常に多く見られます。その際は、契約時のRFPや要件定義書に明記されているかを確認します。記載があれば、費用追加を断る根拠になります。「言った・言わない」の対立を防ぐため、要件の変更や追加はすべて書面（メール・議事録）で記録し、双方の署名または承認を得ます。
契約面では、請負契約と準委任契約で責任分解の考え方が大きく異なります。請負契約では成果物の完成義務が生じ、契約不適合責任（旧瑕疵担保責任）の対象になります。準委任契約は作業遂行義務のみで、成果は保証されません。プロジェクトの性質に合わせて契約形態を選び、主要フェーズごとに検収基準を明確に定義することが重要です。
ポイント3：見積もり変動への正しい理解
ERPリプレイスの見積もりは、プロジェクトの進捗とともに変動することが構造的に避けられません。見積もりは超概算、概算、確定の段階を経て精度が上がるもので、初期の見積もりには±30〜50%の誤差があります。発注側もこれを認識しておく必要があります。
これを理解せずに「当初見積もりから変わったのはおかしい」と判断すると、ベンダーとの関係が悪化したり、必要な追加投資の判断が遅れたりします。見積もりが変動する主な要因は、要件定義による前提条件の変化、非機能要件の判明、設計段階でのカスタマイズ範囲の確定です。
追加費用が生じるときは、何が変わったのか、変更前後の工数差分といった根拠を明示させることが大切です。根拠のない請求には説明を求め、必要であれば第三者（IT顧問・コンサルタント）の意見も参考にして交渉します。予算超過の説明では、差額とあわせてプロジェクトを完遂することのビジネス価値を示すと、追加予算の承認を得る材料になります。
ポイント4：切り戻し基準の設定と1円単位の突合検証
カットオーバー前に必ず行うのが、切り戻し（フォールバック）基準の合意と、データ突合検証の設計です。切り戻し基準とは、本番稼働後にどの状況になったら旧システムに戻すかを、数値で定義したものです。「受発注データの件数不一致が●件以上」「決済処理のエラー率が●%を超えた場合」のように数値基準を決め、経営層・ユーザー部門・ベンダーの三者で合意しておくことが欠かせません。
この合意を怠ると、問題発生時の判断が遅れ、被害が拡大します。データ突合検証では、新旧システムの出力データが一致していることを厳密に確認します。照合観点（件数・金額・計算ロジック・締め処理）を事前に定め、担当者が変わっても漏れなく検証できるチェックリストを整えておくことが望まれます。
会計データは、売掛金・買掛金の残高を旧と新で照合し、1円単位で一致させることが求められます。「150円の差異は誤差の範囲」と見逃すことは許されません。端数処理ロジックの違いか、データ移行の不備かを明細レベルで追跡し、差異の原因を完全に解消してからカットオーバーを迎えることが、監査に対応できる健全な移行の条件です。
ポイント5：経営層のコミットとプロジェクトガバナンス
ERPリプレイスは、情報システム部門だけのプロジェクトではなく、全社的な業務変革プロジェクトです。そのため、経営層のコミットと強力なスポンサーシップが成功の必要条件になります。プロジェクトオーナー（通常はCIOまたは事業担当役員）が定期的に状況をレビューし、部門間の対立や意思決定の遅延を迅速に解決できる権限と責任を持つ体制をつくります。
プロジェクトガバナンスでは、フェーズゲート管理（各フェーズ完了時に品質・進捗・リスクを審査し、次フェーズへの移行可否を判断する仕組み）が有効です。要件定義完了時、設計完了時、UAT完了時などの主要なマイルストーンで正式なレビューを行い、「完了基準を満たしていなければ次フェーズに進まない」と守ることで、後工程での手戻りを防げます。
また、プロジェクトの損切り（サンクコスト放棄）の判断基準も、事前に設けておく必要があります。「すでに投資した費用を回収できない」という理由だけで継続するのは、経営上誤った判断です。完成が見込めない状況では、撤退や縮小も選択肢に入れておく必要があります。
成功事例・失敗事例の振り返り
実際のERPリプレイスプロジェクトの成功・失敗事例を見ると、理論だけでは見えにくい現場の実態が分かります。これから取り組む方にとって、非常に参考になるはずです。
代表的な事例を紹介します。
ERPリプレイス成功事例：鹿島建設・ゼネラルリンク・製造業A社
鹿島建設では、ERPの導入によって文書管理を一元化し、年間100万枚以上の紙書類を削減しました。これにより現場と本社のリアルタイム情報共有が実現し、意思決定のスピードが大幅に向上しています。現場と本社の距離が遠い建設業でも、ERPリプレイスが「攻めのDX」として機能することを示した事例です。
成功の鍵は、単なるシステムの入れ替えではなく、業務プロセスの抜本的な見直しと、経営層によるペーパーレス推進への強いコミットでした。ゼネラルリンクでは、複数システムに分散していた情報の手作業集計を廃止し、月次決算を約3営業日短縮しました。この取り組みで注目すべきは、「集計作業の自動化」というシンプルな目標が、確実に達成された点です。
ERPリプレイスでは、過度に広い目標を設定して収拾がつかなくなるケースがある一方、具体的な業務課題（月次決算の遅延）の解消に絞った点が、成功の要因といえます。製造業A社（従業員100名規模）でも、月次決算が3週間から1週間に短縮されました。経営層への報告サイクルが速まり、機動的な経営判断が可能になっています。
ERPリプレイス失敗事例：食品メーカーAの並行稼働設計不備
食品メーカーAでは、本番稼働前に新旧データの照合観点（件数・金額・計算ロジック・締め処理）の定義が不十分なまま、切り戻し基準も関係者間で合意されていない状態でカットオーバーを迎えました。稼働直後から受発注・在庫データの不整合が連鎖的に発生し、出荷・製造が長期停止するという深刻な事態に陥りました。
建築業Bでは、PoC（概念実証）が不足したまま大容量データや連携バッチの性能を机上で見積もった結果、本番稼働後に性能問題が起き、工期延伸と大幅な予算超過（当初見積もりの1.8倍）につながりました。商社E社では、従業員200名規模にもかかわらず20年分の顧客データが3システムに分散しており、統合とクレンジングだけで4ヶ月を要したため、スケジュールが大幅に遅れました。
食品メーカーAの教訓は、経営層の「期日通りに稼働させろ」というプレッシャーに現場が屈し、テストや検証を飛ばしてしまう組織的な問題です。これらの失敗に共通するのは、「リスクの過小評価」と「不都合な真実から目を背けるプロジェクト文化」です。問題の兆候を早く見つけ、関係者が率直に議論できる体制をつくることが、失敗を防ぐうえで何より大切です。
まとめ
基幹システム・ERPリプレイスは、企業の業務変革と競争力強化を実現できる一方、ガートナーの調査で75%が失敗を経験するとされる、難易度の高いプロジェクトです。
成功のカギは、「現状分析→目的・ROI明確化→RFP・ベンダー選定→要件定義→設計・開発→データ移行・テスト→カットオーバー・定着化」という7ステップを体系的に進めることです。そのうえで、チェンジマネジメント、ベンダーコントロール、切り戻し基準の設定、経営層のコミットという組織的・人的な側面を、同時に管理する必要があります。
Fit to Standardの考え方を採用し、カスタマイズを最小化して標準的な業務プロセスへ変えていくことも、長期的なコスト最適化と保守性の向上の観点から大切です。「標準機能に合わせて業務を変える」という決断は組織にとって痛みを伴いますが、それを乗り越えた企業が鹿島建設や製造業A社のような成果を上げています。
これからERPリプレイスを検討する方は、本記事の進め方とポイントを参考に、企画・準備の段階から着実に取り組んでいただければ幸いです。プロジェクトの成功に不安があるときは、経験豊富なコンサルタントへの相談も選択肢のひとつです。
▼開発を相談する前に読みたい無料ホワイトペーパーはこちらをご覧ください。
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。