roi_decisions に判断履歴を残す経営的価値 — 組織記憶としての強化部判定アーカイブ

強化部の世代交代問題

J リーグクラブの強化部 GM・SD の平均在任期間は 3-5 年。10 年で 2-3 世代の入れ替わりが起き、新スタッフは前任者の判定理由を知らずに業務を引き継ぐ。例: 「3 年前にあの選手を SELL したが、結果として戦力減になった。次回は HOLD すべき」のような学習が、口頭伝承では失われる。

Excel スプレッドシートの限界

多くのクラブは判定を Excel で管理しているが、(1) ファイル散逸 (2) フォーマット非統一 (3) 検索性ゼロ (4) 結果検証が手動、で組織学習に繋がらない。Footnote の roi_decisions はリレーショナル設計で player_profiles / roi_snapshots と紐付き、SQL クエリで「過去 3 年で SELL 判定した CB の outcome」を 1 行で取得できる。

判定時記録 (insert 時)

• player_id: 対象選手
• club_id: 自クラブ ID (RLS で他クラブから不可視)
• decided_by_user_id: 判定者の Footnote ユーザー ID
• decided_at: 判定日時
• decision: SELL / EXTEND / LOAN_OUT / HOLD / PROMOTE_TO_YOUTH 等
• target_window: 「2026 夏」「来シーズン」等の判定対象時期
• rationale: 判定理由 (テキスト、最大 2000 文字)

outcome 後日追記

• outcome_recorded_at: 結果記録日
• outcome_text: 結果テキスト (例: 「翌シーズン契約延長、主力起用」)
• outcome_value_yen: 結果金額 (実売却額・契約一時金等、任意)

監査ログ連動

roi_decisions への insert / update は roi_access_audit_log にも記録される (severity=info)。誰がいつどのアクションを取ったかが 7 年保管 (FIFA 規則準拠)。コンプラ事故時の遡及調査に活用可能。

結果記録待ちリマインダー

Squad ROI ダッシュボードに「結果記録待ち: N 件」のバナーが表示される (3 ヶ月以上前 + outcome 未入力の判定)。/club/squad-roi/pending-outcomes で一覧 + 一括入力可能。月 1 回 30 分の習慣化で、組織学習が継続する。

outcome の質を上げる書き方

• 何が起きたかを 1-2 文で: 例「他クラブからオファー受諾、¥6,000 万で売却」
• 判定時の予想との差異: 例「予想 ¥5,000 万 → 実際 ¥6,000 万、+20% 想定上回る」
• 学んだこと: 例「契約残 1 年の選手は早期売却が経済合理的」
• outcome_value_yen に数値を入れる: G9 ML 校正の学習サンプル必須条件

1. 四半期 review — 判定精度の振り返り

四半期に 1 回、過去 6-12 ヶ月の outcome 確定判定を集計。 (1) 予想 vs 実績の絶対誤差、(2) decision 別の精度 (SELL は正確 / EXTEND は楽観的等)、(3) 判定者別の精度ばらつき、を分析することで、強化部の判断品質が見える化される。

2. 新スタッフ オンボーディング

新任の強化部スタッフは、過去 3 年の roi_decisions を読むことでクラブの判断哲学を学ぶ。「うちのクラブは 25 歳以下の SB は基本 EXTEND 方針」「契約残 6 ヶ月以内の選手は損切り傾向」のようなパターンが明文化される。Excel 時代の口頭伝承から脱却。

3. G9 ML 校正の学習サンプル

outcome_value_yen が記録された判定は、月次バッチで club_roi_calibration の correction_factor を EMA 更新。クラブ固有の評価バイアス (例: うちは CMF を高評価しがち) が学習され、FMV 推定値が自クラブパターンに最適化される。3 サンプル以上で校正適用、12 ヶ月で精度安定。

1. rationale が空欄・「判定済」のみ

「SELL」と書いただけでは将来の判断材料にならない。最低限「(1) 何を見て (2) どう判断したか」を 2-3 行で残す。例: 「直近 6 試合の出場 30%、PVS 5pt 下降、他クラブから ¥3,000 万オファー → 機会損失避け SELL」のような具体性。

2. outcome を記録しない

判定だけして outcome を入れないと、ML 校正の学習サンプルにならず精度向上が止まる。Squad ROI ダッシュボードの「結果記録待ち」バナーを毎月チェックする運用習慣が必要。

3. 判定理由を後で「美化」する

結果が悪いと「実は懸念していた」「データは見ていなかった」と後付け修正したくなるが、これは組織学習を破壊する。判定時の rationale は immutable とし、outcome 記録時に「学び」を別フィールドで残す運用が誠実。

4. 個人プレーで記録

GM 1 人だけが記録する設計だと、退任時に途絶える。owner / admin 複数名で記録権限を持ち、毎月 1 回のレビューミーティングで集合知化することで組織記憶として定着する。