システムリプレイスは、現状分析から本番切り替えと定着化支援まで、7つのステップで進みます。
このプロジェクトは数千万円から数億円規模の投資を伴うため、一度失敗すれば業務停止や経営へのダメージに直結します。ガートナーの調査では、ERPリプレイスプロジェクトの75%が何らかの失敗を経験しています。
▼全体ガイドの記事
・システムリプレイスの完全ガイド
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
システムリプレイスとは――定義とリプレイスが必要になる理由
システムリプレイスとは、老朽化・機能不足・保守限界を迎えた既存システムを、新しいシステムに丸ごと置き換えることです。「システムマイグレーション」と混同されがちですが、マイグレーションはデータや環境を別の基盤へ移す作業に重点を置いています。一方で、リプレイスはシステム自体を刷新する点が異なります。
両者は密接に関連しており、一般的には、リプレイスプロジェクトの中にデータ移行（マイグレーション）が含まれます。
リプレイスの2つの目的――「守りの投資」と「攻めの投資」
システムリプレイスの目的は、大きく2つに分けられます。1つ目は「守りの投資」です。ハードウェアの保守期限切れや、OS・ミドルウェアのサポート終了への対応、特定のベンダーや担当者しか修正できない「ブラックボックス」からの脱却がこれにあたります。さらに、「2025年の崖」と呼ばれるレガシーシステム問題への対応も含まれます。
国税庁の基準ではソフトウェアの法定耐用年数は5年とされており、10年、20年と使い続けているシステムは、すでに技術的負債が蓄積している状態です。
2つ目は「攻めの投資」です。AIや機械学習との連携、クラウドを活用した柔軟なスケーリング、リアルタイムのデータ分析による経営判断の高速化など、デジタル競争力を強化するためのリプレイスを指します。守りと攻めのどちらが主な目的かによって、プロジェクトのスコープや優先事項は大きく変わります。また、経営層への稟議を通す際も、この2軸で整理すると説得力が増します。
リプレイスを検討すべき5つのサイン
次のような兆候が見られるときは、システムリプレイスを本格的に検討する時期です。保守担当ベンダーからサポート終了の通知が届いたときや、月次決算や在庫確認などの基幹業務でExcelによる手作業の補完が常態化しているときが該当します。
システムの処理が遅く業務のボトルネックになっているときや、新しい事業やサービスに対応する機能追加のコストが毎回高額になり、費用対効果が取れなくなってきたときも、兆候の一つです。さらに、担当のシステムエンジニアが退職し、ソースコードの解読に多大な工数がかかるようになった場合もあります。
これらはリプレイスのシグナルです。そのため、早い段階で検討を始めるほど、プロジェクトの選択肢は広がります。
システムリプレイスの進め方――7つのステップ
システムリプレイスを「なんとなくベンダーに相談する」ところから始めると、失敗のリスクが高まります。正しい順序で進めることが、コスト超過やスケジュール遅延、本番トラブルを防ぐ最大の防衛策です。7つのステップを順に進めると、発注側がプロジェクトを主導する体制が整います。
Step1：現状分析と課題の棚卸し
最初のステップは、現在のシステムが抱える問題を洗い出すことです。機能面の不足や性能の問題、保守コストの膨らみ、データの分散や不整合などの観点から、多角的に現状を見ていきます。このとき、IT部門だけで進めず、営業・製造・経理など現場の業務担当者にもヒアリングすることが重要です。現場が「不便だけど慣れている」と感じている非効率は、表面的なヒアリングでは出てこないことが多いためです。
棚卸しの結果を「現行機能一覧」「業務フロー図」「システム構成図」として文書化しておくと、後工程のRFP作成や要件定義が格段に楽になります。一人情シスや専任担当者がいない中小企業では、この工程をベンダーに丸投げしがちです。しかし、課題の整理は発注側が主体的に行うことが、成功の前提条件です。
Step2：目的・ゴールの明確化とROI算出
現状分析が終わったら、このリプレイスで何を達成するのかを数値で定義します。「月次決算を現在の3週間から1週間に短縮する」「手作業によるデータ入力の工数を月間200時間削減する」など、定量的なゴールを置いておくと、後のROI（投資対効果）を計算できるようになります。実際に従業員100名規模の製造業では、基幹システムのリプレイスにより月次決算が3週間から1週間に短縮された事例があります。
ROI計算で業務効率化による人件費の削減額を算出するときは、「基本給の2倍」を用いるのが実務上の目安です。社会保険料や福利厚生費、管理コストなどを加えると、実際の雇用コストは基本給の約2倍に相当するためです。この数字をもとに「削減できる人月数×人月単価」で削減効果を出し、システムの導入・運用コストと比べることで、経営層が納得できるROI試算書を作成できます。
Step3：RFP作成とベンダー選定
RFP（提案依頼書）は、ベンダーから自社に合った提案を引き出すための設計図です。RFPに最低限記載すべき項目は、プロジェクトの背景と目的、現行システムの概要と課題、新システムへの機能要件・非機能要件（性能・セキュリティ・可用性）です。加えて、希望スケジュール、概算予算の範囲、評価基準と選定プロセスも欠かせません。
RFPが曖昧であるほど、ベンダーの提案内容はばらつき、相見積もりの比較が難しくなります。
ベンダー選定では、同業種・同規模のプロジェクト支援実績、PMの経験とプロジェクト管理体制、Fit to Standard（標準機能への適合）の提案姿勢を重点的に評価します。なお、規模の小さい委託先と契約する場合は、下請法が適用される可能性があります。その場合、支払いは納品後60日以内とするルールや書面交付義務など、法的な制約への対応が必要です。発注担当者は事前に確認しておきましょう。
Step4：要件定義――「現行踏襲」の罠への備え
要件定義は、リプレイスプロジェクト全体の方向性を決める工程です。ここで最も多い失敗が、「現行踏襲」という名の思考停止です。「今のシステムと同じことができればいい」という指示をベンダーに出した瞬間、20年分の非効率な業務プロセスごと新システムに持ち込むおそれがあります。そのため、要件定義では次の2点を押さえておく必要があります。
- 現状と理想の切り分け：現行業務（As-Is）とあるべき姿（To-Be）を明確に分け、業務プロセスそのものの改善も視野に入れます。
- 数値での定義：性能・可用性・セキュリティなどの非機能要件、拡張性、移行要件を、具体的な数値で定めます。
「大量データでもサクサク動くこと」のような曖昧な書き方は避け、「10万件のデータ一括処理を30秒以内で完了すること」のように数値で書きます。
建築業Bの事例では、PoC（概念実証）が不足し、大容量データ処理の性能見積もりが甘くなりました。その結果、本番後に工期が延び、予算も大幅に超過しています。この轍を踏まないためにも、要件定義の段階で性能要件を定量化しておくことが欠かせません。
Step5：設計・開発――カスタマイズのコスト意識
設計・開発フェーズでは、ベンダーが基本設計書と詳細設計書を作成し、発注側がレビューする形で進めます。このフェーズで発注側が特に意識したいのは、カスタマイズの範囲です。標準パッケージをベースにする場合、カスタマイズの割合が増えるほど、コストは指数的に膨らみます。そのため、次の3点を押さえておきます。
- カスタマイズの要否：自社の業務プロセスが本当に競争優位の源泉か、それとも「昔からそうだから」という慣習かを、冷静に見極めます。
- 業務の合わせ方：Fit to Standard（標準機能に業務を合わせる）の採用を前向きに検討します。
- 週次の定例報告：週次で報告会を設定し、開発の進捗を確認して、課題管理表でリスクを可視化します。
ある製造業では、標準パッケージに70%のカスタマイズを施した結果、当初予算の2.5倍に費用が膨張しました。ただし、業務への完全適合により、生産性は30%向上しています。
Step6：データ移行・クレンジングとテスト3段階
データ移行は、システムリプレイスのなかでも最もトラブルが多い工程の一つです。ある商社では、従業員200名規模の企業で、20年分の顧客データが3つのシステムに分散しており、データ統合とクレンジングだけで4ヶ月を要しました。その手順は大きく次の4段階に分かれます。
- データ棚卸し：移行対象のデータと件数を確定します。
- クレンジング：表記ゆれの統一（株式会社と（株）など）や欠損値の補完を行い、異常値の除去やコード体系の新旧対応づけも行います。
- 変換ロジックの設計と実装：クレンジング後のデータを変換する仕組みを、設計して実装します。
- 移行テスト：最後に実施します。
移行テストは、「サンプル移行テスト」「全件移行テスト」「移行リハーサル」の3段階で実施するのがベストプラクティスです。
- サンプル移行テスト：サンプル移行で変換ロジックの正確性を確かめます。
- 全件移行テスト：本番データ量での処理時間と整合性を検証します。
- 移行リハーサル：本番と同じ手順・人員・時間帯で、完全なシミュレーションを行います。
会計データの確認は、「1円の差異も許容しない」姿勢で臨むことが大切です。売掛金・買掛金残高で150円の差異が出た場合は、端数処理の問題か、データ移行の不備かを明細レベルで追跡し、1円単位で調べます。これは監査対応を見据えた現場の必須作業です。
Step7：本番切り替えと定着化支援
本番カットオーバーは、最も緊張感の高い工程です。切り替え当日は、「切り戻し（フォールバック）基準」を具体的な判断基準とともに文書にして、あらかじめ合意しておくことが不可欠です。切り戻しの判断に備えて、次の2点を押さえておきます。
- 切り戻しの基準：「本番稼働後に重大なバグが見つかり、業務の継続が不可能と判断した場合は旧システムに戻す」という基準を、事前に定めます。
- 照合観点の定義：新旧データをどの観点で照らし合わせるかを、切り替え前に決めておきます。
切り戻しの判断ができないままカットオーバーした食品メーカーでは、新旧データの照合観点が定義されていませんでした。そのため、受発注と在庫の不整合が連鎖し、出荷と製造が長期間停止する深刻な事態に発展しました。
カットオーバー後の定着化支援も、プロジェクトを成功に導くうえで欠かせない要素です。リリース直後は現場からの問い合わせが急増するため、次の3つを事前に整えておきます。
- ヘルプデスク体制：受付と回答を担う窓口の体制を整えます。
- 操作マニュアル：現場が操作手順を確かめられる資料を用意します。
- FAQ：よくある質問と回答を、ひとまとめにしておきます。
定着化の評価には「ILUO評価フレームワーク」が有効です。現場担当者が新システムの主要操作を「U（理解・一人で実行可能）」のレベルに達したかを確かめてから、サポート体制を縮小するフェーズゲートを設けることを推奨します。
移行方式の比較と選び方――一括・段階・並行・パイロット
システムリプレイスの移行方式は、業務停止リスク、コスト、期間、組織の受容力によって、最適なものが変わります。主要な4つの移行方式の特徴を理解したうえで、自社の状況に合った方式を選びましょう。
4つの移行方式のメリット・デメリット
「一括移行（ビッグバン方式）」は、旧システムを一定の日に完全停止し、新システムへ切り替える方式です。最も短い期間で移行を完了できるため、2つのシステムを並行稼働させるコストが生じません。ただし、移行当日に問題が起きると、業務停止のリスクが最大になります。そのため、事前の移行リハーサルと切り戻し計画が必須です。比較的システムが小規模で、業務停止の許容時間を確保できる場合に適しています。
「段階移行（フェーズド移行）」は、機能・部署・地域などを分けて、段階的に新システムへ移行する方式です。一度に全機能を移すリスクを分散できる点が、最大のメリットです。一方で、旧システムと新システムを一定期間並行して稼働させる必要があるため、データ連携の複雑さとコストが増えます。
「並行移行」は、旧システムと新システムを同時に稼働させながら整合性を確認する方式です。最も安全性が高い反面、現場の二重入力の負担と運用コストが最大になります。「パイロット移行」は、特定の拠点や部門でまず試験的に導入し、問題がなければ全社に展開する方式です。大規模な組織で段階的にリスクを管理する場合に有効です。
自社に合った移行方式の選び方
移行方式は、3つの観点から検討します。まず、「業務停止の許容時間」を見ます。金融や医療など24時間365日の稼働が求められる業種では、段階移行や並行移行が必須です。一方、製造業のように週末の計画停止で済む場合は、一括移行が現実的な選択肢になります。
次に、「プロジェクト予算」を見ます。並行稼働期間が長いほど、二重のシステム維持コストと人件費が発生します。そのため、予算の制約が厳しい場合は、一括移行のコスト効率が優れています。最後に「組織の変革受容力」です。従業員がシステム変更に慣れていない場合や、変化への抵抗が強い組織では、段階移行やパイロット移行で小さな成功体験を積み重ねてから全社に展開する戦略が効果的です。
失敗しないための5つのポイント――現場のプロ知見
技術的な手順を正しく踏んでいても、人や組織、契約、マネジメントの問題でプロジェクトが失敗するケースは少なくありません。ここでは、現場で実際に直面してきた落とし穴を5つ取り上げて解説します。
チェンジマネジメント――現場の抵抗を克服する方法
「新しいシステムを使いたくない」「Excelのほうが便利だ」という現場の心理的な抵抗は、どのリプレイスプロジェクトでも必ず起こります。チェンジマネジメントとは、この抵抗を組織的に管理し、変革を定着させるための取り組みです。経営層は市場環境や競合の状況から強い危機感を持っていても、現場の従業員が同じ温度感を持つことは、ほぼありません。この「温度差」が、変革の最大の障壁となります。
有効な対策は3つあります。まず、「なぜ変える必要があるのか（Why）」を現場の言葉に訳して、繰り返し伝えることです。「システムが古いから」ではなく、「このシステムを使い続けると3年後には月次決算に4週間かかるようになる。今動かないと業務が立ち行かなくなる」という具体性が必要です。
次に、変革に積極的な現場メンバーを「推進役（チャンピオン）」として早期に巻き込み、横展開の起点にします。最後に、反対派のキーマンを無視や排除するのではなく、業務要件の最終確認担当など、プロジェクトの重要な役割に任命して当事者にする方法が効果的です。
ベンダーコントロール――選定後の進行管理
ベンダーを選定した後、プロジェクトの主導権がベンダー側に移ってしまうケースが多発しています。「ベンダーに任せていれば何とかなる」という発想は、追加費用やスケジュール遅延、品質問題のリスクを高めます。定例会議は週次で設定し、進捗率・課題一覧・リスク一覧を定型フォーマットで共有する体制を、発注側から求めることが大切です。進捗報告が「問題ありません」という口頭報告だけの場合は、要注意です。
「それは仕様外なので追加費用が発生します」とベンダーに言われた場合の対処も、実務で欠かせない知識です。まず、要件定義書や設計書の該当箇所を確認し、発注側の認識との差異を文書で整理します。
次に、追加費用の妥当性を確かめます。「なぜその工数が発生するのか」を、根拠となる見積もりの内訳で説明させ、複数のエンジニア単価の相場（新人〜80万円、一般80〜140万円、上級140〜250万円/月）と照合します。すべての合意事項をメールや議事録に残す習慣が、「言った・言わない」のトラブルを防ぐ最も確実な防衛策です。
契約・法務の落とし穴――請負/準委任と責任分解
システムリプレイスの契約には、主に「請負契約」と「準委任契約」の2つの形態があります。請負契約は、ベンダーが成果物（完成したシステム）に責任を負う形態です。仕様どおりに動作しない場合は、ベンダーに契約不適合責任（旧：瑕疵担保責任）が発生します。一方で、準委任契約は、業務の遂行（工数）に責任を負う形態のため、成果物の完成までは保証されません。
要件定義のように不確実性が高い上流工程は準委任、開発やテストのように成果物が明確な工程は請負と、使い分けるのが基本です。SLA（サービスレベル合意）の設計も重要です。システム稼働率（例：月次99.9%以上）と、障害発生時の応答・復旧時間（例：重大障害は2時間以内に対応着手）を、具体的な数値で定めます。
違反時のペナルティ（例：ダウンタイム1時間あたり月額費用の1%を減額）も、同じように合意書に明記します。こうすることで、ベンダーとのトラブルを未然に防げます。契約書の確認は、法務部門や顧問弁護士に依頼することを強くお勧めします。
見積もり変動は「構造的」――発注側が持つべき正しい理解
「最初の見積もりと最終的な金額が2倍以上違う」という経験をされた方は多いでしょう。見積もりの変動は、構造的に起こりうるものとして理解しておく必要があります。ベンダーの悪意だけが原因とは限りません。プロジェクト初期の超概算見積もりは、要件の50%程度しか確定していない状態で算出されます。
要件定義が進むにつれて前提条件が明確になり、非機能要件の追加判明などによって金額が変わるのは、本質的な問題ではなく、プロセスの正常な進行です。
発注側が取るべき対策は、見積もりの「確度（超概算・概算・確定）」をベンダーに明示させることです。さらに、フェーズごとに見積もりを再提示させる仕組みを、最初の契約に組み込みます。「要件定義完了時点で確定見積もりを再提出する」という条項を入れると、後からの青天井的な追加費用を防げます。
「1円の差異も許容しない」突合検証と切り戻し基準の設定
本番カットオーバー前の最終確認として最も重要なのが、会計データの突合検証です。旧システムと新システムの売掛金・買掛金残高、在庫金額などの財務データを照合し、1円の差異も残さない姿勢で確認します。「ほぼ合っている」では許容されません。差異が出た場合は、原因を次の2つのどちらかに絞って、明細レベルで追跡します。
- 端数処理：計算ロジックの違いによる差異
- データ移行：移行ロジックのバグによる差異
この作業の厳密さが、本番稼働後の監査対応や経営報告の信頼性を支えます。
切り戻し基準は、「本番稼働を中止して旧システムに戻す条件」を事前に文書にしたものです。具体的には、次のような定量的な基準を指します。
- 「本番切り替え後X時間以内にY件以上の重大バグが発生した場合」
- 「データ不整合によりZ業務の継続が不可能と判断した場合」
ベンダーと発注者が双方で、これを合意しておきます。切り戻し判断ができなかった食品メーカーの事例が示すとおり、この基準がなければ、カットオーバー後のトラブル対応が場当たり的になり、被害が拡大します。
成功事例・失敗事例から学ぶリアルな教訓
理論だけでなく、実際のプロジェクトで何が起きたかを知ることが、失敗を未然に防ぐうえで最も効果的な学びです。成功と失敗の両面から、プロジェクトで起きた事例を紹介します。
失敗事例――同じ轍を踏まないための教訓
食品メーカーAのケースは、「並行稼働設計の不備」による典型的な失敗です。新旧データの照合観点（件数・金額・計算ロジック・締め処理）の定義が不十分なまま、切り戻し基準も未合意の状態でカットオーバーしました。その結果、受発注と在庫データの不整合が連鎖し、出荷と製造が長期間止まる事態に陥りました。教訓は、移行テスト完了の定義を数値で合意してから本番に臨むことです。
建築業BのケースはPoC（概念実証）不足による失敗です。新システムの性能評価を机上の比較だけで行い、実際の業務データ量での動作検証を省略しました。その結果、大容量データの一括処理と外部システムとの連携バッチの性能が実用レベルに届いていないことが、本番稼働後に分かりました。工期は大幅に延び、当初予算も大きく超過しました。教訓は、非機能要件を必ず本番想定のデータ量でPoC検証することです。
成功事例――共通する成功の要因
鹿島建設のERPリプレイスでは、文書管理を一つにまとめたことで、年間100万枚以上の紙書類を削減し、現場と本社のリアルタイムな情報共有を実現しました。このプロジェクトの成功の背景には、経営トップのコミットメントと、現場部門を巻き込んだ要件定義があります。ゼネラルリンクでは、複数のシステムに分かれていた手作業の集計業務をなくし、月次決算を約3営業日短縮しました。
これらの成功事例に共通するのは、経営層が明確に意思決定し、コミットしていることです。現場を上流工程から巻き込んで要件を定義していることも、共通点です。加えて、段階的な移行テストと品質管理、定着化支援への投資も挙げられます。
ただし、カスタマイズ70%・費用2.5倍という製造業Dのケースのように、高いカスタマイズ率でも、業務要件への完全適合と生産性30%向上という成果を出した事例もあります。コストと業務適合性のバランスをどこで取るかは、経営判断として唯一の正解はなく、プロジェクトの初期段階で経営層と合意形成しておく必要があります。
一人情シス・中小企業のためのリアルな進め方アドバイス
大企業向けのシステムリプレイスのベストプラクティスは、リソースが限られた中小企業や一人情シスには、そのまま適用できない部分も多くあります。ここでは、現実的な制約のなかで成果を最大にするためのアドバイスを整理します。
優先順位の付け方――「やるべき最低限」の見極め
専任のIT担当者が0人か1人という環境では、すべてのベストプラクティスを実行することは不可能です。その場合は、優先度の高い工程に集中することが大切です。省略してはならない最重要工程は、「要件定義（現行業務の棚卸しと課題の文書化）」「データ移行テストの突合検証」「切り戻し基準の合意」の3つです。これらを省くと、本番稼働後のリカバリーに膨大なコストと時間を失います。
一人情シスが通常業務を抱えながらリプレイスを担当する場合は、ベンダーに「PMO支援」を含めた提案を求めることを推奨します。PMO支援は、プロジェクト管理の専門家がスケジュール管理、課題管理、ドキュメント整備を代行するサービスです。発注側の工数負担を大幅に軽減できます。
中小企業の場合、10〜20人規模のハードウェア更改の相場は、サーバーが10〜30万円、ネットワーク構築が10〜20万円です。その後の運用保守は、構築費の10〜15%程度が目安です。クラウドへの移行を選べば、初期投資を抑えつつOPEX型（運用費）で導入できるため、資金繰りの観点からも検討の価値があります。
リプレイス後の情シス部門の役割変革
クラウドベースのシステムに移行すると、従来の「サーバー管理・障害対応・パッチ適用」といった守りのIT業務が大幅に減ります。このタイミングで情シス部門の役割を「守りのIT」から「攻めのIT」へ移すことが、投資効果を最大化するうえで欠かせません。
具体的には、業務部門へのDX推進支援、データ分析基盤の整備、AI活用の社内展開など、ビジネス価値を直接生み出す活動に人手を振り向けます。「システムを維持する部門」から「事業成長を支援する部門」へ転換することこそが、リプレイス投資の本当の見返りです。
まとめ――プロジェクトを成功に導く3つの原則
ここまで、システムリプレイスの全体像や7つのステップ、4つの移行方式、チェンジマネジメントやベンダーコントロール、契約の落とし穴、成功と失敗の事例を見てきました。最後に、プロジェクトを成功に導く3つの原則をまとめます。
第1の原則は、発注側が主体的にプロジェクトを主導することです。ベンダーは技術の専門家ですが、自社の業務に詳しいのは自社です。そのため、要件定義、進捗確認、品質検証のすべてに、発注側が能動的に関わることが成功の基盤になります。
第2の原則は、人と組織の変革を技術と同じくらい重視することです。どれほど優れたシステムでも、現場に定着しなければ投資の意味がありません。チェンジマネジメントは、プロジェクト計画の中心に位置づけるべき活動です。
第3の原則は、上流工程への投資を惜しまないことです。現状分析、要件定義、RFP作成という初期の工程に時間と費用をかけると、後工程でのやり直しコストを大幅に減らせます。
開発工程別の費用比率では、要件定義は10〜15%程度ですが、ここでの手抜きが最終的なコストを数倍に膨らませる最大のリスクです。システムリプレイスは、組織の未来を変える大きな投資です。この記事が、皆さんのプロジェクトを成功へ導く一助となれば幸いです。
▼全体ガイドの記事
・システムリプレイスの完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。