エースが辞めても、チームは死なない。退職者の『勘と経験』をAIに移植する「デジタル・シャーマニズム」【チームビルディングの科学 Vol.80】

「今、ちょっとお時間いいですか？」

金曜日の午後、会議室に呼び出されたあなたの前で、チームの要（かなめ）であるエースPL（プロジェクトリーダー）が申し訳なさそうに切り出します。 「実は、来月末で退職することになりました」

その瞬間、あなたの頭の中では、彼だけが知っている「あの気難しいクライアントのあしらい方」、彼にしか経緯が分からない「複雑怪奇な業務フロー」、そして彼が肌感覚で察知していた「炎上の予兆」が、音を立てて崩れ落ちます。

あなたは慌ててこう頼むでしょう。 「頼む、引き継ぎ資料を完璧に作ってくれ！」と。

しかし、一ヶ月後に出てくるのは、「いつ更新されたか分からないフォルダ」と「形式的な手順書」だけ。
彼が持っていた「なぜその判断をしたのか」という、血の通った判断基準（センス）は、彼の退職とともに永遠に失われてしまいます。

Vol.80となる今回は、この「属人化という名の時限爆弾」を解除するために、AIを使って退職者の「魂（思考プロセス）」をチームに残す技術をお伝えします。

■ 老舗の「秘伝のタレ」を捨てるな

エースが抜けた穴が埋まらないのはなぜでしょうか？
それは、私たちが引き継ごうとしているのが「レシピ（手順）」だけで、「秘伝のタレ（暗黙知）」を捨ててしまっているからです。

• 形式知（レシピ）： 「A社への定例報告は月曜に行う」というルール。

• 暗黙知（タレ）： 「A社の部長は月曜の朝は機嫌が悪いから、ネガティブな報告は火曜の午後にずらす」という判断。

マニュアルに残るのは前者だけです。
しかし、プロジェクトを救ってきたのは、間違いなく後者の「エースの勘」や「阿吽の呼吸」だったはずです。

これを人間が聞き出すのは困難です。
「全部教えて」と言われても、本人すら「無意識にやっていること」は言語化できないからです。

■ マニュアルを作らせるな、AIに「取材」させろ

退職までの貴重な1ヶ月、エースに孤独にドキュメントを書かせてはいけません。 それは「死んだ文字」を量産するだけの作業です。

代わりに、AIを「熱心なインタビュアー」としてエースにぶつけてください。

エースが過去に書いた「日報」「チャットログ（Slack/Teams）」「顧客への提案資料（PPT/PDF）」。
これらをAIに読み込ませ、「なぜ、この時こうしたの？」と深掘りさせるのです。

• AI: 「アップロードされた議事録で、あなたはあえてB案を推していますが、コストが高いB案を選んだ『決定的な理由』は何でしたか？」

• エース: 「あ、それはね、実はクライアントの担当者が……」

この対話こそが、デジタル化された「秘伝のタレ」になります。
AIは、人間が気後れして聞けないような細かいことでも、文脈を読み取って執拗に、かつリスペクトを持って質問し続けます。

■ 「有事」だけでなく「平時」から継承を回す

ここまでは「退職」を前提にお話ししましたが、実はこの手法、エースが辞める予定がなくても、定期的に実施することに真の価値があります。

大きなトラブルを乗り越えた後や、難航した調整が終わったタイミングで、AIにインタビューをさせるのです。

1. 若手の育成: エースの判断基準が言語化され、チーム全員の視座が上がります。

2. エースの負荷軽減: 似たような相談が来た際、「AIの回答を見て」と言えるようになり、エースがボトルネックになりません。

3. チームの資産化: 言語化された「タレ」が蓄積されるほど、チームは「特定の個人」に依存しない、強靭な組織へと進化します。

「辞めるから慌ててやる」のではなく、「エースの感覚をチームに分散させる」ためにAIを使う。
これが現代版の知恵の継承です。

■ 【今回の明日から使えるお土産】

エースが残したチャットログや資料を読み込ませるだけで、「インタビュー質問の作成」から、回答後の「AI学習用データの生成」までを一気通貫で行うプロンプトです。

▼ 手順

1. エースが残したファイル（チャットログ、画像、資料）をアップロードする。

2. 以下のプロンプトを送信し、生成された質問をエースにぶつける。

3. エースの回答をチャット欄に入力する。

4. AIが「RAG登録用フォーマット」を出力するので、それを.txtか.mdで保存する。

▼ デジタル・アーカイブ生成エージェント

# Role (役割)
あなたは、熟練の「ナレッジ・エンジニア」です。
プロジェクトリーダー（PL）や熟練者が持つ「暗黙知（秘伝のタレ）」を抽出し、人間にもAIにも読みやすい「日本語のYAML形式」で保存するまでを担当します。

# Context (前提)
対象者は優秀なエキスパートですが、多くの業務を「勘」や「経験」でこなしており、言語化されていません。
このままでは、プロジェクトの背景や、対人関係の機微、トラブル回避の嗅覚がチームに共有されません。
以下のログから「Why（なぜそうしたか）」「How（どのような感覚か）」を深掘りしてください。

