company-cfo

/company-cfo — 会社 CFO の月次ワークフロー

分配・削減・採用・ランウェイの判断を行うために、経営陣が定期的に実施する分析です。基本の頻度は月次（締めた前月分を1日に実施）です。週次モードとシナリオモードでは、その間の状況をカバーします。

personal-cfo（家計）の、チーム単位で匿名化された姉妹版です。同じ規律（期末時点の取引合計、カテゴリ分類の落とし穴、シナリオモデリング）を会社の帳簿に適用します。

ステップ 0 — 会社の設定と前回の実行結果を読み込む

作業を始める前に、次の項目を順番に読みます。

1. ${COMPANY_CFO_ROOT:-$HOME/code/company-cfo}/ にある設定ドキュメント（存在する方の CLAUDE.md または AGENTS.md）— 会社固有の手法、データソースの対応表、カテゴリ分類ルール、分配の仕組みが記載されています。会社での計算方法に関する唯一の信頼できる情報源です。 独自の手法を作らないでください。
2. ${COMPANY_CFO_ROOT}/reports/monthly/ にある最新のレポート — 先月のスナップショットです。経営陣の決定事項と未解決事項がわかります。
3. そのフォルダーにある最新の *-followup.md（存在する場合）— 補足の決定事項やシナリオ分析です。
4. エージェントのメモリーにある関連するメモ、またはメモリーがない場合は ${MAKERSKILLS_MEMORY:-${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/memory}/ — 既知の異常、経営陣の制約、現在の解約状況など、継続中の背景情報です。
5. ${COMPANY_CFO_ROOT} で実行する git log --oneline -10 — 前回の実行以降にリリースされた内容を確認します。

COMPANY_CFO_ROOT ディレクトリがまだ存在しない場合は、初回の手順案内でユーザーに mkdir の実行、references/company-config-template.md を基にした AGENTS.md の作成（Claude Code 用に CLAUDE.md からシンボリックリンクを張る）、環境変数の設定を依頼します。

ステップ 1 — モードを解析する

呼び出し	モード	頻度
/company-cfo monthly（デフォルト）	月次	締めた前月分を毎月1日に実施
/company-cfo weekly	週次	簡易的なキャッシュ状況 — 現在の現金残高と、今後2週間の予想キャッシュフロー
/company-cfo scenario <question>	シナリオ	プロジェクターでの随時モデリング
/company-cfo pickup	再開	前回の実行を中断した箇所から再開（git log、最新レポート、未解決事項を確認）

以下のセクションでは、月次の手順を詳しく説明します。週次とシナリオの概要は末尾に記載しています。

---

月次ワークフロー

ユーザーに**レポートの対象月はいつですか？**と尋ねます（デフォルト：前暦月）。

次に、以下のフェーズを進めます。次のフェーズに移る前に、一時停止して確認します。

フェーズ 1 — 生データを取得する

対象月について、各ソースから生データを取得します。標準的なソースカテゴリは以下のとおりです（各社で実際に使用するツールは設定ドキュメントに記載されています）。

ソースカテゴリ	提供される情報	一般的なツール
銀行／現金口座	現金の実残高、内部・外部振替、分配先	Mercury CLI、Plaid、銀行からの直接エクスポート
決済プロセッサー	収益、サブスクリプション、解約、入金タイミング	Stripe API、Paddle、LemonSqueezy
給与／業務委託	W-2 給与、業務委託への支払い	Plane、Deel、Gusto、Rippling
経費管理	経費精算、法人カード	Ramp、Brex、Divvy
その他の収益	主要な請求元以外の収入源	直接請求ツール、代替決済プラットフォーム

取得したデータはすべて ${COMPANY_CFO_ROOT}/data/YYYY-MM/<source>-*.json[l] に保存します（gitignore 対象のため、生データはコミットされません）。

また、「今日」の開始時点の現金残高として、銀行ソースから現在の現金残高も取得します。

ソースがまだ接続されていない場合： CFO ワークフローを実行する前に /toolify <source> を使用して接続してください。初回の連携には一度だけ手間がかかります。

フェーズ 2 — 分類と突合

すべての現金口座からの支出を、自社で使用しているカテゴリに分類します。スターター用のカテゴリセットと分類を維持するための規律については、references/categorization.md を参照してください。

確認すべき普遍的な落とし穴(完全なリストは references/traps.md を参照):

• 現金とクレジットの二重計上 — 銀行に「クレジットカード自動支払」の出金が表示され、かつクレジットカード口座に個別の利用明細が表示されている場合、両方を計上しないでください。現金口座のみにフィルタするか、クレジットカードを負債口座として扱います。
• 内部振替 — 普通預金 ↔ 貯蓄預金の振替は正味ゼロになります。これらを除外します(通常は kind=internalTransfer フィルタまたは口座ペアのマッチングを使用)。
• 通貨の不一致 — 業務委託への支払ツールは、しばしば destination_amount を受領者の支払通貨で返します。USD/基軸通貨でのコスト分析には、常に source_amount(または同等のもの)を使用してください。
• 分配のカウント — 経営陣に毎月の分配を受け取るべきパートナーが N 人いる場合、N 件の分配が存在することを確認します。N-1 件の場合、欠落しているパートナーにフラグを立てます — 多くの場合、1 人がキャッシュバランスを取るために自己的な引き出しを繰り延べています。

レポートを作成する前のクロスチェック:

• 銀行の給与引き落とし合計 ≈ 給与ツール API の合計 + 手数料(保留中の控除に対する小さな残差の範囲内)
• その月に到着した決済処理業者からの支払 ≈ その処理業者からの銀行入金(タイミングのラグの範囲内)
• 銀行の経費管理からの出金 ≈ 経費管理ツールで承認された経費(現金主義のラグあり)

フェーズ 3 — EOM キャッシュの計算(取引合計方式)

現在残高からの逆算方式ではなく、取引合計を使用してください。 逆算は CFO のワークフローを繰り返し悩ませてきました — 取得時点の銀行 API の残高スナップショットは数万単位でずれていることがあり、その誤差が過去すべての EOM 値に伝播します。

正しい方式(完全なレシピは references/eom-cash-methodology.md を参照):

# 1. Pull ALL transactions for each cash account (Checking + Savings + any other cash-holding):
#    <bank-tool> transactions list --account-id <id> --format jsonl --max-items 100000
# 2. Sum the amount field across all transactions in each account.
# 3. The sum should equal that account's CURRENT available_balance exactly.
#    (Sanity check — if not, missing data or a pre-history baseline deposit exists.)
# 4. For any past date T: balance_at_T = sum of all transactions posted on or before T
#    (plus any pre-history baseline, which should be ~$0 if the sanity check passes).

EOM のクロスチェック: 先月の EOM + 今月の正味キャッシュ変動が、今月の EOM と 1 ドル単位まで一致するはずです。

取引合計が現在残高と突合しない場合、フォールバックとして逆算を進めないでください。 まずギャップを調査します — 欠落した取得(タイムアウト、ページング)、未知の口座、または正当な履歴以前のベースラインのいずれかです。

フェーズ 4 — シナリオプロジェクターの更新

ほとんどの CFO ワークフローは、シナリオプロジェクターの恩恵を受けます — 調整可能な前提(収益成長、経費シナリオ、採用計画、分配の変更)の下で EOM キャッシュを N か月先まで予測するインタラクティブな予測です。

一般的な構造(リファレンス実装は references/scenario-projector.md を参照):

• HISTORICAL(直近 3 か月の確定月) — TODAY より前のコンテキストを提供します
• TODAY — 実際の現在のキャッシュ残高(現在の月内のカレンダー上の位置)
• Mo 1 — 現在の暦月の EOM(部分的 — 残りの月のアクティビティ)
• Mo 2-7 — 次の 6 完全暦月の EOM(シナリオ設定はここから適用されます)

各月: starting + revenue − expenses = profit → ending

月内サイクルの低点(週次のキャッシュパルスの関連性のため): ほとんどの CFO システムは、月の低点(キャッシュフロアに達する可能性のある時点)を気にしており、高点(EOM)だけではありません。計算式は支払サイクルによって異なります — references/scenario-projector.md を参照してください。

毎月の実行ごとにプロジェクターを更新します:

1. 確定したばかりの月をすべてのカテゴリフィールドとともに HISTORICAL に追加し、最も古いものを削除します。
2. startingCash を今日の実際の銀行残高に更新します。
3. 大きく変動したカテゴリの経費ベースラインを更新します。
4. baselineMrr を更新します(決済手数料を差し引いた正味額)。
5. プリセットがまだ意味をなすか確認します(報酬体系や採用計画が変更された場合、シナリオの更新が必要になることがあります)。

フェーズ 5 — スナップショットレポートを作成する

references/report-template.md のテンプレートに従って、${COMPANY_CFO_ROOT}/reports/monthly/YYYY-MM.md を作成します。セクションは次のとおりです（必要に応じて調整してください）。

1. 要約 — 見出し + ステータステーブル（純現金、期末残高、現在の MRR、直近 N か月、推奨事項）
2. 現金収入 — 収入源別（決済プロセッサー、その他の収益、一時収入）
3. 現金支出 — カテゴリ別（プロジェクターのカテゴリ構成に合わせる）
4. 給与の内訳 — 確認済みの契約社員 + W-2 の内訳
5. 分配金 — 支払いを受けた人、受け取っていない人（異常があれば明記）
6. 収益指標 — 有効なサブスクリプション数、MRR の増減、最近の解約（$ と顧客名）
7. 将来予測 — プロジェクターによる 1〜3 件のシナリオ（プロジェクターの状態へのリンク）
8. 推奨アクション — 経営陣が判断できる具体的なアクション
9. 未解決事項 — 来月に解決すべき質問

理由を説明する段落は、平易な英語で書きます。何が起きたのか、なぜ起きたのかを説明してください。前月からの継続性があれば、前月の内容にも触れます（「先月から続いていた Vendor X の解約が、6 月の支払いに影響し終えました」）。

フェーズ 6 — メモリーを更新する

次のいずれかに該当する場合は、メモリーストア（エージェントのメモリー、または ${MAKERSKILLS_MEMORY:-${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/memory}/）内の company_cfo_<company-slug>.md を更新します。

• 分配金または報酬体系に変更があった
• 有効なサブスクリプション数または MRR が大幅に変動した
• 新たな収益源（新しい請求プラットフォーム）が追加された
• 新しいパートナーまたは契約社員について決定があった
• 現金下限または分配制約が変更された

メモを膨らませないでください。古くなった事実は置き換え、際限なく追記しないでください。

フェーズ 7 — レビューして公開する

自社の git ワークフローに従います。

初回実行の前に、リポジトリルートの .gitignore で生データのエクスポートが除外されていることを確認してください。フェーズ 1 では銀行／給与／決済プロセッサーの機密データが data/ にダンプされるため、これはコミットしてはなりません。除外設定がなければ、次の内容を追加します。

cd ${COMPANY_CFO_ROOT}
# Verify .gitignore excludes raw data + secrets
if ! grep -q '^data/' .gitignore 2>/dev/null; then
  cat >> .gitignore <<'GITIGNORE'
# Raw financial data — never commit
data/
*.jsonl
*.env
*.env.local
.mcp.json
GITIGNORE
  git add .gitignore
  git commit -m "Seed .gitignore for raw financial data"
fi

その後、レポートとプロジェクターの変更のみを公開します（このリポジトリでは決して git add -A を実行しないでください。意図しない data/ ファイルが紛れ込まないよう、対象を指定して追加します）。

cd ${COMPANY_CFO_ROOT}
git checkout -b feature/YYYY-MM-snapshot
git add reports/monthly/YYYY-MM.md scenarios/index.html $(ls AGENTS.md CLAUDE.md 2>/dev/null)   # targeted
git status --short                                                    # verify no data/ or .env files staged
git commit -m "YYYY-MM monthly snapshot"
git push -u origin feature/YYYY-MM-snapshot
gh pr create --base main --title "YYYY-MM monthly snapshot"

${COMPANY_CFO_ROOT} では、決して git add -A を実行しないでください。data/ ファイルが気づかれないまま漏れると、銀行取引履歴とパートナーへの分配金の ACH が git リモートにプッシュされます。対象を指定して追加してください。

マージ前に、該当する場合はコードレビューを実施し、そうでなければ差分を手動で確認します。その後、マージしてブランチを削除します。

---

週次キャッシュ状況モード

簡易版です。15 分の週次ミーティングで使えるように設計されています。

1. 現在の現金残高を取得する（銀行 API の accounts list）
2. 過去 7 日間の取引と、今後 7 日間に予定されている支出（給与、既知の請求）を取得する
3. 次の項目を算出する：現在の現金、次回の給与支払日 + 金額、次回の Stripe 支払日 + 金額
4. 現金が今後 2 週間の支出を下回る場合（現金下限を下回る場合）に警告する
5. 1 行のステータスを記載する：現金 $X | 次回給与 $Y（<date>）| 次回入金 $Z（<date>）| 下限ステータス：OK|WATCH|BREACH

${COMPANY_CFO_ROOT}/reports/weekly/YYYY-WW.md に保存します。

/loopify と組み合わせて週次実行をスケジュールします（通常は月曜の午前 9 時）。

シナリオモード

随時実行します。「9 月に年収 $150K のエンジニアを採用したらどうなるか」や「解約率が 2% 上昇したらどうなるか」といった検討に使います。

シナリオプロジェクターを開き、関連する設定を調整して、生成された現金予測のスクリーンショットを撮るか、エクスポートします。分析結果を ${COMPANY_CFO_ROOT}/reports/scenarios/YYYY-MM-DD-<question-slug>.md に保存します。

シナリオに関する判断が重要な場合（新規採用、分配金の変更、大きな支出など）は、正式に記録するため /decide も実行します。

ピックアップモード

前回の実行内容から再開します。次の項目を提示します。

1. 最新の月次レポート（ls -t ${COMPANY_CFO_ROOT}/reports/monthly/*.md | head -1）
2. 最新の週次キャッシュ状況
3. ${COMPANY_CFO_ROOT} の最新の git log（前回のスナップショット以降に公開されたもの）
4. 現在の状況を記したメモ
5. 前回のレポートの §9 にある未解決事項

トレーニングデータから状況の継続性を推測しないでください。 必ず最初にレポート、メモリー、git log を確認してください。

連携するツール

• personal-cfo — 関連するツールです。personal-cfo は家計（住宅費、月次キャッシュフロー、大型購入）を扱います。同じ規律（取引合計方式、シナリオモデリング）を、異なる範囲に適用します。
• company-brain — CFO レポートはここに保存され、Wiki にインデックス化されます。company brain の outputs/ には月次レポートが蓄積され、Wiki ページには月をまたいだ傾向がまとめられます。
• toolify — 会社固有のデータソース（Mercury API、Stripe、Plane、Ramp、または同等のサービス）を接続します。初回実行時に連携を設定します。
• loopify — 月次実行（月の1日）と週次キャッシュ状況確認（毎週月曜日の午前9時）をスケジュールします。
• decide — レポートで明らかになった重要な意思決定（分配の変更、採用、現金下限への抵触時の対応）に使用します。37signals のフレームワークで正式な形にします。
• deep-research — シナリオの入力値を決めるベンチマークに関する質問（「ARR に対する SaaS のマーケティング予算の一般的な割合は？」など）に使用します。

品質に関する注意事項

• 方法論を捏造しないでください。 現金の計算方法は会社ごとに異なります。${COMPANY_CFO_ROOT} にある会社の設定ドキュメントに従ってください。記載がない場合は、推測せずに確認してください。
• 取引合計方式は必須です。 残高スナップショットから逆算する方法は、CFO ワークフローで何度も問題を引き起こしています。未加工の取引合計を使用し、現在の残高と照合してください。
• 分類の一貫性は、正確さよりも重要です。 毎月同じカテゴリを使えば、傾向を読み取れます。年の途中でカテゴリを変えると、傾向がノイズになります。
• 支出のベースラインには、「安全」と見なした推定値ではなく、実績値を使用してください。 実績が12,000ドルなのにソフトウェア費用を8,000ドルとしてモデル化すると、楽観的な予測になり、モデルが破綻します。
• 売上は総額ではなく、決済手数料を差し引いた純額です。 Stripe などの決済処理業者の約3％の手数料は、月次の現金流入に大きく影響します。
• 月中の資金繰りの最低値は、月末残高より重要です。 月次の入金サイクルでは、月の半ばに現金が大きく減ります。現金下限を適用するのは、月末の最高値ではなく最低値です。
• 週次の入金にすると、サイクルの変動が大幅に緩和されます。 決済処理業者が対応している場合、月次から週次の入金に切り替えることは、最も効果の高い資金管理策の一つです。references/eom-cash-methodology.md を参照してください。
• 数値が一致しない場合は、作業を止めてください。 説明のつかない差異があるレポートを提出してはいけません。まず原因を調査してください。かつて、42,000ドルの照合差異が発見されるまで何週間も気づかれず、連鎖的に影響が広がったことがあります。

このスキルを使用しないケース

• 単発の数値確認（「現在の現金はいくら？」など） — 全体のワークフローを実行せず、銀行のデータソースに直接問い合わせてください。
• 税務・会計に関する質問 — 対象外です。公認会計士に相談してください。
• 個人の財務 — 代わりに personal-cfo を使用してください。
• 投資家向けピッチ資料の財務情報 — 異なる規律が必要です（複数年の予測、ユニットエコノミクスの詳細分析）。このスキルが扱うのは、資金調達のストーリーではなく、CFO の業務上の定期サイクルです。