課金基盤エンジニアのフリーランス案件と単価相場｜サブスク課金の設計力

「プランを 3 階層に増やしたい」「年額契約を途中でアップグレードできるようにしたい」「請求金額が経理の数字と合わない」。参画先でこうした相談が、いつのまにか自分のところに集まってくる。日割り計算のロジックを直し、決済失敗時のリトライ間隔を調整し、解約時の返金処理を書き直す。直近 2 年で最も時間を使い、最も緊張しながら触ってきたのは、間違いなく課金まわりの実装でした。

ところが、エージェントとの面談ではその経験が一行に潰れます。「Go / Rails でのバックエンド開発」。提示される単価は「バックエンドの相場からすると、このあたりですね」という汎用レンジのまま動きません。責任の重さと値付けが、まったく釣り合っていない状態です。

この非対称が起きるのは、あなたの実力が足りないからではありません。課金の仕事が「機能追加」という言葉に翻訳されてしまうからです。日割りの丸め方をどう決めるかで顧客に届く請求額が変わり、締め処理を一度でも二重実行すれば経理・カスタマーサポート・経営会議が同時に止まります。この責任の総量は、書いたコードの行数にはまったく比例しません。だからこそ、実装の分量で評価する枠組みの中では値段がつかないのです。

打ち手は、自分の仕事に正しい職能名と設計語彙を与えることです。課金基盤は、決済 API 連携とは別の、「いくら請求するかを決める層」という独立した領域です。プロレーション、Dunning、締め処理の再実行耐性、収益認識との接続——これらは面談で単価の根拠として通用する言葉であり、汎用バックエンドとの境界線を引く言葉でもあります。

本記事では、課金基盤エンジニアという職能の定義から始めて、案件が生まれる 4 つの起点、設計で問われるスキル、会計との接続が単価差を生む理由、そして関与度合いで分かれる単価レンジの 3 層と、その境界にある壁を整理します。最後に、いまの経験を面談で通じる形に言い換える型と、課金の経験が浅い方が半年で参入する順序までを扱います。

課金基盤エンジニアとは？決済API連携との違い

まず、この記事で扱う「課金基盤」の輪郭をはっきりさせておきます。ここでいう請求とは、プロダクトが顧客に対して発行する請求のことです。フリーランスが自分の稼働に対して発行する請求書とは別の話なので、混同しないようにお読みください。

課金基盤が担う4つの領域

課金基盤は、契約が始まってから売上として計上されるまでの一連の流れを支える仕組みです。おおまかに 4 つの領域に分けられます。

この 4 領域を通して見ると、課金基盤の出力が単なるデータではなく、顧客に届く金額と会社の会計数値そのものであることが分かります。ここが、他のバックエンド領域と決定的に性質が違う点です。

決済API実装との境界線 —「お金を通す層」と「いくら請求するかを決める層」

課金の話をすると、多くの場合「Stripe を使えるかどうか」という話に流れます。しかし、決済 API 連携と課金基盤は責任範囲が異なります。

• 決済 API 連携（お金を通す層）: カードのオーソリとキャプチャ、3-D セキュア、Webhook の受信と冪等性、カード情報を自社で保持しない設計。「確定した金額を、事故なく通す」ことが責任範囲です。
• 課金基盤（いくら請求するかを決める層）: 契約状態と利用実績から請求額そのものを導出し、確定させ、会計に橋渡しする。「その金額が正しいことを説明できる」ことが責任範囲です。

両者は隣接していますが、失敗の質が違います。決済が通らなければ即座に気づきますが、請求額が誤っていても多くの場合すぐには気づかれません。数か月後に経理の突合で発覚し、過去分の訂正と顧客への説明が同時に必要になります。この「静かに壊れる」性質こそが、課金基盤の設計に慎重さを要求する理由です。

お金を通す層の実装・単価の詳細は 決済APIエンジニアの案件と単価 で扱っているため、本記事では請求額を決める層に絞って進めます。

「課金システム 開発 エンジニア」の求人タグはあるのに案件が見つからない理由

