MVCのシステム開発の見積相場や費用/コスト/値段について

MVCのシステム開発費用は、MVP規模なら300万〜700万円、中規模なら700万〜1,500万円、大規模な基幹連携まで含めると1,500万〜5,000万円超が目安です。ただし、MVCは価格表のある製品ではなく、画面・業務ロジック・入力制御を分ける設計パターンのため、機能数や連携、データ移行、セキュリティ要件で金額は大きく変わります。

「MVCのシステムを作りたいものの、いくら予算を確保すればよいのか」「見積書の一式という金額が妥当なのか」と悩む方に向けて、2026年時点の公開相場とリサーチノートの業務システムデータをもとに、費用の内訳、価格帯、開発期間、費用が増減する要因、コストを抑える進め方を解説します。受発注、顧客管理、在庫、申請・承認、勤怠などの業務Webシステムを想定しています。

▼全体ガイドの記事
・MVCのシステム開発の完全ガイド

MVCのシステムはどのような構造ですか？

MVCは、Model、View、Controllerの3つに責務を分けてWebアプリケーションを設計する考え方です。特定の製品名や開発会社名ではなく、ASP.NET Core MVC、Spring MVC、Ruby on Rails、Laravelなどのフレームワークで実装されるアプリケーション構造を指します。Microsoft Learnも、MVCをWebアプリとAPIを構築するためのデザインパターンとして説明しています。

Modelは、顧客、商品、受注、在庫、申請などの状態を扱い、データベースへの保存・検索や業務ルールを担当します。たとえば受注金額の計算、在庫を引き当てられる条件、承認済みの申請だけを確定できるルールなどをModel側に整理すると、画面の変更が業務処理へ波及しにくくなります。画面から切り離された業務ロジックは単体テストもしやすく、将来APIやスマートフォン画面を追加するときにも再利用しやすくなります。

Viewは、HTML画面、入力フォーム、一覧、帳票、画面部品など、利用者への表示を担当します。Viewに業務判断を詰め込まず、受け取ったデータを正しく表示する役割に絞ることが重要です。受注一覧を例にすると、Controllerが取得した受注データをViewが表形式で表示し、表示条件や入力エラーを利用者に伝えます。画面デザインを変更しても、Modelの在庫計算や権限判定を変更せずに済む構成が理想です。

Controllerは、URLやボタン操作などの入力を受け、認証・認可、入力検証、Modelの呼び出し、ViewまたはJSONの返却を仲介します。典型的には「利用者が受注一覧を開く」「ルーティングでControllerへ到達する」「ControllerがModelへ検索を依頼する」「Modelがデータベースから受注を取得する」「ControllerがViewへ渡す」「ブラウザに表示する」という流れです。Controllerに複雑な業務判断を集めすぎると、いわゆる肥大化したControllerになり、テストや保守の費用が増えるため、サービス層やドメイン層を含めて責務を設計します。

MVCのシステム開発費用相場はいくらですか？

MVCの開発費用は、作る画面の数だけでなく、業務ルール、利用者の権限、外部連携、データ移行、可用性や監査ログまで含めた総工数で決まります。以下は、リサーチノートにある業務システムの想定と、2026年に公開された複数の市場目安を突き合わせた、予算計画用のレンジです。MVC固有の公的な価格表ではないため、正式な発注額ではなく、要件定義前の予算取りに使う目安として扱います。

対象業務を一つに絞り、基本的な登録・検索・更新、ログイン、簡易的な権限、単一データベースを実装する場合は、初期費用300万〜700万円程度、期間3〜4か月程度が一つの目安です。たとえば営業案件の登録と一覧、在庫の入出庫、社内申請の受付など、業務の中心となる一連の流れを検証する規模です。画面数が少なく、既存のマスタやCSVをそのまま利用でき、移行データのクレンジングも不要なら、下限に近づきやすくなります。

一方、2026年の一般的な業務システム相場では、単一業務のカスタムシステムを100万〜500万円、小規模な自動化ツールを10万〜100万円とする整理もあります（出典: Cataly Design「業務システム開発の費用相場｜種類別の目安【2026】」）。この幅が示すとおり、MVPに認証や画面を足しただけの案件と、既存業務を置き換える本番システムでは、同じ小規模でも必要なテストや移行作業が異なります。

