個人開発ポートフォリオの配分・共通依存・終了責任

最終更新: 2026-08-02

この章は、複数の製品・サービスを一人で運営するときの内部管理手順である。会計上の引当、法的な返金義務、契約承継、個人情報の移転・削除、税務上の保存期間を一律に判定するものではない。利用規約、個別契約、販売地域、事業形態、決済手段、ストア規約、扱うデータに応じ、最新の一次情報と専門家へ確認する。

この章の役割

この章は、複数製品を一つの時間、現金、共通原因リスク、終了責任として集約する正本である。既存章とは次のように責任を分ける。

問い	正本
売上、粗利、前受、資金繰り、顧客集中をどう計算するか	02 章
本人の生活、内部時間価値、月次容量、13 週現金をどう計算するか	09 章
channel、store、決済、AI provider、agent 委任の依存をどう調べるか	10 章
AI 経路の掲載、引用、接続、実行、履行、実入金をどう証拠化するか	17 章
契約、個人情報、税務、security の個別要件	06 章
顧客案件の closeout と更新	11 章
一つの有償サービスをどこまで製品化するか	14 章
基本的な撤退手順と週次実行	07 章

ここではそれらの結果を period_id × product_id へ集約し、「今期どこへ何時間・いくら使うか」「同時に何が止まるか」「終了後に何が残るか」を決める。個別製品の良し悪しだけでなく、全製品を同時に持つことの機会費用と責任を扱う。

先に結論

アプリ一覧ではなく、時間・現金・義務・依存を含む一つの portfolio として管理する。
cash_engine / validated_core / new_option は今期の投資理由、maintenance / sunset / closed は運用状態、reserve は製品に割り当てない portfolio 資源である。混ぜない。
顧客への履行、security、法務、税、返金、障害・病気、終了作業を先に控除し、残りだけを裁量配分する。
固定比率を普遍的な成功則にしない。本人が期間、上限、反証条件とともに決め、計画と実績を照合する。
既定では、裁量的に成長投資する core は 1 つ、同時に検証する new option も 1 つにする。増やす場合は、切替費用と既存義務を含めて明示的に例外承認する。
製品数や vendor 数ではなく failure_domain_id を数える。同じ顧客、channel、決済、cloud、identity、コード、創業者に依存する製品は、同時停止シナリオでは分散していない。
販売停止やサーバー削除を closed と呼ばない。契約、前受・返金、利用権、顧客データ、保存記録、資格情報、委託先、問い合わせ経路の未完了を sunset liability として閉じる。
売却・譲渡・統合は終了ではない。責任とデータの承継、顧客移行、運営主体の切替が完了するまで別の state として追う。

五つの言葉を一列に並べない

cash_engine、validated_core、new_option、maintenance、reserve は重要だが、同じ分類軸ではない。一列の選択肢にすると、売上があるだけの保守製品へ成長予算を付けたり、予備時間を新製品の空き時間として使ったりする。

軸 A: 今期の一次的な投資理由

各製品は、期間ごとに一つだけ allocation_role を持つ。事実上複数に該当しても、二重予算を避けるため一次役割を選ぶ。

`allocation_role`	意味	最低限必要な証拠	誤用
`cash_engine`	既に回収できる現金を守り、portfolio の義務と次の投資を賄う	同じ定義期間の入金、変動現金費、創業者時間、返金・前受、顧客集中	売上だけを見て赤字の手作業を延命する
`validated_core`	反復価値と支払の証拠があり、次の一段へ裁量投資する	対象 cohort、価値確認、入金、継続または更新理由、容量、安全 veto、次の検証	大きな市場や完成度を検証済みと呼ぶ
`new_option`	不確実な機会を、小さく可逆な支出で調べる	一つの仮説、対象顧客への到達、最大時間、最大現金、判定日、反証条件、終了費用	期限のない side project を「将来性」と呼ぶ
`unfunded`	裁量投資理由が未確定、または今期は配分しない	次回判断日と、義務をどう処理するか	数字がないことをゼロとみなす

cash_engine と validated_core の両方に見える製品は珍しくない。その場合も、今期の追加資源を「現金回収の防衛」に使うのか「検証済み成長」に使うのかを一つ選び、もう一方の性質は metric と根拠に残す。

軸 B: 顧客へ提供している運用状態