課金システム 開発 エンジニアという括りは、求人検索の軸として実在します。日経転職版には「課金システム」がスキルタグとして存在し、そのタグで求人を絞り込めます（日経転職版 課金システムの求人）。

にもかかわらず、案件が見つけにくいと感じるのには構造的な理由があります。募集要件の記述が、ほぼ例外なく言語とデータベース設計に翻訳されてしまうためです。実際の困りごとは「プラン改定に既存の請求ロジックが追随できない」なのに、募集文には「Go / RDB を用いたバックエンド開発、決済関連システムの経験歓迎」と書かれます。求める設計力が言語化されていないので、検索する側も探しようがないわけです。

この構造は、裏を返せばチャンスでもあります。募集側が言語化できていない要件を、面談の場であなたの側から言語化できれば、他の候補者と同じ土俵に並ばずに済みます。そのための語彙を、この先のセクションで揃えていきます。

課金基盤エンジニアの案件が生まれる4つの起点

「課金の案件はあるのか」という不安に対しては、求人票の数を数えるよりも、需要が発生するトリガーから考えるほうが正確です。課金基盤の案件は、企業側で次の 4 つのいずれかが起きたときに発生します。請求管理システム 開発 案件として表に出てくるものも、多くはこの 4 つのどれかが背景にあります。

起点1: プライシング変更への追随

SaaS の料金体系は、定額のシート課金だけでは説明しきれなくなっています。基本料金に従量部分を積む形のハイブリッド型や、クレジット前払い型、成果連動型などが選択肢に入り、特に AI 機能を持つプロダクトでは利用量に応じたコストが発生するため、従量的な要素を組み込まざるを得なくなっています（Scalebase「SaaSの売上を最大化するプライシング戦略」、renue「Usage-Based Pricing（従量課金）とは？」）。

プライシングは経営やプロダクト側が決めますが、決めた瞬間に「今の課金ロジックでは実現できない」ことが判明する、という順序で問題が表面化します。困るのはプロダクトマネージャーと CFO であり、彼らが探すのは「新しい料金体系を既存の請求ロジックに載せられる人」です。

この起点の案件は、期限が固定されているのが特徴です。新料金の発表日が先に決まっているため、遅延が許されません。そのぶん、要件を速く詰められる人の価値が上がります。

起点2: 内製課金の限界とビリングSaaSへの移行

多くの SaaS は、創業初期に最小限の課金ロジックを内製します。プランが 2 つで月額のみなら、それで十分に回ります。問題はその後です。プランが増え、年額が加わり、割引が入り、複数通貨に対応し、途中変更を許すようになると、内製のロジックは分岐の塊になります。

この段階で検討されるのが、Stripe Billing・Zuora・Scalebase といったビリング SaaS への移行です。stripe billing 導入支援という文言で案件が出てくるのは、たいていこのフェーズです。

移行案件が難しいのは、新旧の並走期間があるからです。既存契約をどこまで移し、いつから新基盤で請求するのか。移行期間中に発生したプラン変更をどちらで処理するのか。過去分の請求データをどう扱うのか。この判断ができる人は、実装だけができる人よりも明確に希少です。

起点3: 制度対応（インボイス制度・電子帳簿保存法・多通貨と税）

制度は待ってくれません。適格請求書等保存方式（インボイス制度）では、発行する請求書に登録番号と税率ごとに区分した消費税額を記載する必要があり、消費税額の端数処理は一つの適格請求書につき税率ごとに 1 回と定められています（国税庁 インボイス制度について）。この「税率ごとに 1 回」という制約は、明細ごとに消費税を計算して合算する実装と真正面から衝突します。

電子帳簿保存法についても、2024 年 1 月から電子取引データの電子保存が義務化されており、電子的にやりとりした請求書等をデータのまま保存する必要があります（弥生「電子取引データの保存要件・検索要件」）。プロダクトが発行する請求書を PDF で送って終わり、という設計では要件を満たしません。

海外展開が絡むと、通貨ごとの丸め、為替レートの適用時点、国ごとの税制対応が加わります。インボイス制度 システム対応 開発の案件は、期限が制度側で決まっているため、起点 1 と同様に遅延が許されないタイプです。

