MAS-033: Rule of 40 スコアボード

概要

目的

プロダクト事業の健全性を SaaS 業界標準指標「Rule of 40」（成長率 + 利益率 ≥ 40%）で可視化し、成長速度と収益性のバランスに関する経営意思決定を支援する。

Rule of 40 の背景: Brad Feld (Foundry Group) / Bessemer Venture Partners 等が提唱した SaaS 事業の健全性指標。「成長率を優先するか、利益率を優先するか」の二項対立を、両者の合計で総合評価する考え方で、40% 以上であれば「成長と利益のバランスが健全」とされる。

本機能の出力:

• プロダクト事業（フィルタ条件は 03_sys_params パラメータで指定）の月次スコアをダッシュボードシート 95_dashboard_rule_of_40 に表示
• 直近 13 ヶ月（または利用可能な全期間）の TTM 成長率・TTM 営業利益率・Rule of 40 スコアを時系列で並べ、推移を把握できるようにする
• Human-in-the-Loop: ヘッダー行に計算前提（フィルタ条件・利益率定義・成長率定義）を明記し、利用者が算出根拠を目視で検証できるようにする

現在のコード

新規実装。対応するシート・関数なし。

類似実装の参照元: 600_report/609_datamart_kpi.js（F-03 KPI ダッシュボード）

• 93_kpi_dashboard タブを ss.insertSheet() で動的生成し sheet.clear() でクリアしてから再描画するパターンを踏襲する
• 境界月の検出（仕訳から過去方向に非空セル末尾を走査）・行番号を事前計算してから setValues で一括書き込みする方式を踏襲する

関連する既存モジュール:

• 200_data/202_repository.js の JournalRepository.findAll() — 仕訳帳 DTO 取得（戻り値: { headers: string[], dtos: JournalEntryDTO[] }）
• 200_data/202_repository.js の AccountRepository.findAsMap() — 科目名 → {stmt, cat} マップ（キャッシュ付き。キャッシュは AccountRepository.resetCache() でリセット可能）
• 000_infra/002_constants.js の Constants.getParam(key, defaultVal) — 03_sys_params シート（列 A=キー / 列 B=値）からパラメータを読み取り、引数 defaultVal の型に応じて Number or String を返す。未設定時は defaultVal を返す
• 000_infra/004_utils.js の Utils.parseDateToYm(date) — Date | 文字列を YYYY-MM 形式に正規化するヘルパー（既存の 600_report/ で多用）
• 000_infra/002_constants.js の Constants.MENU_DEFINITION — メニューは宣言的定義で管理（ハードコードされた ui.createMenu() 呼び出しはない）

修正方針

アーキテクチャ概要

┌─────────────────────┐   ┌─────────────────────┐
│ 42_trn_journal      │   │ 11_mst_account      │
│ (JournalRepository) │   │ (AccountRepository) │
└──────────┬──────────┘   └──────────┬──────────┘
           │ findAll()                │ findAsMap()
           │ {headers, dtos}          │ {科目名: {stmt, cat}}
           ▼                          ▼
┌──────────────────────────────────────────────┐
│ 600_report/612_dashboard_rule_of_40.js       │
│   1. プロダクト事業フィルタ（PJ名/組織名）   │
│   2. 月次 TTM 集計（売上・費用の12ヶ月合計）│
│   3. 前年同月 TTM 成長率・TTM 営業利益率    │
│   4. Rule of 40 = 成長率 + 営業利益率        │
└──────────┬───────────────────────────────────┘
           │ setValues()
           ▼
┌──────────────────────────────────────────────┐
│ 95_dashboard_rule_of_40                      │
│  (動的生成シート・DDL setupAllSchemas 管理外)│
└──────────────────────────────────────────────┘

出力先シート