`lifecycle_state`	意味	許される主な作業
`explore`	顧客問題と支払意思を検証中	面談、手動提供、prototype、最小の安全検証
`growth`	検証済みの次の制約へ投資中	獲得、導入、反復価値、標準化、容量改善
`operate`	約束したサービスを通常提供	提供、support、security、信頼性、更新
`maintenance`	新規成長を前提にせず既存義務を限定履行	修正、security update、契約内 support、終了準備
`sunset_planned`	終了判断済み、通知・資金・データ計画を確定中	新規販売停止準備、顧客・契約 inventory、予算化
`sunset_active`	顧客 closeout とデータ・infra 終了を実行中	通知、返金、export、移行、削除、資格情報失効
`closed`	完了 gate と証拠を満たし、提供責任を閉じた	法定・契約上必要な記録保存、限定的な問い合わせ対応

STOP は支出や実験を止める判断であり、顧客への責任が消える closed ではない。maintenance も放置状態ではない。期限、scope、support level、security response、終了条件、予算を持つ。

軸 C: 今回の意思決定

使用する action を限定する。

`decision`	意味
`FUND`	上限内で次の検証・成長へ裁量配分する
`HOLD`	新しい成長投資を止め、指定日まで事実確認または義務履行だけ行う
`HARVEST`	顧客価値と契約を守りながら、追加成長より現金回収を優先する
`MERGE`	顧客・機能・データを別製品へ統合する
`TRANSFER`	運営または契約上の責任を他者へ承継する準備・実行を行う
`SELL`	資産・事業の売却工程へ進む。完了までは運営責任を保持する
`SUNSET`	終了計画と liability 解消へ資源を付ける
`STOP`	option や裁量支出を即時停止する。残存義務は別に処理する
`PAUSE`	veto または期限切れにより、追加支出せず再判定を待つ
`UNKNOWN`	必須情報が欠け、判断不能。ゼロや `FUND` に置換しない

役割、状態、decision は別列にする。例えば cash_engine × maintenance × HARVEST、validated_core × growth × FUND、new_option × explore × PAUSE はいずれも成立する。

`reserve` は製品ではない

Reserve は、事故、病気、返金、終了、予測誤差に備え、決定時点では特定製品の成長へ約束しない時間または現金である。

time_continuity_reserve: 障害、security、創業者不在、予測誤差
cash_continuity_reserve: 入金遅延、障害費、急な必須支出
customer_obligation_cash: 前受未履行、返金、credit、chargeback 等への内部拘束
sunset_time_reserve / sunset_cash_reserve: 終了通知、移行、返金、データ・infra closeout

これは必ずしも会計・税務上の「引当金」ではない。内部の資源拘束と会計表示を混同せず、帳簿・決済・銀行と照合する。

Portfolio 台帳の粒度

正本の一行は period_id × product_id × decision_at とする。最新値で過去判断を上書きせず、その時点で知り得た情報を固定する。

群	最低限の列
Identity	`period_id`, `product_id`, `legal_entity`, `owner`, `decision_at`, `evidence_cutoff_at`
Classification	`allocation_role`, `lifecycle_state`, `decision`, `decision_due_at`
Customer evidence	対象 cohort、active/paid account、価値確認、継続・更新、上位顧客・業界集中
Cash	入金、変動現金費、返金・credit、前受未履行、確定支出、fully-loaded contribution
Time	計画・実績の提供、support、開発、営業、管理、incident、sunset 時間
Dependency	critical dependency 数、`failure_domain_id`、共同停止 scenario、回復証拠日
Liability	open/unknown の cash、time、contract、data、security、record、platform 項目
Next bet	一つの仮説、最大時間、最大現金、判定日、反証条件、次の action
Evidence	契約、invoice、payment、export、delete receipt、runbook test、decision log の参照

同じ期間・同じ cutoff を揃える。MRR は当月、時間は直近 90 日、解約は年次 cohort という状態で単純な総合点を作らない。期間が異なる場合は列に明示し、decision は UNKNOWN または限定付きにする。

時間配分は waterfall で決める

09 章で求めた、休暇を含む現実的な月間稼働可能時間を入力にする。そこから先に義務と予備を引く。

裁量配分可能時間
= 月間portfolio稼働可能時間
- 共通管理・会計・法務・security基盤
- 契約済み提供・support・更新作業
- 既知のincident・不具合・是正作業
- continuity reserve（病気・未知の障害・予測誤差）
- activeなsunset作業

控除順を固定する

安全、法令、契約、顧客への既存約束
共通管理と最低限の信頼性・security
病気、事故、予測誤差の reserve
既に決めた sunset の実行
残った時間を cash_engine / validated_core / new_option へ配分

順序は、古い製品を無限に優先する意味ではない。既存義務が多すぎて裁量時間がないなら、隠して新製品を始めず、価格、scope、契約、移行、終了を変えるべきだという警報である。

