サブスク請求管理システム開発の完全ガイド

サブスク請求管理システムは、契約から会計までを一つのデータの流れで管理し、請求と回収を円滑にする業務システムです。開発では、機能の範囲、導入方式、費用、進め方を押さえることが大切です。

機能の全体像から費用、発注先の選び方まで、各テーマの詳しい内容は下の関連記事で確認できます。

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

サブスク請求管理システムの概要

サブスク請求管理システムは、契約状態と利用実績をもとに請求額を計算し、決済、入金確認、会計処理までを一つの流れにつなぐ業務システムです。毎月同じ請求書を自動で発行するツールとは、担う範囲が大きく異なります。

選定では、請求書の見た目よりも、料金ルールと例外処理を正しく再現できるかを確かめることが大切です。料金の例外を再現できないと、手作業が残って請求や回収に影響が出ます。

請求書発行ツールとの違い

請求書発行ツールは、確定した金額を帳票にして送る用途に強い一方で、契約日や更新日、利用量、値引き、返金に基づく金額の計算は限られる場合があります。そこで、顧客から仕訳までの各データを、同じ識別子で一続きに追います。顧客や商品、プランの情報は契約に結びつき、利用実績をもとに請求へ進みます。請求のあとは、決済と入金を経て仕訳まで届きます。

導入が向いている企業

BtoB SaaSや保守・レンタル、教育などの事業に適しています。会員制サービスや通信、IoT機器のサービス化でも、導入の対象になります。契約数や契約変更が増える事業では、効果を発揮しやすくなります。

営業が契約を登録し、運用が利用量を集計し、経理が請求と消込を担う分業では、担当者ごとの転記を減らせます。また、毎月のExcel加工や、プラン変更時の請求漏れ、決済失敗の追跡を特定の担当者任せにしている場合は、導入の優先度が高いといえます。

契約から入金・会計までの全体像と主な機能

前後のデータをつなぐことで、請求から会計までを一続きに把握できます。

全体像をつかむには、機能ごとに見るより、データの流れに沿って見ると理解しやすくなります。

データは、商品・料金から始まり、顧客・契約、利用実績、課金、請求と進んで、会計までつながります。前後のデータが切れると、その間を手作業でつなぐことになります。

商品・料金マスタと契約管理

商品・料金マスタでは、定額、従量、段階式の料金方式を管理します。また、階段式、最低利用料、セット商品も同じマスタで扱います。さらに、期間限定割引と税率も含めます。

契約管理では、開始日、更新日、請求サイクル、支払条件を記録します。さらに、休止・再開・解約や、契約単位の価格も記録します。

料金は画面に書き込まず、適用期間と変更履歴を持つマスタで管理すると、過去の請求を後から再現できます。

課金計算・請求・決済

課金計算では、月額料金に加えて、日割り、按分、従量を処理します。さらに、割引や最低利用料、複数契約の合算・分割も扱います。

請求では、締め日、請求日、請求書番号を管理します。明細や税額、発行履歴も管理します。決済手段には、カード、口座振替、銀行振込などがあります。

決済が失敗したときは、自動リトライと支払手段の更新依頼を設計し、督促や再請求まで決めておくと、回収が特定の担当者に偏るのを抑えられます。

入金消込・債権・会計連携

入金消込では、請求番号と顧客番号を手がかりに、振込名義や入金額、手数料を使って請求と入金を突き合わせます。未収や延滞、過入金に加えて、分割入金や返金も例外として処理できるかを確かめます。

会計連携では、売上の計上や前受・繰延の扱いを確認します。あわせて、仕訳の出力単位と収益認識の単位も確かめます。

国際会計基準や米国会計基準への対応が必要なら、収益管理は請求管理とは別の機能であるため、別要件として評価します。

サブスク請求管理システムの種類と選び方

標準機能の活用と自社で担う範囲が、方式選定の分かれ目になります。

