システムリアーキテクチャは、5つのフェーズに分けて段階的に進めるのが基本です。現状評価から始め、定着化まで順に進みます。
全体の期間は中堅企業（開発者30〜100名規模）で18〜36か月が目安です。スモールスタートなら、最初の成果は6か月以内に出せます。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・システムリアーキテクチャの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
システムリアーキテクチャとは――2026年に求められる再定義
システムリアーキテクチャとは、既存システムの構造そのものを再設計し、新しい技術基盤と組織の能力に合わせ直すことです。古いコードを新しい言語で書き直すリプレースや、個別の問題箇所を直すリファクタリングとは異なり、設計原則の全体を根本から見直す取り組みです。
見直しの対象には、責務の分離方法やサービス間の通信パターンが含まれます。さらに、データの所有権と境界、デプロイメントの単位も対象になります。2026年時点では、この定義自体が進化しており、技術の移行にとどまらず「ビジネスの俊敏性を回復する組織変革」と位置づける企業が増えています。
リファクタリング・リプレースとの違い
リファクタリング、リプレース、リアーキテクチャは混同されやすいものの、適用すべき状況と期待できる効果が大きく異なります。リファクタリングは、外から見た機能やインターフェースを変えずに、内部の実装を改善する手法です。可読性の向上や技術的負債の局所的な解消には有効ですが、データベースの密結合やモジュール間の循環依存といった構造上の問題には対処できません。
リプレースは、既存システムを新しいシステムに全面移行する手法で、スクラッチ開発によるゼロベースの再構築が代表例です。ただし、プロジェクト期間が長大になりやすく、IPAの調査では大規模リプレースの失敗率が約40%に達するという統計もあります。
これに対してリアーキテクチャは、ビジネスの継続性を保ちながら構造を段階的に変える手法です。後述するストラングラーフィグ・パターンのような漸進的なアプローチにより、リスクを分散させながら価値を継続的に生み出せます。
なぜ2026年に注目されるのか――三重の外圧
2026年に経営課題として急浮上した背景には、IT予算の60〜80%がレガシーシステムの維持管理に費やされているという現実があります。ガートナーの2025年調査では、日本企業のIT投資の平均74%がシステム維持費となり、新機能開発やDX推進に充てられる予算は26%にすぎません。この「維持費の罠」に加えて、三つの外圧が重なっています。
- 規制対応：EUのDORA規制（2025年1月完全施行）は、金融セクターのITシステムに、リスク管理やインシデント報告などを義務づけています。
- AI統合：密結合したCOBOLやJ2EEのシステムでは、APIを通じたAIサービスとの連携が難しいです。
- 技術債務：2000年代に構築したJ2EEや1990年代のCOBOLシステムを維持するエンジニアが高齢化しています。
モノリシックなレガシーシステムでは、これらの要件を満たすことが技術的に困難です。NIS2指令も重要インフラを持つ企業に幅広く適用され、コンプライアンスの不備は、売上高の最大2%または1,000万ユーロを上限とする制裁金のリスクを生じさせます。
McKinseyの試算では、レガシー制約によるAI導入の遅れが2026〜2030年に企業の競争力格差を平均23%拡大させると警告されています。2030年には国内でCOBOL保守エンジニアが約35%不足すると予測されています。この三重の外圧が重なる2026年は、リアーキテクチャを「いつかやること」から「今すぐ始めること」へ転換させる臨界点になっています。
2026年のアーキテクチャトレンド――モジュラーモノリスの台頭
テクノロジー業界では2023〜2025年にかけて、「マイクロサービスが常に正解」という考え方が崩れました。Kubernetes上に小さなサービスを何十個も分散させた結果、サービス間の依存関係が複雑に絡み合い、デバッグに通常の3〜5倍の時間がかかる「分散型モノリス」に悩む企業が相次いだからです。
この反省から、2026年のリアーキテクチャの議論では、「どのアーキテクチャが最先端か」より「自社の規模と成熟度に合うのはどれか」を問う実用的な視点が主流になっています。
マイクロサービスからの回帰事例と教訓
2023年にAmazon Prime Videoが公開したブログ記事は、業界に衝撃を与えました。同社はビデオ品質監視システムを分散マイクロサービスからモジュラーモノリスに移行し、インフラコストが90%削減されるとともに、オペレーションの複雑さも大幅に低減されたと報告しています。同社以外にも、過度に細分化されたサービス群を見直す動きがあります。
- 同様の方向転換：Shopify、Stack Overflow、Basecamp（37signals）も、統合の方向へ舵を切っています。
- Lyft：Istioを開発したLyftは、サービスメッシュのオーバーヘッドを率直に反省し、適切なサービス粒度の見直しを推奨するようになりました。
- 国内の事例：ECプラットフォームや金融系Fintechで、マイクロサービス化が裏目に出たケースが増えています。
- 失敗の典型：ドメイン境界の設計が不十分なまま機能単位でサービスを分割すると、「画面を一つ追加するために5つのサービスのデプロイが必要」という状態に陥ります。
国内では、2020〜2022年のマイクロサービス化投資が「分散型モノリス」という最悪の状態を生んだケースも見られます。こうした失敗では、リアーキテクチャの対象が「失敗したマイクロサービス群」になることも少なくありません。この教訓から、2026年のベストプラクティスでは、チーム規模とデプロイ頻度を基準にしたアーキテクチャ選定が強調されています。
モジュラーモノリスが最適解となる条件と「劣化」防止策
モジュラーモノリスとは、デプロイの単位を一つに保ったまま、内部をドメイン境界に沿った明確なモジュールに分割するアーキテクチャです。次の三つの条件がそろえば、マイクロサービスより優れた選択肢になります。
- 開発チームの規模：50名以下
- 1日のデプロイ回数：10回未満
- ドメインの複雑さ：中程度
採用のメリットは、サービス間のネットワーク通信の負担がなくなることです。デバッグのためのトレース収集も単一プロセス内で完結し、インフラコストと運用負荷も大幅に減らせます。
一方で、時間の経過とともにモジュール境界が劣化する問題には注意が必要です。開発速度を優先するあまり、異なるドメインのモジュールが互いの内部実装に直接依存するようになり、最終的に普通のモノリスへ逆戻りするリスクがあります。
この劣化を防ぐには、アーキテクチャテストをCI/CDパイプラインに組み込むことが不可欠です。
- ツール：ArchUnitやjQAssistant（Java系）、Goのパッケージ依存関係検査ツールなど
- 検出の例：「受注ドメインのコードが在庫ドメインの内部クラスに直接アクセスしている」といった境界違反
- 止め方：Pull Requestの段階で検出し、ビルドを失敗させるルールで止めます。
アーキテクチャの番人をCI/CDに組み込んでいるかどうかが、モジュラーモノリスを長く維持できるかの分かれ目になります。
システムリアーキテクチャの進め方――5つのフェーズ
システムリアーキテクチャを成功させるには、理想の状態を一足飛びに目指すより、フェーズに区切って段階的に進めることが大切です。ここで示す5フェーズは、リアーキテクチャの途中で完全停止のリスクを抑えながら、ROIを測定して進めるための実践的なロードマップです。
5フェーズ全体の期間は、中堅企業（開発者30〜100名規模）で18〜36か月が目安です。スモールスタートを重視すれば、最初の成果を6か月以内に出すことも可能です。
フェーズ1：現状評価とアーキテクチャ診断（1〜2か月）
最初のフェーズでは、現行システムの技術的負債を測り、リアーキテクチャの優先度と方向性を決めます。中心になるのは「アーキテクチャ・フィットネス関数」の測定で、主に次の二つを見ます。
- コード品質：コードカバレッジ、循環的複雑度、モジュール結合度
- デプロイの実績：デプロイ頻度（DORAメトリクス）と変更障害率
今のシステムがどの程度「変更に強い」構造かを、数値で把握できます。
2026年は、AIを活用した静的解析ツール（GitHub Copilot Workspace、Amazon CodeGuru、SonarQubeのAI機能）が、この分析を大幅に効率化しています。従来の手作業による依存関係マッピングと比べて、最大50%の工数削減が報告されています。
ただし、AI分析には限界があり、検出できるものとできないものがあります。
- 検出できるもの：コード上に明示された依存関係
- 検出できないもの：「年度末の決算バッチが終わってから実行しなければならない」といった暗黙のビジネスルールや、ベテランの経験知として文書化されていない制約
このため、AIの分析結果は、5〜10年の業務経験を持つドメインエキスパートと突き合わせるヒューマン・イン・ザ・ループのレビューにかけます。そのうえで「ストラングラー優先度マトリクス」を作成します。縦軸に変更頻度（月次の変更回数）、横軸にビジネスインパクト（売上や顧客への影響度）を取り、既存機能を四象限に配置します。これにより、最初にリアーキテクチャすべき対象を客観的に選べます。
フェーズ2：ターゲットアーキテクチャの設計と技術選定（2〜3か月）
フェーズ2では、フェーズ1の診断結果をもとに、将来あるべきアーキテクチャを設計して採用技術を選びます。その際、特に大切な判断軸が、ベンダーロックインとマルチクラウド対応のトレードオフです。たとえば、AWS Lambdaを全面的に採用すれば開発速度は上がりますが、AWSへの依存度が高まり、将来のマルチクラウド化では抽象化レイヤーの追加コストが生じます。
一方、Kubernetesを中心とした抽象化レイヤーを設ければ移植性は高まりますが、Kubernetesの運用スキルを持つエンジニアの採用・育成コストが追加で必要になります。このトレードオフは、TCO（総所有コスト）の5年試算で定量的に評価することを推奨します。
マネージドサービスを活用するオプションAと、抽象化レイヤーを設けるオプションBを比べると、多くの中堅企業では、3〜5年の期間でオプションAのほうが20〜30%低コストになるという試算が出ます。
アーキテクチャ選定では、「アーキテクチャ選定マトリクス」が有効です。評価の軸は次の四つです。
- チームサイズ：1〜5名、6〜15名、16名以上の区分
- デプロイ頻度：月次、週次、日次の区分
- 変更の独立性要求：低・中・高の区分
- スケーリング要求：均一・部分的・個別の区分
モノリス、モジュラーモノリス、マイクロサービスのどれが最適かを、この四つの軸で明確にできます。
フェーズ3：ストラングラーフィグ・パターンによる段階的移行（6〜18か月）
実際の移行では、ストラングラーフィグ・パターンを中心的な手法として採用します。熱帯植物のストラングラーフィグ（絞め殺しの木）が既存の木を外側から包み込み、少しずつ置き換えていく様子になぞらえた手法です。レガシーシステムを一度に全面停止させず、機能ごとに新アーキテクチャへ移行していきます。具体的には、まず「ファサードレイヤー」をレガシーシステムの前段に配置します。
このファサードがすべてのリクエストを受け付け、移行済みの機能は新システムへ、未移行の機能はレガシーシステムへとルーティングします。
移行の順序は、フェーズ1で作成したストラングラー優先度マトリクスに基づき、変更頻度が高くビジネスインパクトが中程度の機能から始めるのが、最もリスクの低い進め方です。一方で、このフェーズで最も難しい課題がデータマイグレーションです。ダウンタイムゼロでの移行は理論上可能でも、実装の複雑さが大幅に増します。その実装パターンの一つが「ダブルライト」です。
移行期間中は旧DBと新DBの両方に書き込み、新システムの読み取りは新DBから行いながら、旧DBとの一貫性を定期的に検証します。
10年以上稼働してきたレガシーデータには、移行時に表面化しやすい問題が潜んでいます。問題は、文字コードや値の扱い、項目の意味、参照関係の面で見られます。
- 文字コードの混在：Shift-JISとUTF-8の混用が見られます。
- NULL値とブランク値：両者が混在しています。
- カラムの変質：事業変更で意味が変わったカラムがあります。
- 参照関係：削除されたはずの参照整合性の欠落が見られます。
移行前のデータプロファイリングに最低4〜8週間を確保し、データ品質の問題を事前に洗い出すことを強く推奨します。
フェーズ4：並行稼働と移行完了（3〜12か月）
フェーズ4は、旧システムと新システムが並行稼働する過渡期です。計画で最も過小評価されやすい工程で、多くのリアーキテクチャプロジェクトがここで予算超過と期間延長を経験します。並行稼働のコストは初期見積もりの1.5〜2倍になるケースが多く、その主な理由は三つあります。
- 二重管理の複雑さ：同じデータを二つのシステムで整合性を保ちながら管理するため、オペレーションの負荷が想定以上に大きくなります。
- ロールバックのコスト：新システムで問題が起きたときに旧システムへ切り戻すため、データの同期処理が複雑になります。
- ユーザートレーニングと運用ルールの二本立て：移行期間中は新旧両方のユーザーが混在するため、サポート体制と操作マニュアルを二系統で維持する必要があります。
二重管理では、本番データの不一致を調べて直す作業が、通常のバグ対応よりも格段に工数がかかります。これらのコストは事前に見積もりへ含めるとともに、「機能別カットオーバー計画」を詳細に策定しておくことが成功の鍵です。
具体的には、移行が完了した機能を月次で一覧にし、全体の移行率を追跡します。進捗と残リスクは、ダッシュボードでステークホルダーに示します。
フェーズ5：定着化とアーキテクチャ・ガバナンスの確立（継続的）
旧システムのシャットダウンが完了しても、プロジェクトは終わりではありません。フェーズ5では、新アーキテクチャの効果を持続させるガバナンス体制を確立します。最優先の施策は、前述したアーキテクチャテストをCI/CDに組み込むことです。
加えて、「アーキテクチャ決定記録（ADR：Architecture Decision Record）」の文化を組織に定着させることが、長期的な成功を左右します。ADRは、1〜2ページの軽量なドキュメントに記録するプラクティスで、次の内容を残します。
- 選んだ理由：なぜそのアーキテクチャを選んだのか
- 検討した選択肢：どの選択肢を検討したのか
- 見直し時期：決定の前提が変わった場合の見直し時期
ADRがなければ、3年後には誰も設計判断の理由を知らず、同じ議論を繰り返す「アーキテクチャの健忘症」に陥ります。
さらに、DORAメトリクスを定期的に計測し、リアーキテクチャのROIを定量的に評価することも、経営層との対話や予算確保の観点から欠かせません。計測する指標は、次の四つです。
- デプロイ頻度：本番へ反映する頻度
- 変更リードタイム：変更を加えてから本番に届くまでの時間
- 変更障害率：変更が障害につながる割合
- MTTR：障害からの平均復旧時間
成功した企業では、プロジェクト完了後2年以内にデプロイ頻度が平均4.7倍に向上し、障害復旧時間（MTTR）が平均60%短縮されたというデータがあります。
失敗しないためのポイント――競合記事が語らないリアルな課題
成功事例と理想的な手順の解説だけでは、現場の難しさが見えにくくなります。計画どおりに進まない要因は必ず存在し、事前の準備が成否を分けます。ここでは、そうした「リアルな課題」を四点取り上げます。
AIモダナイゼーションの限界とヒューマン・イン・ザ・ループの設計
2025〜2026年にかけて、AWS、Google Cloud、Microsoftは、「AIによるレガシー自動モダナイゼーション」ツールを相次いで提供し始めました。これらは、COBOLやJ2EEのコードをAIが解析し、JavaやGoのコードへ変換するもので、分析フェーズで最大50%の時間削減を謳っています。実際に、コード変換の自動化率が50〜70%に達するケースもあり、一定の効果は認められます。
一方で、現場で必ず直面するのがAIハルシネーションのリスクです。生成された変換コードのうち、「構文上は正しいが、ビジネスロジックを誤って解釈している」ものが、全変換コードの15〜25%程度発生します。
特に問題になるのは、次の二つです。
- 計算の精度：COBOLの計算処理における「精度（小数点以下の桁数と丸め方法）」の解釈差異
- 会計の端数処理：会計処理の端数計算ルール
これらの誤りをテストですべて捕捉するには、テストケースを設計する人が元のCOBOLの意図を深く理解している必要があります。そのため、AIで変換しても、ドメイン知識を持つ人によるコードレビューとテストシナリオの設計を組み合わせた「ヒューマン・イン・ザ・ループ」の運用体制を設計することが不可欠です。
具体的には、次の二つのテストを標準化します。
- 数値一致：全変換コードに対して、元の処理と数値が一致するかを100ケース以上のテストで確かめます。
- 境界値：最大値、最小値、ゼロ除算などでの挙動を検証します。
AIは「たたき台を高速に生成するツール」にすぎず、検証を省ける道具ではありません。この認識を組織全体で共有することが、AIモダナイゼーションを安全に進める前提条件です。
リスキリングの具体的ロードマップ――COBOLエンジニアの現代的転換
リアーキテクチャの技術的課題として語られることは少ないものの、人材の転換（リスキリング）は大きなリスクです。20年以上COBOLやJ2EEでシステムを支えてきたベテランエンジニアは、最も貴重なドメイン知識の持ち主です。一方で、Kubernetes、Go、Rustといった現代的な技術スタックには不慣れなケースが多く、このギャップをどう埋めるかが課題になります。
経験豊富なエンジニアが新技術へ移るには、クラウドの基礎、コンテナ、運用の順に、段階を追って学ぶのが現実的です。
- フェーズ1（3か月）：AWSの主要サービス、コンテナとVMの違い、CI/CDパイプラインの仕組みといった、クラウドの基礎概念を身につけます。
- フェーズ2（3〜6か月）：Dockerでコンテナ化を実践し、GoやTypeScriptによるAPIサービス開発の基礎を習得します。
- フェーズ3（6〜12か月）：Kubernetesの運用、GitOps、オブザーバビリティツールを実践的に活用します。
フェーズ1では、既存システムの知識と新技術をつなぐ橋渡し役として活躍してもらいながら学習を進めます。なお、フェーズ3で扱うオブザーバビリティツールには、DatadogやJaegerなどがあります。
ここで避けたいのは、リスキリングを「既存業務と並行した自己学習」に任せてしまうことです。実務時間の20〜30%を学習と実践に充てることを組織として公式に認め、学習成果をパフォーマンス評価に反映させることで、エンジニアの主体的な参加を促せます。
COBOLエンジニアのビジネスドメイン知識は、新しいシステムを設計するうえで代替できない資産です。学習を支えながら、その知識を新アーキテクチャに移すことが、組織としての最大の競争優位になります。
ROIの定量的測定と経営層への説明責任
リアーキテクチャのROIを証明することは、多くのCTOが頭を悩ませる課題です。McKinseyの調査では、モダナイゼーションプロジェクトの平均コストは290万ドルに達し、経営層がビジネス価値を実感できるまでに平均18か月を要するとされています。このギャップを埋めるために、「フィーチャーベロシティ指標」と「インシデントコスト削減指標」の二つでROIを測ることを推奨します。
- フィーチャーベロシティ指標：新機能を企画から本番リリースまで届けるリードタイムです。
- インシデントコスト削減指標：障害1件あたりの平均復旧時間（MTTR）と影響を受けたユーザー数の積で算出します。
リアーキテクチャの前後で、この数値がどれだけ改善したかを月次で追跡します。あるBtoB SaaS企業では、リアーキテクチャ完了後12か月でリードタイムが平均47日から9日に短縮され、年間リリース回数が12回から156回に増えました。この結果をROIの根拠として、取締役会に報告しています。
これらの指標で、月次の損失コストを把握します。これらを月次の経営報告に組み込めば、「リアーキテクチャは費用ではなく投資」という認識を経営層に定着させられます。
ROI計算テンプレートでは、投資回収率を次の式で算出します。
- 分子：年間インシデントコスト削減額、フィーチャーベロシティ向上による機会収益、インフラコスト削減額の合計
- 分母：プロジェクト総コストを5年間で割った額
投資回収率は、プロジェクト開始前、進捗報告時、完了後の三点で計測する標準プロセスとして設計することを推奨します。
中堅企業向けスモールスタートのアプローチ
テックジャイアントの事例は参考になりますが、開発者500名規模の事例を、開発者30名の中堅企業にそのまま当てはめることはできません。中堅企業が最初に選ぶべきは、「最も痛みが大きく、最も境界が明確な一つの機能」です。たとえば、「ユーザー認証と権限管理」は、多くのレガシーシステムで変更頻度が高く、他の機能との依存も整理しやすい領域です。
最初の目標は、この単一機能を新アーキテクチャで実装し、ストラングラーフィグで切り替えるパイロット実験を3か月以内に完了させることです。あるIT部門が10名の製造業企業では、約20年稼働してきたJ2EEの在庫管理システムのうち、「入出庫記録の登録・照会」機能だけを先行して、Spring Boot＋Vue.jsで再実装しました。ルーティングの切り替えには、nginxをファサードとして使っています。
3か月のパイロットでは、デプロイ時間が4時間から8分に短縮し、テストカバレッジは0%から72%に向上しました。この成果を社内で共有したことで、経営層から追加予算の承認が得られ、残りの機能を移行するプロジェクトへ発展した事例があります。スモールスタートの成功体験を社内に積み上げ、次の投資承認に活用するサイクルを回すことが、リソースに限りがある中堅企業にとって最も現実的な戦略です。
まとめ
ここまで、システムリアーキテクチャの定義と2026年の最新トレンド、5つのフェーズの進め方、そして現場で課題になりやすい点と対策を見てきました。2026年に成功させるための核心は、次の四点に集約されます。
第一に、アーキテクチャは「最先端技術」ではなく、チームの規模と成熟度、デプロイ頻度を基準に選ぶことです。Amazon Prime Videoの事例が示すように、マイクロサービスからの回帰も、時には最善の判断になります。モジュラーモノリスは、多くの中堅企業にとって2026年の最適解になりえます。
第二に、ストラングラーフィグ・パターンによる段階的移行を実装し、データマイグレーションの困難（ダウンタイムゼロ移行、レガシーデータクレンジング）に十分な時間とリソースを確保することです。過渡期の並行稼働コストは、初期見積もりの1.5〜2倍になると想定して計画を立てるのが現実的です。
第三に、AIモダナイゼーションツールの限界を正しく理解し、ヒューマン・イン・ザ・ループのレビュー体制と徹底したビジネスロジック検証テストを組み合わせることです。AIは強力な補助ツールですが、暗黙のビジネスルールの解釈と検証は、人間の責任として残ります。
第四に、CI/CDパイプラインでアーキテクチャの品質を継続的に監視するガバナンス体制と、フィーチャーベロシティおよびインシデントコストによるROI測定の仕組みを構築することです。これにより、経営層への説明責任を果たしながら、新アーキテクチャの価値を長期的に維持できます。
riplaは、中堅企業から大規模エンタープライズまで、現状評価から段階的な移行の実行支援、アーキテクチャ・ガバナンスの確立まで一貫して支援するSIパートナーです。「どこから始めればよいかわからない」「過去のマイクロサービス化の失敗を乗り越えたい」「COBOLシステムのモダナイゼーションでAI活用を検討している」という方は、ぜひriplaにご相談ください。
貴社のシステムの現状と目標に合わせて、最適なリアーキテクチャ戦略をご提案します。
本テーマの全体像をあわせて確認したい方は、次の記事をご覧ください。
▼全体ガイドの記事
・システムリアーキテクチャの完全ガイド
▼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を創業。