起点4: 売上数値の信頼性回復

最も見えにくく、そして最も根深いのがこの起点です。「MRR の数字が経営会議の資料と会計の数字で合わない」「解約率の定義が部署ごとに違う」「請求と入金の突合が毎月手作業で 3 日かかっている」。こうした状態は、課金基盤が積み上げてきた歪みの結果として現れます。

この起点の依頼は、はじめは課金の案件として立ち上がりません。「データ基盤を整理したい」「経理業務を効率化したい」という形で出てきて、掘っていくと請求データの設計に行き着きます。逆に言えば、課金基盤を理解している人がこの手の案件に入ると、問題の本丸に最短で到達できます。

課金基盤の設計で問われるスキル（プロレーション・Dunning・締め処理）

ここからは、サブスクリプション 課金 設計の中身に入ります。ポイントは、課金の難所が「実装の難しさ」ではなく「設計判断の難しさ」であることです。どれも書くコード自体は複雑ではありません。難しいのは、何を正としてどう決めるかであり、決めたことを後から変えられない形で記録することです。

契約・プラン・価格のデータモデル

最初につまずくのは、価格を「現在の値」として持ってしまう設計です。プラン表に単価カラムを一つ置き、値上げのときに更新する。この設計は、値上げした瞬間に過去の請求を再現できなくなります。

課金基盤のデータモデルで押さえるべき論点は次のとおりです。

• 価格の履歴保持: 価格はマスタの現在値ではなく、有効期間を持つレコードとして保持する。過去の請求を再計算したときに当時と同じ金額が出ることが要件になります。
• 契約と価格の結びつき: 顧客がどの時点の価格で契約したのかを契約側に固定する。値上げ後も既存顧客を旧価格のまま据え置く運用（グランドファザリング）は、SaaS では例外ではなく常態です。
• 契約途中の変更履歴: プラン変更・数量変更・解約・再開を、状態の上書きではなくイベントの列として持つ。「なぜこの月の請求がこの金額なのか」を後から説明できる構造にします。

このデータモデルを最初に間違えると、後段のプロレーションも締め処理も会計連携も、すべて例外処理の積み重ねになります。逆に、ここを設計できる人は課金基盤全体の設計を任せられる人です。

プラン変更と日割り（プロレーション）

プロレーションは、契約期間の途中でプランや数量が変わったときに、期間の残りに応じて差額を調整する仕組みです。Stripe では旧プランの未使用分と新プランの利用見込み分の差額を残日数から計算し、請求書に反映します（Stripe ドキュメント「サブスクリプションの修正」）。

実装より先に決めるべきなのは、次のような方針です。

ここで重要なのは、どの選択肢が正解かではなく、選んだ理由を説明できることです。ダウングレード即時反映は顧客体験が良い一方で、返金処理と売上の取り消しが毎月発生します。次期反映にすれば会計はきれいですが、カスタマーサポートに問い合わせが積み上がります。このトレードオフを提示して事業側と合意できる人が、課金基盤の設計主導者です。

決済失敗からの回収設計（Dunning）

サブスクリプションでは、決済の失敗は事故ではなく日常です。カードの有効期限切れ、限度額超過、発行会社側の一時的な拒否。これらは一定の割合で必ず発生します。dunning 決済失敗 リトライの設計とは、この日常をどう捌くかの設計です。

Stripe には失敗した支払いを自動的に再試行する Smart Retries や、支払い失敗時の顧客向けメール自動送信、カード情報の自動更新といった回収機能が用意されています（Stripe ドキュメント「売上回収」）。ただし、ツールを有効化するだけでは設計は完成しません。決めるべきことが残ります。

• リトライのスケジュール: 何日おきに何回試すか。失敗理由によってリトライすべきものとすべきでないもの（カード無効など）を分けるか。
• 猶予期間: 決済が回収できないまま、サービスを何日使わせるか。BtoB では即日停止が現実的でないことが多く、事業判断が必要になります。
• 利用停止の粒度: 全機能を止めるのか、書き込みだけ止めて閲覧は残すのか、データは保持したまま新規作成のみ止めるのか。
• 社内への通知: カスタマーサクセスや経理に、どのタイミングで、どの粒度で通知するか。金額の大きい顧客だけ人力でフォローする運用は多くの企業で採られています。
• 回収後の復旧: 停止後に決済が通ったとき、どこまで自動で戻すか。停止期間分を請求するのか免除するのか。