• シート名: 95_dashboard_rule_of_40
• DDL 管理: 管理対象外（setupAllSchemas に追加しない）
• CLAUDE.md 追記: ## DDL (setupAllSchemas) で管理されないタブ セクションに 95_dashboard_rule_of_40 を追記する（既存の 93_kpi_dashboard に続ける）
• 生成方法: ss.getSheetByName('95_dashboard_rule_of_40') が null の場合 ss.insertSheet()、存在する場合は sheet.clear() で全消去してから再描画（609_datamart_kpi.js の buildKpiDashboard と同一パターン）

データ取得

var journal = JournalRepository.findAll();  // {headers, dtos: JournalEntryDTO[]}
var acctMap = AccountRepository.findAsMap(); // {科目名: {stmt: 'P/L'|'B/S', cat: '売上高'|...}}

• JournalEntryDTO のプロパティは 000_infra/003_contracts.js の @typedef に準拠
• 使用するキー: 発生日(P/L計上日) / 科目名 / 税抜金額_実績 / PJ名 / 組織名 / 仕訳ステータス / 収支区分
• findAsMap() の戻り値構造は {stmt, cat} であり、findAsMap_() 等の派生関数名は存在しない（Phase 1 で 202_repository.js L323-341 を Read して確認済み）

集計単位（TTM: Trailing Twelve Months）

各基準月 YM について、発生日(P/L計上日) が YM - 11ヶ月 から YM の範囲に入る仕訳を集計する。

• 基準月の列挙: 仕訳の最古月〜最新月を Utils.parseDateToYm() で収集し、ユニーク化して昇順ソート
• TTM 集計の最小データ要件: YM 時点で基準月を含む 12 ヶ月のデータが必要。不足月は "-" 表示
• YoY 成長率の最小データ要件: YM と YM - 12ヶ月（前年同月）の両時点で TTM が計算可能であること（= 24 ヶ月以上のデータが必要）

計算定義（暫定。「人間が検討すべき事項」確定後に最終化する）

以下 3 点は Phase 1 のコード調査時点での暫定定義。実装前に MCP 実データ検証（後述）と「人間が検討すべき事項」で確定させる。

注記: 「売上」に該当する 大分類 の正確な文字列は 11_mst_account の実データに依存するため、実装時に MCP で確認する（後述「実データ検証」）。

プロダクト事業フィルタ

• フィルタ対象: JournalEntryDTO.PJ名 または JournalEntryDTO.組織名（どちらを使うかは「人間が検討すべき事項」で確定）
• パラメータ取得: Constants.getParam('RULE_OF_40_FILTER_KEY', 'PJ名') および Constants.getParam('RULE_OF_40_FILTER_VALUE', '') を 03_sys_params から読み取る
  • RULE_OF_40_FILTER_KEY: 'PJ名' | '組織名'（デフォルト: 'PJ名'）
  • RULE_OF_40_FILTER_VALUE: 完全一致する値（例: 'プロダクト事業'）。空文字の場合はフィルタなし（全仕訳が対象）＋ Utils.logInfo で警告出力
• マッチング方式: 完全一致（trim().equals()）。複数値対応が必要になったらカンマ区切り対応を検討（将来拡張）

HitL 対応（Human-in-the-Loop）

ダッシュボードのヘッダー領域（A1:H4 程度）に計算前提を明記:

メニュー登録

• 宣言的定義: 000_infra/002_constants.js の Constants.MENU_DEFINITION に追加する（onOpen() の実装は MENU_DEFINITION を動的展開するため、ui.createMenu() をハードコードしない）
• 追加先カテゴリ: '📋 サイドバー: 📊 マート更新'（F-03 KPI ダッシュボード等が所属する既存カテゴリ）
• 追加項目: { label: '📏 Rule of 40 スコア更新', funcName: 'buildRuleOf40Dashboard', description: '95_dashboard_rule_of_40 (Rule of 40 スコアボード) を再計算' }
• 造語禁止: '📋 サイドバー: 📊 マート更新' は Phase 1 で 002_constants.js L230 を Read して実在を確認した文字列。新規カテゴリは作成しない

影響範囲

変更ファイル

変更しないファイル