方式は四つあります。クラウド製品とAPI連携、既存CRM・業務基盤への追加、個別開発です。

方式を選ぶときは、自由度だけでなく、料金ルールの複雑さや既存データ連携も同じ条件で比べます。さらに、法改正対応と運用体制も確認します。

クラウド製品・パッケージ型

標準の契約、請求、決済の機能を、比較的短い期間で利用できます。帳票や権限管理も、標準の機能として使えます。さらに、インボイス制度や電子帳簿保存の更新を、サービス側に任せやすいのも利点です。

標準の料金に業務を合わせつつ、例外を無理にカスタマイズすると、アップデートや保守が難しくなります。そのため、導入前に、MUST要件の大半を設定で満たせるかを確認します。

API連携・コンポーザブル型

API連携型は、既存サービスの画面や顧客データを生かしながら、請求、決済、利用量の計測を組み合わせる方式です。そのため、独自の顧客体験や料金モデルを実現しやすくなります。

API連携型では、税計算や返金の仕組みを自社で設計する範囲が広がります。決済の失敗と再試行、監査ログ、障害時の再処理も、自社で担う部分になります。

Webhookの再送や冪等性、レート制限を確認します。加えて、保持期間と、障害時にどこまでを誰が受け持つかも確かめます。

既存のCRM・基幹基盤に追加する方式

営業管理や顧客管理、販売管理の基盤を利用している企業は、既存の基盤に契約と請求の機能を加えることで、データの二重登録を減らせます。会計や在庫などを利用している企業でも、同じ方法で二重登録を減らせます。

契約から請求、会計へとつながる流れは組みやすい一方で、マスタの粒度や権限によっては連携が複雑になります。そのため、連携項目を一覧にして、どのシステムを正とするかを決めてから方式を選びます。

スクラッチ開発

スクラッチ開発では、料金や契約、収益認識を独自に作り込めます。顧客画面や決済、監査証跡も、自社の考えに沿って組めます。

独自の料金ロジックや大量処理が競争優位につながるなら、有力な選択肢です。ただし、法改正や決済規格への対応は自社の責任になります。セキュリティや監視、障害対応を含めて、運用要員も自社で担います。

独自開発でも、発注側は請求書や決済をすべて自作せず、外部サービスと内製部分の境界を決めます。

ポイント

方式は、標準機能で足りるか、既存の基盤とつなげられるか、自社で担う範囲で比べます。料金ルールが複雑なほど、運用体制の負担を先に見積もります。

サブスク請求管理システム開発の進め方

技術の選定の前に、業務ルールを具体化します。画面の一覧よりも、契約から入金までの流れと金額計算のテストケースを先に作ります。

初回は必須機能に絞り、例外や高度な分析は段階的に追加します。そうすることで、期間とリスクを管理しやすくなります。

▶ 詳細はこちら：サブスク請求管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

要件定義・企画フェーズ

要件定義では、開発の土台になる情報を整理します。データや料金、業務ルール、処理条件が、その対象です。

データ項目：顧客、商品、契約、利用量から、請求、決済、入金、会計までのデータ項目
料金モデル：定額、従量、段階式、ハイブリッドの区分
業務ルール：無料期間、日割り、プラン変更、解約、返金、代理店価格のルールを文章にしたもの
要件：MUST・WANT、法令・監査要件、業務上の希望の区分
処理条件：連携先一覧、月末の最大処理件数、請求締め時間、帳票、権限、保存期間、復旧目標の取り決め

要件定義の段階で作る資料には、業務フローや料金・データ項目表、権限一覧が入ります。テストケースや移行方針も含めます。

テストの例は、日付と期待結果を組にして書きます。たとえば、「月額10万円」を前提に、「4月15日に開始した場合」や「5月10日に上位プランへ変更した場合」の結果を書き分けます。

設計・開発フェーズ

設計・開発では、契約や請求の状態、料金計算の定義を決めておき、外部連携と情報管理を含めて実装します。

