第27章 プレイブックを更新する

第26章では、案件の背景、制約、仮説、判断、行動、結果を時点ごとの証拠として記録しました。一つの案件でうまくいった手順を、そのまま「今後は必ずこうする」と書けば、偶然や固有条件まで一般化してしまいます。

プレイブックを育てるとは、事例を追加することではありません。複数の経験から適用条件と反例を見つけ、誰が何の証拠で見解を変えたかを残し、次の案件で検証できる暫定ルールへ更新します。

27.1 教科書とプレイブックを分ける

本書は、次の層を持ちます。

原則まで毎回変えると本が不安定になります。事例やツール例を原則のように固定すると古くなります。どの層を更新するかを先に決めます。

27.2 再利用できる知見と固有事情を分ける

案件記録から、次を分けます。

観測:
小規模顧客 20 社では、手動代行後に完了が増えた。

固有事情:
対象は 1 業種、担当者は熟練者、繁忙期外だった。

再利用候補:
製品開発前に手動提供で課題と支援時間を測る。

適用条件:
手動提供が安全で、顧客へ説明でき、本番との差を記録できる。

反例:
専門資格が必要で、人による代行自体が本番を代表しない案件。

「うまくいったこと」ではなく、「どの条件なら次の選択を助けるか」へ変換します。

27.3 一件からルールへ昇格させない

知見の状態を分けます。

案件数だけで昇格を決めません。案件の独立性、証拠の質、反例、損害の大きさ、他の説明を確認します。

複数に見える案件でも、同じ担当者、顧客群、紹介経路、時期に偏っていれば、同じ誤差を繰り返しているだけかもしれません。似た成功例だけでなく、同じ方法が成立しなかった案件と、あえて適用しなかった案件を探します。

確信度は、件数だけで数値化しません。結果を直接測ったか、代替説明を除けるか、異なる条件で再現したか、誤った場合の損失がどちら側に大きいかを言葉で残します。証拠に見合わない「成功確率 82%」のような精度を作りません。

原則へ昇格した後も、反証できない正解にはしません。成立しない条件と、見直しを始める兆候を残します。

27.4 検索できる形で判断を残す

全文検索だけでは、似た言葉を使わない案件を見つけられません。案件記録へ、後から探すための手掛かりを付けます。

• 業種、事業段階、顧客類型
• 意思決定の種類
• 主な制約と最低条件
• 使った方法と AI の役割
• 採用案、結果、確信度
• 適用条件、反例、除外条件
• 情報区分、閲覧権限、保管期限
• 所有者、版、最終確認日、次回見直し日

タグを増やしすぎると入力されません。実際の検索質問から逆算します。例えば「最低現金が厳しい段階投資」「少標本の顧客実験」のような問いで見つかるかを試します。

小さな更新では、対象、変更、根拠、所有者、確認日だけを書きます。移行や安全へ影響する場合だけ、適用条件、反例、権限、保管期限などの詳細を追加します。

27.5 過去の判断を現在の正解で上書きしない

プレイブックの現行版だけを残すと、なぜ見解が変わったかが消えます。

変更記録には次を残します。

• 変更前と変更後
• 対象となる層と章・テンプレート
• 変更理由と新しい証拠
• 影響を受ける案件と利用者
• 互換性、移行、使用停止日
• 提案者、確認者、承認者
• 公開日、版、次回見直し日

過去版は誤りとして消さず、当時の前提とともに参照可能にします。ただし、危険な手順は目立つ形で使用停止を示します。

知識が使えなくなった理由も区別します。

• 訂正: 当時から事実、推論、手順に誤りがあった
• 陳腐化: 法令、市場、技術、組織などの前提が変わった
• 適用縮小: 反例により使える条件が狭くなった
• 統合: 別の項目と重複し、独立した記述が不要になった

この区別があれば、過去の担当者を現在の前提だけで評価せず、次に確認すべき変化も分かります。

27.6 更新の重さを影響に比例させる

誤字と、投資判断の原則変更を同じ手続きにしません。

