MAS-062: PSF プロフィタビリティ指標拡張（Rule of Three 動的分解 + 価値ベース課金移行可視化）

概要

目的

既存の MAS-003（KPI ダッシュボード ✅）/ MAS-024（BEP 分析 ✅・P/L 末尾拡張の前例）/ MAS-051（PSF KPI ダッシュボード 仕様書未着手）/ MAS-043（RICE/VALUE/SEED 2 トラック採算）はカバー範囲が断片的で、「Rule of Three の構造分解 + 価値ベース課金への移行可視化」を扱う統合仕様は空白。

伝統的な「Rule of Three（時間単価×3 倍）」は稼働率 70% + 十分なレバレッジ + 安定した受注フロー が前提だが、ブティック（数人規模）では稼働率 40-55%（創業者が営業・経営・経理兼務）+ レバレッジ不在 + 安定受注の弱さで前提が崩れる。本案件は**「3 倍の時間単価を追うより、6-10 倍相当の利益率を出す案件設計」**へのシフトを P/L 上で可視化し、bizlp 経営者が時間単価モデルから脱却するきっかけを継続提供する。世界の海外 FP&A SaaS（Pigment / Causal / Runway / Mosaic）は時間単価ベースの稼働率管理は扱うが「時間単価モデル vs バリューベースモデルの並列対比」と「6-10 倍相当利益率の達成度シグナル」は不在で、bizlp の差別化機会となる。

現在のコード

本案件は MAS-024 BEP 分析が確立した「P/L 末尾拡張ブロック」パターンに 3 つ目のブロックとして追加する形で実装する。新規ロジックは PSF メトリクス算出（倍率・稼働率・実効回収率・バリューベース指標）と信号機判定のみで、P/L 集計・MAS-003 KPI ダッシュボード描画は既存関数を流用する。

MAS-024 BEP 分析（✅ 完了）の P/L 末尾拡張パターン

MAS-003 KPI ダッシュボード（✅ 完了）の信号機ロジック

93_kpi_dashboard の条件付き書式は Utils.applyTrafficLight_(range, thresholds) を共通ヘルパとして既に持つ。本案件は同関数を呼び出して PSF 信号機（🟢/🟡/🔵）を統一描画する。

MAS-218 タイムトラッキング（未着手・前提）

稼働率の分母（総労働時間 = F-ClientWork タグ + F-Internal タグ + F-Sales タグ）と分子（F-ClientWork タグ）を提供する想定。MAS-218 着手前の暫定運用は 手動入力モード（03_sys_params の F62_MANUAL_UTILIZATION_RATE を読む）で対応する（注意事項 #4 参照）。

32_wrk_invoice の契約形態タグ拡張

現状の INV エンティティに「契約形態」列が存在しない。本案件で contractType 列を追加する（4 値: time_based / fixed_price / retainer / ip_license）。既存 INV は default time_based で初期化（マイグレーション 8XX_migration_f62_contract_type.js を新設）。

修正方針

Step 1 — PSF メトリクス 2 ブロック設計

P/L 末尾に 「PSF メトリクス（時間単価モデル分解）」 と 「価値ベース指標（バリューベース課金分解）」 の 2 ブロックを並列配置する。

ブロック A: PSF メトリクス（時間単価モデル分解）

ブロック B: 価値ベース指標（バリューベース課金分解）

Step 2 — 入力次元の整理

Step 3 — 信号機シグナル設計

Step 4 — 純粋関数エンジン実装

// 400_domain/453_psf_profitability_engine.js (純粋関数 + IIFE 名前空間)