この設計は、実装より先に事業側・カスタマーサポート・経理と合意形成する作業が中心になります。ここに時間を使っている感覚がある方は、すでに設計主導の仕事をしている可能性が高いです。

請求確定と締め処理の再実行耐性

月次の請求確定処理は、課金基盤で最も事故が許されない部分です。バッチが途中で落ちる、タイムアウトして二重に走る、手動で再実行する——これらは運用していれば必ず起きます。そのときに二重請求を出さない構造になっているかどうかが、設計の質を分けます。

押さえるべき考え方は次のとおりです。

• 確定処理の冪等性: 同じ対象期間に対して何度実行しても、結果が一度実行した場合と同じになるようにする。請求単位に一意なキーを持たせ、既に確定済みのものは再作成しない設計が基本です。
• 確定後の不変性: 一度確定した請求は書き換えない。金額が誤っていた場合は元のレコードを直すのではなく、訂正のためのクレジットノート（貸方票）を新たに発行して差し引く。会計監査に耐える形はこちらです。
• 部分失敗の扱い: 1 万件の請求のうち 3 件で失敗したとき、全体をロールバックするのか、成功分を確定して失敗分だけ再処理するのか。後者を選ぶなら、進捗を記録する仕組みが必要です。
• 締め後の変更要求: 締めた後にプラン変更や解約の申請が遡って発生したとき、当月を修正するのか翌月で調整するのかを事前に決めておく。決めていないと、毎回その場の判断になり、数字の説明がつかなくなります。

「締め処理を再実行できるようにした」という一文は、面談で強い意味を持ちます。運用を経験している相手なら、その一文の裏にある設計の総量が伝わるからです。

会計・税務との接続が単価差を生む（収益認識とインボイス）

課金基盤が他のバックエンド領域と決定的に違うのは、出力が会計数値になる点です。そしてこの接続部分こそが、汎用バックエンドと単価が分岐する境界になります。収益認識 saas エンジニアという領域は、会計側にもエンジニア側にも解説が存在する一方で、両者を橋渡しできる人がきわめて少ない場所です。

収益認識の基本 — 前受金・繰延収益・期間按分

年額 120 万円のプランを 1 月に一括で受け取ったとき、1 月の売上は 120 万円ではありません。サービスをまだ提供していない期間の対価は、契約負債（前受金・繰延収益）として計上し、サービス提供にともなって月々 10 万円ずつ売上に振り替えていきます。

現行の収益認識基準は IFRS 第 15 号の考え方を取り込んでおり、契約の識別、履行義務の識別、取引価格の算定、履行義務への配分、履行義務の充足に応じた収益認識という 5 つのステップで判断します。SaaS のサブスクリプション契約のように、対価を先に受け取ってサービスを後から提供する場合は契約負債として扱われます（マネーフォワード「IFRSの収益認識基準とは？」）。

エンジニアとして押さえるべきなのは、会計処理そのものではなく、システム側が何を出力しなければならないかです。

• 請求（いつ・いくら請求したか）と、収益（いつ・いくら売上に計上するか）を別の概念として持てているか
• 契約途中の解約や増額があったとき、按分済みの繰延収益をどう調整するか
• 初期費用・導入支援費のように、月額とは性質の違う対価を分けて持てているか

請求と収益を同一のテーブルで扱っている設計は、この時点で行き詰まります。逆にこの分離を提案できるなら、それは会計側と対等に話せる立場に立てるということです。

インボイス制度・消費税・海外取引がシステム要件に落ちる箇所

制度要件は、抽象的な規制ではなく具体的なカラムと計算順序として実装に降りてきます。