複数部門が利用し、承認フロー、詳細な権限、帳票、検索・集計、CSVや外部API連携を含む場合は、700万〜1,500万円程度、5〜8か月程度を見込みます。受発注と在庫、顧客管理と問い合わせ、申請と会計連携のように複数の業務を一つのデータモデルでつなぐほど、画面制作だけでなく例外処理と結合テストが増えます。既存システムとの連携仕様が未確定なら、要件定義や調査だけで期間が延びることもあります。

別の2026年公開情報では、中規模の業務系システムを300万〜800万円、または部門横断システムを500万〜1,000万円とする目安もあります（出典: イー・ジーシステム株式会社「システム開発の費用相場と見積書の読み方（2026年版）」、SIA株式会社「システム開発の費用・相場【2026年版】」）。この差は、利用者数や画面数、移行、保守の範囲を含むかで生じます。金額だけを比較せず、見積書に含まれる工程と成果物をそろえることが大切です。

基幹システム連携、大量データ、複数拠点、厳格な権限管理、監査ログ、データ移行、災害対策まで含む大規模案件では、1,500万〜5,000万円超を想定します。ERP、会計、倉庫、決済などとリアルタイム連携し、複数の利用者区分やピーク時の性能を保証する場合は、5,000万〜1億円以上、期間1〜2年以上になることもあります。公開相場でも、複数業務を統合する基幹システムは1,000万〜3,000万円以上とされています（出典: Cataly Design、2026年公開情報）。

大規模案件では、MVCを採用すること自体が費用を決めるのではありません。Modelの下にサービス層やドメイン層を置く設計、APIゲートウェイ、非同期処理、監視、冗長化、移行リハーサルなど、将来の障害や変更に備える構成が費用に反映されます。価格を一つに断定せず、対象範囲を段階リリースに分けて、フェーズごとの上限予算を設ける方法が現実的です。

MVCのシステム開発費用の内訳は何ですか？

見積書は、要件定義、設計、実装、テスト、移行、教育、インフラ、保守という工程と費目に分けて確認します。開発費の大半は人件費ですが、MVC業務システムでは画面とControllerを作る作業よりも、業務ルールの整理、権限設計、データ整合性、連携テストに工数がかかることがあります。工程別に価格を読むと、安い見積もりが何を含んでいないのかも見つけやすくなります。

人件費は一般に「役割ごとの人月単価×必要な人月」で算出します。PM、業務担当を支える要件定義担当、アーキテクト、SE、PG、UI担当、テスターなど、誰がどの工程に何人月入るかを確認します。2026年公開の相場情報では、人月単価を60万〜200万円程度とする例があり、別の外注費用目安ではPM90万〜160万円、SE65万〜120万円、PG50万〜100万円と整理されています（出典: SIA株式会社、秋霜堂株式会社の2026年公開情報）。スキル、地域、契約形態、上流工程の有無で変わるため、単価だけで優劣を決めません。

工程配分は、要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%程度を初期検討の基準にできます。ただし、これは固定の正解ではありません。既存データの移行や外部連携が多い案件では設計・テストの比率が上がり、試作中心のMVPでは実装前の要件整理を短くできる場合があります。要件定義を削れば必ず安くなるわけではなく、後工程の手戻りとして支払う可能性がある点に注意が必要です。

人件費以外には、クラウドの初期構築と利用料、データベースや監視の設定、認証基盤、外部APIや帳票ライブラリのライセンス、デザイン素材、脆弱性診断、テスト環境、バックアップ構成などが含まれます。既存のExcelや基幹システムから移行する場合は、データの重複や表記揺れを直すクレンジング、移行プログラム、件数検証、リハーサルも見積もりに入れる必要があります。

運用開始前の利用者教育、マニュアル、問い合わせ窓口、リリース立ち会いも忘れやすい費目です。特に承認業務や在庫業務では、システムが完成しても現場が入力方法を理解しなければExcelへ戻る可能性があります。開発費を抑えるために教育を削ると、定着支援や追加改修の費用が後から発生するため、最初から稼働準備として扱います。