状態管理：契約、請求、決済、入金を分けて持ちます。解約後も未収が残ることがあり、失敗と停止を同じ状態として扱うと、請求停止や回収漏れにつながります。
料金計算：入力値、計算順序、丸め、税、端数処理、適用期間の仕様
段階的な開発：契約登録から会計出力までを小さく動かし、業務担当者が早く確認できる形
外部連携：タイムアウトや重複通知への備え、再実行時も二重請求が起きない冪等性
情報管理：個人情報・決済情報の範囲の絞り込み、権限分離、操作ログ

テスト・移行・リリースフェーズ

品質を確かめるには、料金の例外と移行データ、稼働後の動作を一連の流れで確認します。

基本テスト：初月無料、月途中開始、日割り、上下プラン変更、利用量不足、複数契約の合算のケース
例外テスト：返金、クレジット、決済失敗、再請求、分割・過入金、解約後の未収のケース
出力確認：請求額、明細、税額、仕訳、顧客画面、通知、監査ログを同じケースで追う確認
移行：顧客番号、契約開始日、次回更新日、料金、残高、未収、決済手段、過去の請求履歴の移行
照合：移行前後の件数と金額の照合（サンプルと全件合計の両方）
稼働確認：初回請求の並走または二重確認、エラー率、決済成功率、消込未処理件数の監視

ポイント

最初に業務ルールと金額計算のテストケースを固め、初回は必須機能に絞るのが基本です。例外や高度な分析は、期間とリスクを見ながら段階的に加えます。

費用相場と開発期間の目安

費用は、料金モデルと契約数、決済手段で変わります。また、既存システムとの連携やデータ移行、帳票によっても変わります。さらに、セキュリティや保守範囲も、費用に影響します。

以下の金額は、会計・請求・基幹システムの一般的な工数と公開料金の方式から組み立てた、企画初期の推定値です。正式な見積は要件定義のあとに確定するため、ここでは目安として読んでください。

▶ 詳細はこちら：サブスク請求管理システム開発の見積相場や費用/コスト/値段について

方式別の初期費用の目安

方式ごとの初期費用と期間は、標準導入か連携開発か、個別開発の規模によって変わります。

クラウド標準導入：初期費用は0〜300万円程度、期間は1〜3か月程度が目安です。
外部連携の開発：CRMや会計、販売管理、請求書配信などと連携する場合は、300〜1,500万円程度、3〜6か月程度です。
中規模の個別開発：複数事業や複雑な料金、月末の大量処理を含む場合は、1,500〜4,000万円程度、6〜12か月程度が目安です。
スクラッチ開発：契約、料金、決済、収益認識を独自開発する場合は、3,000万円から1億円超、9〜18か月以上になることがあります。

これらは、類似する会計・請求・基幹システムからの推定で、公的に統一された相場ではありません。そのため、見積書では、要件定義や設計、開発を分けてもらいます。テストや移行、教育、保守も、別々に示してもらうと比べやすくなります。

月額費用・決済手数料・保守費

サービス利用型では、月額や従量料金、決済関連費、保守範囲を分けたうえで、総額を見ます。

サービス利用料：月額のほか、利用者や契約数に応じた従量料金、決済手数料、請求書配信料、外部API費用がかかります。
従量費の例：請求取引額の0.7%を公開料金に設定しているAPIサービスがあります（出典: 決済・請求APIサービスの国内公開料金ページ、2026年）。
参考額：月商1,000万円なら7万円ですが、カード手数料やプラン、対象取引によって変わります。契約前に確認します。
保守費：初期費用の年5〜15%程度が目安です。監視や障害・法改正・脆弱性への対応、問い合わせ、追加開発の含まれる範囲によって、実額は変わります。

初期費用だけでなく、月額や手数料を含め、3年または5年の総額で比べます。保守や移行、追加連携も、その総額に加えて見ます。こうして総額で比べると、安く見える提案を見落としにくくなります。