• 登録番号の保持と出力: 自社の適格請求書発行事業者登録番号を、請求書の様式に確実に載せる。
• 税率ごとの区分と端数処理: 税率ごとに対価の合計を出し、そこから消費税額を計算する。適格請求書 1 枚につき税率ごとに 1 回の端数処理という制約があるため、明細ごとに税額を丸めて合算する実装は要件を満たしません（国税庁 インボイス制度について）。
• 請求書番号の一意性と再発行: 訂正時に同じ番号を使い回さない設計。
• 電子保存: 電子的に授受した請求書等をデータのまま保存し、検索できる状態にする（弥生「電子取引データの保存要件・検索要件」）。
• 海外取引: 通貨ごとの最小単位と丸め、為替レートを請求時点と入金時点のどちらで固定するか、国ごとの税制への対応方針。

これらは調べれば分かる情報です。しかし「調べれば分かる」ことと「要件定義の場でその論点を先に出せる」ことのあいだには、単価にして無視できない差があります。

会計 / CRM / 販売管理との連携設計

課金基盤は単独では完結せず、CRM（契約の獲得情報）、販売管理、会計システムと連携します。ここで問われるのは、どのデータをどこが正とするかという設計判断です。

• 契約情報の正はどこか: 商談成立時の情報は CRM にありますが、請求の根拠となる契約は課金基盤が持つべきです。CRM の内容を課金基盤に流し込む方向を一方通行にできるかがポイントになります。
• 突合の設計: 課金基盤が確定した請求金額と、会計システムに計上された金額が一致していることを、どの単位でどの頻度で照合するか。差異が出たときにどちらを直すか。
• 連携の粒度: 請求 1 件ごとに連携するのか、日次・月次で集計して連携するのか。監査対応の観点では、集計値から個別の請求まで遡れることが求められます。

この設計を担当した経験は、職務経歴書で最も差がつく部分の一つです。「会計システム連携を実装」ではなく「請求と会計の突合設計を担当し、差異検知を日次で自動化した」と書ける経験は、汎用バックエンドの枠には収まりません。

課金基盤エンジニアのフリーランス案件と単価相場

ここからが本題です。課金基盤 単価は、汎用バックエンドの相場に何がどう上乗せされるのかという形で考えると理解しやすくなります。

基準線 — 汎用バックエンドの単価相場

まず基準線を確認します。レバテックフリーランスの公表値では、掲載案件の平均単価は Go 言語が 83 万円、Ruby が 81 万円、Python が 77 万円、PHP が 71 万円、Java が 68 万円です。職種別ではシステムエンジニアが 72 万円、サーバーエンジニアが 69 万円、プログラマーが 66 万円となっています（レバテックフリーランス 単価相場）。

つまり、サーバーサイドの汎用スキルで戦う場合、月額 70〜80 万円台がボリュームゾーンです。バックエンド全般の相場の考え方は バックエンドエンジニアの単価相場 で整理しているので、基礎的な相場観はそちらを参照してください。本記事では、この基準線に課金基盤の専門性がどう上乗せされるかに集中します。

関与度合いで分かれる3層のレンジ

課金基盤の案件は、求められる関与の深さによって性質が大きく変わります。以下は、案件要件と汎用相場から推定したレンジであり、公表統計ではありません。あくまで目安としてお読みください。

レンジが重なっているのは、層の境界が稼働日数や商流によっても動くためです。重要なのは金額そのものより、どの層の仕事をしているかを自分で判定できることです。

層と層の間にある3つの壁

層が上がらない理由は、経験年数ではありません。次の 3 つの壁のどれかを越えていないことが原因です。

壁1: 会計要件を自分で詰められるか。 層 1 と層 2 を分けるのは、経理から降りてきた要件をそのまま実装するのか、経理に対して「その要件だと締め後の訂正が説明できなくなるので、こう分けませんか」と提案できるのかの差です。前者は実装者、後者は設計者として値付けされます。

壁2: 内製かビリング SaaS かを根拠つきで判断できるか。 「Stripe Billing に寄せるべきでしょうか」と聞かれたときに、「調べておきます」で終わるか、判断軸をその場で提示できるかの差です。判断軸については、後述の言語化のセクションで具体的に整理します。