• 42_trn_journal（読み取り専用）
• 11_mst_account（読み取り専用）
• 100_config/101_sys_config.js の setupAllSchemas / DDL 定義（95_dashboard_rule_of_40 は DDL 管理外）
• 100_config/101_sys_config.js の onOpen() 本体（MENU_DEFINITION を動的展開しているため、メニュー追加は 002_constants.js 側のみ）
• 000_infra/003_contracts.js（既存の JournalEntryDTO @typedef をそのまま使用）
• 200_data/202_repository.js（既存の JournalRepository / AccountRepository をそのまま使用）

既存動作への影響

• 読み取り専用・独立ダッシュボード出力のため、トランザクションデータや既存マート（61_pl_monthly 等）への副作用はない
• AccountRepository.findAsMap() のキャッシュ（_cache）を共有利用するが、Read 専用なので他機能のキャッシュ状態を破壊しない

注意事項

1. 読み取り専用設計: この機能は 42_trn_journal と 11_mst_account を読み取り専用で集計し、独立したダッシュボードシート 95_dashboard_rule_of_40 に書き出す。トランザクションデータへの二重更新リスクはないため、排他ロック機構（LockService）は不要
2. 列参照はヘッダー名ベース: 42_trn_journal / 11_mst_account のアクセスは JournalRepository.findAll() / AccountRepository.findAsMap() 経由で行うため、DTO プロパティ名（= ヘッダー名）でアクセスする。列番号ハードコード禁止（CLAUDE.md コーディング規約準拠）
3. 有効フラグ=FALSE はスキップ: AccountRepository.findAsMap() は内部で 有効フラグ が FALSE のレコードを既にスキップしている（202_repository.js L330 で確認済み）。JournalRepository は 有効フラグ 列を持たないため追加スキップ不要
4. 存在しない関数名を使用しない: AccountRepository.findAsMap_() / findAccountMap_() 等の派生関数名は存在しない。必ず findAsMap()（アンダースコア末尾なし、_ は cache と resetCache のみ）を使用する
5. 仕訳ステータスの完全一致判定: 仕訳ステータスコード === "JSTAT_REVERSAL" 等のコード値や 仕訳ステータス === "仕訳振替" の文字列で判定する場合は === の完全一致。実際の格納値は実データ検証で確認（CLAUDE.md「仕訳振替の判定は === "仕訳振替" の完全一致」規約準拠）
6. メニューは MENU_DEFINITION 経由: 100_config/101_sys_config.js の onOpen() には直接編集を加えず、000_infra/002_constants.js の Constants.MENU_DEFINITION に宣言的に追加する（ハードコード禁止）
7. 絶対値計算の取り扱い: 費用は 税抜金額_実績 が正値で入っている前提（科目の符号反転は DTO レベルでは行わず、集計時に Math.abs() で絶対値化する）。実際の符号は MCP 実データで確認する
8. TTM 集計の性能: 仕訳件数 × 月数のループで O(N × M) になるため、前処理で仕訳を YYYY-MM → sumMap に集約してから月次ループを回す実装にすること（609_datamart_kpi.js の境界月検出パターンを参考に）

エッジケース

実データ検証

実装前に MCP ツールで以下を確認すること（Phase 1 のコード読み取りでは確定できない、実データ依存の情報）:

注意: 本仕様書では暫定定義として 大分類 === '売上高' を使うが、実データの実値により Constants.RULE_OF_40_SALES_CATEGORIES = ['売上高', '売上高(本業)'] 等の配列定数に外出しする設計に変更する可能性がある。MCP 検証時に決定すること。

関連ドキュメント

人間が検討すべき事項

TODO_future.md の F-33 行から転記: 「利益率の定義（営業利益率 vs EBITDA margin）。成長率の算出期間（MoM vs YoY）」

上記 2 点に加え、以下 5 項目を実装前に確定する必要がある。

1. プロダクト事業の識別方法（実装前の必須判断）