var PsfProfitabilityEngine = (function () {
  /**
   * @param {Object} input
   * @param {number} input.revenue                 期間売上（円）
   * @param {number} input.billableHours           Billable 時間（h）
   * @param {number} input.totalLaborHours         総労働時間（h）
   * @param {number} input.laborCost               人件費（円・HC RPA 集計）
   * @param {number} input.indirectCost            間接費（円）
   * @param {Object[]} input.invoices              [{contractType, amount, billableHours}]
   * @param {Object} [input.params]                03_sys_params override
   * @returns {{multiplier, utilization, effectiveRecovery, valueBasedRatio,
   *            valueBasedMultiplier, signal, breakdown}}
   */
  function computePsfMetrics(input) {
    var p = input.params || _loadParamsFromSysParams_();

    // ブロック A: 時間単価モデル
    var hourlyRate = input.revenue / input.billableHours;
    var laborRatePerHour = input.laborCost / input.totalLaborHours;
    var multiplier = hourlyRate / laborRatePerHour;
    var utilization = input.billableHours / input.totalLaborHours;
    var effectiveRecovery = multiplier * utilization;

    // ブロック B: 価値ベース
    var valueBasedRevenue = input.invoices
      .filter(function (i) { return ['retainer','fixed_price','ip_license'].indexOf(i.contractType) >= 0; })
      .reduce(function (s, i) { return s + i.amount; }, 0);
    var valueBasedRatio = valueBasedRevenue / input.revenue;
    var valueBasedMultiplier = (valueBasedRevenue / _sumValueBasedHours_(input.invoices)) / laborRatePerHour;

    var signal = _classifySignal_(multiplier, utilization, valueBasedRatio, valueBasedMultiplier, p);

    return {
      multiplier: multiplier,
      utilization: utilization,
      effectiveRecovery: effectiveRecovery,
      valueBasedRatio: valueBasedRatio,
      valueBasedMultiplier: valueBasedMultiplier,
      signal: signal,
      breakdown: _buildBreakdown_(input, p)
    };
  }

  function _classifySignal_(m, u, vbr, vbm, p) {
    if (vbr >= p.valueBasedTargetRatio && vbm >= p.valueBasedMultiplierTarget) return 'BLUE';   // 🔵
    if (m < 2 && u < 0.40) return 'RED';                                                         // 🔴
    if (m >= p.targetMultiplier && u >= 0.60) return 'GREEN';                                    // 🟢
    return 'YELLOW';                                                                             // 🟡
  }

  return { computePsfMetrics: computePsfMetrics };
})();

純粋性の維持: SpreadsheetApp 呼び出しはせず、入力値で完結。シート連携は 600_report/603_datamart_pl.js 側のラッパー関数 renderPlPsfSection_(sheet, metrics) が担当。

Step 5 — P/L 末尾セクション統合 + 93_kpi_dashboard 拡張

600_report/603_datamart_pl.js の改修:

function refreshPlDatamart() {
  var sheet = _getOrCreateSheet_('92_fs_pl');
  var plData = _aggregatePl_();

  _renderPlMain_(sheet, plData);                    // 既存
  renderPlBepSection_(sheet, plData);               // 既存（F-24）
  renderPlPsfSection_(sheet, plData);               // 新規（F-62）← 本案件で追加
  // 将来: renderPlNonOperatingSection_(sheet, plData) (F-63)
}

93_kpi_dashboard 拡張:

MAS-003 既存ダッシュボードに以下 4 セルを追加:

• 倍率（信号機 🟢/🟡/🔴 + 数値）
• 稼働率（信号機 + %）
• 実効回収率（数値）
• バリューベース売上比率（信号機 🔵/灰 + %）

Utils.applyTrafficLight_(range, F03_PSF_THRESHOLDS) を新設して MAS-003 と統一描画。

影響範囲

注意事項

1. MAS-218 タイムトラッキング着手前の暫定運用: 稼働率の分母となる F-ClientWork / F-Internal / F-Sales タグ集計は MAS-218 で実装される。本案件着手時点で MAS-218 が未完了なら、03_sys_params.F62_MANUAL_UTILIZATION_RATE（default 0.50）を毎月手動更新する暫定モードを採用。MAS-218 完了後にデータソース切替（呼出側を 1 行差し替えるだけで済む構造にする）。

2. 業態 default の妥当性: 本 spec の default（ブティック 50% / 大手 70%）は use_cases.md BZ-1〜BZ-5 のコンサル/受託前提。SaaS / 物販 / 製造業など他業態向けプリセットを v1 時点で用意するか v2 に持ち越すかは商用化時期判断（MAS-058 と同じ業態プリセット機構を将来共有）。

3. INV 契約形態タグの後方互換: 32_wrk_invoice への列追加はマイグレーション 8XX で既存行を time_based で初期化する。手動更新は INV 編集画面の dropdown（4 値）で対応。マイグレーション未実行時は新規エンジンが undefined を time_based 扱いに fallback するロジックを内蔵（防御的プログラミング・failure_patterns #19）。

4. MAS-043 RICE/VALUE/SEED との対応関係: MAS-043 は案件評価軸として VALUE トラックを定義済み。MAS-043 の VALUE = INV の fixed_price + retainer + ip_license という対応関係を spec に明記し、二重定義による誤解を防ぐ。MAS-043 実装後の整合性チェックを単体テスト F62-12 に追加。

5. 6-10 倍ターゲットの根拠: 戦略メモ §3 の「代替困難な専門領域では 4-5 倍も射程・小規模ファームでバリューベース移行で 6-10 倍相当」をベースに F62_VALUE_BASED_MULTIPLIER_TARGET = 6.0 を採用。SPI Research 2025 等の業界二次ソースで検証を継続（MAS-051 着手時に再評価）。

6. 稼働率の信号機閾値（60%）の妥当性: 戦略メモ §2-1 のブティック 40-55% を踏まえ、目標を 60% に設定。SPI Research 2025 Billable Utilization 中央値 68.9%（MAS-051 spec で定義）と整合。ブティック default 50% は「目指すべき下限」ではなく「現実値」として運用する点を UI 上で明示。