軽微な改善を重い会議で止めず、重大な変更を一人で公開しません。

更新候補は、再発可能性、影響、緊急性、別案件での再利用性から選びます。案件ごとに本文を増やすのではなく、低影響の一回限りの観測は案件記録に留めます。緊急停止には期限と責任者を付け、通常のレビューで訂正、適用縮小、恒久停止のどれにするか決めます。

役割は変更の重さに応じて分けます。所有者が提案を受け付け、案件担当者が事実を確認し、該当領域の担当者が内容をレビューし、公開責任者が承認します。公開担当は版、適用日、周知を管理し、重大な副作用を見つけた人は承認を待たず使用停止を提案できます。一人が複数の役割を担う小規模組織でも、誰のどの判断かは記録します。

27.7 更新提案を小さな検証へ変える

更新案も仮説です。

変更案:
すべての投資判断メモへ「無決定の費用」を追加する。

根拠:
3 案件で延期が費用 0 と扱われ、再判断日が失われた。

期待:
延期案にも責任者、情報、再判断日が入る。

反対指標:
小額判断のメモ作成時間が過度に増える。

試行:
次の 2 案件で使い、所要時間と決定内容を確認する。

採用条件:
判断の欠落が減り、追加時間が上限内。

テンプレートを更新した時点では完了ではありません。使われたか、判断が変わったか、別の負担を増やしていないかを確認します。

更新の完了条件には、影響する本文、テンプレート、図版、AI 指示例、研修資料、進行中案件への反映を含めます。次の対象案件で実際に参照されたか、例外扱いされたか、判断や所要時間がどう変わったかまで追跡します。

進行中案件へ遡って適用する場合は、案件責任者が費用、日程、契約、顧客への影響を確認します。新しい手順であることだけを理由に、一律に差し替えません。

27.8 矛盾と重複を横断して確認する

章単位で正しくても、全体では用語や条件が食い違います。

• 同じ用語が章ごとに別の意味になっていないか
• 意思決定者、確認者、停止権の役割が変わっていないか
• 金額、顧客数、期限など継続事例の数値が一致するか
• 「必ず」と「場合による」が矛盾していないか
• 小さな判断と重大な判断で、確認の厚さが適切に変わっているか
• 前章の成果物が次章で使う材料になっているか
• 参考資料の版と確認日が古くなっていないか

変更した章だけでなく、定義の利用箇所、前後章、付録、図版、AI 指示例を検索して更新します。

成果物の置き場所も分けます。読者へ説明する原則と手順は本書、表記・図版・出典など複数文書に共通する規則は共通スタイルガイド、契約情報を含む証拠は社内案件記録、読者が変更の影響を確認する情報は公開変更履歴へ置きます。

27.9 公開版と社内プレイブックを分ける

公開版は、読者が検証し再利用できる原則、手順、匿名化した事例を含みます。社内版は、契約で許された範囲の案件記録、費用、判断、顧客情報へアクセスできます。

公開版から社内記録へリンクしません。社内版から公開版へ知見を移すときは、契約、顧客確認、匿名化・再特定、係争、個人への影響、公開価値を確認します。

読者からの指摘は公開情報ですが、案件の内部事情を推測して回答しません。修正の根拠として採用する場合も、再現確認とレビューを行います。

外部からの提案は、再現できるか、影響があるか、既存提案と重複しないか、公開による悪用や再特定の危険がないかを確認してから更新候補にします。採用しない指摘にも、必要な場合は理由と再確認条件を残します。

同じ扱いを社内提案にも適用します。現時点で採用しない案には、必要なら不足している証拠、前提が変わった場合の再検討条件、担当者を残します。

27.10 AI で検索・比較し、人が更新を承認する

AI は、案件横断の共通点、反例、用語の揺れ、古い参照、重複した手順を探せます。

複数の案件記録と現行プレイブックを示します。

