BSS開発の進め方/やり方/流れや方法/手法/工程/手順

BSS開発は、現状診断と目的の設定から始め、業務・データ・連携の要件を定義します。そのうえで、優先する領域をPoCで試し、段階的に移行して運用へ引き継ぎます。

この順に進めると、請求精度と運用の安定につながります。

▼全体ガイドの記事
・BSS開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

BSS開発の全体像

BSSはBusiness Support Systemの略称です。通信サービスの企画や販売、請求などを担う、顧客・事業側の中核システム群を指し、利用量の計測や収益管理も含まれます。

BSSは単一のアプリケーションの場合もありますが、実務では複数の機能と周辺システムとの連携まで含めて考えます。まず、BSSとOSSの境界と、申込みから請求までの流れを把握します。

BSSとOSSの役割の違い

申込後の開通から請求までを追うと、BSSとOSSの役割分担が見えてきます。

• BSS：顧客、契約、料金、注文、利用実績、請求、決済、売上を扱い、事業の運営を担います。
• OSS：設備監視、回線・リソース管理、開通、障害対応など、技術面の仕事を受け持ちます。
• 連携の流れ：BSSが注文を渡し、OSSが回線を設定したあと、BSSが利用量を課金します。

連携の責任範囲が曖昧だと、申込後に開通しない、開通後に料金が出ない、解約後も請求が続くといった問題が起きます。そこで、RFPにはBSS、OSS、CRM、決済、会計の責任分界とデータの所有者を記します。

BSSの主な機能

通信事業者のBSSは、販売から利用量の請求までの業務を支えます。その機能は、販売から請求までの流れに沿って、4つのまとまりに分かれます。

• 商品・販売：商品カタログ、料金プラン、見積、販売の管理。
• 契約・注文：顧客契約と注文の受付、進捗の管理を担います。
• 利用量・課金：利用量収集、メディエーション、チャージングを受け持つ機能です。
• 請求・顧客接点：請求、決済、債権管理、セルフサービスとオムニチャネルを扱います。

個人向けの通信では、申込と本人確認、MNPの手続きが重視されます。割引や日割り、解約の扱いも欠かせません。

一方で、法人向けでは構成見積と承認、SLAを押さえる必要があります。加えて、拠点別の利用量やパートナー精算も求められます。

IoTでは大量のイベントを取り込み、回線単位やデバイス単位で従量課金します。MVNOの申込・契約・課金追加と、大手事業者の複数ブランド刷新とでは、規模も期間も異なります。

標準機能で共通化できる部分と、競争力に直結する料金・精算・注文ルールを分けて考えると、過剰なフルスクラッチを避けやすくなります。

BSS開発の進め方と段階

BSS開発は、現状診断と目的の設定、業務・データ・連携の要件定義、優先領域のPoCの順に進みます。全体は、方式選定、段階移行、運用移管までの7段階です。最初の90日では、刷新する範囲と対象外を決めておきます。

要件定義・企画フェーズでの現状と目的の把握

最初に、業務量と品質を把握するため、次の現状データを一覧にします。

• 規模と負荷：加入者数、契約数、ピーク申込件数、利用イベント数。
• 商品と請求：商品数、料金ルール、請求締め時刻、現在の請求誤り。
• 運用と成果：障害件数、商品投入までの日数。

業務の詰まりは、構成図ではなく、実際の処理の流れから見つけます。申込、審査、開通の順に、担当者と一緒にたどります。さらに、利用から返金までも続けて確認します。

「古いBSSを新しくする」という目的では、成果を確かめられません。そこで、新料金投入を8週間から2週間に短縮する、初回開通失敗率を下げる、月次請求を午前中に確定するなど、測れるKPIに置き換えます。

目的によって、優先する領域は変わります。たとえば、新商品の投入が課題なら商品カタログとCPQを、請求誤りが課題なら利用量・課金・請求の突合を先に進めます。

業務・データ・API要件の定義

データとAPIの要件では、意味や責任範囲がずれないよう、次の点をそろえておきます。

• データ：顧客から精算までの項目と、その状態遷移の定義。
• 注文状態：受付から再処理までの状態をそろえること。
• API運用：エラー時の再送、冪等性、タイムアウト、版、監査ログ、責任分界の決め方。

対象データは、顧客、契約、商品、サービス、回線、注文です。利用イベント、請求、支払、返金、精算も含みます。契約開始日、開通日、課金開始日は、システムによって意味が異なる場合があります。

項目名に加えて、更新者と更新時期、履歴の保持期間、訂正方法も決めておきます。注文状態は、受付から開通済みまでの各段階と、取消、失敗、再処理を定義します。

TM Forum Open APIやSIDに沿った部分を使うと、製品の入れ替えや他社との連携に備えられます。ただし、標準APIへの準拠は、統合が完了したことを示すものではありません。そこで、実際の項目、エラーコード、サポート範囲、変更通知のルールを、サンプルデータで検証します。