同じ作業を二つの控除へ入れない。例えば sunset 中の契約 support は、契約済み提供 か active sunset の一方へ置き、もう一方からは参照 ID だけを持つ。各時間 event の一次 bucket を一つに固定する。

配分規則

各期間の planned hours 合計は、裁量配分可能時間以下でなければならない。
Reserve は planned discretionary hours に再計上しない。使ったときは reason と product/scenario を記録する。
既定では validated_core の成長 WIP は 1、new_option の検証 WIP も 1 とする。
例外で増やす場合は、切替、会議、release、support、monitoring、依存、終了責任の増分を含める。
計画比率ではなく、planned/actual hours と未完了義務を毎月照合する。
差異許容幅は本人が事前に定める。一般的な 70/20/10 等を成功条件にしない。

WIP 1 は科学的な普遍値ではなく、注意力が希少な一人事業の安全な初期値である。二つを同時に育てる方がよい証拠と容量があれば変更できるが、予定表と on-call は分身しない。

Little の L = λW は安定した process の平均 WIP、throughput、滞留時間の関係を示し、Coviello らは task juggling の理論とイタリアの裁判官データで並行案件と完了速度を研究した。どちらも software 開発で「WIP は必ず 1」と証明するものではない。本章では、増やすときに同時進行の実コストを観測できる、反証可能な初期制約として使う。

現金配分も waterfall で決める

売上や会計利益ではなく、decision cutoff 時点の利用可能な銀行・決済残高から始める。

裁量配分可能現金
= 実在する事業用現金
- 税・社会保険・消費税等の内部拘束額
- 前受未履行・返金・credit・chargeback等の顧客義務対応額
- 買掛・未払・給与・確定済みvendor支出
- 絶対に割らない最低現金
- continuity cash reserve
- open sunset liabilityへ確保したcash

現金で間違えやすいこと

年額前払いは全額を裁量投資へ使えるとは限らない。残存利用期間の提供または返金責任を別に持つ。
MRR、売上、invoice、決済成功、銀行着金、自由現金を同じ列にしない。
決済 provider の保留、chargeback、入金遅延を銀行現金と同一視しない。
AI 経路の売上は 17 章で commercial owner、order、reversal、銀行着金を照合し、provider ごとに重複計上しない。
税や法定保存は製品を終了しても残ることがある。
sunset_cash_reserve は終了意思を示すだけでなく、通知、返金、移行、専門家、domain・保守等の支払に owner と期日を付ける。
金額不明の法務・privacy リスクを、根拠なくゼロ円へ変換しない。UNKNOWN として別に veto する。

裁量配分可能現金が負なら、new option と可逆的な成長支出を止める。顧客資金や税の内部拘束を解除したことにして帳尻を合わせない。

絶対最低現金、continuity cash reserve、sunset cash reserve に同じ支出を重ねない。最低現金が continuity を内包する設計なら別控除を 0 にして、その定義と scenario を残す。Reserve を厚く見せる二重計上も、裁量現金を小さく見せる二重控除も避ける。

Option は「小さな権利」であり、第二の本業ではない

探索と既存事業の活用を両方考える必要があるという研究はあるが、個人開発者に共通の最適比率は示していない。Real options の考え方は、不確実な機会へ一度に全面投資せず、情報を得る小さな支出によって、後で拡大できる権利を買うことにある。Adner と Levinthal が概念上の境界を論じるように、順次投資というだけでは option ではない。上限、判定日、行使条件、停止可能性のない side project を real option と呼ばない。

New option card

option_id / product_id:
調べる一つの不確実性:
対象顧客と今期に会える経路:
買おうとしている将来の権利:
最小の検証行動:
開始日 / 判定日:
最大創業者時間:
最大現金:
新しく作る契約・データ・security・support責任:
promotion条件:
反証条件:
停止後の削除・返金・連絡・asset再利用:
決定者 / evidence:

Promotion gate

new_option → validated_core は、次を満たしたときだけ行う。

対象 cohort と顧客問題が特定されている。
希望や登録でなく、価値確認と支払・入金の証拠がある。
次の制約が一つに絞られ、追加予算の用途が明確である。
fully-loaded contribution、創業者容量、安全・契約 veto を確認した。
主要 dependency と終了費用を登録した。
portfolio reserve を残した後でも、追加時間・現金がある。

期限切れ、上限超過、反証成立、必須情報欠落は PAUSE または STOP である。投入済みのコード量は promotion の証拠にしない。

依存は vendor 数でなく failure domain で見る