1. 観測、仮説、反復、暫定ルール、撤回へ分類する
2. 共通条件と一回限りの事情を分ける
3. 暫定ルールへの反例と適用外を探す
4. 現行ルールと矛盾する記録を、双方の根拠付きで示す
5. 用語、役割、数値、期限、版の不一致を探す
6. 更新候補ごとに影響箇所と必要なレビューを示す
7. 機密、個人情報、再特定可能な組み合わせを指摘する
8. 存在しない案件、合意、因果、出典を作らない

AI が似ていると判断した案件が、重要な制約では異なることがあります。原記録と担当者へ戻り、情報区分と利用目的を確認します。AI に原則の昇格や公開可否を自動決定させません。

27.11 更新を定期作業と発生時作業へ分ける

更新の入口は二つあります。

• 発生時: 重大な誤り、法令・仕様変更、安全上の問題、強い反証
• 定期: リンク、書誌、ツール例、未検証ルール、読者指摘、利用状況

各章とテンプレートに所有者、最終確認日、次回見直し日を付けます。更新期限を過ぎただけで内容を無効とせず、未確認であることを表示し、優先度を影響から決めます。

専用の会議は原則として増やさず、第26章の案件振り返りで更新候補を拾い、既存の定期レビューで採否と整理を行います。

更新後は、影響を受ける利用者へ、何が変わり、いつから、過去案件へ遡って適用するかを知らせます。

公開変更履歴では、変更点、影響を受ける読者、適用日、移行の要否を短く示します。内部記録の「公開日」は版を読めるようにした日、「適用日」は新しい手順を使い始める日、「使用停止日」は旧手順を使えなくする日として分けます。「未確認」は見直し期限を過ぎた状態、「使用停止」は危険などのため利用を止めた状態、「撤回」は根拠を再評価して推奨から外した状態です。

27.12 本をプレイブックとして育てる

本書を更新する一連の流れは次です。

案件で判断する
↓
判断時点の証拠を残す
↓
結果と判断品質を振り返る
↓
観測、適用条件、反例を記録する
↓
複数案件で暫定ルールを検証する
↓
影響に応じてレビューする
↓
公開版・社内版を更新する
↓
次の案件で利用と効果を確かめる

更新数を成果にしません。重複を削る、古い手順を撤回する、適用条件を狭めることも改善です。

定期見直しでは、参照されない項目、重複、所有者のいない項目、検証期限を過ぎた暫定ルールを、維持、統合、保留、撤回へ分けます。削除して件数を減らすことも、検索と判断を速くする成果です。

ただし、参照回数だけで価値を決めません。重大事故や法令違反を防ぐ低頻度の手順は、使われないこと自体が正常な場合があります。維持費と、失った場合の損害を合わせて判断します。

小さく始める場合は、案件振り返りで更新候補を少数に絞り、所有者が影響に応じたレビューを選び、次の対象案件で利用と結果を一度確認するところから始められます。

考えてみる問い

第26章の案件記録から一つ学びを選び、観測、固有事情、再利用候補、適用条件、反例へ分けてください。次に、現行プレイブックのどの層を、誰が、どの証拠で更新し、次の案件で何を確認するかを書いてください。

プレイブックを更新するとは、経験を正解として蓄積することではありません。観測と一般則を分け、適用条件と反例を残し、見解が変わった理由を版として保存し、次の案件で再び検証できる形へ整えることです。

本書も完成によって止まりません。実務で使い、成功と失敗を記録し、読者の指摘と新しい証拠を確認しながら、使わなくなった知識を撤回し、新しい判断を加えて育てていきます。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の知見状態表、変更区分、更新フロー、AI への依頼例は、以下の資料を踏まえた本書独自の整理です。

• International Organization for Standardization ― ISO 30401:2018 Knowledge management systems ― 組織の知識管理体系を確立、実施、維持、レビュー、改善する考え方を参照。2026 年 7 月 15 日時点では公開中ですが、2 件の追補があり、後継版の策定が進んでいます
• GOV.UK Service Manual ― Iterate and improve frequently ― 利用データとフィードバックから継続的に改善する考え方を参照