• 論点: 42_trn_journal の PJ名 でフィルタするか、組織名 でフィルタするか、両方の AND/OR 条件が必要か
• 選択肢:
  • A. PJ名 単独フィルタ（本仕様書のデフォルト）: シンプルだが、PJ 名が「プロダクト」プレフィックスで統一されていないと漏れる
  • B. 組織名 単独フィルタ: プロダクト事業部が組織として独立している前提。受託 PJ が同じ組織名で計上されていると混在する
  • C. PJ名 AND 組織名 の複合フィルタ: 最も正確だが運用負荷が高い
  • D. 14_mst_project マスタに「事業区分」列を追加し、マスタ経由で識別: 本格運用向き（F-32 プロダクト別 P/L と共通基盤化可能）
• 判断タイミング: F-33 実装前。F-32（プロダクト別 P/L）が先行実装される場合は D 案で統合する
• 本仕様書のデフォルト: A 案。Constants.getParam('RULE_OF_40_FILTER_KEY', 'PJ名') で切替可能にする

2. 利益率の定義（TODO_future.md 元記載項目）

• 論点: 営業利益率（デフォルト）と EBITDA マージンのどちらを採用するか
• 選択肢:
  • A. 営業利益率 = (TTM売上 − TTM全費用) / TTM売上 × 100（本仕様書のデフォルト）: 一般企業の標準指標
  • B. EBITDA マージン = (営業利益 + 減価償却費 + 無形資産償却費) / TTM売上 × 100: SaaS 業界標準。資本集約度が異なる企業間の比較に有利
• EBITDA 採用時の追加作業:
  1. 11_mst_account で減価償却費・のれん償却費等に該当する科目名を特定（例: '減価償却費' / '無形固定資産償却費'）
  2. 特定科目の金額を営業利益に足し戻す処理を追加
• 本仕様書のデフォルト: A 案。将来的に B 案に切り替える場合は Constants.getParam('RULE_OF_40_PROFIT_METRIC', 'OPERATING') で 'OPERATING' / 'EBITDA' を切替可能にする設計を取る

3. 成長率の算出期間（TODO_future.md 元記載項目）

• 論点: MoM（Month-over-Month、前月比）と YoY（Year-over-Year、前年同月比）のどちらか
• 選択肢:
  • A. TTM YoY 成長率（本仕様書のデフォルト）: (当月TTM − 前年同月TTM) / |前年同月TTM| × 100。季節変動を吸収する SaaS 業界標準
  • B. MoM 成長率: (当月TTM − 前月TTM) / |前月TTM| × 100。変化の検知が早いが季節変動を拾う
  • C. MoM 成長率を年率換算: ((当月TTM / 前月TTM)^12 − 1) × 100。単月の変動が年率に増幅されるため推奨しない
• 本仕様書のデフォルト: A 案

4. 成長率のデータソース（F-28 との依存判断）

• 論点: 成長率指標のベースを 42_trn_journal ベースの TTM 売上高 YoY とするか、F-28（ARR/MRR）実装後の ARR YoY とするか
• 選択肢:
  • A. 42_trn_journal TTM 売上 YoY（本仕様書のデフォルト・F-28 非依存）: F-33 を F-28 より先に実装可能。ただしストック収益（MRR）とフロー収益（スポット）が混在した指標になる
  • B. F-28 の ARR YoY 成長率（F-28 依存）: SaaS 的には正統。ただし F-28 のステータスは現時点「未着手」（Phase 1 で TODO_future.md L266 を確認済み）
• 判断タイミング: F-28 のスコープ確定後。F-28 が実装されるまでは A 案で先行運用し、F-28 完了後に B 案へ切り替える（Constants.getParam('RULE_OF_40_GROWTH_SOURCE', 'JOURNAL_TTM_SALES') 切替）
• 本仕様書のデフォルト: A 案（F-28 非依存で先行実装可能とする）

5. 仕訳ステータスのフィルタ方針