dependency_id は直接利用する対象、failure_domain_id は複数 dependency を同時に止め得る共通原因を表す。

Dependency register

列	例
`dependency_id`	`dep_payment_primary`, `dep_auth`, `dep_model_a`
type	founder、customer、channel、store、payment、AI、cloud、database、DNS、email、repo、shared code、data、license、jurisdiction
provider / asset	会社名、service、account、repository、共有component
`failure_domain_id`	`fd_founder`, `fd_identity_account`, `fd_cloud_region`, `fd_customer_group`
affected products	`product_id` の集合
criticality	停止時に sale、delivery、billing、support、recovery のどれが止まるか
exit/recovery	export、代替、manual degraded mode、credential、runbook
contractual facts	renewal、notice、data location、subprocessor、SLA、利用権
tested evidence	restore、failover、export、連絡先の最終試験日
owner / next review	誰がいつ再確認するか

代表的な failure domain

fd_founder_unavailable: 知識、承認、on-call、本人名義 account が一人に集中
fd_customer_group: 同じ大口顧客、同じ業界予算、同じ規制変更
fd_acquisition_channel: 一つの検索語、marketplace、紹介元、広告 account
fd_store_account: 同じ developer account や policy enforcement
fd_payment_account: 同じ PSP、同じ銀行、同じ本人確認・事業審査
fd_identity_account: 同じ SSO、email、phone、hardware key、recovery account
fd_cloud_control_plane: 別 service でも同じ cloud account、region、請求停止
fd_dns_registrar: 全製品の domain、DNS、email authentication
fd_model_provider: 同一 provider の model、moderation、embedding、billing
fd_repository_supply_chain: 同じ source host、CI secret、package、build pipeline
fd_shared_code_or_schema: 共通 auth、billing、migration、tenant isolation の欠陥
fd_legal_or_license: 同じ license、データ利用根拠、法域、規制分類

二つの AI model を使っていても同じ provider account と billing に結ばれていれば、account suspension に対しては一つの failure domain である。異なる cloud vendor でも、DNS、SSO、決済、創業者の復旧操作が同じなら、事業全体の継続性は分かれていない。

「相関」は係数で飾らず共同停止を試す

小さな製品 portfolio には、十分な独立障害データがないことが多い。そこで Pearson 相関や架空の発生確率を置き、足し算した risk score を作っても精度は生まれない。

この章でいう correlated dependency は統計的推定ではなく、一つの原因で複数製品の sale、delivery、billing、support、recovery が同時に止まる構造を指す。NIST の supplier criticality と contingency planning を個人事業へ応用した推論である。

Scenario exposure

failure_domain_id × scenario_id ごとに次を記録する。

scenario_id / failure_domain_id:
停止または劣化する期間（仮定）:
影響product:
影響するpaying account / user:
影響する入金・monthly contribution:
期限内に履行できない約束:
データ・securityへの影響:
manual/degraded mode:
復旧に必要な創業者時間と順序:
必要現金:
外部連絡先:
最後に試した日とevidence:
未確認事項:

売上や時間を scenario 間で合計して「年間損失期待値」にしない。発生確率と同時発生関係が検証できない場合は、scenario ごとの at-risk exposure、復旧順、最大約束違反をそのまま比較する。

最低限の stress test

期間、価格変化、停止時間は本人の契約と履歴から入力する。下記の数値を普遍値として固定しない。

創業者が一定期間、管理画面・本人確認・顧客連絡を行えない。
主獲得 channel から新規 lead がゼロになる。
PSP が新規課金、更新、入金の一部または全部を止める。
主な AI model/API が終了、品質劣化、価格変更、rate limit になる。
cloud control plane、database、identity、DNS、email の一つが使えない。
上位顧客または同一業界の予算が失われる。
共有 auth、billing、tenant、dependency に security incident が起きる。
repository、CI、package registry、署名鍵が使えず修正を出荷できない。

各 test は「代替 vendor がある」で終えず、権限、データ export/import、DNS、課金、顧客通知、復旧時間を実際に確認する。未試験は UNKNOWN である。

Decision gate は veto を先に通す

加重 score が高くても、重大な未解決責任を相殺させない。次の順で判定する。

安全・法務・privacy veto: 重大な危険、違法・規約違反の疑い、必要な専門確認が未完了なら PAUSE/STOP。
契約・顧客 veto: 既存の提供、返金、export、support を履行できないなら、新しい裁量投資を止める。
Reserve veto: 時間または現金 waterfall が負なら new_option と可逆的成長を funding しない。
Evidence veto: 粒度、期間、cohort、cutoff、source が不明なら UNKNOWN。
Economics: fully-loaded contribution、cash timing、創業者容量、集中を比較する。
Strategic fit: 顧客到達、累積資産、次の学習、portfolio の共通依存を比較する。