壁3: 事故の影響範囲を先に設計できるか。 二重請求が起きたら誰が何時間で気づくのか、気づいたあと何を止めて何を継続するのか、顧客への通知は誰が出すのか。これを実装前に設計に織り込めるかどうかが、層 2 と層 3 を分けます。この視点は、障害を経験していないと出てこないため、経験の価値が最も素直に値段に転換される部分でもあります。

業界特化で上げる道との違い

単価を上げる道筋には、職能を深める方向のほかに、業界に特化する方向もあります。フィンテック領域のように規制対応が参入障壁になっている業界では、業界知識そのものが単価に転換されます。この道筋については フィンテックエンジニアの案件とスキル で整理しています。

両者の違いは、汎用性にあります。業界特化は、その業界の案件が減ったときに単価が連動します。一方、課金基盤という職能は、サブスクリプション型の収益モデルを持つ企業であれば業界を問わず必要とされるため、業界の景気変動から相対的に独立しています。どちらが優れているという話ではなく、自分がどちらのリスクを取るかという選択です。両方を重ねられるなら、それが最も強い組み合わせになります。

経験を単価に反映させる言語化のしかた

ここまでで語彙は揃いました。最後に、いまの経験を面談で通じる形に変換する作業に入ります。値付けが変わるのは、経験が増えたときではなく、経験の説明の仕方が変わったときです。

「改修しました」を責任範囲・金額規模・設計判断で語り直す

職務経歴書に書かれがちな表現と、その言い換えを並べます。ポイントは、作業の名前ではなく、判断した内容と背負った範囲を書くことです。

あわせて、規模の情報を添えると説得力が変わります。「月次請求件数 ◯ 千件」「取扱高 月間 ◯ 千万円規模」「プラン数 ◯ 種類・通貨 ◯ 種類」といった数字は、責任の総量を一言で伝えます。守秘義務の範囲で、桁数だけでも示せると効果的です。

面談で問われる論点と回答の型

課金基盤の経験を評価できる面談者は、次のような質問をしてきます。答え方の型を用意しておくと、その場で考える負荷が下がります。

• 「プラン変更の按分はどう設計しますか」 → 正解を答えるのではなく、選択肢とトレードオフを先に置きます。「即時反映は顧客体験が良い一方、返金と売上取り消しが毎月発生します。次期反映は会計がきれいですが問い合わせが増えます。御社は BtoB で年額比率が高いとのことなので、アップグレードは即時、ダウングレードは次期反映が現実的だと考えます」という構造です。
• 「決済が失敗したらいつ止めますか」 → 事業判断であることを明示したうえで、判断材料を提示します。「停止のタイミングは事業側と決める前提ですが、BtoB では即日停止が現実的でないため、猶予期間を置いて段階的に機能を絞る設計を採ることが多いです。その際、どの機能から止めるかを先に決めておく必要があります」。
• 「締めたあとに訂正が必要になったらどうしますか」 → 監査の観点を持っていることを示します。「確定済みの請求は書き換えず、クレジットノートで差し引く方式が基本だと考えます。当月修正か翌月調整かは経理の締めスケジュール次第なので、そこは先に合意しておきたい点です」。

いずれも共通しているのは、断定せず、判断軸と確認したい点をセットで返す形です。課金基盤の設計に正解はないため、この応答の仕方自体が設計者としての振る舞いの証明になります。

内製 vs ビリング SaaS の判断軸を自分の言葉で持つ

壁 2 を越えるために、判断軸を整理しておきます。以下は絶対的な基準ではなく、議論を始めるための切り口として使えるものです。

面談でこの表の内容を口頭で展開できると、「調べておきます」との差は決定的になります。加えて、「どちらを選んでも移行期間の並走設計が最大の論点になります」と付け加えられると、実装ではなくプロジェクトの成否を見ている人だと伝わります。

課金の経験が浅い人が半年で参入する順序

ここまでを読んで「自分は層 1 にも届いていない」と感じた方に向けて、いまの立ち位置から入っていく順序を示します。課金基盤は、転職や案件の乗り換えをしなくても、いまの現場で経験を積める領域です。