• 論点: どの 仕訳ステータス を集計対象に含めるか
• 選択肢:
  • A. '自動計上' のみ: RPA 経由の信頼できる仕訳に限定。手動入力ミスを排除
  • B. '自動計上' と '手動' の両方を対象、'仕訳振替' のみ除外（本仕様書のデフォルト）: 人手確認済みの手動仕訳も含めて実態を把握。仕訳振替は二重計上防止のため除外
  • C. 全ステータスを対象: 最も包括的だが、検討用の仕訳振替まで入ってしまう
• 判断タイミング: 実データ検証（上記「実データ検証」#2）完了後
• 本仕様書のデフォルト: B 案

6. 判定閾値の調整可能性

• 論点: スコア 40 固定で良いか、段階判定（40 未満 = 要改善 / 40〜60 = 良好 / 60 以上 = 優秀）が必要か
• 選択肢:
  • A. 40 固定の 2 段階（本仕様書のデフォルト）: ✅ OK / ⚠️ 要改善
  • B. Constants.getParam('RULE_OF_40_THRESHOLD', 40) で閾値を可変化
  • C. 3 段階 or 5 段階（例: 60 以上 🚀 優秀 / 40〜60 ✅ OK / 20〜40 ⚠️ 要改善 / 0〜20 🔴 警戒 / 0 未満 🚨 緊急）
• 本仕様書のデフォルト: A 案（運用開始後に B/C へ拡張）

7. 再実行頻度と月次スナップショット保存の要否

• 論点: 毎回 95_dashboard_rule_of_40 を全置換する方式で運用するか、月次でスナップショットを別シートに保存するか
• 本仕様書のデフォルト: 全置換方式（93_kpi_dashboard と同じ運用）。スナップショットが必要になったら別途 96_snapshot_rule_of_40_YYYYMM 的な保存機能を追加（F-02 前年度 P/L スナップショットに類似）

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

実装時は以下のプロンプトを Claude Code に与えて自律実行させる。行頭 4 スペースインデントで記述（コードブロック不使用）:

あなたはGAS会計システム(bizlp-gas-accounting)のシニア開発者です。
案件 F-33「Rule of 40 スコアボード」を実装してください。

## 実行前タスク（全て Read で裏取りすること。名前から推測しない）

1. `000_infra/003_contracts.js` を Read し、JournalEntryDTO の全プロパティ名を確認する
   （特に `発生日(P/L計上日)` / `科目名` / `税抜金額_実績` / `PJ名` / `組織名` /
   `仕訳ステータス` / `収支区分` の実際のキー文字列）
2. `200_data/202_repository.js` を Read し、以下を確認する:
   - JournalRepository.findAll() の戻り値型が { headers: string[], dtos: JournalEntryDTO[] }
   - AccountRepository.findAsMap() の戻り値型が { [科目名]: {stmt, cat} }
   - findAsMap_() / findAccountMap_() 等の派生関数名は存在しない
3. `000_infra/002_constants.js` を Read し、以下を確認する:
   - Constants.getParam(key, defaultVal) が 03_sys_params からパラメータを読む
   - MENU_DEFINITION の '📋 サイドバー: 📊 マート更新' カテゴリの配置順
4. `600_report/609_datamart_kpi.js` を Read し、以下のパターンを踏襲する:
   - ss.insertSheet() + sheet.clear() による動的生成
   - 境界月検出・行番号事前計算・一括 setValues()
5. `000_infra/004_utils.js` を Read し、Utils.parseDateToYm() / Utils.logInfo() /
   Utils.logError() のシグネチャを確認する
6. MCP で以下を確認する（実データ依存項目）:
   - 11_mst_account の `大分類` 列の実値一覧（売上に該当する文字列特定）
   - 42_trn_journal の `仕訳ステータス` 列の実値一覧
   - 42_trn_journal の `PJ名` / `組織名` 列の実値一覧（プロダクト事業の識別値）
   - 42_trn_journal の `税抜金額_実績` の符号運用（費用が正値か負値か）

## 修正対象ファイル