費用を左右する変数

見積額は、契約数だけでなく、料金体系や請求と会計の連携方式、月末の処理量によっても変わります。

料金・範囲：定額か従量・段階式か、国内か海外通貨・税も扱うかによって、工数が変わります。
請求と移行：合算・分割のほか、失敗時の再試行回数や過去データの移行年数も影響します。
会計連携：ファイル出力かリアルタイムAPIかによって、費用と運用の負担が変わります。
処理量：月末の処理件数と許容時間を押さえます。月1万件と月100万件では、バッチやキュー、監視、復旧、性能試験の内容が変わります。

見積を依頼するときは、契約件数と月次の請求件数、最大同時処理、今後3年の増加見込みを伝えます。あわせて、将来の拡張にかかる費用も確認します。

ポイント

費用は、月額や保守、移行を含めた3年または5年の総額で比べます。初期費用だけで判断すると、後から増える費用を見落としやすいため、見積の条件をそろえることが大切です。

サブスク請求管理システムの開発会社・ベンダーの選び方

開発会社を選ぶときは、自社の料金ルールを安全に運用できるかを見ます。知名度や月額料金も、その判断材料の一つです。

製品の提供者と導入支援、個別開発のSIは、役割が異なります。決済や会計の連携先も、それぞれ役割が違います。そこで、提案項目をそろえ、同じテストケースへの回答を比べると、機能表には出てこない差が分かります。

課金モデルと業務知識の実績

定額課金の実績があっても、従量・段階式・ハイブリッド料金に対応できるとは限りません。そこで、候補には、無料期間や日割り、プラン変更の処理を実演してもらいます。さらに、返金、失敗決済、再請求、入金消込まで見せてもらいます。

導入事例は、社数だけでなく、契約数や期間、業務範囲を聞きます。さらに、標準機能と追加開発の境界、稼働後の運用体制も確認します。

連携・移行・データ所有権

CRMや販売管理、会計など、連携する先を一覧にします。決済や顧客ポータル、BIなども、同じ一覧に入れます。連携方式や更新頻度、エラー通知、再送を決めておきます。データの正や保持期間、退会後の扱いも明記します。

移行時は、顧客番号と契約番号が変わらないか、過去の請求と入金を再現できるかを確認します。また、解約済みの契約や未収残高を持ち越せるかも、確かめておく必要があります。

契約が終わったあとでも、データを取り出せる形式と期限は、発注前に確認しておきます。

セキュリティ・保守・責任分界

候補の運用体制を比べるには、安全管理やデータの取り扱い、保守条件を確かめます。

安全管理：権限、多要素認証、暗号化、操作ログを評価します。バックアップや脆弱性、障害通知、復旧、監査も見ます。
データと連絡：決済情報を保持するシステム、個人情報の送信先、外部障害時の顧客連絡担当
保守条件：受付と初動の時間、復旧目標、法改正対応、アップデート、問い合わせ範囲を、契約に記します。
委託先管理：委託先を含む供給網の管理も、評価の対象です。
運用実績：障害訓練や権限レビュー、ログ提出、バックアップ復元の実績

IPA資料でも、委託先を含む供給網の管理が重視されています（出典: IPA「サイバーセキュリティ経営ガイドラインVer.3.0」実践資料、2026年更新）。さらに、事故対応や事業継続、復旧体制を、契約と第三者による確認で担保する考え方も示されています。

▶ 詳細はこちら：サブスク請求管理システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：サブスク請求管理システム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、知名度より、自社の料金ルールを安全に運用できるかで選びます。同じテストケースに回答してもらうと、機能表に出てこない差が見えてきます。

法制度・セキュリティ・データ連携の確認項目

請求操作とデータ管理を複数の確認項目で支える構成です。