現案件で拾える課金タスク

課金は、たいていの現場で「誰も積極的に取りに行かない領域」です。だからこそ、手を挙げれば任されます。次のようなタスクは、参入の入口として現実的です。

• 請求と入金の突合: 毎月経理が手作業でやっている突合を、部分的にでも自動化する。この作業を通じて、請求データの構造と会計側の見方の両方が分かります。
• 決済失敗の運用: 失敗した決済の一覧を確認し、失敗理由を分類する。理由ごとにリトライすべきかどうかを整理するだけでも、Dunning 設計の下地になります。
• プラン追加の要件詰め: 実装だけでなく、仕様の確認役を引き受ける。「途中で変更されたらどうしますか」「解約時の返金はどうしますか」と聞いて回るだけで、要件の抜けが見つかります。
• 過去の請求の再現: 特定顧客の過去 3 か月分の請求額を、契約情報から手計算で再現してみる。合わないポイントが、そのままデータモデルの弱点です。

いずれも、大きな改修の許可を取る必要がありません。小さく始めて、結果を記録しておくことが重要です。

学習の順序

課金基盤の学習は、技術から入ると全体像が掴めません。次の順序が効率的です。

1. 会計の基礎: 発生主義、前受金、未収入金といった概念を押さえる。簿記 3 級の範囲で十分です。ここを飛ばすと、経理との会話が翻訳作業になります。
2. 収益認識の考え方: 5 ステップの枠組みと、契約負債の扱いを理解する。SaaS の年額前払いがどう処理されるかを一つの例で追い切ると、応用が利きます。
3. ビリング SaaS の機能仕様: Stripe Billing のドキュメントを、実装ガイドではなく仕様書として読む。プロレーション・Dunning・請求書発行・クレジットノートが、どういう概念で整理されているかを掴むのが目的です。よく設計された製品の概念モデルは、そのまま設計の教科書になります。
4. 自分のプロダクトへの当てはめ: いま参画しているプロダクトの課金ロジックを、上記の概念に対応づけて読み直す。「これは実質的にプロレーションだが、ダウングレード時の扱いが決まっていない」といった発見が出てくれば、そこがあなたの提案材料です。

この順序を 3〜4 か月かけて進め、残りの期間で実際のタスクに当てていくと、半年後には層 1 の要件を満たした状態で語れるようになります。

案件の探し方

最後に、案件の探し方です。前述のとおり、募集要件は言語・データベース設計に翻訳されているため、職種名で検索しても見つかりません。探し方を変えます。

• 案件本文をキーワードで検索する: 職種ではなく、案件の説明文に含まれる語で探します。「課金」「請求」「サブスクリプション」「決済基盤」「収益管理」といった語が本文にあれば、課金基盤の要素を含む案件である可能性が高いです。
• プロダクトのフェーズで絞る: シリーズ B 以降で、プランの多階層化や海外展開に着手している SaaS は、起点 1・2 の状態にあることが多いです。企業側の資金調達や新料金の発表は、案件が出る少し前のシグナルになります。
• エージェントへの伝え方を変える: 「バックエンドができます」ではなく、「課金・請求まわりの設計から入れます。プラン変更の按分や締め処理の設計を担当してきました」と伝えます。エージェント側が案件を思い出す語彙が変わるため、紹介される案件の質が変わります。
• いまの現場に提案する: 最も確実なのは、参画中の現場で課金基盤の課題を自分から提案することです。実績を作ったうえで契約更新の交渉に臨むほうが、案件を探して単価を上げるより短い距離であることも少なくありません。

課金基盤は、目立つ領域ではありません。しかし、サブスクリプション型のビジネスがある限り、必ず誰かが背負わなければならない領域です。すでにその責任を背負ってきたのであれば、あとは正しい名前で呼び直すだけです。

関連情報

課金基盤や請求まわりの設計に関われる案件を探したい方は、Workee でご自身のスキルと希望条件に合う案件をご覧いただけます。稼働日数やリモート可否といった条件から案件を比較でき、プロフィールを登録しておくと条件に合った案件のオファーを受け取ることもできます。

Workee で案件を探す