BSSは、顧客・契約の管理、注文から開通までの連携、利用量に応じた課金を一体で設計することで、通信事業の販売から回収までを支えるシステム群です。
機能と方式、開発の進め方、費用、発注先の選び方、セキュリティを順に取り上げます。各テーマの詳細は、関連記事もあわせてご覧ください。
▼関連記事一覧
・BSS開発の進め方
・BSS開発でおすすめの開発会社6選と選び方
・BSS開発の見積相場・費用
・BSS開発の発注・外注・委託方法
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
BSSの役割とOSSとの境界
BSSは、通信サービスの販売や契約、利用量の計算を支え、請求と回収までを担う顧客・事業側のシステム群です。また、通信サービスは、BSSとネットワーク設備や開通、障害、リソースを扱うOSSの連携で成り立ちます。そのため、両者の境界を先に定めておくと、要件の漏れや重複開発を防ぎやすくなります。
BSSとOSSの違い
BSSは、顧客や契約、料金を管理する役割を持ちます。注文や請求、売上も含め、事業と顧客接点を担当するシステムです。
一方でOSSは、回線やネットワーク機器の状態を扱い、開通作業や障害対応も担います。番号や帯域などのリソースも、OSSが扱う対象です。
たとえば回線申込では、BSSが注文を受けて契約と料金を確定し、OSSに開通を依頼します。その後、OSSの開通結果が顧客通知や請求開始に反映されます。
BSSが必要になる理由
料金プランや割引、オプション、最低利用期間の組み合わせは増えやすく、そこに従量課金や日割りも重なります。さらに税や返金まで含めると、手作業や個別システムの寄せ集めでは、請求の精度を保ちにくくなります。
BSSは商品と料金ルールを管理し、申込から利用イベント、決済、会計までを一連の業務として扱います。その結果、新料金の投入や契約変更、問い合わせ対応、売上の把握を速く進められます。
BSSの主要機能と全体構成
BSSの機能は、顧客接点や業務処理を担う層から、課金・収益管理、外部連携の層まで、4層で整理できます。機能の洗い出しに加えて、データの作成者や確定状態、失敗時の再処理担当まで確かめる必要があります。
顧客・契約・商品カタログの管理
BSSでは、顧客、契約、商品カタログの3つを管理します。
- 顧客情報：個人・法人情報、請求先、本人確認、与信、問い合わせ履歴、契約回線の管理
- 契約情報：契約期間、利用中サービス、変更履歴、解約日、端末・回線との関係の追跡
- 商品カタログ：プラン、容量、オプション、割引、キャンペーン、SLA、最低利用期間、従量単価の表現
見積・注文・開通の連携
法人向けの見積は、拠点数や帯域、オプションを組み合わせて作ります。契約期間や割引、SLAも加わります。サービスが複雑になるほど、見積、構成、価格計算を担うCPQの役割が大きくなります。
注文管理は、申込や変更、解約の受付に加えて、番号移行や開通依頼も扱います。その状態をOSSに連携するほか、在庫、決済、顧客通知へも伝えます。
注文の状態は「受付」「審査中」「開通待ち」「利用中」「取消」「失敗」などと定めておきます。これにより、二重処理や放置された注文を見つけやすくなります。
利用量・課金・請求・回収の処理
課金から顧客接点までの処理では、利用データや請求条件、連携先の整合性を保つ必要があります。この節には、課金・請求の処理のほか、チャネル連携とAI利用の項目も含めます。
- 利用データと料金計算：通話、通信量、SMS、IoTイベントを取り込み、形式をそろえたうえで、リアルタイムまたはバッチで計算
- 請求・回収：締め日、日割り、税、割引、返金、再請求、未収、督促、カード・口座決済、パートナー精算の扱い
- イベント品質：通信量が多い場合の取りこぼし、重複、遅延、再送の検知と、冪等性による二重課金の防止
- チャネル・データ連携：Web、アプリ、店舗、コールセンター、代理店、外部APIをつなぎ、残容量・請求予定額・契約状態・売上の一致
- AI利用：問い合わせ支援や料金提案での、参照データの範囲と承認者の設定
チャネル間で情報をそろえるために、マスタとデータの確定時点も決めておきます。
BSSの種類と開発方式の選び方
現実的なのは、標準機能と追加開発を組み合わせ、既存システムを段階的に置き換える進め方です。適切な方式は、事業規模や料金の複雑さによって変わるほか、既存データの品質や停止可能時間にも左右されます。
パッケージ・SaaSを使うケース
標準的な業務が多く、早期の立ち上げと運用負荷の軽減を優先するのであれば、パッケージやSaaSが候補になります。選ぶ前には、料金や商品を設定で増やせるか、APIの意味とバージョンが公開されているかを確かめます。あわせて、利用量に応じて料金がどう増えるかも見ておく必要があります。
標準に合わせれば初期開発を抑えやすい一方で、独自要件を無理に組み込むと、追加費用や運用の複雑化につながります。
クラウドネイティブ・API中心で作るケース
新ブランドやMVNO、IoT通信、法人向けネットワークでは、サービスを早く投入することや外部連携が重視されます。そのような場合は、クラウドネイティブ構成が適しています。
機能を小さなサービスに分けてAPIとイベントでつなぐと、カタログやCPQの部分だけを先に交換できます。一方で、監視や障害時の再処理、データ整合性、バージョン管理は難しくなります。そのため、分割そのものを目的にはしません。
スクラッチ開発を選ぶケース
独自料金やパートナー精算、業界固有の契約、特殊なネットワーク連携が、競争力に直結する場合があります。そのようなときは、対象領域だけをスクラッチで作る方法があります。
全機能を一から作ると、自社で担う範囲が広がります。請求精度や法改正への対応、決済、監査に加えて、24時間運用や保守人材まで含まれます。そこで、標準化できる機能は既製品に寄せ、開発資源は差別化の部分に集中させます。
BSS開発の7段階の進め方
業務とデータを整理して小さく検証し、請求と開通の品質を確かめながら広げていく方法が安全です。全機能を一斉に切り替えるビッグバン方式では、原因の究明が難しくなり、請求の停止や顧客への影響も大きくなります。
1. 現状診断と目的設定、2. 業務・データ要件の定義
最初の2段階では、現状を整理して目的を定め、必要なデータと、その責任者を決めます。
- 現状把握：事業規模、業務状況、既存システムの確認
- 目的設定：改善目標の、具体的な数値による設定
- データ設計：必要なデータモデルと状態遷移の定義
- 責任分担：標準・独自ルールと各データの責任者の決定
まずは、加入者数やピーク時の注文数、利用イベント数を洗い出します。料金計算の締め時刻や請求誤り、商品投入の日数、障害復旧の目標も対象になります。また、既存のOSSやCRM、会計、決済も確認します。
目的は、「BSSを刷新する」と掲げるだけで終わらせず、「新料金を2週間以内に投入する」「注文から開通までの失敗率を下げる」「請求確定後の訂正を減らす」のように、数値の形にそろえておくことが大切です。
商品、顧客、契約のデータモデルと状態遷移を定義します。サービスやリソース、注文も対象になります。さらに、利用イベントから請求、支払、返金、精算までの流れも定義します。
標準APIや業界共通モデルに寄せる部分と、自社固有のルールは分けて扱います。そのうえで、データの作成者や所有者、確定者を明確にしておく必要があります。
これらが曖昧なまま製品を比べると、デモ画面の印象だけで選んでしまいがちです。
3. 優先領域の選定、4. PoC、5. 方式決定
優先領域を選び、PoCで本番条件を検証してから方式を決めます。
- 優先領域：収益効果か業務上のボトルネックかを基準にした選定
- PoC：本番運用で問題となる条件の検証
- 方式決定：検証結果に合わせた方式の組み合わせ
料金カタログやCPQ、リアルタイム課金、法人注文の中から対象を選びます。実データは匿名化しておく必要があります。
料金ルールの変更やピーク負荷、APIエラーを検証し、監査ログや障害時の再処理も確かめます。PoCは、本番で困る条件を短期間に見つけるための場です。
評価後は、標準BSSやSaaSに、クラウドネイティブや既存拡張、対象領域のスクラッチを組み合わせます。
計画上の目安として、単一モジュールの交換は数か月、新ブランドや小規模事業者の導入は6〜18か月です。段階移行は1〜3年、全面刷新は数年が目安です。
期間は、データ移行件数とテスト環境の有無で大きく変わります。
6. 段階移行と突合、7. 運用移管と改善
切替対象を絞って旧新システムを並行稼働させ、突合後に運用を移管します。
- 新カタログや新ブランド、特定法人サービスなどから切り替えるストラングラーパターンで、旧新システムを一定期間並行稼働させる
- 請求や開通に関わる項目の、本番相当データによる突合
- 責任分界と運用手順の明文化
- リリース後の商品投入時間、請求訂正率、注文失敗率、再処理件数、障害復旧時間の測定
請求額や税、割引、日割りに加えて、返金、締め処理、再請求、MNP、開通失敗、障害復旧も、本番相当データで突合します。
切替・ロールバックの条件と、計算差異が出た場合に正とする側も、決めておく必要があります。
サービス、課金、データ、セキュリティ、開発・保守について、どこまでを誰が受け持つかを明文化します。
監視やバックアップ、災害復旧、脆弱性対応に加えて、問い合わせや料金ルールの承認、終了時のデータ返却も、運用手順に含めます。
▶ 詳細はこちら：BSS開発の進め方
BSS開発の費用相場とコストの内訳
BSS専用の国内一律価格表は公開されていません。そのため、基幹システムの公開費用目安に、通信特有の課金・移行・高可用性の要件を組み合わせた、2026年時点の計画用レンジを示します。
実際の見積額は、加入者数やピークイベント数、料金ルール、連携数、データ品質、24時間運用の条件によって大きく変わります。また、請求事故を防ぐ品質保証も、費用比較の対象に含めます。
スコープ別の初期費用レンジ
対象範囲と事業規模ごとの初期費用は、次の計画レンジが目安です。
- 調査・PoC、料金計算やカタログ検証：500万〜2,000万円
- 既存BSSの単一モジュール追加・交換：1,000万〜8,000万円
- MVNO・小〜中規模ISPのクラウドBSS：顧客・契約・課金・決済・会計・ネットワーク連携を含む場合、3,000万〜1.5億円
- 中堅事業者の複数チャネル・大規模移行：1億〜5億円程度
- 大手の複数ブランド・加入者基盤・旧新並行・全国運用・段階切替：5億〜30億円超
全面フルスクラッチやレガシーBSSの完全刷新では、10億〜数十億円以上に達することもあります。これらは規模と作業範囲から作った推定であり、製品の販売価格ではありません。
予算策定では、対象モジュールと移行単位を分けて、複数の概算を取ります。
見落としやすいコストの内訳
BSSの費用は導入作業に加え、試験、運用、クラウド利用などにも発生します。
- 導入費：要件定義・業務設計、ライセンスまたはSaaS、実装、API・ETL・OSS連携、データ整備・移行が含まれます。
- 品質・運用費：性能・請求精度試験、セキュリティ、教育、並行稼働、運用設計、保守も対象です。
- 基幹システムの参考値：人月単価は50万〜200万円程度、保守費は開発費の15〜20％／年とされる場合があります。
- BSS運用費：24時間監視、障害時の再処理、環境数、DR、サポート範囲で増減します（出典: 公開されている基幹システム費用目安、2026年）。
- クラウド継続費：利用量課金、ログ、監視、バックアップ、災害復旧、転送、検証環境、サポート契約が発生します。
初期費用が低くても、3〜5年のTCOで見ると印象が変わる場合があります。そのため、製品や追加開発、移行、運用、契約終了時の移行費を分けて見積もります。
▶ 詳細はこちら：BSS開発の見積相場・費用
BSSの見積もりを取る際のポイント
開発規模を判断するには、加入者数に加えて、ピーク注文・利用イベント数や料金ルール数も見る必要があります。請求頻度、外部連携、過去データの件数と品質、許容停止時間、監査期間もRFPに記載し、提案条件をそろえます。
要件と前提条件の数値化
RFPには、現在と将来の加入者数や、秒あたりの注文数、1日あたりの利用イベント数を記載します。さらに、料金プランや割引の種類、請求締め日、ピーク時間も書き添えます。
対応チャネルや連携先、移行件数、目標の復旧時間と時点も明記します。機能一覧に加え、受入基準も必要になります。たとえば、請求確定後の訂正を何分以内に検知し、再処理できるかを基準として設けます。
複数見積の5年TCO比較
初期開発費に加えて、ライセンスやクラウド、保守、追加変更の費用を、5年TCOに並べます。教育や移行、並行稼働、障害対応、契約終了時の返却までを含めて比べます。
標準機能に業務を合わせる提案と、独自開発の多い提案とでは、初期費用と将来の変更費用のバランスが異なります。また、料金プランの年間変更回数も、方式を選ぶ際の比較の観点になります。
追加費用が発生する条件
データが想定より汚れていたり、既存APIの仕様が不明だったり、請求テストのケースが増えたりすると、追加費用につながります。
契約前には、データ品質の調査や連携仕様の確定方法、料金ルールの追加単価、性能試験の再実施、環境追加費、要件変更の承認手順を確かめておく必要があります。除外事項をはっきりさせておくと、予算超過の兆候を早く把握できます。
BSS開発会社・サービスの選び方
知名度よりも、通信課金の実績や同規模の加入者基盤、移行力、24時間運用、障害時の責任の分け方を確認します。製品事業者や導入支援のSI事業者、クラウド運用事業者では、得意領域が異なります。
そのうえで、自社に足りない能力を補えるかを比べます。
通信・課金・移行の類似実績
実績は、社名や件数だけで見るのではなく、加入者規模や料金ルール、ピーク負荷、移行件数で判断します。旧新並行の期間や請求精度の検証方法も、判断材料になります。
匿名化した画面やテスト結果、障害報告例、顧客紹介の可否を尋ねると、運用力を確かめられます。成功事例の効果指標は自己申告の場合もあるため、自社のPoCで再現性を見ておきます。
標準API・データモデル・保守体制
標準APIに準拠しているかだけでなく、APIの意味やエラー形式、再送、冪等性を確認します。バージョンアップの方法やデータの所有者、サポート範囲も対象になります。
商品カタログから請求までのデータが分断されていないかを見ます。契約終了時に設定や履歴、ログを返却できるかどうかも大切です。
国内窓口や夜間休日対応、脆弱性パッチの期限、再委託先の管理も、選定表に加えます。
5年TCOと責任の分け方の比較
選定表では、機能の適合や、通信・MVNO・ISPの実績、課金精度を比べます。締め処理やカタログ変更の速さも、比べる項目になります。
APIや移行品質、国内サポートに加えて、SLAや障害責任、5年TCO、終了時の移行性も確認します。BSS、OSS、決済、会計、ネットワーク、問い合わせの境界ごとに、提案者の責任範囲を図にしてもらうと、後で責任を押し付け合う場面を減らせます。
▶ 詳細はこちら：BSS開発でおすすめの開発会社6選と選び方
BSS開発の発注・外注・委託で決める項目
外注する場合も、発注側が目的や業務ルールを決める必要があります。データの所有権や受入基準、運用責任者も、発注側が決めます。
丸投げにすると、業務知識が提案者に偏り、契約終了時に設定や移行手順を取り出せないおそれがあります。発注側にも事業責任者と課金責任者を置き、意思決定が止まらない体制にします。
RFPで確認する項目
RFPには、目的KPIや対象モジュール、加入者数、ピークイベント、移行範囲、外部連携を指定します。テスト環境や切替方式、SLA、サポート時間、納品物、追加費用の条件も、盛り込んでおく必要があります。
提案書に加えて、同規模の事例や、要件追加時の見積ルール、障害時の連絡経路、再処理の設計、契約終了時の出口計画も、提出してもらいます。
受入基準と障害時の責任の契約への記載
受入テストでは、画面表示の確認に加えて、料金計算、割引、日割りといった業務の計算を検証する必要があります。そのうえで、次の項目も本番相当データで確認します。
- 請求額の計算：税の計算、返金、再請求の結果を確かめる
- イベントの処理：遅延・重複イベントの扱いを確かめる
- 番号移行と開通：MNPと開通失敗時の処理
- 締めと障害対応：締め処理と障害復旧
誤請求を何時間以内に検知・訂正するか、課金イベントをどう再処理して二重請求を防ぐかを、機能要件とSLAの両方に記載します。
ベンダーロックインと出口戦略の防止
ソースコードだけでなく、設定や商品カタログ、料金ルールの帰属と返却方法も定めます。契約終了時にこれらを取り出せるかどうかが分かれ目になるため、次の項目も契約で扱いを決めておきます。
- データとAPI：データモデル、API仕様
- 監査と運用：監査ログ、運用手順
- テストと復旧：テスト、バックアップ
- 引き継ぎ：移行支援の扱い
再委託先や国外クラウドの所在、監査権、脆弱性対応、終了後のデータ消去も確認します。標準APIや文書化したデータ形式を使い、担当者しか分からない運用を残さないことが、出口戦略になります。
▶ 詳細はこちら：BSS開発の発注・外注・委託方法
BSSのセキュリティと2026年の最新動向
BSSは、次の情報を扱います。
- 顧客情報：氏名、連絡先、本人確認
- 業務データ：契約、請求、決済、利用履歴
通信の秘密や個人情報、委託先、国外クラウド、監査、災害復旧も、設計の対象になります。
機能の追加やAI活用を急ぐ場合ほど、目的外の利用や過剰な権限を防ぐ仕組みを先に用意します。
個人情報・請求・運用の一体的な保護
設計書とRFPには、データ分類や最小権限、特権ID、職務分離を記載します。さらに、保存時と通信時の暗号化、鍵管理、API認証、レート制限、再送防止も含めます。
このほか、料金変更や請求確定の改ざん防止ログ、脆弱性パッチの期限、バックアップ、復旧目標、漏えい時の連絡手順も、定める内容に含まれます。
電気通信分野の個人情報ガイドラインには、2026年にも解説の改正履歴が掲載されています。公開時点の最新版を確認し、要件に反映します（出典: 個人情報保護委員会「特定分野ガイドライン」、2026年）。
AI・標準API・クラウドネイティブの動向
2026年の技術動向と公開事例からは、標準化とAI活用の進展、適用範囲の見極めが読み取れます。
- 業界動向：通信業界でのAIとクラウドネイティブ化の進展
- CPQ事例：海外事業者が法人向けCPQを40超のクラウドネイティブなマイクロサービスに分け、8か月で本番化したと報告された事例
- 移行手法：既存コードから業務ルールを抽出した事例。
- 適用範囲：事例の対象はCPQに限られ、BSS全体を同じ期間で刷新できる根拠にはならない点
- AIの管理：利用範囲と、人による承認・監査の手順の設定
この事例では、API標準化や段階移行、400件超の回帰テストも組み合わせています（出典: 通信向けクラウド移行の公開事例、2026年）。
共通APIや統合データ、AIエージェント、意図に基づく自動化も、進みつつあります。2026年6月のレポートは、OSS・BSSをまたぐリアルタイム判断と共有APIの重要性を示しています（出典: TM Forum公開レポート、2026年）。
AIをBSSに追加すれば課題が解消するとは限りません。データ定義が不統一だと誤った提案や請求判断につながるため、AIの操作範囲、承認処理、参照できる顧客情報を決めます。
操作ログや、人が誤りを止める手順も必要です。そのうえで、データ品質と、どこまでを誰が受け持つかを明確にします。
5G・IoT・API課金への対応
5G、IoT、法人ネットワークでは、通信量のほかに接続時間やイベント数、品質などを料金に反映する場面が増えます。帯域やSLA、API利用、パートナーとの収益分配も、対象になります。
BSSにはリアルタイムまたは準リアルタイム課金、品質連動請求、パートナー精算、利用上限通知が必要です。商品カタログと料金ルールを柔軟にすると、新しい収益モデルに対応しやすくなります。
よくある質問（FAQ）
BSSは対象範囲が広いため、自社に必要な機能と導入規模を切り分けて考える必要があります。初期検討でよくある疑問に答えます。
小規模なMVNOやISPでもBSS開発は必要ですか？
必要ですが、全機能を最初から導入する必要はありません。申込や顧客・契約、料金計算、決済など、収益と業務負荷に直結する範囲から始められます。
会計や高度分析は既存サービスと連携する方法もあります。単一モジュールやPoCは500万〜2,000万円程度の計画レンジから検討できる場合がありますが、金額は連携と移行で変わります。
BSSとOSSは別々に開発しても問題ありませんか？
別チームや別製品で開発できますが、注文や開通、利用量、請求の境界は、共通のデータモデルとAPIで定義しておきます。
誰がどこまで受け持つか、エラーや再送、状態遷移、監査ログが曖昧だと、OSSで開通が済んでも、BSSが請求を始められず、顧客への通知もできないことがあります。システムを分けることと、業務を分断することは別の話です。
BSS開発にはどのくらいの期間がかかりますか？
単一モジュール追加・交換は3〜9か月、MVNOや小〜中規模ISPのクラウド導入は6〜18か月、中堅事業者の複数連携・移行は12〜30か月が目安です。
大規模な段階的モダナイゼーションは2〜5年、全面刷新は3〜7年となることがあります。データ品質や請求の並行突合、テスト環境、切替可能範囲は、早い段階で確認します。
BSSにAIを導入すれば開発費を下げられますか？
データマッピングや問い合わせ支援、料金提案、異常検知で作業を減らせる可能性はあります。ただし、導入だけで費用が下がるとは限りません。
誤った料金判断を防ぐための承認や、参照データの管理、操作ログ、監査、権限設計も必要です。そのうえで、正規化した顧客・商品・注文・課金イベントを整え、限定した業務で効果とリスクを検証します。
まとめ
BSSは、通信事業の中核となるシステム群です。顧客や契約、商品を管理しながら、次の業務を一連の流れでつなぎます。
- 注文：申込や変更、解約の受付と、開通の依頼
- 利用量と課金：通話や通信量などの利用データから料金を計算
- 請求と回収：締め処理から、未収の督促まで
OSSや会計、決済、CRMとの連携を前提に、業務の状態とデータの責任の分け方を設計します。
自社に合うBSS開発を始めるための要点
検討の初期に範囲と移行条件を定め、費用とパートナーを比べながら、段階的に進めます。
- 最初の90日：全刷新を前提にせず、現状診断、データモデル、優先モジュール、PoC、概算費用、切替条件の決定
- 費用比較：初期費用と運用費用、それぞれの金額の違い
- パートナー選定：通信課金実績、標準API、移行、請求精度、24時間運用、責任の分け方、セキュリティ、終了時の出口戦略の確認
- 段階的な刷新：AI・クラウドネイティブ化は、データ品質と人の承認を整えたうえで進めます。課題を一つの収益・業務単位に絞り、検証可能な部分から始めます。
費用はPoCで500万〜2,000万円、単一モジュールで1,000万〜8,000万円、全体刷新で数億円以上と幅があります。加入者規模だけでなく、料金ルールや取引量、移行、試験、運用を含めた3〜5年TCOで比べます。
▼関連記事一覧
・BSS開発の進め方
・BSS開発でおすすめの開発会社6選と選び方
・BSS開発の見積相場・費用
・BSS開発の発注・外注・委託方法
▼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を創業。