公開後は、障害対応、問い合わせ、OS・ブラウザ・フレームワークの更新、脆弱性対応、バックアップ確認、監視、法改正や業務変更への改修が発生します。計画段階では、初期開発費の年15〜25%程度を運用保守費として置く考え方が使いやすいです。ただし、月額5〜15%と表現される情報もあるため、月額なのか年額なのか、含まれる対応時間や改修上限は何かを必ず確認します。

クラウド料金は利用者数、データ量、アクセスのピーク、ログ保存期間、冗長化の有無で変動します。開発時に最小構成だけで試算し、本番のバックアップや障害時の復旧構成を別扱いにすると、稼働後に予算超過しやすくなります。初期費用と運用費を分け、3年程度の総保有コストで比較すると、見かけの安さに引きずられにくくなります。

MVCの見積もりが高くなる変動要因は何ですか？

同じMVCでも、ログインと一覧だけの社内ツールと、複数拠点が使う基幹システムでは費用が大きく異なります。価格差の理由を、機能、データ・連携、非機能、進め方の4つに分けて整理すると、削ってよい要件と削ってはいけない要件を判断しやすくなります。

登録・検索・更新という基本CRUDだけなら比較的見積もりやすい一方、承認の分岐、差し戻し、代理承認、締め処理、在庫引き当て、複数通貨、帳票出力、通知、決済などが加わるとModelの業務ルールとテストケースが増えます。画面数が少なくても、一つの画面に多くの状態や権限を持たせると複雑になります。見積もり依頼では「画面10枚」とだけ書かず、利用者の操作、入力条件、エラー時の動き、完了条件を業務シナリオで渡します。

会計、ERP、倉庫、決済、メール、認証、外部SaaSとつなぐ場合は、APIの仕様確認、認証方式、エラー時の再送、タイムアウト、データ形式の変換、連携先のテスト環境が必要です。APIがないシステムではCSVやRPAなど別の方式を検討することになり、運用上の手作業も残りやすくなります。連携先が一つ増えるごとに単純に同じ金額が足されるわけではありませんが、接続本数だけでなくデータの重要度と障害時の影響を評価します。

移行費用は、元データの件数、形式、履歴の保存期間、重複や欠損の状態、移行後の照合方法で変わります。顧客マスタだけなら比較的軽くても、受注・請求・在庫の履歴を整合させる場合は、移行プログラムと複数回のリハーサルが必要です。「既存データは利用者側で整える」という前提を見積書に明記し、誰が何を準備するかを分けておくと、後からの追加請求や責任の押し付けを避けられます。

利用者数だけでなく、同時アクセス数、ピーク時の処理件数、許容レスポンスタイム、バックアップの復旧目標、障害時の復旧時間と復旧時点、監査ログの保存期間を数値で決めます。数万人が使うサービスと数十人が使う社内システムでは、サーバー構成、負荷試験、監視、冗長化の費用が異なります。高い可用性が不要な業務に過剰な構成を入れず、必要な業務には十分な構成を確保することが重要です。

個人情報や機密情報を扱う場合は、認証・認可、通信と保存データの暗号化、アクセス制御、委託先管理、漏えい時の対応を要件に反映します。Webアプリの受入基準にはOWASP ASVS 5.0を参照でき、Controllerの認可漏れ、Modelへの過剰なデータバインディング、Viewの出力エスケープ漏れ、CSRF、SQLインジェクション、監査ログの欠落を確認します。セキュリティ診断を後付けにせず、設計とテストの費用として最初から計上します。

短期間でのリリースを求めると、開発者を急に増員したり、並行作業を増やしたりする必要があります。引き継ぎやレビューの負担が増え、結果として総工数が下がらないこともあります。また、要件が固まっていない段階で固定価格にすると、仕様変更のたびに追加見積もりや契約調整が発生します。最初に業務のMustとNice to haveを分け、変更を受け入れる範囲と、別フェーズに回す基準を合意しておきます。