小さく進めるPoC・設計・開発・テスト

効果が大きく、境界の明確な領域を選んだうえで、PoC、設計・開発、テストの順に小さく進めます。

1. PoC：料金計算、商品カタログ、法人向け見積、注文連携などから一領域を選びます。
2. 設計・開発：標準BSS・SaaS、APIや設定による拡張、独自マイクロサービスに分けて考えます。
3. テスト：正常系と例外系を確認し、料金結果を旧システムと突き合わせます。

PoCでは、画面の見た目より、料金変更や取消、返金といった処理の正しさを確かめます。あわせて、利用イベントの遅延や重複、再処理、監査ログ、ピーク負荷も見ます。そのうえで、匿名化した実データを本番に近いイベント量で試し、性能とデータ品質の問題を早く見つけます。

全機能をスクラッチで作ると自由度は高まります。ただし、課金例外や税、日割り、締め、再請求、障害復旧までを自社で保守することになります。そのため、一般機能は標準に合わせ、固有の料金や精算を拡張するのが現実的です。

テストには、MNP取消、開通失敗、月途中のプラン変更、割引の重複を含めます。さらに、タイムゾーンをまたぐ利用、利用量の遅延、決済失敗、返金、再請求、請求確定後の訂正も対象にします。

請求額は、明細単位で旧システムと突き合わせ、差額の原因を追える状態にしておきます。受入基準には、検知時間と訂正担当、二重請求を防ぐ再処理の方法も定めます。

段階移行・旧新突合・運用移管

切替の前に、差異を見つける方法と復旧の条件まで決めておくと、移行後の請求事故を防げます。

1. 段階移行：商品、ブランド、顧客セグメント、地域を順に切り替えます。
2. 旧新突合：並行稼働中に契約数、開通数、利用量、請求額、未収額を日次で照合します。
3. 切替判断：条件、停止判断者、ロールバック方法、顧客案内を事前に決めます。

EricssonはIndosat Ooredoo Hutchisonの事例を公開しています。初期段階で800万のポストペイド加入者、次段階で8,300万のプリペイド加入者を移行しました（出典：Ericsson「Indosat Ooredoo Hutchison: BSS transformation for digital future enablement」、2025年公開事例）。

同事例では、移行後の重大インシデントをゼロに抑えました。ただし、大規模な体制と段階管理を伴う特定の事例のため、同じ成果を前提にせず、自社の切替単位や障害時の責任者を計画します。

運用移管では、サービスオーナー、課金・データ責任者、セキュリティ担当、開発会社、クラウド事業者の責任分界を文書にします。そのうえで、監視やアラート、脆弱性対応、バックアップ、DR、障害時の再処理の手順を決めます。

さらに、月次請求の締め作業、商品登録の承認、契約終了時のデータ返却も、手順に含めます。本番稼働の完了条件は、開発の完了ではなく、自社の担当者が安全に料金を変更できる状態とします。

BSS開発の費用相場とコストの内訳

BSSの国内一律の価格表は公開されていません。ここで示すのは、2026年時点で予算計画に使う概算のレンジで、実見積ではありません。

金額は、加入者数、ピーク課金イベント、料金ルールによって大きく変わります。ほかにも、次の要素が影響します。

• モジュール数：対象とするモジュールの数で、開発の範囲が変わります。
• 外部システムとの連携：OSS、CRM、会計、決済とつなぐ範囲の広さ。
• データ移行：移行するデータの品質。
• 運用条件：24時間運用の要件の有無。

小規模な機能追加と大手通信事業者の全面刷新は、同じ相場として扱わないようにします。

スコープ別の初期費用と期間の目安

BSSは、対象のモジュールと移行の規模によって必要な投資や期間が異なるため、スコープごとに計画します。

• 調査・PoC：500万円から2,000万円程度、1〜3か月。
• 単一モジュール：1,000万円から8,000万円程度、3〜9か月。
• MVNO・小〜中規模ISP：3,000万円から1億5,000万円程度、6〜18か月。
• 中堅事業者：1億円から5億円程度、12〜30か月。
• 大手事業者：段階刷新は5億円から30億円超、2〜5年。全面刷新は10億円から数十億円以上、3〜7年。

単一モジュールの場合、カタログ、CPQ、注文、請求のうち一領域が対象になります。このレンジは、既存のAPIとテスト環境が整っていることを前提にしています。

クラウドBSSで顧客・契約・課金・決済・会計・ネットワークを連携させると、データとテストの比重が高まります。また、中堅事業者では、複数ブランドや複数の料金体系、旧新並行、移行リハーサルが費用の上振れ要因になります。

これはBSS専用の価格ではなく、基幹システムの相場に通信特有の要素を加えた推定です。課金、連携、高可用性を加味しています。