7. failure_patterns #25 遵守（並列実装対称性）: MAS-024 BEP セクションと完全に対称な構造を保つ。renderPlBepSection_ ↔ renderPlPsfSection_、F03_BEP_THRESHOLDS ↔ F03_PSF_THRESHOLDS のペアで命名統一。

8. failure_patterns #18-#20 遵守（命名造語禁止）: 関数名 computePsfMetrics / renderPlPsfSection_ は既存命名と整合（動詞 + 目的語）。「PSF」は Professional Services Firm の業界標準略称・新語ではない。Read で既存ファイルに同名関数がないことを着手時に裏取り。

9. failure_patterns #26 遵守: appsscript.json の OAuth スコープは変更不要（既存スコープ内で完結）。

10. 顧客向けサービス化時のテンプレート粒度: 商用化時に PSF 業態専用テンプレートとして切出すか、汎用 KPI として MAS-003 配下に統合するかは PH-4 商用化期に判断（MAS-051 PSF KPI ダッシュボードと統合可能性あり）。v1 では bizlp 自身の運用で実証する段階に絞る。

11. 戦略メモ更新時の MAS-062 spec 同期フロー: docs/_internal/biz/pricing_strategy_rule_of_three.md が更新されたら、本 spec の §目的・§注意事項 #5 / #6 を再点検。戦略メモは経営者本人の SSoT・spec はそれを実装に落とした派生物 という関係性を保つ。

12. バリューベース実効倍率の計算境界: 分母の「投入時間」がゼロのリテイナー（成果物提出のみ）の扱い。spec では _sumValueBasedHours_ でゼロ除算を回避し、ゼロ時はリテイナー単独売上を別表示する分岐を内蔵。

13. MAS-029 Unit Economics との関係: MAS-029 は LTV/CAC など SaaS 指標。本案件は PSF（受託/コンサル）指標。両者は業態軸が異なり並列共存で、UI 上で「業態に応じてどちらを表示するか」をテナント設定 Constants.getParam('TENANT_BUSINESS_TYPE') で切替（MAS-219 ADR-0009 連動）。

エッジケース

実データ検証

1. bizlp 自身の現状値（戦略メモ §5 をテストフィクスチャ化）

実装完了後に以下を 901_test_runner.js で自動検証し、±10% 以内で一致を合格基準とする（戦略メモは「推計」ベースのため許容幅を MAS-058 より広く取る）。

2. 6-10 倍相当の達成シミュレーション

戦略メモが示す「6-10 倍相当の利益率を出す案件設計」のターゲット状態を入力して 🔵 シグナルが点灯することを検証:

• バリューベース売上比率 60% / 価値ベース実効倍率 7.0 → 🔵 達成
• バリューベース売上比率 60% / 価値ベース実効倍率 5.5 → 🟡（実効倍率不足）
• バリューベース売上比率 40% / 価値ベース実効倍率 7.0 → 🟡（バリューベース比率不足）

3. MAS-003 KPI ダッシュボード閾値との整合確認

PSF 信号機が MAS-003 既存 KPI（労働分配率・営業利益率・ランウェイ）と矛盾しないことを実機検証。「PSF 🟢 なのに MAS-003 営業利益率 🔴」は閾値不整合のサインとして spec 側の調整対象。

4. MAS-043 VALUE トラックとの整合（MAS-043 実装後）

MAS-043 着手後、MAS-043 の VALUE 売上集計と本案件のバリューベース売上が ±1 円一致 することを単体テスト F62-12 で検証。

5. エッジケース検証（単体テスト F62-01〜F62-13）

エッジケースセクションの 13 項目それぞれを 1 テストケースとして 901_test_runner.js に追加。

関連ドキュメント

人間が検討すべき事項

1. 業態 default 細分化粒度: ブティック 50% / 大手 70% / コモディティ 40% の 3 段階で十分か。SaaS / 物販 / 製造業の業態追加は v1 vs v2。商用化時期と直結。

2. バリューベース売上の判別ロジック: INV 契約形態タグ拡張で対応するか、別途プロジェクト属性管理（14_mst_project に列追加）にするか。MAS-043 起票時のスキーマ判断と統合検討。

3. 6-10 倍ターゲットの根拠: 業界ベンチマーク確認（SPI Research 2025 / Deltek / Service Performance Insight 等の二次ソース）。MAS-051 着手時に再評価。

4. MAS-218 タイムトラッキング着手前の暫定運用: 手動入力 vs 計算スキップの選択。spec は「手動入力 default 0.50 + バッジ表示」を採用したが、ユーザー運用負荷を考慮して計算スキップ（PSF セクション非表示）も選択肢。