MVCのシステム開発はどのように進めますか？

費用を抑えながら品質を保つには、いきなり実装を始めず、現行業務と将来の運用を先に整理します。MVCの責務分担は設計段階で決めますが、予算と納期を左右する業務範囲や非機能要件は、企画と要件定義の段階で具体化します。MVPを先に作って現場で検証し、利用状況を見ながら段階的に広げる進め方も有効です。

まず現行業務、例外処理、Excelや紙、既存DB、利用者、承認者、データの発生源と利用先を棚卸しします。そのうえで、対象業務をMust、将来追加する機能、標準化できる業務に分けます。要件には画面一覧だけでなく、同時利用者数、ピーク時件数、検索の応答時間、権限、ログ保存期間、バックアップ、RTO・RPO、法令や社内規程を記載します。

現場が画面モックを操作しながら確認すると、言葉だけでは見つからない入力項目や例外処理を発見できます。この段階で「承認の差し戻しは何回までか」「締め後の修正を誰が許可するか」「退職者のデータをどう扱うか」まで決めれば、ControllerとModelの境界も明確になります。要件定義の成果物として、業務フロー、画面一覧、データ項目、権限表、連携一覧、非機能要件、受入条件を残します。

基本設計では、Model・View・Controllerの責務だけでなく、サービス層、ドメイン層、リポジトリ層、データベース、トランザクションの境界を決めます。認証と認可をどこで実施するか、APIとブラウザ画面で業務ルールをどう共有するか、エラーや再送をどう扱うかもこの時点で合意します。Controllerに全ての業務処理を置かないことが、後からの改修費を抑えるポイントです。

同時に、クラウドやオンプレミスなどの実行環境、CI/CD、コードレビュー、静的解析、ログと監視、バックアップ、脆弱性対応の方法を設計します。技術選択では、ASP.NET Core MVC、Spring MVC、Rails、Laravelなどの既存スキルや保守担当者の確保を考慮します。フレームワークの知名度だけで選ぶと、採用後の改修や脆弱性対応で外部依存が強くなるため、5年程度の運用体制まで確認します。

実装では、Modelの業務ルール、Viewの入力と表示、Controllerの認証・入力検証・呼び出しを分け、コードレビューと自動テストを組み込みます。単体テストだけでなく、画面からデータベースまでの結合テスト、外部API連携、権限別の総合テスト、性能テスト、脆弱性テストを実施します。受入テストは現場の業務シナリオで行い、正常系だけでなく、重複登録、締め後の修正、通信失敗、権限不足などを確認します。

リリース前にはデータ移行のリハーサル、バックアップからの復旧確認、切り戻し手順、問い合わせ窓口、利用者教育を準備します。公開後の初期サポートと保守の分界を決め、ソースコード、設計書、IaC、テスト仕様書、操作マニュアルを納品物として契約に含めます。開発会社を変更する可能性がある場合は、著作権・翻案権、第三者ライセンス、アカウントの名義、保守移管に必要な情報も確認します。

MVCのシステム開発費用を最適化するポイントは何ですか？

コスト最適化は、単価を下げることではなく、価値の低い機能や重複作業を減らし、重要な品質に予算を配分することです。安価な見積もりを選んで要件定義、テスト、セキュリティ、移行を削ると、稼働後の障害や追加開発で総額が増える場合があります。自社の競争力に直結する業務だけをスクラッチMVCで作り、標準化できる領域はパッケージ、SaaS、ローコードに寄せる考え方が有効です。

会計、人事、勤怠、CRMなど一般的な業務は、既存のSaaSやパッケージで要件を満たせるかを先に確認します。パッケージに合わせて業務を標準化できれば、初期開発費と保守費を抑えやすくなります。反対に、標準機能に無理なカスタマイズを重ねると、アップデートのたびに検証費用が発生し、スクラッチMVCより高くなることもあります。

独自性が高い顧客対応、特殊な承認、既存DBとの密接な連携などはMVCで専用開発し、標準業務は外部サービスへ任せる構成も選択肢です。MVCは内部構造の考え方であり、パッケージやSaaS、マイクロサービスと対立するものではありません。どの部分を自社の資産として持つかを決めてから、技術方式を選びます。

