結論：料金計算システムの発注・外注では、料金表を計算する機能だけでなく、契約者情報、
利用実績、請求、決済、返金、会計連携までを含めて業務基盤として設計することが重要です。
本記事では、通信キャリア、MVNO、ISP、CATV、通信回線を利用するSaaS事業者を想定し、
料金計算システムを発注する方法を解説します。発注形態の選び方、RFPと要件整理、
請負・準委任の使い分け、2026年時点の費用相場、委託先の選定、見積書の比較、移行と運用まで、
外注前に決めておきたい事項を順番に整理します。
▼全体ガイドの記事
・料金計算システム開発の完全ガイド
料金計算システムを発注する前に知っておきたい全体像
料金計算システムは、英語ではrating、charging、billingなどの言葉で表現され、
BSS（Business Support System）の中核に位置します。料金計算は利用量や契約条件から金額を算出する処理であり、
請求はその結果を明細・請求書・決済・回収へつなげる業務です。発注時は両者の境界と責任分担を最初に決めないと、
後から追加開発が増えやすくなります。
料金計算と請求は別の機能として整理します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
料金計算では、月額料金、従量単価、無料枠、超過料金、日割り、時間帯、曜日、地域、速度、割引、キャンペーン、上限額などを組み合わせて金額を決めます。
請求では、締め日、請求先、支払方法、税、請求書、入金消込、未収、督促、返金、会計仕訳までを扱います。
例えば、月額3,000円にデータ通信量の従量料金を加え、契約開始月だけ日割りし、キャンペーン割引を適用する場合、計算式だけでなく。どの料金ルールをどの順序で適用したかを明細に残す必要があります。
規模は加入者数だけでなくルールとイベント量で決まります
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
必要なシステム規模を加入者数だけで判断するのは危険です。
料金ルールの数、1日・1秒あたりの利用イベント数、リアルタイム判定の有無、外部連携の本数、請求締めの時間、停止できる時間。監査証跡の要件によって難易度が変わります。
小規模のMVNOでも、複数の卸先から大量の利用実績を受け取り、短時間で再計算する場合は、単純な月額請求システムより高い性能要件が必要です。
料金計算システムの発注形態はどのように選びますか？
結論として、料金ルールと既存データの整理が不十分な段階では準委任型の要件整理から始め、
仕様と成果物を固めた後に請負型の開発へ移る進め方が現実的です。標準機能が多いパッケージなら導入支援を中心に依頼し、
独自の料金ロジックや複数システムとの連携が競争力に直結する場合は、スクラッチ開発またはハイブリッド方式を検討します。
パッケージ・クラウド・スクラッチを比較します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
パッケージは、料金、契約、請求、債権などの標準機能を利用でき、短期間で導入しやすい方式です。
一方で、国内の請求慣行、法人別の個別単価、特殊な割引、既存の業務手順をそのまま再現できるとは限らず、追加設定や周辺開発が必要になります。
クラウドやSaaSは、初期インフラ構築を抑え、自動拡張やアップデートを利用しやすい反面、利用量に応じた従量料金、データ所在、SLA、障害時の復旧手順。
サービス終了時のデータ移行を確認する必要があります。
スクラッチ開発は、自社の料金ルールや既存システムに合わせやすい方式です。
しかし、料金マスタの管理画面、計算エンジン、再計算、請求照合、監査ログ、障害対応まで自社または開発会社が長期に保守する責任を負います。
実務上は、標準課金エンジンを利用しながら、差分をAPI、ルール設定、周辺サービスで吸収するハイブリッド方式が、適合性と保守性のバランスを取りやすいです。
一括発注と段階発注を使い分けます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初から本番の全機能を一括発注すると、要件の抜け漏れが大きな追加費用につながります。
まず現行業務の棚卸し、料金ルール表の作成、データフローの可視化、技術方式の比較、複雑な料金ケースを通すPoCを発注し。その結果をもとに本開発を依頼する段階発注が有効です。
PoCの成果物には、計算結果だけでなく、入力データ、適用ルールの版、請求明細、返金、再計算、エラー時の処理を含めます。
一括発注が適するのは、料金ルール、連携先、移行範囲、性能条件、受入基準がすでに定まっており、発注者側に意思決定できる体制がある場合です。
反対に、現行システムの仕様が不明、部門ごとに料金計算の認識が違う、経理と事業部で請求の正解が異なる場合は、要件定義を別工程に分ける方が。見積の精度と契約上の責任分担を明確にしやすいです。
RFPと要件整理で発注条件を具体化する方法
RFPは、開発会社に作ってほしい機能を並べるだけの資料ではありません。事業背景、
対象業務、現行の課題、対象範囲、非対象範囲、データ量、性能、セキュリティ、移行、
保守、見積条件を同じ前提で伝え、提案と見積を比較するための資料です。料金計算システムでは、
画面数よりも料金ルールと利用実績の扱いを具体化することが重要です。
RFPには料金ルール・データ・連携条件を記載します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
料金ルールは、料金プラン、月額・従量の区分、無料枠、日割り、割引、キャンペーン、上限、税、締め日、返金、取消、再請求、法人の個別単価。代理店や卸先との精算に分けて記載します。
各ルールには適用開始日と終了日、優先順位、併用可否、端数処理、変更承認者を付けます。
例えば「初月無料」とだけ書かず、「契約開始日が月途中の場合に基本料を0円にするのか、利用従量分も0円にするのか、翌月に請求するのか」まで例示します。
データ条件には、加入者・回線・SIM・端末・契約・請求先・支払方法・利用実績の項目、1日あたりのイベント数、ピーク時の集中、遅延や重複の発生。訂正データの形式を含めます。
連携条件には、CRM、契約管理、ネットワーク、メディエーション、決済、会計、顧客ポータル、データ分析との接続方式、APIの認証、再送、タイムアウト。障害時の復旧を記載します。
受入テストを計算例と照合条件で定義します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
受入テストは「正常に動けばよい」ではなく、料金業務の正解を再現できることを基準にします。
月額料金だけの単純なケース、月途中の新規契約、無料枠を超えた利用、割引の併用、プラン変更、休止、解約、返金、利用実績の遅延、重複。締め後の訂正を代表ケースとして用意します。
各ケースには入力データ、期待金額、明細の表示、会計連携の結果、監査ログの内容を記載します。
非機能要件では、ピーク時の処理件数、請求処理の完了時間、障害復旧時間、バックアップ、データ保持期間、権限分離、暗号化、ログ監視、脆弱性対応を決めます。
料金計算は誤請求が直接顧客対応や返金につながるため、性能試験だけでなく、全件照合、再計算の再現性、旧システムとの並行稼働。ロールバック条件まで受入基準に含める必要があります。
請負・準委任など契約形態をどう選びますか？
契約形態は、納品物と責任の範囲を決めるための重要な発注条件です。要件が固まった開発を請負契約、
調査・要件整理・技術検証・伴走支援を準委任契約とするなど、工程ごとに使い分ける方法があります。
契約名だけで責任が決まるわけではないため、成果物、検収、作業範囲、変更管理、障害対応、
支払条件を契約書と個別仕様書で明確にします。
完成責任を求める工程は請負契約にします
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
請負契約は、合意した成果物を完成させ、検収を受けることを前提にする契約です。
料金計算エンジン、料金マスタ管理、請求書出力、定義したAPI、移行ツール、操作マニュアルなど、完成状態を確認できる工程に向いています。
発注者は、検収条件、検収期間、修正期限、瑕疵対応、納品ソースコード、設計書、テスト証跡、第三者ライセンスの一覧を確認します。
ただし、料金ルールが未確定のまま全工程を請負にすると、仕様変更が追加費用や納期延長として扱われやすいです。
何が当初仕様で、何が変更かを判断できるよう、料金ルールの版管理、変更要求票、影響範囲、見積の再承認手順を用意します。
発注者側の判断遅延やデータ提供遅延が納期に与える影響も、前提条件として書面に残します。
要件整理や専門人材の支援は準委任契約にします
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
準委任契約は、受託者が善管注意義務をもって合意した業務を遂行し、作業時間や役務に対して報酬を支払う形です。
現行業務のヒアリング、料金ルールの整理、アーキテクチャ検討、PoC、プロジェクト管理、内製化支援など。結果を事前に一つの完成物として確定しにくい工程に向いています。
経済産業省の資料でも、システム化構想など仕様検討段階の役務は準委任型。
仕様が定まった製作は請負型とする考え方が整理されています。
出典: 経済産業省「サイバーインフラ事業者に求められる役割等に関するガイドライン」、2026年。
準委任では、作業時間を払えば成果物が不要になるわけではありません。月次の作業報告、課題一覧、決定事項、設計レビュー記録、検証結果、次月計画を提出物として定めます。
時間単価だけでなく、誰が何時間参加し、どの意思決定を支援したかが分かる状態にすると、発注者は予算と進捗を管理しやすくなります。
料金計算システムの費用相場と内訳
通信キャリア向けの料金計算システム単体には、公開された統一価格表がほとんどありません。
以下の金額は、2026年7月時点の一般的な料金計算システム開発相場を基礎に、通信課金特有のデータ連携、
請求照合、性能試験、移行、監査対応を加味した初期検討用の推定レンジです。正式な見積ではなく、
発注予算を決めるための目安として利用します。
初期費用は500万円から数億円まで幅があります
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
小規模のMVNOやISPで、料金プランが少数、既存のCRMと決済へ限定連携し、クラウドまたはパッケージ設定を中心にする場合は。500万〜1,500万円程度が一つの目安です。
期間は3〜6か月程度を想定します。
中規模で複数サービス、法人別料金、大量の利用実績、明細・会計・回収連携を含める場合は、2,000万〜6,000万円程度、期間は6〜12か月程度が目安です。
複数ブランドや固定・モバイルの統合、リアルタイム課金、24時間運用、段階移行、厳格な性能・セキュリティ試験を含む大規模刷新では。
6,000万円から数億円、期間は12〜24か月以上になる可能性があります。
一般的な料金計算システム開発の目安として、SIA株式会社は2026年7月更新の記事で、小規模500万〜1,200万円。
中規模2,000万〜6,000万円、大規模6,000万円〜1.5億円超を示していますが、同社も独自試算であり。
地域や工程で変わると説明しています。
出典: SIA株式会社「料金計算システム開発費の相場と9つの決定要素」、2026年7月。
通信課金ではこのレンジに連携・移行・運用要件が上乗せされます。
見積金額は工程・連携・移行・保守に分けて確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
費用内訳は、要件定義・基本設計、実装、外部連携、データ移行、テスト・請求照合、インフラ、セキュリティ、プロジェクト管理、教育、予備費に分けます。
初期検討では、要件定義・基本設計が10〜20%、実装が20〜35%、連携・移行が15〜25%、テスト・請求照合が15〜25%程度という比率を置くと。抜け漏れを確認しやすいです。
ただし、これらも案件特性により変わる推定値であり、割合だけで優劣を判断しません。
初期費用以外に、クラウド利用料、監視・ログ保管、決済手数料、カード情報の非保持化や第三者診断、料金改定対応、保守、教育、データ移行の追加作業が発生します。
運用保守は新規開発費の年15〜25%程度が一般的な目安ですが、24時間監視や障害時の待機、料金改定の頻度。
内製化支援を含めると高くなる場合があります。
出典: SIA株式会社「料金計算システム開発費の相場と9つの決定要素」、2026年7月。
3年分の総保有コストで比較することが大切です。
委託先の選定と見積比較で見るべきポイント
委託先は、会社の知名度や見積総額だけで決めません。複雑な料金ルールを業務担当者から聞き取り、
計算結果を説明可能な明細へ落とし込み、障害や再計算まで設計できるかを確認します。
同じRFPと同じ計算ケースを複数社へ渡し、提案内容、前提条件、除外事項、体制、納期、
保守を同じ軸で比較すると、価格差の理由が見えやすくなります。
通信課金・請求・移行の経験を確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
候補会社には、通信キャリア、MVNO、ISP、サブスクリプション、決済、会計など、近い業務の実績を確認します。
実績数だけでなく、料金ルールの設定、利用実績のメディエーション、リアルタイム課金、ポストペイド請求、プリペイド残高、収益保証、旧システムからの移行。並行稼働のどこを担当したのかを聞きます。
実績を開示できない場合でも、匿名化した計算モデルやデモで、同じ複雑な料金ケースを再現してもらいます。
2025年のEricssonの事例では、オランダの通信事業者Odidoが、MVNOの約100万人を先行移行した後。約500万人の顧客をクラウドネイティブな請求基盤へ移行したと説明されています。
事例では標準請求処理が30%高速化し、複雑な法人請求は最大5倍速くなったとされていますが、これは特定の案件の結果であり。
他社で同じ効果を保証する数字ではありません。
出典: Ericsson「Odido migrates to cloud-native billing for 5G innovation」、2025年。
大規模案件では、先行グループ、リハーサル、全件照合、ロールバックを提案できる会社を評価します。
安い見積ではなく除外事項と追加条件を比較します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
見積比較では、総額の安い順に並べるだけでは不十分です。要件定義、料金マスタ、利用実績取込、課金、請求、決済、会計、照会画面、監査ログ、移行、試験、教育、保守が含まれているかを確認します。
「連携一式」「テスト一式」「移行一式」と書かれている項目は、対象本数、データ件数、試験ケース、担当範囲、完了条件を質問します。
価格が安い理由が標準機能の活用なら有利ですが、移行や請求照合を除外しているだけなら、後から費用が増える可能性があります。
比較表には、初期費用だけでなく、月額利用料、保守費、追加改修単価、クラウド費、データ転送料、決済関連費、障害対応費。契約終了時のデータエクスポート費を記載します。
さらに、ソースコードや料金ルールの所有権、データの返却、API仕様の開示、再委託先、担当者の交代、サポート時間、SLA、損害賠償の上限を確認します。
過去に経済産業省と国家サイバー統括室が公表したガイドラインも、供給者と顧客がそれぞれの役割を確認する評価チェックリストを示しており。
委託先選定時の質問項目として活用できます。
出典: 経済産業省・国家サイバー統括室「サイバーインフラ事業者に求められる役割等に関するガイドライン」。
セキュリティ・移行・運用を発注範囲に含めます
料金計算システムは、氏名、住所、契約、利用履歴、請求、支払情報を扱うため、開発会社に任せきりにできない領域です。
カード情報を扱う場合は、PCI DSS v4.0.1の適用範囲、カード情報を保持しないトークン化、
ネットワーク分離、暗号化、アクセス権、脆弱性対応、ログ監視、インシデント対応を要件に落とします。
PCI Security Standards Councilは、PCI DSS v4.xの一部要件について2025年3月31日以降の適用を案内しているため、
2026年の発注では「将来対応」とせず、
現行の適用範囲と責任者を確認します。出典: PCI Security Standards Council「PCI DSS v4.x FAQ」
、2026年参照）。
個人データの委託先管理と再委託を契約で定めます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
個人情報保護委員会のガイドラインでは、個人データの取扱いを委託する場合、委託先の選定基準、アクセスを認める情報やシステムの範囲。
委託先における安全管理措置、再委託。監査などを確認することが望ましいとされています。
出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」。
そのため、RFPにはデータ項目、利用目的、保管場所、保存期間、アクセス権、再委託の事前承認、事故時の報告、監査権、契約終了時の返却・削除を記載します。
運用設計では、料金改定を安全に行う手順が特に重要です。
業務部門が料金ルールを登録し、別の承認者が計算例を確認し、指定日時に反映するワークフローを設けます。
料金マスタのバージョン、適用期間、変更者、承認者、変更前後の差分、シミュレーション結果を保存すると、誤請求時に原因を追跡できます。
本番後の問い合わせ、返金、再請求、障害時の手動処理も、保守契約の対象に含めます。
移行は並行稼働と全件照合まで計画します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
旧システムから新しい料金計算システムへ移行する場合、顧客、契約、料金マスタ、残高、未請求の利用実績、請求履歴、入金、未収、返金履歴を移します。
移行前にデータ項目の対応表と欠損・重複の扱いを定め、テスト移行を繰り返します。
本番切替では、一定期間の並行稼働を行い、加入者数、利用イベント数、請求金額、税額、売上、入金、未収残高を日次で突合します。
切替判断は「画面が表示できる」ではなく、許容差分、未処理イベント、障害件数、問い合わせ件数、復旧時間を基準にします。
新規契約や一部ブランドから段階的に切り替え、問題があれば旧システムへ戻す条件を決めます。
移行の担当会社だけでなく、経理、顧客サポート、ネットワーク運用、法務、セキュリティの責任者を本番判定に参加させると。金額だけでは見えない業務リスクを抑えられます。
よくある質問（FAQ）
料金計算システムの発注では、費用だけでなく、契約、移行、運用、セキュリティを同時に確認する必要があります。
ここでは、発注担当者から特に多い質問へ直接回答します。
料金計算システムの外注費用はいくらですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
小規模の導入・開発で500万〜1,500万円程度、中規模で2,000万〜6,000万円程度、大規模刷新で6,000万円から数億円程度が初期検討の目安です。
ただし、公開された固定価格ではなく、料金ルール、イベント量、連携数、移行、性能、セキュリティ、24時間運用の有無で変動します。
見積は初期費用だけでなく、3年程度の保守・クラウド・追加改修を含めて比較します。
パッケージとスクラッチ開発はどちらが適していますか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
料金ルールが標準的で、早期導入と保守性を優先する場合はパッケージやクラウドが適しています。
特殊な割引、法人個別単価、ネットワークや既存基幹との密接な連携が競争力に直結する場合は、スクラッチまたはハイブリッドを検討します。
判断する際は、製品説明を聞くだけでなく、実際の複雑な料金ケースを登録から請求・返金まで通し、変更のしやすさとデータの持ち出しやすさを確認します。
RFPに最低限書くべき項目は何ですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
事業背景と目的、対象業務、現行システム、料金ルール、加入者・契約・利用実績のデータ、イベント量、連携先、機能範囲、非機能要件、移行範囲、受入テスト。
運用保守、セキュリティ、希望スケジュール、予算条件を記載します。
特に、月額・従量・無料枠・日割り・割引・返金・再計算を含む代表的な計算例を、期待結果付きで添付すると、会社ごとの提案と見積を比較しやすくなります。
請負契約だけで料金計算システムを発注できますか？
発注できますが、料金ルールと受入条件が固まっていることが前提です。現行業務の整理やPoCまで請負に含めると、
仕様変更の責任や追加費用の判断が難しくなるため、要件定義は準委任、本開発は請負と分ける方法が適しています。
契約形態よりも、成果物、責任分界、変更手順、検収、保守、障害対応を具体的に記載することが重要です。
まとめ
発注前に料金業務と責任分担を確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
料金計算システムの発注・外注を成功させるポイントは、料金計算だけを切り出さず、契約、利用実績、請求、決済、会計、移行。運用までを一つの業務フローとして整理することです。
RFPには、料金ルールの適用順序、データ量、連携先、性能、受入テスト、セキュリティ、保守、除外事項を記載し、複数社へ同じ条件で提案と見積を依頼します。
同じ計算ケースで見積を比較してから発注します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
費用は、小規模で500万〜1,500万円程度、中規模で2,000万〜6,000万円程度、大規模で6,000万円から数億円程度が初期検討の目安ですが。正式な金額は要件と責任分担で決まります。
まずは料金ルール表と代表的な計算例を作成し、準委任で要件整理やPoCを行い、仕様が固まった範囲を請負で開発する進め方が、発注リスクを抑えやすいです。
委託先を選ぶ際は、通信課金や請求の実績、複雑な料金ケースのデモ、移行と並行稼働の計画、料金改定後の運用支援、データとソースコードの扱いまで確認します。
自社の業務担当者、経理、顧客サポート、ネットワーク、法務、セキュリティを早い段階から巻き込み、発注後に「その条件は聞いていない」という状態を防ぐことが大切です。
▼全体ガイドの記事
・料金計算システム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。