- `600_report/612_dashboard_rule_of_40.js`（新規作成・約250行）
  - エントリ関数: `buildRuleOf40Dashboard()`
  - 内部ヘルパー: `collectTtmJournal_(journal, acctMap, filterKey, filterVal)` /
    `computeRuleOf40_(ttmByMonth)` / `renderRuleOf40Sheet_(sheet, rows, ctx)`
- `000_infra/002_constants.js`（MENU_DEFINITION への1項目追加のみ）
  - '📋 サイドバー: 📊 マート更新' カテゴリ配列の末尾付近に
    { label: '📏 Rule of 40 スコア更新', funcName: 'buildRuleOf40Dashboard',
      description: '95_dashboard_rule_of_40 (Rule of 40 スコアボード) を再計算' } を追加
- `CLAUDE.md`（1行追記のみ）
  - `## DDL (setupAllSchemas) で管理されないタブ` の列挙に
    `95_dashboard_rule_of_40` を追記

## 実装内容

1. 出力先シート `95_dashboard_rule_of_40` の取得 or 新規作成＋ clear()
2. JournalRepository.findAll() で仕訳 DTO 取得（戻り値: {headers, dtos}）
3. AccountRepository.findAsMap() で科目マスタ取得
   （戻り値: { [科目名]: {stmt, cat} }）
4. プロダクト事業フィルタを適用:
   - Constants.getParam('RULE_OF_40_FILTER_KEY', 'PJ名') で 'PJ名' or '組織名' を取得
   - Constants.getParam('RULE_OF_40_FILTER_VALUE', '') でフィルタ値を取得
   - 値が空なら無フィルタ + Utils.logInfo で警告
   - 値がある場合は完全一致（trim 比較）
5. 仕訳ステータスフィルタ: '仕訳振替' を除外（本仕様書デフォルト方針 B 案）
6. 事前集約: filteredJournal を月(YYYY-MM)×{売上, 費用} の2次元 Map に集計
   （O(N × M) 避けるため。609_datamart_kpi.js の境界月検出パターンを参考）
7. 月次 TTM ループ:
   - 基準月 YM について、YM-11 から YM までの12ヶ月分の売上・費用を集計
   - YM-12 から YM-23 までの12ヶ月分（前年同月 TTM）も集計
8. 成長率・営業利益率・Rule of 40 スコアの計算:
   - エッジケース（当期売上=0 / 前年売上=0 / 24ヶ月未満）はすべて '-' で返す
   - 判定: score >= 40 → '✅ OK' / score < 40 → '⚠️ 要改善'
9. ヘッダー領域（A1:H4）に計算前提を明記:
   - A1: 'Rule of 40 スコアボード'
   - A2: 'フィルタ条件: {key} = "{value}"'
   - A3: '利益率定義: 営業利益率 = (TTM売上 − TTM全費用) / TTM売上 × 100'
   - A4: '成長率定義: TTM売上 YoY = (当月TTM − 前年同月TTM) / |前年同月TTM| × 100'
10. 表ヘッダー（6行目）:
    '基準年月' / 'TTM売上' / 'TTM営業利益' / '成長率(%)' /
    '営業利益率(%)' / 'Rule of 40 スコア' / '判定' / '備考'
11. データ行（7行目以降）を直近13ヶ月 or 全期間で出力
12. 数値フォーマット適用:
    - 金額列: Constants.NUMBER_FORMATS.CURRENCY
    - パーセント列: Constants.NUMBER_FORMATS.PERCENT or '0.0%'
13. 002_constants.js の MENU_DEFINITION に 1 項目追加
14. CLAUDE.md の DDL 管理外タブ一覧に追記

## 制約（CLAUDE.md コーディング規約準拠）

- 列参照は必ずヘッダー名ベース（DTO プロパティアクセス）。列番号ハードコード禁止
- 42_trn_journal および 11_mst_account への書き込み禁止（読み取り専用）
- 95_dashboard_rule_of_40 は DDL 管理外。setupAllSchemas に追加しない
- AccountRepository.findAsMap_() 等の存在しない関数名を使用しない
- メニュー追加は MENU_DEFINITION 経由。onOpen() 本体は変更しない
- 仕訳ステータス判定は === の完全一致
- 有効フラグ=FALSE のマスタレコードはスキップ
  （findAsMap() が内部で処理済み。JournalRepository には該当列なし）