UNKNOWN は中間値でもゼロでもない。重要な未知を埋める最小調査だけを FUND し、本格投資を止める。

Action の完了条件

Action	必要な完了条件
`FUND`	上限、milestone、判定日、反証、owner、reserve 残高がある
`HOLD`	既存義務、許される作業、次回判定日がある
`HARVEST`	顧客価値・support・securityを守る範囲と、終了/再投資条件がある
`MERGE`	account、契約、price、data、identity、URL、support の移行 plan がある
`TRANSFER/SELL`	承継対象、除外、未払・前受、IP/license、data、incident、顧客通知、運営切替が定義済み
`SUNSET`	liability inventory、資金・時間、通知、closeout state machine、closed gate がある
`STOP`	新規支出停止に加え、既存顧客・データ・契約をどの state へ送るか決まっている

Sunset liability を製品ごとに数える

Sunset liability は、製品を終了・移行・売却するときに残る未完了責任である。cash と time は定量化し、法務・privacy・security の未確認を無理に金額換算しない。

Liability taxonomy

種類	代表例	完了 evidence
`cash`	前受未履行、返金、credit、chargeback、未払、解約費、税	reconciliation、refund/credit receipt、bank/payment記録
`contract`	通知期間、残存利用権、SLA、support、更新停止、license、個別合意	契約inventory、通知、終了/承継確認
`customer`	代替案、export、移行、read-only期間、問い合わせ窓口	送達記録、export受領、migration acceptance
`data`	customer/user data、backup、log、analytics、processor copy、legal hold	inventory、削除/返還receipt、保存根拠・期限・owner
`platform`	subscription、store listing、domain、DNS、email、webhook、cron、queue、API、vendor	停止設定、invoice close、account state、監視結果
`security`	secret、token、key、OAuth app、service account、脆弱性・incident窓口	revoke/rotate記録、access review、final scan
`record`	帳簿、invoice、契約、同意、incident、tax/security記録	archive場所、access、retention end、disposal owner
`time`	通知、support、export、移行、削除、復旧、専門家対応	planned/actual hours、owner、完了日
`unknown`	適用法、返金範囲、データ所在、承継可否が未確認	確認先、期限、回答 evidence

各行に liability_id, product_id, account/contract, amount, hours, currency, due_at, owner, status, evidence, retention_end_at を持つ。amount や hours が不明なら null のまま unknown を開き、0 を入力しない。

Platform 固有の終了は別々に確認する

Apple の auto-renewable subscription は、販売停止後も対象 subscriber へ subscription 期間中の内容を提供する責任があり、公式資料は販売停止、事前通知、期間に応じた終了時期を案内している。App record や in-app purchase の削除とは別工程である。
Google Play の unpublish は、新規利用者から listing を隠すが、既存利用者は app を利用し update を受けられる。Unpublish、subscription、完全な app deletion を同じ操作と考えない。
日本で資金決済法上の前払式支払手段に該当するものを終了する場合、金融庁は利用終了時の法定払戻手続と公告等を案内している。通常の割引 coupon、単なる未収売上、前払式支払手段を自己判断で同じ扱いにしない。

Store、PSP、通信販売、契約、前払の要件は変わり得る。終了を決めた時点で、対象 country、plan、billing channel、契約版ごとに公式資料を再確認する。

通常の月額・年額 SaaS すべてに共通する「未利用期間は必ず全額返金」または「返金不要」という一律ルールは本調査では置かない。提供不能期間、契約・表示、B2C/B2B、解約条項、決済 channel、適用法、実損を確認し、refund_due = UNKNOWN のまま owner と期限を付ける。

終了は state machine で進める

OPERATE
  -> SUNSET_PLANNED
  -> SALES_AND_RENEWALS_STOPPED
  -> CUSTOMER_AND_CASH_CLOSEOUT
  -> DATA_CLOSEOUT
  -> INFRA_AND_SECURITY_CLOSEOUT
  -> EVIDENCE_ARCHIVED
  -> CLOSED

作業は並行できるが、前提を飛ばして closed にしない。

1. `SUNSET_PLANNED`

product、legal entity、owner、対象 customer/account を固定する。
現行の契約・利用規約・privacy notice・store/PSP plan version を収集する。
active、trial、free、annual prepaid、credit、dispute、invoice、refund、support case を inventory 化する。
customer data、backup、log、warehouse、analytics、subprocessor、AI provider への copy を map する。
必要時間・現金と sunset reserve を承認する。
終了日、販売停止日、更新停止日、通知日、export window、削除日、記録保存期限を分ける。