riplaの解説でも、基幹システムの費用には幅があります。方法や規模により数十万円から数億円までとされています（出典：株式会社ripla「基幹システム開発の見積相場や費用／コスト／値段について」、2026年確認）。

初期費用以外に発生するコスト

初期費用の範囲を見極めるには、見積もりの項目を工程と運用に分けて把握します。

• 導入作業：要件定義、業務設計、環境構築、設定・カスタマイズ。
• 連携と移行：製品ライセンス・SaaS利用料、API・ETL・OSS連携、データクレンジングと移行。
• 稼働準備：性能・請求精度・セキュリティテスト、教育、並行稼働。
• 継続運用：運用設計、保守、切替支援、障害対応、問い合わせ窓口。

ライセンス費と開発費だけで見積もられている場合は、移行リハーサル、旧新突合、切替支援が別料金かどうかを確かめます。

クラウド費用には、環境数、ピーク時の計算資源、ログ保存、監視、バックアップ、DRが加わります。さらに、転送、サポート、セキュリティ監査、外部決済の従量料金も含まれます。

保守費は、年額の計画目安として、開発費の15〜20％程度とすることがあります。BSSでは、24時間監視や料金改定、法令対応、OSやミドルウェアの更新があるため、費用は契約内容によって変わります。

Infosysは米国通信事業者のCPQを、40超のクラウドネイティブなマイクロサービスへ移行しました。8か月で本番化した事例です（出典：Infosys「US Telco Modernizes BSS CPQ with Cloud Native Microservices」、2026年掲載）。

同事例では、年間TCOを200万ドル削減したとしています。ただし、既存製品のライセンス・サポート費が大きい案件のため、自社ではライセンス、保守、障害対応、商品追加の工数から効果を試算します。

BSSの見積もりを取る際のポイント

見積もりは金額だけでなく、算出の条件をそろえて比べます。前提が違う場合は、安く見える見積もりが対象範囲を狭めているだけのこともあります。

まず、加入者数、ピーク時の注文・課金イベント、商品数を、各社に同じ条件で提示してもらいます。残りの条件も、次のとおりそろえます。

• 料金ルール：料金の計算方法の前提。
• 連携先：接続する既存システムの範囲。
• 移行件数：移行対象となるデータの件数。

目標稼働率、復旧時間、データ保存期間、サポート時間も、同じ条件にそろえます。

要件定義とRFPに入れる項目

RFPには、現在と将来の加入者数などの条件を、次の観点で書き込みます。各社の見積もりを同じ前提で比べるためです。

• 処理規模：加入者・契約・回線数、秒あたりピークイベント、日次・月次利用量。
• 料金と範囲：プラン・割引数、締め時刻、訂正件数、MNP・返金、対象機能。
• 非機能：応答時間、遅延、復旧時間・時点、監視、ログ保存期間、バックアップ頻度。
• 切替と請求：停止時間、脆弱性対応期限、日割り、税、割引、締め、再請求、取消、返金、未収、精算。

顧客・契約・商品・注文・利用量の対象範囲と、請求・決済・会計の対象も明記します。既存システムを残すか対象外にするかも示します。非機能要件は「高性能」「高可用性」ではなく、目標値や対応期限を数値で示します。

複数社を比べる観点と発注先の選び方

候補会社は、価格や知名度だけでなく、案件への適合性で比べます。通信やMVNO、ISPでの類似の加入者数や担当モジュールも、あわせて確かめます。

• 製品と技術：課金精度、商品変更速度、TM Forum Open APIやデータモデルへの対応。
• 移行と支援：移行実績、国内24時間サポート、障害時の責任分界。
• 契約と継続性：5年TCO、契約終了時の移行性。

大手向けのフルスイートに強い会社と、既存基幹との連携や段階移行に強い会社とでは、向いている案件が異なります。

提案を受ける際は、同規模の匿名事例や請求テスト、移行リハーサル、追加費用の条件を確かめます。成功事例のKPIは自己申告のことも多いため、測定の期間や範囲、指標を尋ねます。

有償または小規模のPoCで、料金変更やAPIエラー、再処理、監査ログを試すと、提案書だけでは分からない適合度を判断できます。

見落としやすいリスクと対策

BSS刷新では、移行、データ、請求、契約の各面にリスクが生じます。そのため、先に主なリスクを洗い出します。

• 移行：ビッグバン切替や二重運用の長期化。
• データと連携：品質未確認や独自APIの乱立。
• 請求と契約：請求誤りやベンダーロックイン。

移行対象を分け、匿名化した実データでリハーサルし、APIの所有者と版を管理します。そのうえで、旧新の料金結果を突き合わせ、二重運用の終了条件と切戻し期限も、計画書や契約に記します。

