Visual Studioのシステム開発の完全ガイド

Visual Studioを使ったシステム開発は、開発環境の役割、構成の方式、開発の工程を順に整理すると、自社に合う全体像をつかみやすくなります。

システムの種類、開発の進め方、費用と方式の選び方は互いに関係します。各テーマの詳細は、下の関連記事もご覧ください。

▼関連記事一覧
・Visual Studioのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Visual Studioのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Visual Studioのシステム開発の見積相場や費用/コスト/値段について
・Visual Studioのシステム開発の発注/外注/依頼/委託方法について

Visual Studioで作るシステムの概要

Visual Studioは、業務の入力・承認・検索・集計を担うアプリを設計、実装、テストするための統合開発環境(IDE)です。.NETやデータベース、クラウドを組み合わせてソフトウェアを作る点で、既製の業務システム製品とは異なります。

IDEと業務システムの違い

Visual Studioを入れても、販売管理や在庫管理が自動で出来上がるわけではありません。そのため、開発者がC#でプログラムを書き、利用者の業務に合うシステムを作る必要があります。

開発では、ASP.NET Core、Entity Framework Core、SQL ServerやAzure SQL Databaseなどを組み合わせて使います。

IDEの料金だけでは、業務システムにかかる費用の全体は分かりません。工程ごとに分けて確かめると、それぞれの費用の中身が見えてきます。

  • 要件定義・設計・実装:費用の内訳をそれぞれ確認
  • テスト・データ移行・クラウド:別の項目として見積もる
  • 保守:稼働後の費用として別に見る

実現できる主な機能

業務システムは、日々の処理を記録する機能と、状況を確認する機能を組み合わせて作ります。機能は、利用者管理から状況確認と連携まで、4つの領域に分けて整理できます。

  • 利用者管理:ログインと部門・役職ごとの権限
  • 業務データ管理:顧客・商品・拠点のマスタと受注・発注・入出庫
  • 申請と帳票:申請・承認、CSV・Excel・PDFの帳票
  • 状況確認と連携:ダッシュボード、操作履歴、外部サービス連携

会計、ERP、Microsoft 365、外部SaaSとは、REST APIで連携できます。

ExcelやAccessから置き換える場合は、画面を作り直すだけでなく、データの重複や承認ルールも見直します。

例外処理や月次締めの手順まで再設計すると、画面を作り直すだけにとどまらず、業務の実態に合った構成を選べます。

Visual Studioで作るシステムの種類と構成

Webシステムを画面、アプリケーションコア、インフラストラクチャ、データアクセスに分けて示す図
役割を層ごとに分けると、テストや機能追加を進めやすくなります。

Visual Studioを使う場合も、すべてを同じ方式で作るわけではありません。方式を選ぶ際は、利用端末、業務の特殊性、既存データを見ます。

利用者数、セキュリティ、将来の拡張性も、方式を判断する基準になります。

Web、Windows、API、クラウドは組み合わせて使うこともあります。一方で、複雑な分散構成から始めず、将来の変更点を切り分けやすい一体型のアプリを選ぶ方法もあります。

ASP.NET CoreによるWebシステム

社内ポータルや販売・在庫・顧客管理、申請、予約のように、複数の拠点や端末で使う業務には、Web方式が有力です。ブラウザから利用できるので、クライアントごとの配布を減らせます。

業務ルールはサーバー側に集約できます。そのうえで、画面、アプリケーションコア、インフラストラクチャ、データアクセスを論理的に分けておくと、テストや機能追加を進めやすくなります。

Microsoft Learnの指針でも、単一デプロイのモノリスを論理的な層に分ける考え方が示されています(出典: Microsoft Learn、2025年更新)。

WPF・WinForms・WinUIによるWindowsシステム

工場や店舗の専用端末、バーコードリーダー、USB機器、オフライン環境など、Windowsに密着した操作には、WPF、WinForms、WinUIが候補になります。

既存の.NET Frameworkアプリを維持しながら、段階的に改修することもできます。その場合は、サポート期限や32ビット依存、古い認証方式を先に調べます。

