Dynamics 365のシステム開発は、業務課題とKPIを決めることから始まります。対象アプリと標準化の範囲を定めたうえで、設計、テスト、稼働、定着へと進めると、業務改善につながります。
また、段階ごとに終了条件を合意しておくことが、進め方の要になります。
▼全体ガイドの記事
・Dynamics 365のシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Dynamics 365のシステムの全体像
Dynamics 365は、営業、顧客サービス、財務などの業務を支えるアプリ群で、1本の業務ソフトとは異なります。販売、在庫、製造、プロジェクトなどの業務も対象になります。Microsoft 365、Teams、Outlook、Power BI、Power Platform、Azureとも連携し、業務データを共通の基盤へ集めます。
導入がうまくいくかどうかは、どの業務をどのアプリで管理し、どこまで標準化するかで決まります。
業務領域ごとのアプリの組み合わせ
業務領域ごとに候補アプリを洗い出すと、必要な構成が見えてきます。
- 営業・顧客対応：営業活動の可視化や案件管理はSales、問い合わせとナレッジ管理はCustomer Serviceが候補です。
- 訪問作業：技術者の訪問や作業指示にはField Serviceが候補です。
- 財務・供給：財務会計・予算・債権債務はFinance、購買・在庫・倉庫・生産はSupply Chain Managementが候補になります。
- 中堅・中小企業：財務、販売、購買、在庫、プロジェクトをまとめる場合はBusiness Centralも比較します。
営業だけを対象にするか、顧客サービスや複数法人の会計、製造まで含めるかで、データモデルや移行量が変わります。その結果、権限、テスト量、期間も変わります。
初回リリースの対象と将来の拡張候補を分けておくと、予算と現場の負担を管理しやすくなります。
標準アプリ、Dataverse、Power Platform、連携の一体的な構成
構成図には、標準アプリと、DataverseまたはFinance・運用系のデータモデルを載せます。さらに、拡張、連携、認証の要素も整理します。
- 標準アプリ：業務領域に合うDynamics 365アプリ。
- データモデル：DataverseまたはFinance・運用系のモデル。
- 拡張・連携：Power Apps、Power Automate、Azure、既存基幹とのAPI。
- 認証・権限：Microsoft Entra IDによる認証と権限。
SalesやCustomer Serviceでは、取引先、担当者、案件などのテーブルと、セキュリティロールを設計します。
FinanceやSupply Chain Managementでは、法人と勘定科目、品目と倉庫・在庫の関係を中心に整理します。税、原価、締め処理との関係も見ておきます。
拡張の範囲は、標準機能と設定で足りるかを先に確かめ、足りない部分をPower Platform、外部システム、個別開発に分けて整理します。
デンソー工機部は、Dynamics 365を基盤に、コミュニケーション情報と設備づくりの情報を蓄積しています。約20％の作業工数削減と、年間約8万時間の創出が期待されています（出典: Microsoft Customer Stories「デンソー 工機部、Dynamics 365を活用」、2026年）。
AIを導入する前に、データを蓄積して業務で使える状態にする順序が参考になります。
Dynamics 365のシステム開発の進め方
Dynamics 365の開発は全部で6フェーズあり、要件整理から始めて定着まで進みます。段階ごとに終わりの条件を合意し、標準機能に業務を合わせる範囲と拡張範囲を早めに決めます。
各段階で、発注者が成果物と判断基準を確認します。
フェーズ1：要件整理による業務課題とKPIの設定
導入する製品から考えず、まず解決したい業務課題を言葉にします。そのうえで、効果を検証できるよう、現状値、目標値、測定方法、責任部署も決めておきます。
業務ごとに、効果を測るKPIを選びます。
- 営業：案件化率、受注率、失注理由、入力から予実確認までの時間。
- 顧客対応：一次解決率、平均処理時間、未対応ケース数。
- ERP：月次締め日数、在庫精度、原価差異。
業務ごとに、担当者、入力データ、承認者を一覧にします。加えて、例外処理と出力帳票、利用頻度、繁忙期まで洗い出します。
データ源も一覧にします。Excel、旧CRM、会計、販売管理などに加えて、メールや外部ポータルも含めます。
対象の法人・拠点と利用ユーザー数に加え、個人情報や営業機密の扱い、連携先を確認します。さらに、保持期間、RTO・RPO、希望稼働日、許容停止時間も確かめます。
この段階の終わりには、対象と対象外の業務、優先順位が決まり、KPIと現行データの責任者も定まっている状態にします。
フェーズ2：選定による対象アプリと標準化の境界の決定
選定では、Sales、Customer Service、Financeを候補にします。Supply Chain ManagementやBusiness Centralも候補に入ります。各アプリは、業務要件に照らして比べます。
営業部門が10〜50人程度であれば、Salesから始める案があります。案件、活動、見積の状況を把握するのが目的の場合に、現実的な案です。
一方で、複数法人の会計や、販売から生産までを統合する場合は、FinanceやSupply Chain Managementを中心に据えます。法人構造や日本の商習慣への適合性も確認します。
また、財務と販売管理を一体化したい中堅・中小企業は、Business Centralも比べ、ユーザー権限を確かめます。
候補を絞った後は、Fit to Standardのワークショップを行います。境界をはっきりさせるため、次の区分で色分けします。
- 標準機能・設定：標準に業務を合わせる領域と、設定だけで対応する領域。
- ローコード拡張：Power Apps、Power Automate、Power BIで補う領域。
- 外部連携：APIやファイル連携で外部システムに残す領域。
- 個別開発：標準や拡張では対応が避けられない領域。
個別開発にするかは、独自機能が競争優位に直結するか、アップデートに耐えられるか、利用者が業務を変えられるかで判断します。また、追加費用と保守負担を受け入れられるかも確かめます。
判断は、画面デモよりも、実データに近いサンプルを使って行います。そこでは、案件登録、承認差戻し、顧客重複、月次締めを試します。在庫引当、権限エラー、連携失敗も、同じサンプルで確かめます。
複数社には、同じ業務シナリオ、データ件数、受入条件を渡します。そのうえで、提案の巧さではなく、要件をどれだけ整理して説明できるかを見ます。
この段階の終わりには、アプリ構成と標準化方針、PoCの範囲について合意します。候補パートナーと概算予算も決まっている状態にします。
フェーズ3：設計開発によるデータ、権限、連携の具体化
設計開発では、業務とデータ、連携を具体化します。環境と成果物も、この段階で決めます。
- 業務・データ：プロセス、モデル、画面、帳票、ワークフロー。
- 連携：方式、再送、監視、障害時の責任分界。
- 拡張環境：Power Platformの環境分離と移送。
- 成果物・記録：仕様書、計画、運用手順、判断理由。
Dataverseの顧客接点アプリでは、取引先と担当者の重複ルールや、案件の状態遷移を設計します。あわせて、所有者とチーム、セキュリティロールも決めます。
FinanceやSupply Chain Managementでは、法人・拠点と勘定科目・品目を中心にマスタを整理します。そのほか、倉庫・在庫や税区分・原価も対象になります。マスタごとに、登録する人と承認する人、変更のタイミングも決めておきます。
連携方式には、リアルタイムAPI、Azure Logic AppsやFunctions、ETL、定時ファイル連携などの候補があります。そのうえで、送信元と送信先のどちらを正とするか、重複の排除、順序の逆転、タイムアウトも確認します。
Power Platformでは、ソリューション管理、コネクタの認証情報、フローの所有者を決めます。また、標準のコードを直接変更せず、更新で壊れにくい拡張を優先します。
開発期間中は週次で課題を管理し、節目ごとに設計レビューを行います。
要件定義書やFit & Gap一覧、データ移行仕様、権限マトリクスなどを作成します。画面・帳票一覧、連携仕様、テスト計画、教育計画も含めます。
標準機能を採用した理由や、個別開発を見送った理由を残しておくと、変更管理や引き継ぎで役立ちます。
フェーズ4：テストによる業務、移行、権限、連携の検証
テストは、単体、結合、総合、ユーザー受入の順に分けて行います。業務ごとに一連の流れを試し、正常系だけでなく例外も確認します。
- Sales：案件登録から受注・失注、売上見込みまで。
- Customer Service：受付から担当割当、回答、エスカレーション、クローズまで。
- Finance：伝票、承認、請求、支払、締めまで。
試験には、重複データや必須項目の漏れ、権限不足、承認差戻しを含めます。さらに、API停止や通信遅延、日付や通貨の境界値も対象にします。
移行テストでは、顧客、商品、担当者、勘定科目、在庫、取引履歴などを照合します。件数と必須項目、金額と日付を中心に、文字コードや重複、参照関係も確かめます。
旧システムとDynamics 365で同じ処理を行い、合計金額、残高、在庫数が一致するかを確かめます。
移行リハーサルは、少なくとも一度行います。差異の修正担当、再実行の方法、移行対象外データの保管方法を決めておくと、本番切替時の混乱を抑えられます。
セキュリティテストでは、職務分掌と最小権限を確認します。Microsoftはデータセンターや基盤を担います。利用企業は、データ分類やユーザー、ロール、監査、連携資格情報を管理する、共有責任の関係です（出典: Microsoft Learn「Secure your Dynamics 365 data and apps」、2026年確認）。
管理者に見える画面が、一般ユーザーにも見えるとは限りません。そのため、営業秘密、個人情報、給与、原価などのアクセス境界を、実際のユーザーで検証します。
フェーズ5：稼働での切替手順とロールバック条件の決定
稼働方式ごとの特徴を比べ、業務への影響を踏まえて選びます。
- 全社一斉切替：データと業務をまとめやすい一方、問題時の影響が大きい方法。
- 段階展開：学習と改善の時間を確保できる一方、二重運用や連携が増える方法。
- Sales先行：Salesだけを先行して導入する方法。
- 法人展開：1法人から始め、テンプレートを横展開する方法。
方式は、利用者数と業務の重要度、締め日から決めます。拠点の差や旧システムの保守期限も、判断材料に加えます。
切替手順書には、作業を時系列で記載します。最終抽出から移行実行、件数照合までの作業と、代表業務の確認、利用開始、問い合わせ窓口、監視、経営層への報告を含めます。
切替の前に、中止するエラー率と、旧システムへ戻す期限、最終判断者を決めておきます。ロールバックできない処理や二重登録を避けるため、戻す対象と戻せない対象を明示します。
稼働判定では、ログインできるかだけでなく、KPIに直結する代表業務を確認します。データ件数や帳票、承認の状態も見ます。連携や監査ログ、バックアップ、アラート通知も、あわせて確認します。
稼働後の初週は、問い合わせを集中的に受けるハイパーケア期間とします。届いた問い合わせは、操作ミス、設計不備、データ不備、追加要望に分けて整理します。
追加要望は、無制限に実装せず、業務への影響と契約の範囲を確認してから変更管理へ回します。
フェーズ6：定着での教育、運用、アップデートの継続
定着では、教育と利用状況の確認、継続的な運用を組み合わせて進めます。
- 教育：役割別教材、業務演習、FAQ、現場チャンピオン、窓口。
- 利用状況：入力や処理状況を確認し、項目や画面を改善。
- 継続運用：更新を検証し、KPIや権限、連携を見直す。
具体的には、入力率や案件更新の遅れ、未処理ケースを定期的に確認します。承認の滞留やマスタ申請の差戻しも見て、使われない項目や複雑な画面を改善します。
教育の責任者と、運用ルールを変えられる業務責任者を分けておくと、問い合わせが特定の担当者に集まりにくくなります。
稼働後も、リリースノートの確認、サンドボックスでの回帰テスト、影響範囲の判断、ユーザーへの告知が欠かせません。
2026年リリースウェーブ1では、2026年4月から9月に機能が提供されます。Dynamics 365は年2回のリリースウェーブで更新されます（出典: Microsoft Learn「Dynamics 365 2026年リリースサイクル1の計画」「リリーススケジュール」、2026年）。
新機能は、業務効果やセキュリティ、教育負担、既存拡張への影響を評価して、採用するものを選びます。
引き継ぎ時は、構成図や権限一覧、データ辞書、連携仕様、障害時のランブックを確認します。バックアップ・復旧、更新、問い合わせのSLA、変更申請の手順も納品物に含めます。
月次または四半期ごとに、KPIやライセンス数、容量を見直します。連携エラーや権限、追加開発のbacklogも確認します。定着した業務から順に次の部門へ広げ、業務指標の改善を続けます。
Dynamics 365のシステム開発にかかる費用相場
総額は、ライセンス費、導入の費用、保守・運用費に分けて見積もります。導入の費用には、初期設定・開発、移行、外部連携が含まれます。さらに、テストや教育・切替も含まれます。追加容量やAI利用料も、総額に入れて考えます。
ここで示す開発費は、公定価格ではなく、リサーチノートの業務システム相場と、想定構成・工数による予算の目安です。
ユーザー数や法人・拠点、データ量、連携本数などで変わります。そのため、同じ前提をそろえて個別見積もりを取得します。
ライセンス費を左右するユーザー数とアプリ構成
Salesの年払い相当、税別の表示価格は、2026年8月にMicrosoft公式の日本語ページで確認しました。
- Professional：9,745円のユーザー・月相当。
- Enterprise：15,742円のユーザー・月相当。
- Premium：22,488円のユーザー・月相当。
10ユーザーで単純計算すると、年間約116.9万円から約269.9万円になります。
ただし、消費税や導入支援、移行、連携は含まれていません。追加容量、Power Platform、Azure、サポートも対象外です（出典: Microsoft公式「Dynamics 365 Salesの価格」、2026年8月確認）。
また、Financeは31,484円、Finance Premiumは44,977円のユーザー・月相当です。10ユーザーでライセンスだけなら、年間約377.8万円から約539.7万円になります。
なお、Business Centralは、ユーザー・月相当でEssentialsが11,994円です。Premiumは16,491円、Team Membersは1,199円です。
役割ごとに、フルアクセス、制限付きアクセス、承認のみといった権限の違いを確認します（出典: Microsoft公式「Dynamics 365 Financeの価格」「Business Centralの価格」、2026年8月確認）。
導入・開発費の規模別の目安
導入・開発費の予算の目安は、規模や展開範囲によって異なります。
- 小規模CRM：300万〜800万円、3〜6か月程度。
- 中規模CRM・SFA：800万〜2,000万円、6〜12か月程度。
- 複数法人・拠点のERP：2,000万〜1億円以上、9〜24か月程度。
- 大規模グループ展開：1億円超、1〜3年以上。
小規模CRMは、Salesを10〜30人で利用し、標準設定と権限、少数の移行、1〜2本の連携を想定します。簡単な帳票も含みます。
標準機能の確認やデータクレンジングを発注者側で行える場合は、費用が下がる可能性があります。ただし、ライセンス費は別に計上します。
中規模CRM・SFAは、20〜100人で利用する想定です。旧CRM履歴の移行、Outlook・Teams連携、複数部門の承認を含みます。さらに、Power Apps・Power Automate・Power BI、外部基幹API、UAT、教育も見込みます。
大規模グループ展開は、共通テンプレートやデータ標準、ガバナンス、海外ローカライズを含みます。拠点展開や教育、運用組織まで含めて想定します。
費用は、最初の1社分の設定費に、共通テンプレートなどの展開費を加えて考えます。たとえば、AGC化学品カンパニーは、異なる基幹システムを使う関係会社3社から始めました。FinanceとSupply Chain Managementで、業務とデータを標準化した事例です（出典: Microsoft Customer Stories「AGC化学品カンパニー」、2026年5月公開）。
保守・運用費と追加利用量の見積もり
費用項目を分けて確認すると、運用費の見積もり漏れを防げます。
- 保守費の目安：一般的な業務システムでは、初期開発費の年15〜25％、または月15万〜80万円程度。
- パートナー業務：問い合わせ、監視、障害対応、軽微改修、更新検証、マスタ保守。
- 追加利用料：容量、クラウドサービス、バックアップ、AI利用分。
追加費用には、Power Platform容量、AzureのAPI・Functions・Logic Appsが含まれます。Power BIやデータ転送、Copilot Studioのクレジットも、追加費用になります。Dynamics 365のライセンス費は、パートナーの保守・運用費と分けて見積もります。
24時間監視や休日対応、SLA、法改正対応、追加開発の時間単価が契約に含まれるかどうかで、年間の費用は変わります。
AIエージェントを使う場合は、利用人数や実行回数、対象データ、Azureサブスクリプション、権限を確認します。
初年度だけでなく、3年間のライセンス、運用、更新、拡張の総額で比べると、見積もりの安さだけでは判断しにくくなります。
見積もりを取る際のポイントとチェックリスト
合計金額よりも、作業範囲、成果物、前提条件、除外事項、責任分界を確認します。「Dynamics 365導入一式」とだけ書かれた見積もりでは、要件定義や移行照合、負荷試験、教育、切替支援、更新検証の有無が分かりません。
候補の会社には、同じ要件書と業務シナリオを渡し、同じ粒度で回答してもらいます。
要件書に記載する情報と業務シナリオ
見積もりの前に、要件書へ記載する情報を整理します。
- 対象と体制：アプリ、ユーザー数と役割、法人・拠点、希望時期。
- 現行環境：現行システム、データ件数と履歴年数、連携先。
- 要件：帳票、承認、権限、性能、可用性、セキュリティ。
Salesでは、リード登録から受注までを業務シナリオにします。担当割当、案件化、見積承認もその流れに含めます。ERPでは、受注から購買、生産、入出庫までを一つの流れで示します。さらに、請求、入金、月次締めも同じ流れに含めます。
資料には、現行画面やデータサンプル、マスタと連携の一覧を添えます。帳票サンプル、組織図、権限、繁忙期の処理量、目標KPIも用意します。個人情報や営業秘密は匿名化したうえで、サンプルの利用範囲を決めます。
未確定の要件は、隠さずに仮説や確認期限、見積もり上の扱いを記します。曖昧な範囲を一律に開発費に含めるより、調査、PoC、追加変更の費用を分けたほうが、予算を管理しやすくなります。
複数社の同条件での比較と担当者・体制の確認
候補の会社について、経験、実装・移行力、運用体制を同じ基準で確認します。
- 経験：近いアプリ・業種の事例、担当者の経験、製品・Power Platformの資格や実績。
- 実装・移行：移行方法、テスト体制、標準と個別開発の境界。
- 運用体制：教育・定着支援、窓口、SLA、再委託の有無。
大手SIerは総合力、Microsoft専門会社は製品知識、業種特化会社は業務理解に強みがあります。そのため、会社規模だけで選ばないようにします。
提案では、標準機能と個別開発の境界を説明できるかを見ます。そのうえで、標準利用時の業務変更や、Power Platformの保守、アドオンの更新影響、外部連携の障害対応も示してもらいます。
可能であれば、代表的な業務シナリオのデモとPoCの評価項目を、同席者全員で確認します。
見積もりに含める移行、権限、アップデートのリスク
見積もりには、移行、アクセス管理、法務・経理要件、更新対応のリスクを含めます。バックアップの復元と性能試験も確認します。
- 移行：クレンジング、リハーサル、履歴照合、切替、教育、引き継ぎ。
- アクセス管理：認証、権限、個人情報、監査、秘密情報。
- 法務・経理：電子取引、保存期間、検索性、証憑と仕訳のひも付け。
- 更新対応：回帰テスト、機能判断、教育資料、検証環境、緊急修正。
Excelや旧CRMの顧客名、商品コード、担当者コードに表記の揺れがあると、移行や連携、帳票にも影響します。そこで、発注者側でデータを整理する担当と期限を決め、遅延時の追加費用や日程変更を契約に記載します。
Entra IDでは、多要素認証を組み合わせ、退職者のアカウントを停止します。また、職務分掌や個人情報の分類、連携先の秘密情報も確認します。
法務・経理が関わる場合は、適格請求書と電子帳簿保存法を要件に含めます。日本向けの機能があっても、自社の法的要件が自動的に満たされるわけではありません。
Dynamics 365は年2回のリリースウェーブで更新されるため、契約時から対応体制を決めます。
初期見積もりが安くても、これらが別料金であれば、稼働後の総額は高くなる可能性があります。
よくある質問（FAQ）
費用や期間は前提条件によって変わります。判断の観点と、開発会社への確認事項を、質問ごとに挙げます。
Dynamics 365のシステム開発費用はどれくらいですか？
小規模CRMは300万〜800万円、中規模CRM・SFAは800万〜2,000万円、複数法人のERPは2,000万〜1億円以上が予算計画の目安です。
これは、ライセンスを含まない開発・移行・テストなどの推定の幅であり、Dynamics 365の一律の価格ではありません。
対象アプリやユーザー数、データ量などの条件をそろえ、教育や保守も含めて個別見積もりを取ります。
SalesとFinanceは同時に導入すべきですか？
必ずしも同時に導入する必要はありません。営業プロセスを早く見える状態にしたい場合は、Salesを先行させます。
財務・在庫・生産まで一体化するなら、FinanceやSupply Chain Managementを中心に、全体を設計します。
将来連携する顧客、商品、法人、担当者、勘定科目などのマスタの方針は、初期に決めておきます。先行して導入しても、将来の統合を妨げないようにします。
標準機能に業務を合わせるべきですか？
原則として、Fit to Standardを第一候補にします。標準機能は、更新やサポート、教育、他部署への横展開を行いやすいためです。
法令や、顧客への独自価値、製造や原価などの競争優位に関わる要件は、無理に業務を変える必要はありません。
業務変更、設定、Power Platform、外部連携、個別開発の順に比べ、保守負担と将来の変更費を含めて判断します。
Excelや旧CRMのデータはどこまで移行できますか？
顧客、商品、担当者、案件、取引履歴などは、技術的には移行できます。ただし、すべての過去データを同じ品質で移せるとは限りません。
参照の頻度、法令・監査上の保存要件、データの正確性、移行費用を基準に、現行データと要約データ、必要なときに参照するアーカイブに分けます。
移行前には、重複や欠損、表記の揺れ、コード体系を整理し、日付と金額、個人情報の扱いも決めます。件数と合計値の照合を、受入条件とします。
まとめ
Dynamics 365の開発は、対象業務とKPIを定め、必要なアプリを選ぶところから始まります。製品の契約や画面の作成のほかに、業務設計、データ、権限、連携の整理も含まれます。
候補は、Sales、Customer Service、Finance、Supply Chain Management、Business Centralなどです。標準機能と拡張の境界を決めることが出発点です。
6フェーズの終了条件の合意と、次の段階への移行
要件整理では課題とKPI、選定ではアプリと標準化の境界、設計開発ではデータ、権限、連携を確認します。テストでは、業務と移行後の整合性を確かめます。
稼働では切替とロールバック、定着では教育、運用、更新を確かめます。また、成果物、判断者、未決事項、次へ進む条件を明示して、課題の先送りを減らします。
最初の一歩：業務シナリオと見積もり前提の整理
対象部門や利用人数、現行システム、移行データ、連携先を1枚にまとめます。希望時期、予算、改善したいKPIも書き添え、候補会社へ同じ条件で相談します。
見積もりは、ライセンス、導入開発、移行連携に分けます。そのうえで、教育切替や保守、CopilotやAzureなどの追加利用量も、別の項目として示してもらいます。3年間の総額と定着支援まで比べると、事業成果につなげやすくなります。
▼全体ガイドの記事
・Dynamics 365のシステム開発の完全ガイド
▼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を創業。