最初から全社機能を完成させようとせず、最も効果が大きい一つの業務をMVPとして稼働させます。たとえば受注登録と承認だけを先に導入し、帳票の高度化や他拠点展開を第2フェーズに回します。実際の利用者から入力時間やエラーの情報を得てから追加機能を決めれば、使われない機能に費用をかけるリスクを下げられます。

MVPでも、後から拡張できるデータモデル、認証・認可、監査ログ、バックアップは安易に削らないことが重要です。将来の拡張を見越して、Modelの境界とAPIの契約を初期設計で決めます。全てを完璧に作るのではなく、後から変更しやすい土台に必要な費用を配分する考え方です。

ローコードは定型的な画面やワークフローを短期間で検証したい場合に向きます。MicrosoftはPower Appsの説明で、ローコードによって工数削減や開発者の負担軽減が期待できるとしています（出典: Microsoft「ローコード開発とは」）。ただし、複雑な業務ルール、高い性能要件、細かなデータ移行、厳格な監査が必要な領域まで無理に載せると、ライセンスや制約回避の追加開発が膨らむ可能性があります。

クラウドは、マネージドデータベース、監視、バックアップ、CI/CDを活用しやすく、初期のサーバー構築を軽くできる場合があります。ただし、毎月の利用料、データ転送、ログ保管、バックアップ、冗長化の料金は継続します。開発会社には、想定ユーザー数とデータ量を前提にした月額・年額試算を求め、3年分の総額とサービス終了時のデータ移行方法を確認します。

MVCの見積もりを取る際に確認すべきことは何ですか？

相見積もりは、同じ要件と同じ前提を渡して初めて比較できます。機能一覧だけでなく、業務フロー、画面イメージ、データ件数、外部連携、利用者数、性能、セキュリティ、希望納期、納品物、保守範囲をRFPにまとめます。見積もりの金額だけでなく、前提条件と除外項目を読み合わせることが、後からの追加費用を抑える近道です。

RFPには、解決したい経営課題、対象部門、業務の開始条件と完了条件、例外処理、画面と帳票、マスタ、権限、外部連携、移行対象、受入テストの観点を記載します。非機能では、平常時とピーク時の件数、応答時間、稼働時間、バックアップ、復旧目標、ログ保存、脆弱性対応、個人情報の扱いを具体化します。「高性能」「安全」といった形容詞だけでは、会社ごとに解釈が違い、価格を比較できません。

まだ決められない要件は、未確定として一覧化し、確定予定日と見積もりへの扱いを明示します。概算見積もりと正式見積もりを分け、要件定義に必要な調査費用を別建てにする方法もあります。最初から精度の高い固定価格を求めるより、調査・要件定義で不確実性を減らしてから本開発の契約へ進む方が、予算管理は安定しやすくなります。

「開発一式」とだけ書かれた見積書は、会社間で比較しにくい形式です。要件定義、基本設計、詳細設計、実装、単体・結合・総合・性能テスト、移行、教育、リリース、保守を工程別に分け、各工程の人月、単価、期間、成果物、レビュー回数を確認します。2026年の見積もり解説でも、工程別の内訳がない一式見積もりは比較しにくいとされています（出典: イー・ジーシステム株式会社「システム開発の費用相場と見積書の読み方（2026年版）」）。

安い見積もりでは、データ移行、テスト、マニュアル、脆弱性診断、クラウド初期設定、公開後の不具合対応が除外されていないかを確認します。反対に、高い見積もりでも、過剰な会議や重複した管理費が含まれている場合があります。各社に同じ質問を行い、差額が生じる理由を説明できる会社を選びます。価格の透明性は、開発中の仕様変更や将来の保守移管にも影響する重要な評価軸です。