## エッジケース実装（本仕様書の「エッジケース」セクション参照）

| 条件 | 処理 |
|------|------|
| 前年 TTM 売上 = 0 | 成長率 = "-" |
| 当年 TTM 売上 = 0 | 利益率 = "-" |
| TTM 計算に 24ヶ月未満のデータ | 成長率 = "-" |
| 営業利益 < 0 | マイナス値をそのまま表示（正常） |
| フィルタ一致レコード = 0件 | "-" + Utils.logInfo で警告出力 |
| 科目マスタ未登録の科目 | 該当仕訳をスキップ + Utils.logInfo で件数集計 |
| 発生日(P/L計上日) が空 | 該当仕訳をスキップ |
| 税抜金額_実績 が数値以外 | Number(...) || 0 で 0 として扱う |

## 動作確認

1. npm run push:dev でデプロイ
2. dev スプレッドシートの `🚀 BizLP` > `操作パネルを開く` からサイドバーを開き、
   「📏 Rule of 40 スコア更新」を実行
3. 95_dashboard_rule_of_40 が生成され、ヘッダー行（計算前提）と
   データ行（直近13ヶ月）が正しく出力されることを確認
4. 以下のエッジケースを目視確認:
   - 売上ゼロ月で利益率 = "-"
   - 24ヶ月未満のデータで成長率 = "-"
   - 03_sys_params に RULE_OF_40_FILTER_VALUE を設定してフィルタ動作を確認
   - 空文字設定時に Utils.logInfo で警告出力されることを確認
5. 数値フォーマット（通貨・パーセント）が適用されていることを確認
6. 動作確認後に git commit → git push → PR → main マージの順で進める

### 拡張思考の使用状況

| フェーズ | 拡張思考 | 備考 |
|---------|---------|------|
| Phase 1（調査・設計） | あり | ファイル構造把握・固有名詞裏取り・MCP 実データ検証 |
| Phase 2（実装） | なし | Phase 1 確定内容の書き下しに徹する |

推奨実行モデル

変更履歴

仕様書作成プロンプト

# F-33: Rule of 40 スコアボード
## 概要
## 目的
## 現在のコード
## 修正方針
## 影響範囲
## 注意事項
## エッジケース
## 実データ検証
## 関連ドキュメント
## 人間が検討すべき事項
## 実装プロンプト（Claude Code 用）
## 推奨実行モデル
## 変更履歴
## 仕様書作成プロンプト

あなたはGAS会計システム(bizlp-gas-accounting)のシニア開発者です。
案件 F-33「Rule of 40 スコアボード」を実装してください。

## 実行前タスク
- `000_infra/003_contracts.js` を Read し、JournalEntryDTO の全プロパティ名を確認する
- `200_data/202_repository.js` を Read し、JournalRepository.findAll() の戻り値型と
  AccountRepository.findAsMap() の {stmt, cat} 構造を確認する
- `100_config/101_sys_config.js` を Read し、onOpen() のメニュー追加先の実在する文字列を確認する
- `600_report/` の既存ファイルを Read し、新規ファイル番号(609以降)または追記先ファイルを決定する
- MCP で 11_mst_account の大分類実値、42_trn_journal の仕訳ステータス実値、
  PJ名・組織名の実際の格納値を確認する

## 修正対象ファイル
- `600_report/609_rule_of_40.js`（新規作成）または Phase 1 で特定した既存ファイルへの追記
- `100_config/101_sys_config.js`（onOpen() へのメニュー追加のみ）