ActiveXや専用ドライバーの有無も確認します。Web化だけで解決するとは限らないため、機器連携と現場の操作速度を含めて選定します。

API・Azure・データベースを組み合わせる構成

外部サービスやスマートフォン、別の業務アプリから使う場合は、ASP.NET Core Web APIを中心に構成します。

ブラウザやWindowsクライアントからAPIを呼び出し、業務ロジックと認可はAPI側に集約します。データはSQL ServerまたはAzure SQL Databaseに保存します。

  • Azure機能:業務に必要なサービスを選んで、構成に加えます。
  • 役割分担:認証、秘密情報管理、ログ監視、バッチ、ファイル保管をサービスごとに分担します。

Azure App Service、Functions、Storageは、必要に応じて加えます。

Key Vault、Application Insights、Entra IDも、同じ分担の中で使います。

Azureの料金は、サービス、リージョン、稼働時間、データ転送、冗長化によって変わります。そのため、構成を決めないままでは、月額を断定できません。

Visual Studioのシステム開発の進め方

開発を要件定義とPoC、設計・開発・テスト、データ移行と段階リリースの段階で示す図
先に前提をそろえ、検証と段階的な切替へ進む構成です。

開発の成否は、実装の速さよりも、作る範囲と業務ルールを早くそろえられるかで決まります。

要望は機能一覧にするだけでなく、目的、利用者、データ、例外処理、完了条件に分けてから、段階的に開発します。

▶ 詳細はこちら:Visual Studioのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

要件定義とPoCによる業務の前提合わせ

業務フローでは、誰がいつどのデータを使い、何を判断するかを決めておきます。

受注では、見積、受注確定、在庫引当の各状態と担当者を決めます。出荷、請求、返品についても、状態と担当者を決めておきます。

機能はMust、Should、将来対応に分けておくと、初回リリースに機能を詰め込みすぎるのを防げます。PoCでは、画面モックやサンプルデータを使います。

現場の担当者に登録・検索・承認・帳票を操作してもらい、現場で使えるかを確かめます。PoCの合格条件は、画面が動くことに加えて、次の観点を満たすことです。

  • 業務完了:代表業務を最初から最後まで完了できること
  • 権限とデータ:想定外の操作ができず、既存データが正しく表示されること
  • 処理時間:業務上許容できる速度で処理できること

PoCで問題を見つけられれば、本開発に入った後の手戻りを減らせます。

設計・開発・テストの管理

設計、実装、テストでは、確認する対象と環境をそれぞれ分けて管理します。

  • 設計:画面遷移・権限、データ項目・テーブル・API、エラー表示・ログ・バックアップ・非機能要件を決めます。
  • 実装:業務ロジックをUIから切り離し、単体・結合テストを自動化しやすい形にします。
  • 環境管理:ローカルと本番の差分や設定値の管理、本番で安全に動くことの確認
  • テスト:正常系に加え、重複登録・期限切れ・承認者不在、在庫不足・通信切断・権限外アクセス・同時更新、移行後の件数差異を確認します。

受入テストでは、現場のシナリオを使って合否と未対応事項を記録します。

Visual Studio 2026では、AIやMCPの開発支援機能も更新されています。一方で、生成されたコードや更新案は人がレビューし、テスト結果も確認します(出典: Microsoft Learn「Visual Studio 2026 リリースノート」、2026年)。

データ移行と段階リリースの設計

移行元データの整理から切替後の確認まで、段階を分けて進めます。

  • 移行元の確認:項目名とコード体系の整理
  • 切替準備:少なくとも1回の移行リハーサル
  • 段階リリース:一部門か一拠点から始め、対象を広げます
  • 稼働後の確認:課題の整理と、要望・不具合の優先順位付け

リハーサルでは、切替時間、差分データ、旧システムの参照期間、障害時の戻し方を確かめます。

特に、一斉切替は問題が起きたときの影響が大きくなります。そのため、問い合わせ、操作ログ、処理時間、入力ミスを見ながら、対象を少しずつ広げます。