サブスク請求は、業務の効率だけでなく、税務や会計、個人情報、決済のセキュリティにもかかわります。後から法対応を加えると、請求の確定や履歴の設計をやり直すことになりやすいため、要件定義の段階で、帳票の発行時期、データの保存期間、訂正や承認ができる人を決めておきます。

インボイス制度と電子帳簿保存

制度要件の確認では、適格請求書の記載と電子保存の両方を押さえます。

適格請求書：登録番号や取引内容、税率ごとの金額、消費税額などの記載項目を満たす必要があります。
電子データ：請求書の検索性や見読性、保存、訂正削除の履歴の設計
保存要件：自社の電子取引データの保存要件の確認

財務省の資料は、電子取引データの改ざん防止や適正な記帳、電子帳簿との相互の関連性を示しています（出典: 財務省「令和7年度税制改正」、2025年）。

デジタルインボイスと入金データ連携

デジタルインボイスの国際標準であるPeppolや、全銀EDIであるZEDIを活用すると、請求情報と支払・入金情報をデータで渡しやすくなります。国税庁も、会計ソフトを導入している事業者の効率化に向けて、PeppolやZEDIの活用を案内しています（出典: 国税庁「事業者のデジタル化促進」、2026年閲覧）。

導入するときは、相手先の対応状況や文字コード、請求番号の引き継ぎを確認します。あわせて、エラーが起きたときに手動で処理する手順も確かめます。

権限・監査証跡・復旧設計

請求操作の変更や復旧を後から追えるように、権限、履歴、安全管理を設計しておきます。

操作履歴：請求額の変更、返金、取消、契約更新、消込修正の実行者と日時の追跡
権限と承認：登録、承認、確定、返金の権限の分離、承認前後の差分と理由の記録
復旧設計：バックアップ後の復元時間とデータ整合性の定期確認、目標復旧時間と許容損失量の数値による設定
安全管理：多要素認証、最小権限、暗号化の確認。脆弱性診断、ログ監視、秘密情報、委託先の管理も含みます。
経営項目：IPAの重要10項目は、予算・体制、事故対応、事業継続、委託先を含む管理について整理しています（出典: IPA、2026年）。

請求データには売上や個人情報が含まれるため、経理だけでなく、情報システムの担当と経営層も評価に加わります。

ポイント

インボイス制度や電子帳簿保存の対応は、要件定義の段階で決めておくと、後の設計のやり直しを減らせます。権限や監査証跡、復旧の条件も、同じ段階でそろえておきます。

導入で起きやすい失敗と運用KPI

よくある問題は、料金ルールを決めないまま開発を始めることです。ほかにも、営業や運用、経理の例外処理を拾わない、月額料金だけで選ぶ、移行を後回しにする、障害時の手動運用を決めないといった例があります。

発注側は、機能を増やす前に、請求額を正しく計算できること、根拠を追えること、回収できることを優先します。

よくある失敗と対策

「標準機能で対応できる」と聞いても、初月無料や日割り、返金、失敗決済が手作業で残る場合があります。そこで、候補のデモでは実際のシナリオを動かしてもらい、対応方法を整理します。

標準設定：設定だけで対応できる範囲の記録
追加開発：個別開発が必要な処理の記録
手動運用：担当者が行う処理と条件の記録

契約更新日や残高を誤って移行すると請求額に直結するため、本番の前に、移行のリハーサルと全件の照合を行います。

決済失敗後の連絡を担当者任せにすると、対応が続きません。そこで、失敗の理由を分けたうえで、再試行や通知、支払手段の更新の条件を決めておきます。契約停止や手動回収の条件も、あわせて決めます。

請求の確定後に訂正や返金をする場合は、データを直接上書きせず、訂正の履歴と承認を残しておきます。そうすると、顧客への説明や監査に対応しやすくなります。

導入後に見るKPI

運用の効果を捉えるには、請求と回収、事業の指標を導入の前後で比べます。