5. MAS-043 RICE/VALUE/SEED との整合性: MAS-043 の VALUE トラック ≒ 本案件のバリューベース売上の対応関係を spec で明示したが、MAS-043 着手時に齟齬がないか再点検。両者の整合性テスト F62-12 を必須化。

6. 顧客向けサービス化時のテンプレート粒度: PSF 業態専用テンプレート vs 汎用化。商用化時の SKU 設計に影響。

7. 戦略メモ更新時の MAS-062 spec 同期フロー: SSoT 更新の検知方法（git hook / 手動レビュー）。docs/_internal/biz/ 全般の同期ルール化が必要。

8. PSF 信号機の閾値カスタマイズ性: テナント別 F62_* を許可するか、業態 default を強制するか（商用化時のサポート負荷とのトレードオフ）。

9. MENU 配置カテゴリ: 現状 spec は「📊 マート更新」配下に「PSF プロフィタビリティ更新」を配置。refreshPlDatamart() から自動呼出のため独立メニューは optional。MAS-024 BEP と並列で削除も検討可。

10. リテイナー収益安定率の計算窓: 直近 3 ヶ月 vs 6 ヶ月 vs 12 ヶ月。短期は感度高・長期は安定。bizlp 規模では 3 ヶ月推奨だが SaaS 顧客向けには 12 ヶ月が妥当か。

実装プロンプト（Claude Code 用）

Claude Sonnet 4.6 推奨。MAS-024 BEP セクションの拡張パターンに MAS-058 spec の純粋関数 + 信号機ロジックを組合せる中難易度。

## 案件
MAS-062 — PSF プロフィタビリティ指標拡張（Rule of Three 動的分解 + 価値ベース課金移行可視化）

## 事前調査（必ず Read する）
1. `docs/dev/dev_mas-062_psf_profitability_extension.md` 全文（本仕様書）
2. `docs/_internal/biz/pricing_strategy_rule_of_three.md` 全文（戦略 SSoT）
3. `docs/dev/dev_mas-024_bep_analysis.md` — P/L 末尾拡張パターンの先例
4. `docs/dev/dev_mas-058_required_revenue_solver.md` — 純粋関数 + 信号機ロジックの手本
5. `docs/dev/dev_mas-003_kpi_dashboard.md` — 93_kpi_dashboard 拡張方法
6. `600_report/603_datamart_pl.js` — `renderPlBepSection_` 実装確認
7. `200_data/202_repository.js` — InvoiceRepository の API
8. `100_config/101_sys_config.js` — `32_wrk_invoice` DDL 拡張箇所
9. `docs/_internal/failure_patterns.md` #18-#20 / #25 / #26

## 実装対象

1. `400_domain/453_psf_profitability_engine.js` 新規（IIFE 名前空間 PsfProfitabilityEngine）:
   - computePsfMetrics(input) — メイン API
   - 内部ヘルパ: _loadParamsFromSysParams_ / _classifySignal_ / _sumValueBasedHours_ / _buildBreakdown_

2. `600_report/603_datamart_pl.js` 拡張:
   - renderPlPsfSection_(sheet, plData) を `renderPlBepSection_` 直下に追加
   - refreshPlDatamart() から呼出

3. `100_config/101_sys_config.js` 拡張:
   - 32_wrk_invoice DDL に contractType 列追加（4 値 enum）

4. `8XX_migration_f62_contract_type.js` 新規（番号は `ls 800_ops/` で次番取得）:
   - 既存 INV を contractType = 'time_based' で初期化（冪等）

5. `93_kpi_dashboard` セル追加（MAS-003 既存セルの右隣）+ 条件付き書式
   - 倍率 / 稼働率 / 実効回収率 / バリューベース売上比率 の 4 セル

6. `03_sys_params` の 6 キー追加（default は Constants.getParam の第 2 引数）

7. `900_test/901_test_runner.js` に F62-01〜F62-13 単体テスト

## 動作確認
1. bizlp 現状データで信号機が 🟡 表示
2. 6-10 倍シミュレーションで 🔵 表示
3. MAS-003 KPI ダッシュボードと閾値整合
4. エッジケース 13 項目すべて想定通り

## デプロイ
1. dev で push:dev → メニュー「📊 マート更新」実行 → 92_fs_pl 末尾の PSF セクション目視確認
2. Go なら push:prod
3. コミット: feat(MAS-062): PSF プロフィタビリティ指標拡張 (Rule of Three + バリューベース可視化)

## failure_patterns チェック
- #18-#20: computePsfMetrics / renderPlPsfSection_ を Read で裏取り
- #25: MAS-024 BEP セクションと対称構造
- #26: appsscript.json は変更なし

推奨実行モデル

変更履歴