BSSは、氏名や連絡先、本人確認情報を扱います。さらに、契約や請求、決済、利用履歴も含みます。そのため、個人情報保護法に加え、電気通信分野の個人情報等保護ガイドラインや通信の秘密にも配慮します。

個人情報保護委員会のページでは、電気通信分野ガイドラインの解説について、2026年5月までの新旧対照表が案内されています（出典：個人情報保護委員会「特定分野ガイドライン」、2026年確認）。公開時点の最新版を確かめ、利用目的、第三者提供、国外移転を、設計と契約に反映します。保存期間や削除請求、委託先・再委託先の監査権も、契約と設計で扱います。

2026年の変革のテーマは、クラウドネイティブ、共通データ、Open API、AIエージェント、intent-based operationです。TM Forumは、2026年6月の「Transformation 2.0」で、AI-native ODAを紹介しています。

これは、AIエージェントが従来のシステム境界を越え、リアルタイムに動くためのアーキテクチャです（出典：TM Forum「Transformation 2.0: towards an AI-native Open Digital Architecture」、2026年6月）。

AIを問い合わせ対応や不正検知、料金設計の支援に使う場合は、データへのアクセス、実行操作、承認者、ログを先に決めます。AIでレガシー連携が不要になるとは考えず、データ定義や権限、監査を整えます。

よくある質問

BSS開発では、既存システムを残す範囲と、請求・移行の品質をどう担保するかが判断の中心になります。初期検討で多い疑問に答えます。

小規模なMVNOでもBSSを開発できますか？

開発できます。全機能を一度に作らず、クラウドBSSや標準パッケージを中心に、申込・契約・課金など事業開始に必要な範囲から導入します。

加入者数に加えて、料金プラン数、イベント頻度、決済方式、MNPや返金の有無を整理しておきます。そのうえで、単一モジュールの追加やPoCから始められます。

BSSはパッケージとスクラッチのどちらがよいですか？

顧客・契約・請求や一般的な注文管理は、パッケージまたはSaaSを活用します。一方、競争力に直結する料金計算や法人向けの見積、パートナー精算は、APIやマイクロサービスで拡張する方法が適しています。

標準業務に合わせにくい固有要件が多く、将来の変更を自社主導にする必要がある場合はスクラッチを検討します。初期費用に加えて、5年間の保守人材、ライセンス、クラウド、移行、変更費用を比べます。

BSS開発にはどれくらいの期間がかかりますか？

期間の目安は、単一モジュール追加やPoCが1〜9か月、MVNOや小〜中規模ISPのクラウドBSSが6〜18か月、中堅事業者の大規模カスタマイズが12〜30か月です。

複数ブランドの加入者基盤を移す刷新では、2〜5年かかる場合があります。そこで、移行とテストの範囲を分け、旧新突合と切替判断を先に設計すると、期間の短縮につながります。

BSSにAIを導入すれば開発期間や費用を削減できますか？

AIは、既存仕様の抽出やテスト作成、問い合わせ対応、不正検知、料金設計の効率化に役立つ可能性があります。ただし、導入しただけで期間や費用が必ず下がるわけではありません。

データ定義がそろっていないと、AIの出力を検証する工数が増える場合があります。そこで、参照データや実行操作、承認者、監査ログ、誤提案の訂正方法を決めたうえで、小さな業務から効果とリスクを測ります。

まとめ

BSS開発で押さえる結論

BSS開発では、事業目的と運用責任に沿って、顧客から請求までの仕組みを再設計します。BSSとOSSの境界を明確にし、段階的に進めることが、全面刷新のリスクを抑えます。

目的と機能、責任範囲をそろえたうえで、対象を絞った検証から稼働後の運用までつなげます。

1. 現状診断とKPI設定を行い、業務・データ・API要件を定義します。
2. 優先領域でPoCを行い、標準機能と固有機能を切り分けます。
3. 段階移行後に旧新を突合し、運用へ引き継ぎます。

調査・PoCは500万円から2,000万円程度、単一モジュールは1,000万円から8,000万円程度です。MVNOや小〜中規模ISPは3,000万円から1億5,000万円程度、中堅事業者は1億円から5億円程度です。さらに、大手の段階刷新は5億円から30億円超、全面刷新は10億円から数十億円以上が計画レンジです。

これらは定価ではなく、加入者数やイベント量、料金ルールを含めて精査するための目安です。連携や移行、テスト、並行稼働、保守の条件も含めて考えます。比べるときは、初期費用と3〜5年TCO、契約終了時の移行性を並べて見ます。

最初の90日に決める事項

最初の90日で、現行業務とデータを一覧にし、課題のKPI、優先モジュール、PoCの評価項目、RFPの前提、切替とロールバックの方針を決めます。

業務とシステムの境界を整理しておくと、見積もりの精度が上がり、将来の変更もしやすくなります。

▼全体ガイドの記事
・BSS開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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