リリース後の1〜2か月は、開発担当者と業務責任者が定例で課題を確認します。

移行元の対象は、Excel、Access、古い.NET Framework、オンプレミスSQL Serverです。

重複・欠損・表記ゆれを直したうえで、移行件数、エラー件数、未移行理由を確認します。

ポイント

迷ったときは、作る範囲と業務ルールを先にそろえ、PoCで現場の使い勝手を確かめてから本開発に進むのが目安です。

Visual Studioのシステム開発費用相場

費用は、Visual Studioのライセンス、初期開発、クラウドやサーバー、保守運用に分けて考えます。

ライセンス料の安さだけで判断したり、運用費を見落としたりすると、予算と総額に差が出ます。以下は2026年時点の参考額です。

正確な金額は、要件、利用者数、連携数、移行量、可用性によって変わります。

▶ 詳細はこちら:Visual Studioのシステム開発の見積相場や費用/コスト/値段について

Visual Studioのライセンス費用

Microsoftの公式価格ページに掲載された契約区分ごとの料金は、次のとおりです(出典: Microsoft「Visual Studio 価格」、2026年8月確認)。

  • Visual Studio Professional Standard:年払いで1ユーザーあたり月99.99米ドル(約1万5,000円)
  • Enterprise Standard:年払いで月499.92米ドル(約7万5,000円)
  • 月次契約:Professionalは月45米ドル、Enterpriseは月250米ドル
  • IDEスタンドアロン:499米ドル

円換算額は、1米ドル150円として計算した予算検討用の目安です。

実際の請求額は、為替、税、販売チャネル、契約条件によって変わります。

Communityは、利用者や組織の条件によって無償で使えます。ただし、企業の商用開発では、ライセンス条件を確認しておく必要があります。

複数人で開発する場合は、ソース管理、CI/CD、テスト、開発環境でのAzure利用、開発用データの保護も見積もりに含めます。

IDEの費用は、開発者が使うツールの代金です。そのため、業務システムの開発費や本番のAzure費用とは別に計上します。

初期開発費と期間の目安

初期費用と期間は、開発規模と含める機能の範囲で変わります。規模の小さいものから大きいものへ、4つの区分で目安を示します。

  • 小規模PoC・部門ツール:画面数が少なく、既存データ・外部連携が少ない場合、100万〜300万円、1〜3か月
  • 部門業務システム:ログイン、権限、マスタ・トランザクション管理、帳票、簡易ワークフローを含み、300万〜1,000万円、3〜6か月
  • 複数部門・拠点:API連携、データ移行、監査ログを含み、1,000万〜3,000万円、6〜12か月
  • 全社基幹:高可用性、複数連携、移行リハーサル、24時間運用を含む場合、3,000万円〜1億円以上、12〜24か月以上

これは、Visual Studio固有の公的な一律価格ではありません。業務システムの相場をもとに、認証・DB・権限・帳票・API・移行を含むケースに寄せて推定した数字です。

人件費は全体の60〜80%程度が目安です。工程別では、要件定義が10〜12%、設計・環境が22〜24%、実装が48〜50%、テストが15〜17%程度で、見積比較の起点にできます。

Azure運用費と保守費

Azure運用費の概算は、環境や利用規模ごとに異なります。次の金額は、いずれも推定値です。

  • 開発・検証環境:月1万〜5万円
  • 部門向け本番:月5万〜30万円
  • 全社利用:高可用性、複数環境、監視を含み、月30万〜150万円以上
  • 保守費:初期開発費の年15〜25%、または月15万〜80万円程度

保守費は契約の対象範囲によって変わるため、作業内容を具体的に決めておきます。

保守では、OS・.NET更新、脆弱性対応、Azure設定変更を含めるかどうかを決めます。さらに、バックアップ復旧、問い合わせ、障害・法改正対応、追加開発も、どこまで含むかを決めます。

費用は、App Service、Azure SQL Database、Storage、Application Insightsの構成によって上下します。

