結論：料金計算システムの開発会社を選ぶなら、料金表の計算機能だけでなく、
加入者・利用実績・請求・決済・会計までを一つの業務基盤として設計できる会社を選ぶことが重要です。
通信キャリアやMVNO、ISP、CATV、通信回線を利用するSaaS事業者では、
月額料金、従量課金、日割り、無料枠、割引、上限額、返金を組み合わせる必要があります。
本記事では、株式会社riplaを最初に、実在する5社とあわせて計6社を紹介します。
各社の特徴と向いている案件、発注前の比較ポイント、費用の考え方まで、2026年時点の公開情報をもとに解説します。
▼全体ガイドの記事
・料金計算システム開発での完全ガイド
料金計算システムのパートナー選びが重要な理由
料金計算システムは、単価を掛け算するプログラムではありません。契約者の状態、サービスの開始日と終了日、
利用量、時間帯、割引条件を受け取り、課金結果を明細・請求書・決済・会計へつなぐ業務基盤です。
通信分野では、英語でrating、charging、billingと呼ばれる機能がBSS（Business Support System）の中核に置かれます。
料金計算は業務ルールとデータ連携の複合問題です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
たとえば、月額3,000円の基本料金に、データ通信量1GBあたり500円の従量料金、契約初月の日割り、家族割引。キャンペーンによる無料枠を組み合わせるケースがあります。
さらに、利用実績が翌日に届いたり、誤ったデータを訂正したり、締め日後に返金したりする処理も必要です。通常時の計算結果だけでなく、遅延・重複・欠損・再計算・取消を安全に扱えるかが品質を左右します。
料金計算と請求を別々に発注すると、同じ割引条件が異なるシステムに重複実装され、請求額と顧客向け画面の表示がずれることがあります。
契約管理、利用実績の収集、課金、請求、決済、入金消込、会計連携、監査ログをどこで担当するかを、開発会社と最初に整理する必要があります。
加入者数だけでなく料金ルール数とイベント量を見ます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
必要なシステム規模は、加入者数だけでは決まりません。
料金プランの数、法人ごとの個別単価、1秒単位で残高を更新する必要性、1日に取り込む利用イベント数、CRM・ネットワーク・決済・会計との連携本数。停止できない時間、監査の厳しさによって大きく変わります。
小規模なMVNOでも料金ルールが複雑なら、一般的な請求SaaSの標準機能だけでは不足することがあります。発注前には、代表的な料金ケースを期待結果付きで作成します。
「月額料金＋従量料金＋無料枠＋日割り＋割引」「解約日をまたぐ返金」「利用実績の訂正後に再請求」という3つ以上のケースを同じ条件で各社に提示すると。
機能一覧だけでは分からない設計力とテストの深さを比較できます。
株式会社ripla｜コンサルから開発まで一気通貫で支援
riplaは、コンサルティングから開発まで一気通貫で支援できる企業です。
IT事業会社として社内DXを推進してきた経験を活かし、ビジネスへの成果創出とシステムの定着支援に強みがあります。
営業・顧客・生産・販売管理など、幅広い基幹システムの構築・導入実績があり、企業の業務要件に合わせて柔軟に対応できる体制を整えています。
特徴と強み
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
料金計算システムでは、事業部門が持つ料金ルールを整理し、契約・利用実績・請求のデータモデルへ落とし込む作業が最初の難所になります。
riplaは、業務ヒアリング、現行システムの整理、要件定義、開発、導入後の定着までを一つの流れで相談しやすい点が特徴です。
料金計算だけを切り出すのではなく、顧客管理や販売管理など周辺の基幹業務とのつながりを踏まえて、現実的な段階導入を検討できます。
既存のCRM、契約管理、決済、会計を残し、料金ルールと請求明細の部分から改善したい場合にも、最初に対象範囲を整理できます。
逆に、新規サービスの立ち上げにあわせて契約から請求までをまとめて作る場合は、業務フロー、権限、例外処理、運用担当者の役割を先に決め。必要な開発を過不足なく切り出すことが大切です。
得意領域・向いている案件
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
riplaは、業務部門とシステム部門の間にある要望を整理し、段階的な刷新計画へつなげたい案件に向いています。
たとえば、通信サービスの月額・従量・日割り計算を新設する案件、表計算で管理している法人別料金をシステム化する案件。既存の請求基盤を残して利用実績や明細表示を改善する案件です。
通信キャリア向けの専用パッケージやネットワーク接続が必要な場合は、専門ベンダーとの責任分界を含めて確認します。
相談時には、料金プラン数、加入者数、日々のイベント量、リアルタイム課金の有無、既存システム、求める可用性、移行時期を共有すると。
riplaが担う範囲と連携先へ委ねる範囲を具体化しやすくなります。
株式会社日立ソリューションズ｜国内の請求・債権管理までまとめたい企業向け
株式会社日立ソリューションズは、サブスクリプション事業を支援する「BSSsymphony サブスクリプションプラットフォームサービス」
を提供しています。顧客管理から決済までを扱うクラウドサービスとして、料金計算だけでなく請求管理や債権管理を含めて検討したい企業の候補になります。
特徴と強み
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
2026年1月28日の日立ソリューションズの発表では、BSSsymphonyの請求・債権管理機能を強化し。
同一顧客が契約する複数サービスの請求先分割や、複数顧客のサービスを特定の請求先へまとめる一括請求に対応するとされています。
支払条件を柔軟に設定できる点も示されており、法人契約や部門横断の請求を扱う企業が確認しやすい構成です。
このようなサービスを利用する場合でも、自社独自の料金ルールが標準設定で表現できるか、追加開発になるかを見極める必要があります。
月額・従量・日割り・割引の組み合わせ、請求締め、未収、返金、会計連携をサンプルデータで試し、標準機能と個別対応の境界を見積書に記載してもらいます。
得意領域・向いている案件
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
国内の請求慣行、複数部門の請求先、支払条件、債権管理を重視するサブスク事業者や通信関連企業に向いています。
大規模なネットワーク課金をゼロから作るというより、契約・請求・決済・回収の業務を整理し、国内運用に合わせた基盤を整えたい案件で比較しやすい会社です。
選定時は、利用実績をどの形式で受け取れるか、リアルタイム課金と月次請求をどう使い分けるか、料金改定の予約反映や過去データの再計算に対応できるかを確認します。
クラウド利用料、初期設定、連携、移行、運用保守、制度変更時の対応費を分けて提示してもらうと、総額を比較しやすくなります。
Ericsson｜クラウドネイティブな通信課金へ移行したい企業向け
Ericssonは、通信事業者向けのOSS/BSS領域で、Ericsson Billingを含むグローバルな製品・導入支援を展開する企業です。
モバイル、固定回線、MVNOなど複数事業の請求を統合し、5Gや新しいサービスの料金化を進めたい大規模案件で比較対象になります。
特徴と強み
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
Ericssonが公開する2025年のOdido事例では、Ericsson BillingをAWS上のクラウドネイティブ基盤として運用し。モバイル・固定・MVNOの請求を統合しています。
約570万加入者をクラウドネイティブ基盤へ移行し、標準的な請求処理が30％速くなり。
複雑な法人請求は最大5倍速くなったと紹介されています（出典: Ericsson「Odido migrates to cloud-native billing
for 5G innovation」、2025年）。
また、MVNOブランドの約100万加入者を先行移行してから大規模移行へ進む段階的な方法も示されています。
大規模移行では、旧システムと新システムの請求額、加入者残高、件数、売上を並行して突合し、切り戻し条件を決めることが重要です。製品の導入だけでなく、移行計画、試験データ、障害時の運用体制まで確認します。
得意領域・向いている案件
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
モバイルと固定回線を統合したい通信事業者、5G・FWA・IoTなど新サービスを短いサイクルで料金化したい企業。複数のレガシー課金基盤をクラウドへ段階移行したい企業に向いています。
大量の加入者と利用イベントを扱いながら、事業部門が新しい商品を展開するスピードも高めたい場合に検討しやすい候補です。
一方で、国内の請求書式、税、決済、会計、サポート体制が自社の要件に合うかは個別確認が必要です。
国内パートナーの担当範囲、データ所在、SLA、クラウド費用、ライセンス体系、製品からデータを取り出す方法を、導入前の質問票に含めます。
NEC｜5GネットワークとBSSの課金連携を重視する企業向け
NECは、通信ネットワークと業務システムの接続を含めて、料金計算の前段にある利用情報の整理を相談しやすい企業です。
料金エンジン単体の比較ではなく、5Gコアから届く複雑な課金情報をBSSへ渡すゲートウェイ、
認証、ネットワーク、顧客管理との連携を一体で考えたい案件に適しています。
特徴と強み
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
NECは2023年1月、NTTドコモのスタンドアローン5G向けにCharging Gateway Function（CGF）を提供し。2022年12月から稼働したと発表しています。
5Gコアネットワークから送られる多様な課金情報を整理し、顧客管理・請求のBSSへ連携するゲートウェイとして。
複雑化するサービスの課金処理を支援する位置づけです（出典: NEC「NEC provides billing gateway for DOCOMO’s
standalone 5G system」、2023年）。
この実績から、NECを評価するときは「料金計算の画面があるか」だけでなく、ネットワークイベントをどのように正規化し、重複・遅延・再送を処理し。BSSへ引き渡すかを確認します。
CGFや連携部分が対応しても、契約管理、割引、請求書、入金消込、返金、会計仕訳が別の製品になる可能性があるため、全体構成と責任分界を図にしてもらいます。
得意領域・向いている案件
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
5G、IoT、ネットワークスライシング、法人向け通信など、ネットワークから発生する利用情報の種類が増えている企業に向いています。
通信インフラ、認証、課金ゲートウェイ、BSSを複数の会社へ分けて発注する場合も、NECが担当する接続範囲と。別の課金・請求製品へ渡すデータ項目を整理しやすくなります。
相談時は、ネットワークイベントの件数、リアルタイム性、オンライン課金とオフライン課金の区別、利用実績の再送・訂正方法、通信断時の処理。既存BSSのAPI仕様を提示します。
特定の通信方式や製品の実績が自社環境にそのまま適用できるとは限らないため、同じ規模・同じ接続方式の事例を確認します。
Oracle｜通信向けBRMで課金・請求・収益管理を統合したい企業向け
Oracleは、通信事業者向けにOracle Communications Billing and Revenue
Management（BRM）を提供しています。
BRMは、利用量や定額料金のcharging、月次などのbilling、支払い処理、
顧客アカウント管理、収益管理を扱う製品です。既存のOracle製品群や大規模な通信基盤との整合性を重視する企業が検討しやすい候補です。
特徴と強み
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
Oracle公式ドキュメントでは、BRMについて、利用イベントをリアルタイムに課金するオンライン課金と。CDRなどの利用記録をまとめて評価するオフライン課金の両方が説明されています。
Elastic Charging EngineやPipeline Manager、Pricing Design Centerなどを組み合わせ、商品。
料金、利用イベント、顧客残高、請求。
支払いの流れを構成できる点が特徴です（出典: Oracle Communications Billing and Revenue Management
Documentation 15.0、2026年参照）。
料金ルールは、商品・プラン・割引・イベント属性・契約状態の組み合わせで設計します。
通信だけでなく、SMS、データ通信、固定回線、ローミング、IoTなど複数サービスを扱う場合に、料金モデルの共通化を検討できます。
ただし、導入には製品構成と専門知識が必要になるため、標準機能、設定、拡張、周辺開発、ライセンス、保守の範囲を分けて説明してもらうことが大切です。
得意領域・向いている案件
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
プリペイドとポストペイドを統合したい企業、利用イベントの種類が多い通信事業者、複数サービスの料金・請求・収益管理をグローバルに標準化したい企業に向いています。
Oracle Database、CRM、会計など既存のOracle環境を活用したい場合も、連携方式やデータ正本を整理しやすい候補です。
選定時は、料金改定の予約反映、過去イベントの再レーティング、返金・訂正、請求締め、債権、税、帳票、会計連携を一連のテストケースで実演してもらいます。
クラウドで利用する場合は、データ所在、障害時の復旧目標、拡張単位、従量課金、環境の分離、撤退時のデータエクスポートも確認します。
Netcracker Technology｜複雑なリアルタイム料金モデルを大規模に扱う企業向け
Netcracker Technologyは、
通信事業者向けのRevenue ManagementやConvergent Charging Systemを提供するグローバル企業です。
通信・非通信のサービス、個人・法人、プリペイド・ポストペイドなどを一つの料金・収益管理基盤で扱い、
5G、IoT、B2B2Xなど新しいビジネスモデルへ対応したい企業が比較する候補です。
特徴と強み
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
Netcrackerの公式情報では、Convergent Charging Systemについて、利用から支払いまでの業務を支援し。
さまざまな属性にもとづく複雑なリアルタイム料金設定へ対応する方針が示されています。
ネットワーク技術、通信・非通信の商品、顧客種別、ビジネスモデルを特定の方式に固定しない構成を掲げているため。料金モデルの変化が多い大規模事業者が検討しやすい製品です。
複雑な料金を扱えることは強みですが、実際に自社の業務へ適合させるには、商品カタログ、注文、利用実績、課金、請求、回収、収益認識の境界を設計する必要があります。
製品デモでは、複数サービスの束ね売り、法人の階層請求、上限額、割引、利用量の訂正、返金、異常イベントの再処理を同じシナリオで確認します。
得意領域・向いている案件
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
大規模通信事業者、複数ブランドや複数国の料金を統合したい企業、IoT・法人サービス・デジタルコンテンツを組み合わせて提供したい企業に向いています。
料金計算の一部だけではなく、収益化を早めるための商品・注文・課金・請求の流れを再設計したい場合に、グローバルな選択肢として比較できます。
海外製品を導入する際は、国内の税・請求書・決済・個人情報の要件を誰が実装するかを確認します。
日本語の運用支援、国内パートナー、常時の障害窓口、バージョンアップ、移行支援、年間保守費、データの持ち出し方法まで含めて評価すると。製品機能だけでは見えない導入リスクを比較できます。
料金計算システムのパートナー選びのポイント
6社を比較するときは、企業規模や製品名だけで優劣を決めないことが大切です。自社の料金ルール、
データ量、リアルタイム性、既存システム、運用体制に対して、どの会社の方式が過不足なく合うかを確認します。
見積の安さだけでなく、移行後に自社で料金改定を安全に行えるかまで評価します。
実績と経験を自社の条件に置き換えて確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
「通信業界で実績がある」という説明だけでは不十分です。自社と近い加入者規模、料金プラン数、利用イベント量、リアルタイム課金の有無、請求締め、決済手段、既存システムでの実績かを質問します。
公開事例の加入者数が大きくても、同じ構成を自社の規模で利用するとは限らないため、標準構成と最低利用規模も確認します。RFPには、現行のデータフローと代表的な料金ケースを記載します。
各社から、標準機能、設定、追加開発、外部サービス、前提条件、対象外の範囲を分けた回答を受け取ると、実績の有無を自社要件に置き換えられます。
事例を開示できない場合も、匿名化した構成図やテスト観点を確認すると評価しやすくなります。
技術力は料金変更と異常系のデモで評価します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
技術評価では、通常の料金計算ができることよりも、料金ルールを安全に変更できることを見ます。
新プランを未来の日付で予約し、旧プランの契約者を維持し、キャンペーン対象者だけ割引し、改定前の利用分を再計算するシナリオを実演してもらいます。
承認者、反映日時、バージョン、変更前後の差分が監査ログに残るかも重要です。
異常系では、利用実績の重複、欠損、遅延、再送、計算途中の障害、決済失敗、請求後の返金を確認します。
処理IDや冪等キーで二重請求を防げるか、失敗レコードを再処理できるか、手動承認や補償処理を行えるかを見ます。
画面の見た目より、業務担当者が原因を追跡して説明できる明細と証跡が残ることを重視します。
プロジェクト管理と費用の責任分界を確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
料金計算システムの費用は、画面数だけでは見積もれません。
2026年7月更新の受託開発相場をもとにした一般的な推定では、小規模で500万〜1,200万円、中規模で2,000万〜6,000万円。大規模で6,000万〜1億5,000万円超が目安になります。
通信課金では、料金ルール整理、利用実績の正規化、外部連携、データ移行、性能試験、請求照合が追加されるため。
この記事では小規模MVNO・ISPで500万〜1,500万円、中規模で2,000万〜6,000万円。
大規模刷新で6,000万円〜数億円を推定レンジとして扱います（出典: SIA「受託開発の費用相場と決定要素」、2026年7月更新）。
見積書では、要件定義・基本設計、実装、連携・移行、テスト・請求照合、インフラ・セキュリティ、教育、予備費を分けてもらいます。
運用保守は新規開発費の年15〜25％程度という一般的な目安がありますが、クラウド利用料、監視、ログ保管、カード決済の従量料金、第三者診断。PCI DSS対応費は別建てになることがあります。
安い見積ほど、移行・異常系試験・本番並行稼働が含まれているかを確認します。
よくある質問（FAQ）
料金計算システムの開発では、機能の有無だけでなく、費用、期間、既存システムとの接続、
公開後の運用体制が質問されます。ここでは、発注前に特に確認されやすい3つの疑問へ回答します。
料金計算システムの開発費用はいくらですか？
小規模なMVNO・ISPの導入で500万〜1,500万円、中規模の課金・請求基盤で2,000万〜6,000万円、
大規模なキャリア刷新で6,000万円〜数億円が推定レンジです。料金ルール数、イベント量、
リアルタイム性、連携数、移行データ、性能試験、セキュリティ要件で変わるため、加入者数だけを伝えて見積を取ると精度が下がります。
パッケージとスクラッチ開発はどちらがよいですか？
標準的な料金・請求業務を短期間で導入したい場合はパッケージやクラウドが有力です。
独自の商習慣、特殊な料金ルール、既存システムとの細かな連携が競争力に直結する場合はスクラッチや追加開発を検討します。
実務では、標準課金エンジンを使い、差分を設定・API・周辺サービスで吸収するハイブリッドが費用と柔軟性のバランスを取りやすいです。
料金計算システムにセキュリティ要件は必要ですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
必要です。カード情報を扱う場合はPCI DSS v4.0.1を対象範囲に応じて確認し、トークン化や非保持化、ネットワーク分離、暗号化、アクセス制御、ログ監視。脆弱性対応を設計します。
PCI Security Standards Councilの文書ライブラリでは。
PCI DSS v4.0.1と2025年1月の優先対応ツールが公開されています（出典: PCI Security Standards Council。2025年）。
加入者の氏名、住所、契約、利用履歴、請求情報を扱う場合は、個人情報保護委員会のガイドラインも確認します。
同委員会の通則編は、2026年6月に一部改正され。
業種・規模を問わず個人情報取扱事業者などへ適用されます（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年）。
利用目的、委託先管理、保管期間、削除、越境移転、事故時の連絡体制を要件定義に含めます。
まとめ
料金計算システムの開発会社を選ぶときは、料金表の計算機能だけでなく、契約、利用実績、
課金、請求、決済、会計、収益保証までの業務をどのようにつなぐかを比較します。国内の請求・債権管理を重視するなら日立ソリューションズ、
クラウドネイティブな大規模移行ならEricsson、5Gネットワーク連携ならNEC、
通信向けBRMならOracle、複雑なリアルタイム料金モデルならNetcrackerが候補になります。
業務整理から開発・定着まで一気通貫で進めたい場合は、株式会社riplaにも相談できます。
6社を比較するときの考え方
発注先は、会社の知名度だけでなく、自社が最も困っている領域から絞り込みます。国内の請求・債権管理、
ネットワークイベントの連携、クラウド移行、BRM製品の導入、複雑なリアルタイム課金のどこを重視するかを先に決めると、
候補会社との打ち合わせが具体的になります。
発注前に比較する項目
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
発注前には、料金ルール数、加入者数、イベント量、リアルタイム性、連携先、移行範囲、SLA、請求締め、受入テストを一つのRFPにまとめます。
各社へ同じ料金ケースを提示し、標準機能と追加開発、初期費用と保守費、通常系と異常系、導入後の責任分界を比較すれば、自社に合うパートナーを選びやすくなります。
▼全体ガイドの記事
・料金計算システム開発での完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。