ソースコードだけでなく、設計書、データベース定義、API仕様、インフラ構成、IaC、テスト結果、脆弱性対応の記録、操作マニュアル、バックアップと復旧手順を納品物に含めます。ソースコードや設計書を誰が利用・改変できるか、第三者ライブラリのライセンスをどう扱うか、契約終了後に別会社へ保守を移管できるかも確認します。納品物が曖昧だと、保守会社を変更できず、長期的なコストが上がる可能性があります。

保守契約では、障害の受付時間、復旧目標、対応の優先度、月に含まれる作業時間、軽微な改修の定義、法改正対応、フレームワークのバージョンアップ、クラウド費用の負担者を決めます。開発費だけで判断せず、稼働後の年間費用と、追加機能を頼む場合の単価・見積もり方式まで比較することが大切です。

よくある質問（FAQ）

MVCの費用を検討するときは、「MVCなら安いのか」「ローコードとどちらがよいのか」「保守費用はいくらか」といった疑問が生じます。ここでは、予算と発注判断に直結しやすい質問に答えます。

MVCを採用しただけで、開発費用が自動的に安くなるわけではありません。責務を分けることでテストや保守の見通しを立てやすくなり、将来の画面追加やAPI連携の手戻りを抑えられる可能性はありますが、初期の設計やテストには費用が必要です。価格はMVCという名称ではなく、対象業務、画面、連携、移行、非機能要件で見積もります。

独自の業務ルールや既存システムとの複雑な連携が競争力になるなら、MVCのスクラッチ開発が向きます。会計や勤怠など標準業務が中心なら、SaaSやパッケージを先に検討し、独自部分だけをMVCで補う方が初期費用と保守費用を抑えやすいです。ローコードは定型画面やワークフローを早く検証するのに向きますが、性能、監査、ライセンス、将来の移行性を確認して適用範囲を決めます。

保守費用は、開発費の年15〜25%程度を初期計画の目安にできますが、固定額ではありません。問い合わせ件数、障害対応の時間帯、フレームワークやOSの更新、法改正、追加改修、監視・バックアップ、クラウド利用料をどこまで含むかで変わります。月額契約なら含まれる時間と超過単価、年額契約なら対応範囲と追加費用を確認し、初期費用と合わせた3年程度の総額で判断します。

要件の前提をそろえたうえで、少なくとも2〜3社に概算または正式見積もりを依頼すると比較しやすくなります。会社数を増やしすぎるより、業務知識、MVCまたは近いWebアーキテクチャの実績、既存DB・API連携、セキュリティ、保守・移行の体制を確認することが重要です。各社の価格差が出た項目を説明してもらい、総額だけでなく工程、成果物、前提、除外項目を同じ表で比較します。

まとめ

MVCのシステム開発費用は、MVPで300万〜700万円、中規模で700万〜1,500万円、大規模で1,500万〜5,000万円超、全社基幹級では5,000万〜1億円以上になることがあります。これはMVCの採用料ではなく、画面、業務ルール、権限、外部連携、移行、性能、セキュリティ、テスト、運用までを含めた業務システム全体の目安です。公開されている2026年の相場でも、単一業務は100万〜500万円、基幹システムは1,000万〜3,000万円以上と幅があるため、金額の断定ではなく前提と変動要因をセットで考えます。

人件費、クラウドやライセンス、データ移行、教育、保守を工程別に分け、初期費用と稼働後の費用を合わせて比較します。安い一式見積もりを選ぶのではなく、要件定義やテスト、セキュリティ、納品物が含まれているかを確認します。自社独自の業務はMVCで作り、標準化できる領域はSaaSやパッケージ、ローコードを活用し、MVPから段階的に広げると、使われない機能への投資を抑えやすくなります。

発注前には、現行業務と例外処理、Must機能、データ件数、利用者数、連携先、性能、認証・認可、ログ、バックアップ、復旧目標、受入条件を整理します。その資料を同じ条件で2〜3社へ渡し、要件定義から保守までの工程、役割、成果物、権利、移管条件、追加費用のルールを比較してください。MVCを採用すること自体を目的にせず、業務を標準化する範囲と独自開発する範囲を決めることが、納得できる費用と長期的なシステム価値につながります。

▼全体ガイドの記事
・MVCのシステム開発の完全ガイド

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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