レガシーシステムのリニューアルは、準備、RFPの作成、契約、旧ベンダーからの引き継ぎ、発注後の管理の順に進めると整理できます。
仕様書がない、旧ベンダーが協力しない、何から手をつければよいかわからないといった声は多く、既存システムがブラックボックス化したままの発注には特有の難しさがあります。
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステムリニューアルの発注前の準備
レガシーシステムのリニューアルは、新規のシステム開発に比べて発注前の準備の重要度が高くなります。
現行システムの状態を正確に把握しないまま発注すると、見積もりの精度が極端に低くなります。その結果、プロジェクトの途中で大幅な仕様変更が起き、予算超過につながりやすくなります。
発注前の準備に十分な時間と人員を割けるかどうかが、プロジェクト全体の成功を左右します。
仕様書・設計書がない場合の現行システムの棚卸し
レガシーシステムの多くは、当初の仕様書が失われているか、実装との乖離が大きくなっています。こうした状態でも、次の手順でシステムの棚卸しを進められます。
- 業務フロー・画面の洗い出し：担当者に画面ごとの操作を一つずつ確認し、各画面のスクリーンショットを操作手順とともに文書化します。これで機能一覧の原型ができます。
- データ構造の把握：テーブル一覧、カラム情報、件数をエクスポートし、各項目の意味を業務担当者に確かめて文書にします。
- 外部連携の特定：他システム、外部サービス（APIやファイル連携）、帳票出力、メール送信など、依存する要素を一覧にします。
- リバースエンジニアリングの検討：ソースコードが入手できる場合は、コードから仕様を逆算する作業を新しいベンダーに依頼する方法も有効です。
現場担当者が行っている非公式な運用（Excelによる手作業補完、定期的な手動データ修正など）も、必ず記録してください。こうした運用は、新システムへの移行要件として重要な情報です。
データベース管理ツール（A5:SQL Mk-2・pgAdmin・phpMyAdmin等）を使えば、仕様書がなくてもテーブル定義を取得できる場合が多くあります。不明なカラムや使われていないテーブルも、記録しておきましょう。
外部連携は新システムへの移行で見落とされやすく、後から発覚すると大幅なスコープ拡大につながります。そのため、発注前に必ず洗い出し、連携先のシステム担当者にもヒアリングして連携仕様の概要を確認します。
リバースエンジニアリングには一定の費用がかかるため、調査フェーズとして別に契約を結ぶのが一般的です。詳しくは後述の「調査フェーズの契約分割」で扱います。
社内体制の構築（IT担当者がいない場合）
中小企業では、「IT担当者がいない」「システムのことはすべて旧ベンダー任せだった」というケースが多くあります。こうした状況でも、次のアプローチで発注に向けた社内体制を整えられます。
- プロジェクトオーナーの任命：システム部門がなくても、業務を最もよく理解している部門のリーダーを任命します。
- PMO（プロジェクト管理支援）の外部調達：社内にITプロジェクトの経験者がいない場合は、ITコンサルタントやPMO支援会社の活用を強く推奨します。
- 各部門のキーパーソンの巻き込み：現場部門からキーユーザーを選び、要件定義への参加を依頼します。
プロジェクトオーナーを選ぶときは、「システムの技術知識があるか」よりも、「社内の業務要件を代弁できるか」「意思決定の権限があるか」が大切です。経営層に近い立場の人が担うと、予算の確保や関係部門の調整が進めやすくなります。
PMOは、開発ベンダーとは別に発注者側の立場でプロジェクトを管理・監督する役割です。こうしたPMOを置けば、ベンダー任せになるリスクを大きく下げられます。費用はかかりますが、プロジェクトが失敗するリスクと比べれば、十分に費用対効果が見込めます。
キーユーザーは、業務知識の提供、テストの実施、新システム移行後のサポートを担う重要な役割です。プロジェクトの開始時から参加してもらえば、「使えないシステムができあがった」という失敗を防げます。
経営層の合意形成と予算確保
レガシーシステムのリニューアルは、数百万円〜数千万円規模の投資になることが多くあります。経営層の強いコミットメントがなければ、プロジェクトが途中で頓挫するリスクがあります。
リニューアルしないリスクの可視化：
経営層を動かすには、「やらないことのリスク」を具体的な数字で示すのが効果的です。現行システムを使い続けることのリスクは、障害、保守、人材、セキュリティの各面で数字にできます。
- 障害の頻度：現行システムで起きている回数
- 対応コスト：現行システムの対応にかかる費用
- 保守ベンダーの撤退リスク：保守を担う会社が手を引く可能性
- エンジニアの採用の難しさ：COBOLやVB6など旧技術の人材不足
- セキュリティインシデントの発生リスク：事故が起きる可能性
たとえば、「このまま5年間維持した場合の総コスト」と「リニューアルした場合の初期投資＋ランニングコスト」を並べた資料を作ると、説得力が増します。
予算の段階的確保：
リニューアル全体の費用を一括で確保するのが難しい場合は、「調査・要件定義フェーズ」「設計・開発フェーズ」「移行・本番化フェーズ」に分けて、段階的に予算承認を得る方法が現実的です。最初のフェーズは比較的小さな予算で進められるため、経営層の合意も得やすくなります。
RFI・RFPの作成（レガシー特有の注意点）
レガシーシステムのリニューアル発注では、通常のRFP（提案依頼書）に加えて、まずRFI（情報提供依頼書）を活用すると効果的です。
現行システムの全体像をつかみきれていない段階では、ベンダーから技術的な助言や概算費用を引き出し、RFPの内容を磨いていくことが大切です。
レガシー特有の記載事項（現行システムの状況説明）
レガシーシステムのRFPには、通常のシステム開発のRFPにはない「現行システムの状況説明」の項目が欠かせません。ベンダーが適切な提案をできるよう、次の情報を可能な限り詳しく記載してください。
- 現行システムの基本情報：稼働開始年、使用技術（言語・フレームワーク・データベース・OS・サーバ環境）、ユーザー数、主な機能一覧を記載します。
- ブラックボックス化の程度：「仕様書の有無」「設計書の有無」「担当エンジニアが在籍しているか」を、正直に記載します。
- リニューアルの目的と優先課題：「保守できるエンジニアがいなくなる」「セキュリティ上の問題がある」など、リニューアルの動機を具体的に書きます。
特に「何年前に構築されたか」「最後にシステムを触ったエンジニアがいるか」は、ベンダーのリスク評価に直結する情報です。ソースコードが入手できるか、バージョン管理がされているかも、あわせて明記してください。
ソースコードの可読性（コメントの有無、変数名が意味をなしているか）も記載します。状況を過小評価してベンダーに伝えると、後から追加費用が発生するトラブルの原因になります。
例として「現行システムでは対応できない新機能が必要」「クラウド移行によるコスト削減」などがあります。目的によって、リニューアルの進め方（フルスクラッチ、リファクタリング、プラットフォーム移行、クラウドリフトアンドシフトなど）は大きく変わります。このため、ベンダーの提案の方向性にも影響します。
移行方式・データ移行要件の明記
レガシーシステムのリニューアルでは、データ移行が最も難易度が高く、トラブルも起きやすい領域です。RFPの段階で、データ移行の要件をできるだけ詳しく書いておくことが大切です。
- データ移行の対象と規模：移行するデータの種類（顧客データ、取引履歴、マスターデータなど）、件数、更新頻度、保持期間を記載します。
- データクレンジングの必要性：必要かどうか、どの程度の品質を期待するかをRFPに明記します。
- 移行方式の検討：「一括移行（ビッグバン移行）」と「段階的移行（フェーズ移行）」のどちらにするかを決めます。
移行するデータは、「過去○年分のデータを移行する」「○万件の顧客データを移行する」のように、具体的な数値で示します。こうした数値があると、ベンダーは移行の工数を適切に見積もれます。
長年稼働したシステムのデータには、重複、欠損、フォーマットの不統一、文字化けなどが蓄積していることがあります。さらに、クレンジング作業を誰が担当するか（発注者、ベンダー、共同）も、事前に決めておく必要があります。
一括移行はリスクが高い一方で、コストを抑えやすい方式です。段階的移行はリスクを分散できますが、並行運用の期間が生じます。
また、「移行時のシステム停止は何時間まで許容できるか」「移行後のデータ検証はどのように行うか」も、RFPに盛り込んでください。
ベンダーへの質問事項と評価基準
レガシーシステムのリニューアルに関する提案を評価するときは、通常のシステム開発とは異なる質問項目と評価基準を設けることが大切です。
確認すべき質問事項：
「過去にリバースエンジニアリングを伴うリニューアルプロジェクトの実績はあるか」「仕様書がない状態からの移行経験はあるか」と尋ねます。さらに、「データ移行の失敗事例と、その対処法を教えてほしい」「調査フェーズとしてのPoCは、どのように進めるか」「移行期間中の並行運用のサポートは、どのように行うか」を確認します。こうした質問で、ベンダーの真の実力が見えてきます。
評価基準のポイント：
レガシーリニューアルの評価では、「価格の安さ」より「リスク対応力」と「コミュニケーション能力」を重視すべきです。不確実性の高いプロジェクトでは、問題が起きたときにどれだけ誠実に対処できるかが、成否を左右します。そのため、提案書の完成度よりも、ヒアリング時の質問の鋭さや、懸念点を的確に指摘できるかを見ることをおすすめします。
契約締結時の重要ポイント
レガシーシステムのリニューアルは不確実性が高いため、契約段階での取り決めが、通常の開発以上に大切になります。
「やってみないとわからないこと」が多いプロジェクトだからこそ、その不確実性を管理する仕組みを契約に盛り込む必要があります。
請負契約 vs 準委任契約の使い分け
レガシーシステムのリニューアルでは、フェーズによって適した契約形態が変わります。使い分けを理解しておくと、発注者のリスクを適切に管理できます。
- 請負契約が適するフェーズ：要件が明確になった後の「実装・テストフェーズ」が対象です。
- 準委任契約が適するフェーズ：現行システムの調査、要件定義、基本設計の段階で結ぶ契約です。
- ハイブリッドアプローチ（推奨）：実務では、調査・要件定義は準委任、設計・実装・テストは請負とする方法が、最も多く採用されています。
請負は完成した成果物に対して報酬を支払う形式なので、仕様を確定したうえで請負にすれば、品質の責任をベンダーに明確に負わせられます。ただし、レガシーリニューアルでは「調査してみたら想定外の問題が見つかった」というケースが多いため、変更対応の条件を契約に明記しておくことが欠かせません。
「やってみないとわからない」要素が多い調査フェーズでは、工数に応じて報酬を支払う準委任が現実的です。準委任は成果物の完成を約束しません。そのため、「何を成果とするか」（調査報告書・要件定義書等の文書）を契約に明記しておく必要があります。
フェーズの区切りと、請負フェーズに移るための条件（要件定義書の承認など）を明確にしておくと、双方のリスクをバランスよく分担できます。
調査フェーズの契約分割（PoC・フィジビリティスタディ）
レガシーシステムのリニューアルで特に大切なのが、調査フェーズを独立した契約として分けるアプローチです。全フェーズを一括で契約するのではなく、まず調査フェーズだけを契約すると、発注者のリスクを大きく減らせます。
調査フェーズ（フィジビリティスタディ）の内容：
現行システムのソースコード、データ構造、外部連携の詳細な調査、リニューアルの技術的な実現可能性の検証、概算費用とスケジュールの精度を高めるための情報収集を行います。この段階で「想定よりはるかに複雑だった」「特殊な技術が使われていて対応が難しい」といった問題が見つかっても、被害を最小限に抑えられます。
PoC（概念実証）の活用：
技術的に不確かな部分がある場合は、PoCとして部分的なプロトタイプを作り、実現可能性を確かめてから本格開発に進む方法が有効です。「新技術で現行の処理速度を実現できるか」「データ移行のサンプルが正しく移行できるか」などを小規模で確認すれば、本番のリスクを減らせます。PoCの費用は数十万円〜数百万円程度が相場で、プロジェクト全体の費用と比べれば小さな投資です。
スコープ変更への対応条項
レガシーシステムのリニューアルでは、調査が進むにつれて「想定外の機能が見つかった」「データの品質が想定より悪かった」といったスコープ変更が避けられません。こうした変更への対応を、契約に明記しておくことが欠かせません。
想定外発見時の対応手順：
「調査の結果、当初の見積もりから○%を超える工数増加が見込まれる場合は、双方で協議の上でスコープまたは予算を再設定する」という条項を、契約に盛り込みます。この「協議義務」を明文化しておけば、ベンダーが一方的に追加費用を請求することを防げます。
変更管理プロセスの明記：
スコープ変更の申請手順、影響評価の期限、承認の流れ、変更後の契約更新の手続きを、書面で取り決めておきます。口頭での変更依頼は「言った言わない」のトラブルの原因になりやすいため、変更はすべて書面で記録することを契約に明記してください。
【独自】旧ベンダーからの乗り換え交渉術
レガシーシステムのリニューアルで最大のハードルの一つが、旧ベンダーからデータや仕様書を引き継ぐことです。
長年の保守実績を持つ旧ベンダーが、情報開示に協力的でなかったり、引き継ぎを拒否したりするケースは珍しくありません。この問題に正面から向き合うことが、リニューアル成功の鍵になります。
データ・仕様書の引き出し方
旧ベンダーからデータや仕様書を引き出すには、まず「何を要求できる権利があるか」を正確に理解することが大切です。
- 知的財産権の確認：ソースコード、データベース設計書、仕様書の著作権（知的財産権）が誰に帰属するかを、最初に確認します。
- データの引き渡し要求：ソースコードの著作権がベンダーにあっても、データベースに格納されたデータは発注者（貴社）の財産です。
- 段階的な引き継ぎ要求：最初から全情報の開示を求めるより、段階を踏んで求めるほうが円滑に進むケースが多くあります。
なお、発注者が費用を負担して開発した場合でも、契約に「著作権はベンダーに帰属する」と書かれていると、ソースコードの開示を求める権利がない場合があります。既存の契約書は弁護士に確認してもらい、権利関係をはっきりさせてから交渉に臨むことをおすすめします。
データのCSVエクスポートやデータベースダンプの提供を求める権利は、発注者にあります。旧ベンダーがデータの引き渡しを拒んだ場合は法的に問題になる可能性があるため、最終的には応じざるを得ないケースがほとんどです。
旧ベンダーとの関係を壊さないためには、「まずデータ定義書だけでも共有してほしい」「運用手順書の提供をお願いしたい」と求めます。旧ベンダーが「情報を開示するほど自社が不要になる」と感じている場合は、インセンティブを示すのも有効です。インセンティブの例は、「保守業務の引き継ぎ料を支払う」「移行後も一定期間のサポート契約を維持する」です。
非協力的なベンダーへの法的対処法
旧ベンダーが情報の開示に応じない場合や、引き継ぎを意図的に妨げている場合は、法的な手段も検討する必要があります。
- 内容証明郵便による正式な要求：要求が無視されている場合は、弁護士名義の内容証明郵便で引き継ぎ資料の提供を正式に求めます。
- 契約違反の主張：保守契約に「契約終了時のドキュメント提供義務」や「引き継ぎ支援義務」が含まれているかを確認します。
- ベンダーロックイン対策の教訓：新ベンダーとの契約には、必ず「契約終了時のソースコード・ドキュメント・データの引き渡し義務」を盛り込みます。
内容証明は法的な証拠として機能するため、旧ベンダーの態度が変わることが多くあります。費用は数万円程度で、弁護士への相談から内容証明の送付まで、数日から1週間程度で対応してもらえます。
含まれている場合は、その不履行を根拠に損害賠償を請求できます。弁護士に契約書を精査してもらい、旧ベンダーの行為が契約違反に当たるかを確認してください。
非協力的なベンダーへの対応には、多大な労力がかかります。そのため、「ソースコードのエスクロー（第三者への預け入れ）」も盛り込み、同じ失敗を繰り返さないようにしてください。
エスクロー契約は、ベンダーが廃業したりサービスを終了したりした場合でも、ソースコードを入手できる仕組みです。特に基幹システムでは、強く推奨します。
移行期間中の並行運用と引き継ぎの取り決め
新システムへの移行期間中は、旧システムと新システムを並行して運用するのが一般的です。この期間の責任分担と費用負担を、事前に明確にしておくことが大切です。
並行運用期間の定義：
「旧システムの保守を続ける期間」と「新システムへ完全に移行するタイミング」を、旧ベンダーと新ベンダーの双方と合意します。並行運用の期間が長くなるほどコストは増えるため、明確なカットオーバーの日程と、それまでの判断基準（新システムの受け入れ条件）を定めておきましょう。
旧ベンダーへの引き継ぎ支援費用：
旧ベンダーに引き継ぎ作業（仕様説明・質問対応・ドキュメント整備等）を依頼する場合は、その費用を明確にしておく必要があります。一般的には、時間単価×工数で見積もりを取り、上限金額を設定した契約を結びます。旧ベンダーが過大な費用を求めてくる場合は、新ベンダーによるリバースエンジニアリングを選ぶほうが、結果的に安くなるケースもあります。
発注後のプロジェクト管理（発注者の役割）
レガシーシステムのリニューアルプロジェクトは、ベンダーに任せきりにすると、問題が高い確率で発生します。発注者が能動的に関わることが、プロジェクト成功の大きな要因になります。
特に不確実性の高いレガシーリニューアルでは、問題を早く見つけ、すばやく意思決定することが求められます。
ベンダー任せにしない進捗管理
「ベンダーを信頼する」ことと「ベンダー任せにする」ことは、まったく別のことです。発注者は定期的にプロジェクトの状態を確認し、必要に応じて意思決定を行う責任があります。
- 週次定例ミーティングの設定：週1回のステータス報告で、進捗、課題、リスクを共有します。
- マイルストーンレビューの実施：要件定義、基本設計、実装、テストの各段階の完了時に、成果物のレビューと承認を行います。
- EVM（アーンドバリューマネジメント）の活用：中規模以上のプロジェクトでは、スケジュールとコストの進捗を数値で管理すると効果的です。
週次定例では、アジェンダは「①先週の実績 ②今週の計画 ③課題・リスクの共有 ④意思決定が必要な事項」の4項目を基本とし、毎回議事録を残します。発注者側からも必ず担当者が参加し、ベンダーが困っていることを早い段階でつかめる体制を整えましょう。
承認の際は、「何を確認し、何を承認したか」を文書に残してください。後から「承認した覚えがない」といったトラブルを防ぐためです。承認基準（受け入れ条件）を事前に定めておけば、恣意的な判断を避けられます。
計画コスト（PV）、実績コスト（AC）、出来高（EV）を週次で追うと、プロジェクトの健全性を客観的に評価できます。EVMに慣れていない場合でも、「当初の計画に対して何%完成しているか」を数値で把握する習慣をつけることをおすすめします。
「言った言わない」を防ぐドキュメント管理
レガシーシステムのリニューアルは不確実性が高く、仕様変更や認識のずれが起きやすい環境です。「言った言わない」のトラブルを防ぐには、ドキュメントの管理が欠かせません。
- 決定事項の即時文書化：ミーティングで決まった事項は、終了後24時間以内に議事録にまとめ、参加者全員に送って確認を求めます。
- 課題管理ツールの共有：Backlog、Jira、Redmine、GitHubのIssueなどを、発注者とベンダーの双方が参照・更新できる形で運用します。
- 成果物のバージョン管理：要件定義書、設計書、テスト仕様書などは、更新のたびにバージョン番号、更新日、更新者を記録します。
特に「仕様変更」「スコープ変更」「スケジュール変更」に関わる決定は、必ず書面で相互に確認してから実行します。「メールで送ったが確認されていなかった」という事態を防ぐため、重要な決定事項は返信での確認を必須にします。
口頭での指示や個人メールでの依頼は原則禁止とし、すべての課題と変更要求をツール上で管理します。そうすれば、作業履歴と決定の経緯を一元的に追えます。
どれが最新版か分からなくなる事態を防ぐため、共有フォルダの命名規則やファイル管理のルールを、プロジェクトの開始時に決めておきましょう。
炎上兆候の早期発見と対処
レガシーシステムのリニューアルでは、問題が表面化するのが遅れがちです。炎上の兆候を早く察知し、手を打つことが大切です。
- 炎上の典型的な兆候：報告の遅れや曖昧さ、担当者の頻繁な交代などが挙げられます。
- 早期対処のアプローチ：兆候に気づいたら、ベンダーのプロジェクトマネージャーに「率直に現状を教えてほしい」と直接たずねます。
- 撤退判断の基準：プロジェクトの継続が技術面や財務面で不可能だと判断した場合は、損切りの決断も必要です。
ほかにも、「予定していたデモができない状態が続く」「課題管理ツールの更新が止まる」といった状況があります。ベンダーから「問題ない」という言葉ばかりで、具体的な説明がない状況も兆候の一つです。
こうした状況が続く場合、プロジェクトが危機的な状態にある可能性があります。これらのサインを見逃さないことが大切です。
問題を隠しているとは限らず、報告の仕方が悪いだけの場合もあります。問題が深刻であれば、PMO支援会社や独立したITコンサルタントなど第三者のプロジェクト監査を入れ、客観的に評価してもらうのも有効です。
炎上が確定した場合は、「縮小版リリース（最低限の機能で本番稼働）」と「残りの機能の段階的なリリース」に切り替えると、全面的な失敗を避けられます。
「ここまでの投資が無駄になる」というサンクコストに引きずられて続けると、さらに大きな損失につながるケースは少なくありません。定期的に「このまま続けるべきか」を客観的に評価する仕組みを持つことが、経営リスクの管理につながります。
まとめ
準備から発注後の管理までを通して、特に押さえておきたいのは次の5点です。
- ①発注前の現行システムの棚卸し：業務フロー・画面・データ構造・外部連携を文書にする
- ②調査フェーズの独立契約（分割）：全フェーズを一括で契約せず、まず調査とPoCを別の契約で進める
- ③旧ベンダーからの引き継ぎの早期着手：データの権利確認、段階的な情報要求、必要に応じた法的対処を準備する
- ④契約へのスコープ変更対応の組み込み：変更管理プロセスと協議義務を契約に明記する
- ⑤発注者による能動的なプロジェクト管理：週次定例、ドキュメント管理、炎上兆候の早期察知を発注者側で行う
仕様書がない状態でも、業務フロー・画面・データ構造・外部連携を地道に文書化すれば、発注の精度を高められます。この準備を省くと、後工程でのトラブルや追加費用が増えてしまいます。
発注者は「やってみないとわからない」部分を正直に認め、段階的に進めることが成功への近道です。
新ベンダーとの契約には、ベンダーロックインを防ぐ条項を必ず盛り込みましょう。
レガシーリニューアルでは、想定外の問題が必ず起こります。変更管理プロセスと協議義務を契約に明記しておけば、追加費用をめぐるトラブルを防げます。請負と準委任を組み合わせるハイブリッドアプローチも、特に有効です。
週次定例、ドキュメント管理、炎上兆候の早期察知など、発注者側のプロジェクト管理能力が、リニューアルの成否を大きく左右します。社内にIT担当者がいない場合は、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を創業。