システムリニューアルは、棚卸しから本番稼働まで、7つのステップを順に進める取り組みです。前半の棚卸しとROI設計をしっかり行うかどうかが、成否を左右します。
予算500万円以下の中小企業から、数億円規模のエンタープライズまで対応できる内容です。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
システムリニューアルの定義と、リプレイスとの違い
「リニューアル」「リプレイス」「マイグレーション」は日常的に混同されがちですが、それぞれ意味が異なります。言葉の定義を最初にそろえておくと、ベンダーとの認識のずれを防ぎやすくなります。また、リニューアルが必要になる兆候を早く把握すれば、プロジェクトの主導権を自社に取り戻せます。
リニューアル・リプレイス・マイグレーションの定義
システムリニューアルとは、現行システムの機能や業務プロセスを見直しながら新しいシステムへ移行する取り組みです。単なる技術更新にとどまらず、業務の再設計や組織変革を伴うことが特徴です。一方、リプレイスは既存システムの機能をほぼそのまま新しいシステムに置き換えるもので、業務プロセスの変更を最小限に抑える点でリニューアルと異なります。
マイグレーションは、さらに範囲の狭い技術的な用語で、データやシステムを別の環境（クラウドや新しいサーバー）に移す作業そのものを指します。実務上は、業務プロセスの見直しが入るかどうかが、リニューアルとリプレイスの境界線になります。
たとえば、受注管理システムをSAP Business Oneに入れ替える場合は、従来の業務フローを踏襲するか、標準機能に業務を合わせるFit to Standardアプローチを取るかで、スコープと工数が大きく変わります。発注者側は、「リプレイスで対応できます」と提案されても、実態がリニューアルに近ければ工数・費用が過少見積もりになるおそれがあるため、定義を確認してください。
リニューアルが必要になる5つの兆候
現場でよく見られる兆候は五つあります。
- 改修費の高騰：システム改修の見積もりが年々高くなっている
- 影の台帳：Excelやスプレッドシートで台帳を別に管理している
- 更新の遅れ：セキュリティパッチの適用が数ヶ月単位で遅れている
- ベンダー担当者の頻繁な交代：担当者が頻繁に変わっている
- 採用への影響：古い技術しか使えない職場という評判が立っている
年々上がる改修費は、ベンダーロックインと技術的負債が重なって表れる症状で、放置するほど抜け出しにくくなります。現場スタッフが独自の台帳で業務を回している状態は、システムが現場の業務実態に追いついていないサインです。
特にWindows Server 2012やOracle Database 11gなど、すでにメーカーサポートが終了したミドルウェアを使い続けている場合は、情報漏洩のリスクが現実のものとなっています。そのため、速やかな対応が必要です。過去の経緯を知る担当者がいなくなることや、エンジニア採用に影響が出始めることも、深刻な兆候です。
これら五つのうち二つ以上が当てはまる場合は、リニューアルの具体的な検討を始める時期に来ています。
システムリニューアルの全体プロセス【7ステップ】
システムリニューアルは、7つのステップを順序どおりに進めるのが基本です。一つの工程を飛ばすと後続の工程に深刻な影響が出るため、特に前半の「棚卸し」と「ROI設計」は、しっかり行う必要があります。
Step1 現行システムの棚卸しとブラックボックス解消
最初のステップは、現行システムの全体像を把握する「棚卸し」です。驚くほど多くの企業で、自社のシステムがどの業務に使われているかを、誰も正確に把握できていません。
棚卸しでは、システム名、担当ベンダー、月次費用などを一覧表にまとめ、各システムのデータフローを図に落とします。この作業には通常1〜3ヶ月かかりますが、ここを省くと後続のすべてのステップで手戻りが発生します。
2026年現在、AIを活用したレガシーコード解析ツールを使い、GitHubにコードをアップロードしてClaude等のLLMに解析させると、仕様書がなくても処理の概要を数日でドキュメント化できます。かつては数百万円かかっていたコード解析が、AIの活用により数十万円規模で実現できるようになりました。ただし、AI解析は「たたき台」なので、現場担当者のレビューとセットで進めます。
Step2 経営課題との紐付けとROI設計
棚卸しが終わったら、リニューアルの「目的」を経営課題と紐付けて言葉にします。「古いから更新する」という理由だけでは、予算承認が下りないのはもちろん、途中で方向性がぶれたときに判断の基準を持てなくなります。
具体的には、現状の課題コスト（非効率な業務の人件費、障害対応コスト、機会損失）と、リニューアル後の期待効果（工数削減、売上貢献）を数値で示したROI試算書を作ります。たとえば、受発注処理に月100時間かけているなら、時給3,000円換算で月30万円・年360万円の人件費コストが発生しており、5年間で1,800万円になります。
2,000万円のリニューアル投資でも、業務改善効果が年500万円あれば4年で回収できる計算が立ちます。このROI試算は、社内稟議を通すためだけでなく、提案依頼書（RFP）の目的欄に書くことで、ベンダー選定時の評価基準にもなります。「経営課題を解決するためのリニューアル」という文脈を明確にしておけば、提案段階で的外れな過剰機能を提案されるリスクが減ります。
Step3 移行方式の選定（一括/段階/並行/パイロット）
移行方式には主に四つのパターンがあります。一括移行（ビッグバン）は、旧システムを停止して一気に新システムへ切り替える方式です。移行コストは最小限で済みますが、失敗時の影響が全社規模に及ぶためリスクが最も高く、十分なテスト期間と緊急時のロールバック手順が必須です。
段階的移行は、機能やモジュール単位で順次切り替える方式で、リスクを分散できる一方で、新旧システムの並存期間中のデータ整合性管理が複雑になります。並行稼働（パラレルラン）は、新旧システムを一定期間同時に動かし、出力結果を比べる方式です。最も安全性が高い反面、運用コストが約1.5〜2倍になるため、3〜6ヶ月が上限の目安です。
パイロット移行は、特定の拠点や部門に先行導入し、そこで得た知見を全社展開に活かす手法です。特に中小企業では人員が限られるため、「基幹機能のみ先行でパイロット導入」という現実的な選択が多くなります。どの方式でも、選定の根拠をドキュメントに残しておけば、後半で方針変更の議論が出たときの判断材料になります。
Step4 Fit&Gap分析とカスタマイズ判断
パッケージソフトを採用する場合は、自社の業務要件とパッケージの標準機能のギャップを洗い出す「Fit&Gap分析」が欠かせません。Fitは標準機能で対応できる要件を、Gapはカスタマイズや業務側の変更が必要な要件を指します。Gapが生じたときは、「カスタマイズするか」「業務プロセスをパッケージに合わせるか」を選ぶことになります。
カスタマイズは初期費用が膨らむうえ、バージョンアップ時のメンテナンスコストが恒久的に発生します。そのため、「なぜその業務フローでなければならないのか」を問い直す姿勢が大切です。Gapの判断は、「その業務フローが競合優位性に直結しているか」を基準にするとよいでしょう。
この基準で、経費精算や勤怠管理などはFit to Standardに振り切り、差別化の源泉となる独自の価格計算ロジックや顧客管理のみカスタマイズする方針が、コストと保守性のバランスを取るうえで役立ちます。弊社が支援した製造業の事例では、当初のカスタマイズ80項目をこの基準で精査した結果、必要な項目は23項目に絞れ、開発費用を約35%削減できました。
Step5 RFP作成とベンダー選定
提案依頼書（RFP）は、ベンダーに提案条件をそろえて比較するための文書です。RFPなしの口頭発注は、後から「言った・言わない」の争いになりやすく、特に中小企業では費用追加のトラブルが多発します。RFPには、まずプロジェクトの背景・目的、現行システムの概要、要件の優先度（Must/Want）を書きます。
さらに、スケジュール要件を示し、予算上限の目安を明示すると、ベンダーの過大提案を抑えられます。評価基準には、価格・技術力・実績・サポート体制の重み付けを明記します。ベンダー選定では、提案金額だけでなく、類似業種・同規模の実績、PMの経歴、保守・運用まで一気通貫で対応できるかを確認します。
中小企業向けのSI経験に乏しいベンダーに発注すると、エンタープライズ向けの過剰な管理プロセスを持ち込まれ、コストが跳ね上がるケースが散見されます。3〜5社から提案を取り、金額の最高値と最低値の開きが30%以上あれば、スコープの理解に差がある可能性があるため、ヒアリングで要件認識をすり合わせてください。
Step6 データ移行・クレンジングの実務
データ移行は、多くのプロジェクトで最も工数が膨らむ工程です。移行の前には、まずデータクレンジング（不正データの修正・統一）が必要ですが、この作業は想像以上に泥臭いものです。データクレンジングは事前に完了させてから移行に入るのが原則で、その工数を見積もりに十分盛り込むことが不可欠です。
典型的な問題には、顧客名の全角・半角混在（「株式会社ABC」と「株式会社ＡＢＣ」が別レコードになる）、住所の旧表記と新表記の混在、退職者や廃業先が削除されずに残る「ゾンビレコード」などがあります。部門ごとに意味不明なコード体系が乱立していることも、よくある問題です。
弊社の実績では、データクレンジングの工数が当初見積もりの2〜4倍になることも珍しくありません。ある流通業の事例では、顧客マスタ約8万件のクレンジングに担当者2名が3ヶ月フルコミットしました。この工数をベンダーへの委託費用に換算すると500万円を超え、当初予算に計上されていなかったため、プロジェクト全体の予算超過の主因となりました。
Step7 本番稼働とハイパーケア期間の運用
本番稼働（Go-Live）後の1〜3ヶ月は「ハイパーケア期間」と呼ばれ、障害対応と業務サポートに最大のリソースを投入する集中支援の期間です。この期間は、ベンダーの常駐サポートまたはオンコール体制を契約に明記しておく必要があります。また、Go-Live日は、月初や期初を避け、データ量の少ない月中旬の月曜日に設定すると、万が一のときにロールバックしやすくなります。
稼働直後に必ず発生するのは、「本番データでしか検証できなかった不具合」「テストで想定しなかった業務パターン」「操作に慣れない現場スタッフからの問い合わせ殺到」の三つです。これらへの対応が遅れると、現場の新システムへの不満が一気に高まり、チェンジマネジメントが失敗に終わります。
ハイパーケア期間の終了は、三つの指標で決めておくと、感情論ではなくデータに基づいて判断できます。その指標は、「重大インシデント件数がゼロになってから2週間継続」「問い合わせ件数が導入直後の20%以下に低下」「バックログ（未解決課題）が全て優先度低以下になる」の三つです。
【独自】現場が語らないリニューアルの「泥臭いリアル」
教科書の「あるべき論」では語られにくい、現場で実際に起きる課題は三つあります。データクレンジングの手作業、「抵抗勢力」との向き合い方、本番稼働初日のパニックへの対処は、どれもプロジェクトの成否を左右するテーマです。
データクレンジングは想像の3倍かかる―工数の実態
「データ移行は技術的な話だからベンダーが全部やってくれる」と思い込む発注者は多いですが、これは大きな誤解です。ベンダーが担当できるのは「正しいデータを正しい形式で移す」作業で、データが正しいかどうかの判断は、業務知識を持つ発注者にしかできません。弊社が支援した小売業（従業員120名）では、商品マスタのクレンジングに経理担当者2名と営業担当者1名が計4ヶ月かかりました。
たとえば、同じ取引先が「山田製作所」「山田製作所株式会社」「ヤマダ製作所」として別々に登録されていると、どれが正しいかをベンダーは判断できず、発注者の担当者が一件ずつ確認する必要があります。当初、プロジェクトマネージャーが「データ移行は2週間で終わる」と見積もったため、スケジュールは約3ヶ月半ずれ込み、本番稼働が繁忙期にかかってしまいました。
そのため、データクレンジングは最低でも「商品・顧客・仕入先マスタの件数×1件あたり平均2分」で工数を試算し、さらにその50%増しを見ておくのが現実的です。また、クレンジング作業は現場業務と並行するため、担当者の業務負荷が通常の1.5倍になる期間が生まれます。この人員負荷を計画に組み込まないと、現場スタッフの疲弊がプロジェクト全体の士気低下につながります。
「抵抗勢力」を味方にする具体的な5つの手法
システムリニューアルで最も見落とされがちなのは「人的抵抗」です。反発は、ITリテラシーの低いスタッフだけでなく、現行システムを使いこなすベテラン社員や、非効率なプロセスで利権を持つ部門長からも起きます。力で押さえつけると長期的に失敗するため、五つの手法を組み合わせるのが有効です。
- 巻き込みによる共犯関係の構築：ベテラン社員を業務有識者として要件定義に招き、問題点を語ってもらいます。関与した人は責任感から推進派に転じやすくなります。
- 業務改善シナリオを体験させる：「今まで30分かかっていた月次集計が5分になります」とデモで見せ、日常業務に直結する改善効果を実感してもらいます。
- 上長経由ではなく本人に直接敬意を示す：「あなたの業務知識なしにはこのプロジェクトは成功しない」という姿勢を伝えると、感情的な抵抗が和らぎます。
- 移行後も役割が変わらない（むしろ上がる）ことを示す：「新システムのパワーユーザーとして社内サポートリーダーに」と役割を示すと、変化への不安が期待に変わります。
- 小さな成功体験を積ませる：「思ったより使いやすい」と実感してもらうことが、最終的な定着につながります。
また、研修後は必ずアンケートを取り、寄せられた声には発注側の担当者が翌週中に回答して、現場の信頼を積み上げます。
Day1パニックを乗り越えるサポート体制の作り方
本番稼働初日（Day1）は、どれだけ準備しても必ずトラブルが起きるため、起きる前提でサポート体制を設計することが大切です。具体的には、稼働日の午前7時にベンダーの担当者3名以上が現地またはオンラインで待機し、問い合わせ専用のチャットチャンネルを開設しておきます。
問い合わせは担当者別ではなくチームで受けることで、担当者が離席中でも即時に対応できる体制を作ります。Day1でよくあるパニックは三つあります。一つ目は「ログインできない」問題で、本番直前に大量のユーザーアカウントを作成するため、パスワード設定ミスや権限設定漏れが多発します。
これは、リハーサル時に全ユーザーのログインテストを必ず行うことで9割防げます。二つ目は「データが反映されていない」移行不完全問題で、移行完了チェックリストで、旧新の主要数値（件数・合計金額）を突合し、稼働前夜に終えておく必要があります。三つ目は「画面の動きが研修と違う」設定漏れ問題で、本番と研修の設定差異リストを事前に作り、本番で最終確認することが鉄則です。
プロジェクト炎上時のリカバリー戦略
プロジェクトが炎上したり、ベンダーが機能しなくなったりして、続けるべきか撤退すべきか判断できない状況に陥ることがあります。こうしたとき、感情的にベンダーを責めるだけでは、状況は改善しません。
炎上時には、冷静に状況を診断し、法的・実務的な対処の手順を踏むことが不可欠です。
炎上の兆候を見逃さないチェックリスト
炎上プロジェクトには必ず予兆があり、開始から3ヶ月以内にいずれかが現れたら、早期の介入が必要です。スケジュールが2週間以上遅れているのに「取り返せる」という楽観論が繰り返される状態は、現実逃避が始まっているサインです。
議事録が作られない、または共有されない会議が続く場合は、認識のずれが深刻になっています。また、ベンダーの担当者が突然変わった場合は、前任者が「逃げた」可能性もあり、引き継ぎの品質に懸念があります。さらに、追加費用の見積もりが次々と出され、当初予算の150%を超えそうな状況は、要件定義の甘さとスコープ管理の失敗が重なった典型例です。
こうした兆候が重なったら、PMO支援会社など外部の第三者に客観評価を依頼することを強くお勧めします。内部だけでは感情論になりがちですが、第三者の視点で続行か撤退かの判断基準が整理されます。実際、弊社が支援したリカバリー案件の約70%は、開始から6ヶ月以内に異常に気づいていたのに、対処が12ヶ月後にずれ込んだパターンでした。
ベンダーとの責任分界と法務対応・途中解約の判断基準
炎上時にベンダーとの関係が悪化すると、「仕様書を渡さない」「成果物を人質にする」「法外な追加費用を請求する」といった事態が、中小企業のリニューアルで実際によく起きています。「仕様書を渡さない」問題は、契約書に成果物一覧として仕様書・設計書・ソースコードを明記していなかった場合に起きます。
根本的な対策は、契約締結前に「成果物として何を納品するか」を箇条書きで確認し、契約書に添付することです。途中解約は、「スケジュール遅延が当初計画の50%以上」「品質が検収基準を3回連続で満たさない」「人員をアサインできていない（稼働証明が出ない）」のうち二つ以上が当てはまれば、弁護士を交えた解約協議を検討します。
請負契約では、民法632条に基づく完成義務があり、債務不履行を主張できることがあります。一方、準委任契約は成果物責任がなく、未完成でも支払い義務が生じることがあるため、契約形態の確認が先決です。ベンダーを切り替える際は、費用をかけてでも移行可能性調査で既存成果物の引き継ぎ範囲を確かめると、スコープと見積もりの精度が上がります。
中小企業のための「身の丈リニューアル」戦略
従業員50〜300名規模の中小企業では、専任のIT担当者がいないケースが大半です。「社内でシステムのことがわかるのは社長だけ」「ITベンダーに言われるまま契約を続けている」という状況から抜け出すには、現実的な戦略が役立ちます。
専任IT担当者がいない場合の進め方
専任IT担当者がいない場合は、まず「社内IT推進責任者」を任命します。ITに詳しい必要はなく、社内の業務を全部門にわたって把握している人であることが、最優先の条件です。
総務部長や経営企画部長が適任なケースが多く、この人物がベンダーとの窓口を担い、各部門の要望を集約します。さらに、外部のIT顧問（フリーランスPMO）を月10〜20万円程度で顧問契約し、推進責任者のサポート役として活用する方法も効果的です。
中小企業が陥りやすい失敗は、「ITに詳しい若手社員に丸投げする」ことです。個人のスキルに依存すると、その人の退職でプロジェクトが止まるリスクが高まり、意思決定権限もないため身動きが取れなくなります。そのため、経営幹部をスポンサーとして巻き込み、月1回以上のステアリングコミッティ（経営レビュー会議）を設けることが、中小企業では成功の鍵です。
「ケチってはいけない予算」と「削っていい予算」の境界線
予算が限られる中小企業では、どこにお金をかけ、どこを削るかの判断が重要です。絶対に削ってはいけない予算の筆頭は、要件定義・設計フェーズです。
- 要件定義・設計：全体予算の20〜30%を要件定義に投じるのが理想で、ここを削ると後半の追加費用として必ず跳ね返ってきます。
- データ移行・クレンジング：データ品質がリニューアル後の業務品質を直接決めるため、削減は禁物です。
- ハイパーケア期間のサポート体制：稼働直後の混乱を短期で収束させるためのコストで、現場の生産性損失と比べれば割安です。
一方、削ってよい予算の筆頭は、不要なカスタマイズ費用です。次に削る対象は、過剰なドキュメント作成費用と研修費です。
- 不要なカスタマイズ費用：Fit&Gap分析で件数を減らすのが最も効果的です。
- 過剰なドキュメント作成費用：大企業向けのドキュメント体制を中小企業に当てはめると数百万円かかることがあるため、実運用に必要な設計書に絞ります。
- 研修費：内製化できる部分があり、ベンダー主導ではなく、パイロットユーザーが社内講師になる「トレーナーズトレーニング」方式で、50〜70%削減できます。
よくある失敗パターンと回避策【事例付き】
システムリニューアルの失敗事例を分析すると、同じパターンが繰り返されていることがわかります。
なかでも「要件定義の手抜き」と「ベンダー丸投げ」の二つは、日本の中小企業におけるリニューアル失敗の約8割を占めるとも言われています。それぞれの構造的な原因と、具体的な回避策を見ていきます。
要件定義の手抜きで後から発生する追加費用の実態
要件定義を手抜きすると、稼働後に「現行システムでできていたことが新システムでできない」という問題が見つかり、追加費用がかかります。ある運送会社では、旧システムで当然のように使えていた「ドライバー別実績集計機能」を要件定義で言語化していなかったため、新システムに含まれず、追加開発費用として280万円が発生しました。
この費用は「仕様変更」扱いとなり、発注者側が全額負担せざるを得ませんでした。要件定義の品質を高める方法として、「業務シナリオテスト」の作成が非常に有効です。たとえば、「月曜の朝、営業担当者が先週の受注を確認し、出荷指示を出すまでの一連の操作」のように、業務の流れをシナリオとして文書化し、新システムでそのシナリオが完結するかを要件定義の段階で検証します。
このシナリオが承認されれば、後から「こんな操作ができないのはおかしい」という主張が通りにくくなります。また、要件定義書は50ページの大部なものより、業務シナリオ30本のほうが実用的であることを知っておいてください。
ベンダー依存・丸投げによる失敗とベンダーロックイン脱却
「ITのことはよくわからないからベンダーに任せます」というスタンスは、短期的には楽に見えますが、中長期では深刻なベンダーロックインを招きます。典型的な症状は、他社に見積もりを取ろうとするとソースコードや仕様書が出てこない、保守契約を打ち切ると言うと数千万円の移行費用が出てくる、軽微な設定変更にもベンダーの承認が要る、という状況です。
ロックインからの脱却は、まず、ソースコードと全設計書の所有権が発注者にあることを、新規または更新契約時に必ず明記するところから始めます。次に、運用マニュアルと管理者向けドキュメントを定期的に更新させる義務をSLA（サービスレベル合意書）に含めると、担当者交代時の引き継ぎコストを下げられます。
また、年に一度「他社ベンダーによる技術評価」を実施すると、現ベンダーへの牽制と市場価格の把握を同時に進められます。中小企業でも実践できる最初の一手は、現行システムの構成図と主要設定情報を書面で提出してもらうことです。
まとめ：成功するシステムリニューアルの3原則
ここまで、7ステップの流れや現場の課題、炎上時の対処、中小企業向けの進め方を見てきました。最後に、成功するシステムリニューアルを支える原則を三つ挙げます。
第一の原則は「プロジェクトのオーナーシップを発注者が持つ」ことです。ベンダーはあくまで技術的な実行パートナーであり、業務要件の定義、優先順位付け、最終判断は、すべて発注者の責任です。わからない部分は外部PMOに伴走してもらいながら、自分たちで決める姿勢が、成功の絶対条件です。
第二の原則は「データと現場を軽視しない」ことです。データクレンジングと抵抗勢力への対応は技術の話ではなく人と組織の話で、ここへの投資を惜しんだプロジェクトは、高確率で稼働後に問題を起こします。「システムが動く」ことと「業務が回る」ことは別物だと、チーム全員で共有することが必要です。
第三の原則は「炎上の兆候を見たら、早く動く」ことです。問題を先送りにするほど解決コストは指数関数的に増大するため、「まだ何とかなる」という楽観論を捨て、第三者の客観的な診断を早期に取り入れることが、プロジェクトを救う最善策です。
システムリニューアルは組織変革の最大の機会でもあります。泥臭いリアルと向き合いながら、ぜひ成功をつかんでください。
本テーマの全体像は、システムリニューアルの完全ガイドで確認できます。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。