請求・回収：エラー率、確定から入金までの日数、決済成功率、未収残高、消込未処理件数を月次で確認します。
処理・事業指標：返金処理と契約変更の反映時間、MRR、ARR、解約率、顧客単価、アップグレード率
導入前の基準値：月末処理が5営業日かかる場合の、処理日数と担当者工数の記録
稼働後の比較：エラー率、手動修正、未収発見までの時間の比較
計測データ：開始・確定・決済・入金・消込の日時のイベント保存

よくある質問（FAQ）

導入前によく寄せられる質問に、順に答えます。自社の契約数や料金モデルに置き換えて考えると、ベンダーへの質問を整理しやすくなります。

サブスク請求管理システムは必ず個別開発が必要ですか？

個別開発が必要かどうかは、業務の条件で決まります。定額中心で業務を標準化できる企業なら、クラウド製品の設定から始められます。

従量・段階式料金や独自の契約状態が競争優位に関係する場合は、API連携や個別開発を組み合わせます。複数事業の合算や特殊な収益認識も、同じ検討の対象に入ります。

費用はどのように比較すればよいですか？

初期費用だけでなく、月額や決済手数料、請求書配信も含めて比べます。さらに、ユーザー数や外部API、データ移行の費用を加えます。保守と追加開発もあわせて、3年または5年の総額で見ます。

見積の条件をそろえるため、同じ契約件数と請求件数を提示します。料金のシナリオや連携先、保守時間も、同じ条件で示します。

公開料金がない場合は、金額を言い切らず、見積の変数と上限を確認します。

既存の契約データは移行できますか？

移行は可能ですが、データの品質に左右されます。対象となるのは、顧客や契約、料金のデータです。更新日や請求履歴、未収残高、決済手段も含まれます。

移行の前に、重複した顧客や更新日の欠落、表記の揺れを整理します。さらに、終了した契約や残高の不一致も整理したうえで、テスト環境で試しておきます。本番では、件数だけでなく請求額と残高の合計を照合します。そのうえで、旧システムの参照期間を設けます。

インボイス制度や電子帳簿保存に対応できますか？

対応可否は、サービスや構成によって異なります。そのため、帳票や記載項目、保存期間を要件として確認します。さらに、検索条件や訂正削除の履歴、承認の記録も確かめます。

「対応済み」と書かれていても、請求の確定や再発行まで、デモと証跡で確かめます。返金や取消、データ出力までを対象にします。

最終的な保存要件は、自社の税務担当者や顧問の専門家にも確認しておく必要があります。

まとめ

サブスク請求管理システムは、契約から会計までを一つのデータの流れで管理します。課金や請求、決済、入金消込も、その流れの中に含まれます。

日割りや従量、段階式、割引を扱えるかが、請求書発行ツールとの大きな違いです。返金や失敗決済、未収まで扱えるかも、あわせて確かめます。

導入方式を決めるポイント

クラウド製品やAPI連携、既存基盤への追加、スクラッチ開発のなかから、自社の料金モデルと業務体制に合う方式を選びます。

初期費用だけでなく、月額や決済手数料を含めた総額で比べます。連携や移行、保守も、その総額に含めます。そのうえで、同じテストケースで候補を評価します。

要件定義では、料金ルールとデータの正を具体化します。権限や監査証跡、障害時にどこまでを誰が受け持つかも、そこで決めます。

最初に作るべき資料

導入の準備では、要件を整理し、見積もりに使う資料と具体的なテスト例をそろえます。

準備する資料：業務フローや料金ルール表、例外処理一覧、連携先一覧、移行対象、テストシナリオ
具体的なテスト例：「4月15日開始で日割り」「翌月に上位プランへ変更」「決済失敗後に再請求」「返金と会計仕訳」の記載

具体的な条件まで書いておくと、候補の比較や見積の精度が上がります。目的は、請求の正確性や回収の早さ、監査可能性、担当者の負荷を改善することにあり、導入そのものは手段です。

▼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を創業。