バックアップやネットワーク、ログ量も費用に影響します。また、稼働時間と冗長化も影響します。

Azure公式の料金ページと料金計算ツールを使い、開発・検証・本番を分けて試算します。

障害時の連絡時間や復旧目標を定めていない安価な契約では、業務停止のリスクを下げられません。

ポイント

費用に迷ったときは、ライセンス、初期開発、Azure運用、保守を分けて見積もり、要件や利用者数などの前提をそろえて比べるのが目安です。

パッケージ・ローコード・スクラッチの選び方

Visual Studioで開発する前に、既製品やSaaS、ローコードで足りるかを確かめます。

標準業務に合わせられるなら、短期導入やアップデートの面で既製の方式が有利です。

独自の承認や複雑な料金計算が競争力に直結する場合は、カスタム開発が候補になります。特殊な機器連携、細かな権限、既存データとの密接な連携も、判断の材料になります。

標準機能で足りる場合のSaaS・パッケージ

業務フローを標準機能に合わせられ、制度変更や複数社連携を自社だけで管理したくない場合は、SaaSやパッケージを優先します。

初期費用を抑えやすい一方で、利用料やデータの保管場所を確認します。加えて、API制限、帳票の自由度、解約時のデータ返却も見ておきます。

カスタマイズの保守性もあわせて見ておきます。標準外の機能を追加し続けると利点が薄れるため、業務変更と追加開発の範囲をあらかじめ合意します。

小さく始める場合のローコード

申請、台帳、簡易な案件管理、部門内共有などは、データ項目と承認が比較的単純です。そのため、ローコードやデータサービスで短期間に試せます。

現場で改善しやすい反面、複雑な権限、大量データ、細かな帳票、双方向連携、長期監査の場面では、設計の限界が出ることがあります。

将来ASP.NET Coreへ移る可能性がある場合は、データ定義、ID体系、API、権限を初期から整えておきます。

独自業務の場合のASP.NET Core中心の開発

カスタム開発では、要件定義とテストの責任に加えて、稼働後の保守体制も見込んでおく必要があります。

  • 検討条件:固有の業務ルール、複数の既存システム、厳格な権限・監査、特殊な機器連携
  • 構成:ASP.NET Core、SQL ServerまたはAzure SQL、API、認証基盤の組み合わせ
  • 進め方:効果の大きい範囲をMVP(Minimum Viable Product)として切り出し、利用状況を見て広げることで、初期投資とリスクを抑える

柔軟性は高い一方で、要件定義とテストの責任は重く、稼働後の保守体制も必要になります。

ポイント

まず既製品やSaaS、ローコードで足りるかを確かめ、足りない部分だけをカスタム開発で検討するのが目安です。

移行・セキュリティ・法対応で失敗を防ぐ方法

業務システムを中央に置き、認証、権限、監査ログ、保存期間で囲む図
利用者と業務に合わせた制御を設計段階で組み込みます。

業務システムでは、機能の多さに加えて、情報漏えいの防止、操作権限、障害からの復旧も欠かせません。

セキュリティは、終盤に追加するのではなく、最初から組み込みます。要件定義では、認証と認可、ログの扱いを決めます。

保存期間、バックアップ、復旧目標も、この段階であわせて決めておきます。

認証・権限・監査ログの先行設計

認証、権限、監査ログは、利用者と業務に応じて先に設計しておきます。

  • 認証:社内アカウントやEntra ID、多要素認証、条件付きアクセス、退職・異動時の停止
  • 権限:画面を隠すだけでなく、部門、役職、拠点、データ所有範囲、承認段階で分け、API・DB側でも検証
  • 監査ログ:操作者、日時、画面・API、変更内容と前後の値、結果、失敗理由を記録

個人情報を扱う場合は、指針に照らして、安全管理措置、アクセス制御、委託先管理、漏えい時の対応を確認します(出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年確認)。

ログに個人情報を過剰に記録することも、リスクになります。そのため、記録の目的と保存期間を定めておきます。