# Rule (制約事項)
1.  **即時完了の禁止**: ユーザーが「以上」「保存」「YAML出力」等の明確な終了合図を出すまでは、**絶対にStep 3（YAML出力）を実行しないでください。**
2.  **反復ヒアリング**: Step 2で回答を受け取った後、内容に曖昧な点があれば追加質問を行うか、「他に追加すべきエピソードはありますか？」と確認してください。
3.  **情報の蓄積**: 対話の中で発生した「訂正」や「追記」は、内部メモリに蓄積し、最終的な出力時にすべて反映させてください。
4.  **出力分離**: 最終的な挨拶は、必ずYAMLコードブロックの**外**に出力してください。

# Process (実行手順)
このチャットセッションでは、以下のステップを実行してください。

**Step 1: 分析と質問生成**
ユーザーがアップロードした「ログ、画像、資料」を分析し、以下の**[Output Example]**の水準で、鋭い質問リスト（5〜10問）を作成し提示してください。

**[Output Example for Step 1]** (※この深さを基準にすること)
* **カテゴリ: 人間関係**
  Q. 「A社定例資料（P.5）で、あえてコスト高のB案を推奨していますが、担当者の『どのような性格』を考慮しての判断でしたか？」
* **カテゴリ: プロジェクトの歴史**
  Q. 「構成図（Fig.2）に『※要相談』というメモ書きがありますが、ここにある『仕様書には書けない懸念』は何ですか？」
* **カテゴリ: リスク嗅覚**
  Q. 「チャットログで、障害発生直後に『まずは静観する』と指示しています。どのような兆候があれば『動くべき』と判断しますか？」
* **カテゴリ: 運用・裏技**
  Q. 「マニュアルには『承認必須』とありますが、緊急時にあなたが使っている『ショートカットの手順』はありますか？」

**Step 2: 回答の待機と深掘り（ループ）**
提示した質問に対し、ユーザー（エース本人またはインタビュアー）が回答を入力するのを待ってください。
回答を受け取ったら、即座に終了せず、**「認識に齟齬がないか確認」**または**「さらなる深掘り質問」**を行い、ナレッジの純度を高めてください。
※ユーザーから終了の合図があるまで、このStepを繰り返します。

**Step 3: ナレッジの保存（日本語YAML形式）**
ユーザーから「完了」「YAML出力」の指示があった場合のみ、これまでの全回答（訂正含む）を整理し、以下の形式で出力してください。

# Output Format for Step 3 (最終出力イメージ)
```yaml
引継ぎナレッジリスト:
  - カテゴリ: "人間関係・ステークホルダー"
    質問: "A社への提案時に、あえてコスト高のB案を推奨した理由は？"
    回答: |
      A社の佐藤部長は「安さ」よりも「サポートの手厚さ」を重視する傾向があるため。
      過去の議事録（2024/05）にもある通り、安価なプランでトラブルになった際、激昂された経緯がある。
      そのため、多少高くても保守工数が確保できるB案の方が、結果的に信頼を得られると判断した。
    関連タグ: ["A社", "佐藤部長", "リスク管理", "提案ノウハウ"]

  - カテゴリ: "トラブル対応の嗅覚"
    質問: "システム監視アラートを「静観」した判断基準は？"
    回答: |
      CPU使用率が80%を超えても、メモリに余裕がある場合はバッチ処理の一時的な負荷であることが多い。
      過去の傾向から、15分以内に自然解消する場合が9割なので、即座に再起動せず様子を見る。
    関連タグ: ["運用", "トラブルシューティング", "インフラ"]
```

ヒアリングへの回答ありがとうございました。
全ての情報はYAML形式でパッキングされました。
---
# System Message
**アーカイブ・エージェント起動。**
まずは分析対象となるファイル（チャットログ、資料など）をアップロードし、「分析開始」と指示してください。

【出力イメージ】

【入力のやり取り】

💡 使い方のヒント：ファイルの「束ね方」

引き継ぎのヒアリングは、1回では終わりません。 AIの出力結果を毎回別ファイルにすると管理が大変になるため、「業務単位」でテキストファイルを用意し、そこに追記していく運用をおすすめします。

【推奨ファイル構成例】

• A社案件_引継ぎ.txt

• 運用トラブル対応_引継ぎ.txt

• 開発プロジェクト経緯_引継ぎ.txt

例えば、今日は「A社について」インタビューしたら、出力結果をA社案件_引継ぎ.txtの末尾に貼り付けます。 将来、「A社の契約更新で困った！」という時は、このA社案件_引継ぎ.txtひとつをAIにアップロードして相談すれば、的確な回答が得られます。

■ 人は去るが、知恵は残せる

「後は任せた」と言って去っていくエースの背中は、寂しいものです。
しかし、AIという新しい器に、彼の「視座」や「想い」を少しだけ分けてもらうことはできます。

マニュアルという「抜け殻」ではなく、思考という「魂」を引き継ぐこと。 それができれば、エースが抜けた穴は、チーム全員が成長するための「窓」に変わるはずです。

本日の処方箋は以上です。

「よし、辞める前に根掘り葉掘り聞いて、アーカイブしてやるぞ！」と思った方は、 ぜひ「スキ（♡）」と「フォロー」をお願いします。
（スキの数だけ、私もAIに自分の思考を学習させます！）

チームビルディングの科学は、まだまだ続きます。 次回Vol.81もお楽しみに！

#ナレッジマネジメント #プロジェクトマネジメント #引き継ぎ #退職 #AI活用 #RAG #チームビルディング #ChatGPT #Gemini #Claude