2. `SALES_AND_RENEWALS_STOPPED`

Web、sales、app store、marketplace、API、partner で新規販売を止める。
自動更新と trial conversion を billing channel ごとに止める。
広告、affiliate、promo code、紹介、sales automation を止める。
「購入できない」だけでなく、古い checkout URL と API を test する。

3. `CUSTOMER_AND_CASH_CLOSEOUT`

顧客別に提供最終日、利用権、通知、代替、export、移行、refund/credit を決める。
通知の送達と問い合わせを記録する。
前受未履行、refund、credit、chargeback、未収・未払を決済・銀行・帳簿と照合する。
read-only や migration support の scope、support deadline、責任境界を明示する。
連絡不能顧客も未完了として扱い、契約・法令に沿う処置を記録する。

4. `DATA_CLOSEOUT`

Export の形式、完全性、受領、再取得期限を確認する。
利用目的がなくなった customer/user data を、適用要件と定めた schedule に従って削除または利用不能化する。
backup、log、analytics、support、AI/provider、subprocessor の残存を確認する。
税務、契約、紛争、security 等で保存する記録は、利用データと分け、根拠、最小範囲、access、owner、retention end を付ける。
Delete job を実行したことと、実データが対象範囲からなくなったことを別に検証する。

個人情報保護委員会は、個人情報保護法が全データに一律の保存期間を置くものではない一方、利用する必要がなくなった個人データを遅滞なく消去するよう努めると説明している。「遅滞なく」の具体的期間も取扱状況等で異なる。したがって「終了後一律 30 日」や「法務のため永久保存」と決めず、データ category ごとに根拠を持つ。

製品上の customer export は、移行と信頼のための強い終了実務だが、個人情報保護法上の開示請求と同義とは限らない。対象データ、形式、本人確認、第三者情報、契約上の portability を別に確認する。

5. `INFRA_AND_SECURITY_CLOSEOUT`

cron、queue、webhook、email、notification、backup、monitoring、domain、certificate を一覧にする。
API key、OAuth app、token、service account、CI/CD secret、store/PSP role を revoke または限定する。
database、object storage、log、cache、search index、model/vector store をデータ計画と照合して終了する。
vendor plan、support、invoice、data deletion/export、account owner を確認する。
domain と security/contact channel は、なりすましや旧 URL の危険を評価して保持期間を決める。サーバーと同日に自動失効させない。
最終状態を外部から test し、unexpected charge、公開 bucket、稼働 job、dangling DNS がないことを確認する。

6. `EVIDENCE_ARCHIVED`

最終顧客・契約 inventory
通知と送達
refund/credit/cash reconciliation
export/migration の提供・受領
data retention/deletion の根拠と receipt
credential/access closeout
vendor/store/PSP state
open incident/dispute
帳簿・税務・契約・security record の保存場所、期限、owner
最終 decision と unresolved exception

保存 archive 自体にも最小権限、復旧可能性、削除期限を持つ。証拠を残すために利用データ一式を無期限複製しない。

`CLOSED` gate

次のいずれかが UNKNOWN または open なら sunset_active のままにする。

新規販売・自動更新・trial conversion が停止した。
active contract、entitlement、support promise が終了または有効に承継された。
前受未履行、refund、credit、chargeback、未払が照合された。
顧客へ export/移行機会と最終連絡先を提供した。
customer/user data は削除・利用不能化されたか、保存根拠・範囲・期限・owner がある。
subprocessor/provider copy と backup の扱いが確認された。
job、webhook、key、token、role、storage、public endpoint が終了状態と一致する。
domain、email、security contact、脆弱性・incident 対応の残存期間が決まった。
税務・会計・契約・security 記録の保存と最終廃棄 owner がある。
dispute と incident は解決済みまたは有効に承継され、通常の終了後問い合わせ窓口には owner と期限がある。
完了 evidence が、後から確認できる場所に保存された。

売却・譲渡・統合は `closed` ではない

売却価格や LOI が決まっても、運営責任が自動的に移るわけではない。少なくとも次を分ける。

売る asset: code、domain、brand、data、契約、receivable、prepaid balance、documentation
残す asset と責任: tax、過去 incident、既存債務、別製品の共有 code/account
IP/license: 自作、OSS、外注、顧客固有物、AI/model/output の利用条件
契約: assignment/novation、change of control、通知、同意、SLA、refund
Data: due diligence で見せる範囲、承継対象、利用目的、国外移転、交渉不成立時の返還・削除
Operation: account owner、PSP/store、DNS、cloud、support、on-call、security contact の切替時点
Customer: price、terms、privacy notice、export、問い合わせ、継続または退出の選択

