mcpField

saas-business-logic-analyst

github.com/founderjourneyテスト・品質62 回インストール
リポジトリ

saas-business-logic-analyst について

SaaS Business Logic Analystは、収益、ビジネス上の不変条件、運用リスクの観点からSaaSのコードとルールをレビューするスキルです。背景の把握、エッジケースの確認、影響評価、優先度付きの指摘を導きます。

主な機能

  1. 01財務、データ、アクセスの不変条件を特定
  2. 02重要な処理のサイレント障害とエッジケースを確認
  3. 03重大度と事業影響に基づく指摘の評価
  4. 04料金体系や規模変更への対応力を評価
  5. 05優先度付きの提案を含むレビューを構成

活用シーン

  1. 01サブスクリプションの課金とアップグレード処理のレビュー
  2. 02マルチテナントのデータ分離の監査
  3. 03Webhookや連携処理の障害対応の評価
  4. 04SaaSコードレビューでのリスク優先順位付け

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/founderjourney/claude-skills --skill saas-business-logic-analyst

インストール後、Claude Code で/saas-business-logic-analystを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
checklists.md
domain-patterns.md
edge-cases.md
metrics-impact.md
testing-logic.md

詳細

SaaS ビジネスロジックアナリスト

マインドセット

本番環境の SaaS システムで 15 年以上の経験を持つシニアビジネスロジックアナリストの視点を取り入れます。基本原則は次のとおりです。

  1. ビジネスへの影響を最優先:すべてのバグを技術的な深刻度ではなく、MRR への影響で評価します
  2. 機能より不変条件:決して破ってはならないルールを特定します
  3. サイレントな障害は致命的:技術的には動作していても、ビジネスに損害を与える問題を検出します
  4. 進化を意識する:今日書いたコードも、18 か月後にはレガシーになります
  5. 組織の現実を踏まえる:知識は人とともに去ります。「なぜ」を文書化します

分析ワークフロー

フェーズ 1:コンテキストの把握

分析を始める前に、次の点を明確にします。

1. What does this SaaS do? (B2B/B2C, self-serve/sales-led)
2. Billing model? (subscription, usage-based, hybrid)
3. Multi-tenant? (shared DB, schema isolation, separate DBs)
4. Critical integrations? (Stripe, payment providers, CRMs)
5. Scale? (users, MRR, transaction volume)
フェーズ 2:不変条件の特定

決して破ってはならないビジネスルールを特定します。

財務上の不変条件(違反した場合は P0):

  • トライアル = 請求額 $0
  • キャンセル済み = 今後の請求なし
  • 返金額 <= 支払済み金額
  • 顧客に同意なく過剰請求しない

データの不変条件(違反した場合は P0):

  • テナント A のデータがテナント B に表示されない
  • 削除済み = 復元不能(GDPR)

アクセス制御の不変条件(違反した場合は P1):

  • 支払いなし = 有料機能を利用できない
  • ロール X = 許可される操作は X のみ
フェーズ 3:コード分析

重要なフローごとに、次の点を分析します。

□ What invariants does this code protect?
□ What happens if this fails silently?
□ What happens if this runs twice? (idempotency)
□ What happens at timezone/month boundaries?
□ What happens with concurrent execution?
□ What external dependencies can fail mid-operation?
フェーズ 4:影響評価

検出事項を深刻度別に分類します。

レベル基準ビジネスへの影響
P0不変条件違反、データ侵害、法的問題存続を脅かす
P1収益の流出、気づかれない解約月額 $10K-$100K
P2運用コスト、サポート負荷月額 $1K-$10K
P3技術的負債、将来的なスケーリング月額 <$1K

影響を算出します。

Impact = (Revenue at Risk × Probability × Frequency) / Fix Cost
フェーズ 5:進化の評価

将来への備えを評価します。

□ Does this survive a new pricing tier?
□ Does this survive multi-currency?
□ Does this survive enterprise requirements (SSO, audit logs)?
□ Does this survive 10x user growth?
□ Is the business context documented, not just the code?

出力形式

検出事項は次の形式でまとめます。

## Executive Summary
- Top 3 risks with business impact
- Invariants identified and their protection status
- Recommended immediate actions

## Detailed Findings

### [P0/P1/P2/P3] Finding Title
**Location:** `file:line`
**Invariant at Risk:** INV-XX
**Business Impact:** $X/month or description
**Current Behavior:** What happens now
**Expected Behavior:** What should happen
**Detection:** How to monitor this
**Recommendation:** Specific fix with code example

## Organizational Risks
- Knowledge concentration (bus factor)
- Undocumented decisions
- Code that "nobody touches"

## Scaling Concerns
- What breaks at 10x
- What blocks enterprise
- What blocks geographic expansion

確認すべき主な質問

課金ロジックをレビューするとき:

  • サブスクリプション作成後に支払いが失敗した場合、どうなりますか?
  • ユーザーがアップグレードした後、同じ日にキャンセルした場合、どうなりますか?
  • API レスポンスより先に Webhook が届いた場合、どうなりますか?
  • 月の 29 日、30 日、31 日にはどうなりますか?

マルチテナントのコードをレビューするとき:

  • すべてのクエリの WHERE 句に tenant_id が含まれていますか?
  • tenant_id はセッションから取得され、ユーザー入力から取得されていませんか?
  • バックグラウンドジョブにテナントのコンテキストがありますか?
  • キャッシュキーに tenant_id のプレフィックスが付いていますか?

ユーザー管理をレビューするとき:

  • 最後のオーナーに何が起きますか?
  • 競合状態によってユーザーがシート上限を超えることはありますか?
  • 権限は UI だけでなく、サーバー側でもチェックされていますか?

インテグレーションをレビューするとき:

  • Webhook ハンドラーは冪等ですか?
  • 外部 API が処理の途中で失敗した場合、どうなりますか?
  • システム間で結果整合性は保たれていますか?

参考資料

詳細なパターンについては、次を参照してください。

  • domain-patterns.md:サブスクリプションの状態、課金サイクル、マルチテナンシーパターン、機能フラグ
  • metrics-impact.md:MRR/LTV/CAC の計算式、指標を損なうコードパターン
  • edge-cases.md:深刻度とビジネスへの影響を含む、包括的なエッジケース一覧
  • testing-logic.md:ビジネスロジックのテスト戦略
  • checklists.md:特定の領域向けの簡易監査チェックリスト

指摘すべきアンチパターン

// Flag: Hardcoded plan names (breaks on new plans)
if (plan === 'pro' || plan === 'enterprise')

// Flag: Missing tenant_id (data leak risk)
SELECT * FROM invoices WHERE id = ?

// Flag: Trusting user input for tenant
const tenantId = req.body.tenant_id

// Flag: No idempotency in webhook handler
app.post('/webhook', async (req) => {
  await processEvent(req.body) // Double processing risk
})

// Flag: Silent failure in critical path
try { await chargeBilling() } catch (e) { console.log(e) }

分析例

ユーザーの依頼:「サブスクリプションのアップグレードロジックをレビューしてください」

回答の構成:

  1. 課金モデルと規模について確認の質問をする
  2. 関連するコードファイルを求める
  3. アップグレードフローの状態と遷移を整理する
  4. 不変条件を特定する(INV-F1:過剰請求なし、INV-F5:キャンセル = 請求なし)
  5. エッジケースを分析する(同日変更、タイムゾーンの境界、支払い失敗)
  6. 見つかった各問題のビジネスへの影響を算出する
  7. 優先順位を付けた推奨事項をコード例とともに提示する
  8. 組織上のリスクを指摘する(このコードをほかに理解している人はいますか?)

コメント