データ移行と電子取引データでは、確認する要件が異なります。

  • データ移行:移行元の洗い出し、データ品質、移行後の突合の確認
  • 電子取引データ保存:電子帳簿保存法に沿った保存要件の確認

移行前には、データの所有者、項目の意味、コード変換、重複・欠損、過去データの保存期間を確かめます。

移行後は、件数と金額を突き合わせ、サンプルで履歴や関連付けを確かめます。旧システムは、一定期間、参照専用として残しておきます。

電子取引データでは、請求書、注文書、領収書の保存要件を確認します(出典: 国税庁「電子帳簿保存法の概要」、2026年確認)。

検索性、改ざん防止、保存期間、訂正削除履歴、権限は、機能要件として扱います。加えて、規程や運用手順、担当者教育も整え、機能の追加だけで法令対応を終えないようにします。

AI支援を使う場合のレビュー

AIは、定型コード、テスト案、既存コードの説明に役立ちます。一方で、脆弱性、誤った業務ルール、ライセンス問題、個人情報の混入が起きる可能性もあります。

  • 利用ルール:入力可能な情報、利用ツール、レビュー担当、テスト基準、ログ保存を決めておく
  • 重点レビュー:認証、権限、決済、給与、個人情報、帳票計算の実装は、人が検証する
  • 検証と記録:静的解析、依存パッケージの脆弱性確認、単体・結合・権限・ペネトレーションテストを行い、合格判定者を残す

開発の速さと安全な運用は、別の評価軸として見ます。

ポイント

認証、権限、監査ログ、移行、電子取引データの保存、AI支援の利用ルールは、要件定義や開発の早い段階で決めておきます。終盤にまとめて追加する形は避けます。

Visual Studioのシステム開発会社・ベンダーの選び方

開発会社は、Visual Studioを使えるかどうかより、業務を理解し、C#・.NET・Azure・データ移行・セキュリティ・運用を一つの計画にまとめられるかで選びます。

技術名や知名度だけで決めないよう、同じ粒度のRFPを複数社に渡して、提案と見積の前提を比べます。

技術力と業務理解の同時確認

確認したい技術は、C#、.NET、ASP.NET Core、Entity Framework Coreです。加えて、SQL ServerまたはAzure SQL、認証・認可、APIも対象になります。

CI/CD、監視、バックアップも対象になります。そのうえで、技術名だけでなく、業務フローから正とするデータや例外処理を説明できるかを見ます。

  • 担当体制:アーキテクト、PM、開発者、テスト責任者、保守担当者の特定
  • 引き継ぎと品質:別会社・別拠点が実装する場合の引き継ぎ方法と品質管理の確認
  • 類似実績:同規模のデータ移行、既存.NET Frameworkのモダナイズ、監査ログや外部連携の経験を、成果物で確認

工程別の見積と前提条件の比較

「システム開発一式」という見積では、金額を比べにくくなります。そのため、見積では工程と前提条件を分けて確認します。

  • 工程と条件:要件定義、設計、実装、各テスト、移行、インフラ、リリース、教育、保守の工数・単価・担当・期間・成果物
  • 費用を左右する範囲:画面数、権限パターン、帳票数、外部連携数、移行件数、同時利用者数、環境数
  • 追加費用の条件:要件変更、データ不備、外部仕様変更、納期短縮、休日対応、セキュリティ検査、Azure超過
  • 受け取る成果物:ソースコード、設計書、テスト仕様・結果、構成図、運用・バックアップ手順、アカウント一覧、データ辞書

契約・権利・稼働後の体制

契約、社内での引き継ぎ、稼働後の支援をあわせて決めます。

  • 契約と権利:コード所有権、利用許諾、第三者ライセンス、再委託、秘密情報、脆弱性報告、契約終了時の引き継ぎの確認
  • 社内での変更:環境設定やデプロイ手順がないと、自社では変更できないことがあります。そのため、自社の担当者が理解し実施する作業範囲を定めます。
  • 保守と総額:保守範囲、総保有コスト、担当体制の比較