個人情報保護委員会は、事業承継に伴い取得した個人情報を、承継前に特定された利用目的の達成に必要な範囲で利用できると説明する。これは買手が無制限に別用途へ使えるという意味ではない。また、事業承継の交渉が不成立なら、交渉で受け取った個人データの返還・消去・廃棄等が必要とされる。個別契約、国外移転、regulated data、承継の実体は専門家へ確認する。

Transfer gate は、顧客とデータの責任が誰にいつ移り、旧 owner が何をいつまで保持するかを evidence 化した時点で閉じる。移行不能な account や vendor が一つでもあれば、別 liability として残す。

創業者不在を一つの failure domain として扱う

一人事業では、本人が最大の shared dependency になりやすい。完全な事業継続組織を作るのではなく、顧客被害を限定する最低限の continuity packet を用意する。

発動条件と権限者:
顧客・会計士・専門家・主要vendorの連絡先:
status / support / security連絡の更新方法:
新規販売・更新・危険なautomationを止める方法:
返金・credit・決済確認の手順と上限:
customer export / restore / read-onlyの手順:
domain・DNS・email・cloud・PSP・storeのaccount owner:
break-glass accessの保管、監査、失効:
open incident / contract / annual prepaidの一覧:
本人復帰、移管、sunsetの判定期限:
最後にtabletop testした日:

平文の全 secret を一つの文書へ集めない。最小権限、複数要素、sealed recovery、利用記録、定期失効を使う。代理人に対する access plan は、契約変更や支出の無制限な権限を意味しない。誰も代理できない場合は、危険な自動 action を安全側に止め、顧客へ状態を伝えられる設計を優先する。

中小企業庁の事業継続力強化計画は、災害等への事前対策と継続計画を中小企業が取り組みやすくする枠組みを提供する。個人 SaaS の RTO や予備率を決める benchmark ではないが、創業者不在、資金、代替手段、連絡体制を事前に書く参考になる。

月次 90 分 Portfolio review

毎月は初期値であり、入金頻度、契約更新、事業数に応じて cadence を変える。重要なのは、同じ cutoff と decision log を持つことだ。

0〜15 分: cutoff と事実を固定

銀行、PSP、会計、invoice、subscription、support、時間記録を照合する。
各 metric の期間、cohort、source、取得時刻を記録する。
欠測、遅延、定義変更を UNKNOWN にする。

15〜35 分: 義務と reserve

time/cash waterfall を再計算する。
契約、前受、refund、incident、tax、sunset liability を更新する。
reserve 使用理由と補充 plan を記録する。

35〜55 分: 製品ごとの role/state/action

各製品の primary allocation_role と lifecycle_state を確認する。
前回 bet の上限、期限、反証、実績を比較する。
sunk cost ではなく次に使う 1 時間・1 円の価値を判断する。

55〜75 分: failure domain

新しい顧客、channel、provider、code、account が共通原因を増やしたか確認する。
上位 exposure を一つ stress test する。
未試験の recovery を UNKNOWN とする。

75〜90 分: commit

FUND/HOLD/HARVEST/MERGE/TRANSFER/SELL/SUNSET/STOP/PAUSE/UNKNOWN を一つ記録する。
今期の最大時間、最大現金、owner、判定日、反証を確定する。
Calendar と cash forecast に反映する。
顧客への変更がある場合は、11 章の account/contract 単位へ落とす。

四半期または重要変更時には、創業者不在、決済停止、cloud/identity、主 channel、security incident の tabletop test を行う。実障害があれば定例を待たず台帳を更新する。

Fully synthetic example

以下はモデルの動作を説明する完全な架空値であり、推奨比率や benchmark ではない。

時間 waterfall

月間portfolio稼働可能時間             120 h
- 共通管理・会計・security             12 h
- 契約済み提供・support                 36 h
- continuity reserve                   16 h
- active sunset作業                      8 h
= 裁量配分可能時間                      48 h

本人は 48 h を、cash engine の回収・維持へ 16 h、validated core の次の導入制約へ 24 h、new option の顧客検証へ最大 8 h と決めた。比率が良いからではなく、先に 72 h の義務・reserve を確保し、各 bet に判定日があるから許される。

現金 waterfall