## 実装内容
1. `95_dashboard_rule_of_40` シートの作成/クリア処理
2. JournalRepository.findAll() で仕訳 DTO 取得（戻り値: {headers, dtos}）
3. AccountRepository.findAsMap() で科目マスタ取得（戻り値: { [科目名]: {stmt, cat} }）
4. プロダクト事業フィルタを適用（PJ名 または 組織名。Constants.getParam() で取得）
5. 月次 TTM 集計ループ（Utils.parseDateToYm() で発生日(P/L計上日)を YYYY-MM に正規化して判定）
6. 成長率・営業利益率・Rule of 40スコアの計算（エッジケース処理を必ず含める）
7. ダッシュボードヘッダー行に計算前提（フィルタ条件・利益率定義・成長率定義）を記載
8. 101_sys_config.js の onOpen() に実行メニューを追加（Read で確認した実在する文字列の下に追加）

## 制約
- 列参照は必ずヘッダー名ベース（indexOf または buildHeaderIndex_）。列番号ハードコード禁止
- 有効フラグ=FALSE の行はスキップ
- 42_trn_journal および 11_mst_account への書き込み禁止（読み取り専用）
- 95_dashboard_rule_of_40 は DDL 管理外（setupAllSchemas に追加しない）
- AccountRepository.findAsMap_() 等の存在しない関数名を使用しない
- メニュー名は onOpen() を Read して実在する文字列のみ使用する（造語禁止）

## エッジケース
| 条件 | 処理 |
|------|------|
| 前年 TTM 売上 = 0 | 成長率 = "-" |
| 当年 TTM 売上 = 0 | 利益率 = "-" |
| TTM 計算に 24ヶ月未満のデータ | 成長率 = "-" |
| 営業利益 < 0 | マイナス値をそのまま表示（正常） |
| フィルタ一致レコード = 0件 | "-" + Utils.logInfo で警告出力 |

## 動作確認
1. npm run push:dev でデプロイ
2. メニューから Rule of 40 実行関数を起動
3. 95_dashboard_rule_of_40 が生成されヘッダー・データ行が正しく出力されることを確認
4. 売上ゼロ月・24ヶ月未満データ月で "-" が正しく表示されることを確認
5. 動作確認後に git commit → git push → PR → main マージの順で進める

### 拡張思考の使用状況
| フェーズ | 拡張思考 | 備考 |
|---------|---------|------|
| Phase 1（調査・設計） | あり | ファイル構造把握・固有名詞裏取り |
| Phase 2（実装） | なし | Phase 1 確定内容の書き下しに徹する |

<details><summary>展開して表示</summary>

（この <instruction> タグ内の全文をここに転記する）

</details>

{ "file": "dev/dev_F-33_rule_of_40_scoreboard.md", "title": "E.5.X F-33 Rule of 40 スコアボード" }

| 2026-04-20 | [dev_F-33_rule_of_40_scoreboard.md](dev_mas-033_rule_of_40_scoreboard.md) | 初版作成。TTMベースのRule of 40スコアボード仕様書 |

git add docs/dev/dev_F-33_rule_of_40_scoreboard.md docs/_config.json docs/_internal/changelog.md
git commit -m "docs: F-33 Rule of 40 スコアボードの開発仕様書を作成

TTMベースの成長率・営業利益率・Rule of 40スコア計算方針、
エッジケース（ゼロ除算・データ不足）、Human-in-the-Loop設計、
プロダクト事業識別等の人間検討事項3点を記載。

https://claude.ai/code/session_XXXXX"
git push -u origin {現在のブランチ}

📌 取り込み時の注記 (2026-06-02 sub 復元)

本仕様書は旧 F-番号体系で作成され PR 未マージのまま孤立していたドラフトを、origin/docs/dev-* ブランチから内容無改変で復元し、案件ID のみ MAS 体系へ正規化したもの。status: Open（未実装）。

⚠️ ファイル番号ドリフト: 本文「対象ファイル」が指す 600_report/610〜612_*.js は現行 main で 別機能に使用済み（610=投資分析/MAS-013・611=財務モデリング/MAS-010・612=採用sim/MAS-012）。 実装時にファイル番号の再割当が必要。