保守では、受付時間、一次回答、復旧目標、障害の重大度、定期点検を取り決めます。

脆弱性対応、.NET・Azureの更新、バックアップ復元テスト、改善提案も、対象に含めるかを決めます。

初期費用に加えて、3〜5年の総保有コストと担当者の継続性を比べます。さらに、移行や契約終了のしやすさも確認します。

▶ 詳細はこちら:Visual Studioのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら:Visual Studioのシステム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、Visual Studioを使えるかより、業務を理解して計画にまとめられるかで比べます。見積は工程別に前提条件をそろえ、保守や契約の範囲まで確認してから決めます。

Visual Studioのシステム開発でよくある質問

Visual Studioのシステム開発を検討する際には、ライセンス、方式、既存資産、期間についての疑問が多く挙がります。

下の質問は、相談時の説明や見積比較にも役立ちます。

Visual Studioのライセンスだけで業務システムを作れますか?

作れません。Visual Studioは開発環境のため、業務フロー、画面、業務ロジックは、別途設計と実装が必要です。データベースと認証も、別に整える必要があります。テストと運用基盤も、別に用意しておきます。

予算は、ライセンス費、開発費、本番環境の利用料、保守費に分けて立てます。

ExcelやAccessからVisual Studioへ移行できますか?

移行はできます。ただし、ファイルやテーブルをそのまま移すのでは不十分です。重複、欠損、コード体系、担当者ごとの運用を洗い出します。

承認や締め処理を踏まえて、新しいデータモデルと業務フローを決めます。また、既存資産の一部を残し、APIや段階的な移行でつなぐ方法もあります。

Azureとオンプレミスはどちらがよいですか?

利用者数の変動や拠点数、社内ネットワーク、機器連携、データ保管方針を見て決めます。そのほか、運用担当者、可用性、予算も判断の材料になります。

クラウドは、初期のハードウェア投資を抑えやすく、利用量に応じて拡張したり、マネージドサービスを使ったりしやすい一方で、毎月の費用と設定の管理が必要です。

オンプレミスは、既存設備や閉域環境に適する場合があります。ただし、更新、バックアップ、障害対応を自社で担う範囲は広くなります。

Visual Studioのシステム開発には何か月かかりますか?

小規模PoCは1〜3か月、部門業務システムは3〜6か月が目安です。複数部門の連携やデータ移行を含む場合は、6〜12か月程度になります。

全社基幹は12〜24か月以上が目安です。期間を左右するのは、合意形成、データ整備、外部調整、受入テスト、移行リハーサルです。

小さく検証してから段階的に広げると、全体の不確実性を下げられます。

まとめ

Visual Studioは、C#・.NETを中心とする開発基盤で、それ自体は業務システムの製品ではありません。

Web、Windows、API、Azure、SQL Serverなどを、業務や運用体制に合わせて組み合わせます。

費用と方式を分けた判断

予算は、IDEライセンス、初期開発、Azureやサーバー運用、保守に分けて立てます。開発費は、工程別に比べます。

標準業務ならSaaSやパッケージ、簡易な部門ツールならローコードが候補です。独自業務や複雑な連携には、ASP.NET Coreのカスタム開発が選択肢になります。

最初に行う業務フローとRFPの作成

業務の整理、候補企業の比較、PoCの順に進めると、本開発の判断材料がそろいます。

  1. 現場の業務フローと利用者・権限を1枚にまとめ、データ量と外部連携も書き添えます。
  2. 複数社へ同じRFPを渡し、提案、工程別見積、担当体制を比べます。
  3. 小さなPoCで業務への合い具合と安全性を確かめ、費用と納期の予測精度を高めてから本開発へ進みます。

RFPには、非機能要件、移行範囲、保守希望も同じ1枚に含めます。比較では、納品物、契約、稼働後の支援も見ます。

▼関連記事一覧
・Visual Studioのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Visual Studioのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Visual Studioのシステム開発の見積相場や費用/コスト/値段について
・Visual Studioのシステム開発の発注/外注/依頼/委託方法について

 

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。