事業用現金                         2,400,000 円
- 税等の内部拘束                     400,000 円
- 前受未履行・返金等                  500,000 円
- 確定済み支出                        250,000 円
- 絶対最低現金                        700,000 円
- continuity cash reserve            200,000 円
- sunset cash reserve                150,000 円
= 裁量配分可能現金                    200,000 円

Option の最大現金を 50,000 円にしても、残り 150,000 円を自動的に core へ使わない。次の invoice、reserve 補充、evidence の質に応じて unallocated のまま残せる。

四製品の判断

Product	Role	State	Decision	根拠と次の一手
`ledger_bridge`	`cash_engine`	`operate`	`HARVEST`	回収済み現金と正の完全負荷後貢献あり。大口集中を下げるまでは大型個別開発をしない
`close_flow`	`validated_core`	`growth`	`FUND`	同一 cohort の価値・入金・更新理由あり。24 h で導入 bottleneck 一つを検証
`brief_option`	`new_option`	`explore`	`FUND`	顧客 3 件への到達経路あり。8 h/50,000 円/判定日で支払意思だけを調べる
`receipt_ping`	`unfunded`	`sunset_active`	`SUNSET`	annual entitlement 3 件、export 1 件、記録保存が open。販売停止済みでも `closed` ではない

ledger_bridge と close_flow は別製品だが、同じ PSP account、cloud control plane、founder、共有 auth を使う。製品数は二つでも、これらの scenario では分散していない。PSP 停止 scenario では両製品の paying account、入金、refund 手段、顧客通知、復旧時間を一緒に数える。

実務付属物

Portfolio / dependency / sunset pack: 期間予算、製品 card、option、failure domain、scenario、liability、終了、譲渡、continuity、review のコピー用書式
SQLite companion: 粒度、分類軸、time/cash waterfall、相関依存、option 上限、sunset liability、fail-closed decision を fully synthetic data で再現するモデル

Template や SQL は判断を自動的に正しくしない。契約・決済・銀行・実作業・顧客 evidence との照合を前提にする。

今月の導入手順

1 日目

全製品・service・paid pilot・API・store listing・放置 domain を列挙する。
各 product に owner、顧客、契約、billing channel、data store を付ける。
分からない行を削除せず UNKNOWN とする。

2 日目

09 章から本人の時間・現金制約を取り込む。
time/cash waterfall を計算する。
Reserve を calendar と cash forecast へ実際に確保する。

3 日目

各 product に allocation role、lifecycle state、decision を別々に付ける。
新しい option は一つに絞り、最大時間・現金・判定日・反証を設定する。

4 日目

Dependency を failure_domain_id で group 化する。
最も広い共同停止 scenario を一つ tabletop test する。

5 日目

Maintenance または放置製品の sunset liability を inventory 化する。
closed gate を満たさない製品へ owner、期日、予算を付ける。
次の 30 日の Calendar、cash、顧客通知へ反映する。

根拠と限界

March の exploration/exploitation 研究は、新しい可能性の探索と既知の確実性の活用の配分が長期適応に関わることを論じる。個人開発者向けの固定時間比率は示さない。
McGrath の real options logic は、不確実性の下で小さな段階投資により将来拡大する権利を持つ考え方を支える。全 side project の価値や成功確率を保証しない。
Adner と Levinthal は、順次投資をすべて real option と呼ぶことへ注意を促す。個別製品の撤退 threshold を与える研究ではない。
Little の queueing relation と Coviello らの task juggling 研究は WIP と完了時間を考える根拠になるが、software 開発に固有の WIP 1 を証明しない。
NIST CSF 2.0 の C-SCRM quick-start guide は、supplier を知り criticality で優先し、関係を通じて risk を管理する枠組みを提供する。米国の cybersecurity guidance であり、本章の cash 配分率や障害確率を定めない。
NIST contingency planning は、impact に基づく recovery strategy、alternate equipment/location、manual method 等を扱う。連邦情報 system 向け資料を小さな SaaS へ比例的に応用する。
中小企業庁の事業継続力強化計画は、事前対策、継続計画、risk finance の入口になる。SaaS portfolio の benchmark ではない。
PPC の削除・事業承継資料、国税庁の帳簿保存、金融庁の前払式支払手段、Apple/Google の app/subscription 資料は、対象制度・channel にだけ使う。個別契約、国外提供、消費者法、法人/個人、税区分で追加要件があり得る。

本章の WIP 1、review cadence、state、field は管理上の初期設計であり、研究が示した普遍値ではない。本人の販売周期、契約、生活、事故履歴、回復試験で更新する。判断式を精密に見せることより、未履行の顧客責任と共通原因を見落とさないことを優先する。