担当が変わってもAI業務が止まらない。引き継ぎパッケージの設計

4月の異動の後に、こういう相談が来ます。
「前の担当者がAIでやっていた業務が、止まってしまいました」。

引き継ぎ自体はきちんと行われていて、業務の手順書も渡されているのに、です。
ところがAIを使った部分だけが再現できません。
指示の内容、前提の設定、どこまでを任せてどこから人が確認するかという情報が、引き継ぎ資料に入っていないからだと思います。

今回は、引き継ぎパッケージの設計について整理していきます。
情報をどの層に置くかという整理のほうはAIは前の会話を覚えているのか。情報の置き場所を決める3分類にまとめてあります。

なぜAIを使った部分だけ止まるのか

理由は3つあります。
どれも、設計しておけば防げるものです。

まず、引き継ぎ資料の様式にその欄がないことです。
既存の様式は業務の手順・関係者・使うシステムという構成で、AIの使い方を書く場所がないので単純に書かれません。

次に、前任者が「業務の一部」だと認識していないことです。
自分の工夫として使っていた場合、そもそも引き継ぐべきものだと思っていないので、「便利だからやっていただけ」という認識のまま異動していきます。

もうひとつが、やり取りの中にしか情報がないことです。
指示の文面、前提の設定、試行錯誤の経緯が個人のアカウントの履歴の中にあると、そもそも引き継ぎようがありません。

再現に必要なのは指示・前提・判断基準の3つ

引き継ぐべき情報は3つで足ります。
何を渡せば、後任は前任者と同じように動けるのでしょうか？

まず、指示です。
何をどう依頼しているかという、依頼文そのものを指します。

次に、前提です。
その依頼の前に渡している情報で、参照させている資料、自社の説明、様式の指定などです。
毎回書いている前提をまとめて置く方法は毎回同じ前提を書かせない。組織の共通前提をデフォルト化するで扱っています。

もうひとつが、判断基準です。
どこまでを任せてどこから人が確認するか、出てきたものの何を見て良否を判断するかです。

なかでも判断基準が最も抜けます。
ここがないと、後任は出てきたものをそのまま使うか、逆に全部を疑って手作業に戻るかのどちらかになります。

どちらも業務として成立しません。
判断基準は前任者に聞かないと出てこないので、異動が決まってからでは間に合いません。
日常的に書き残す設計のほうが、確実に必要になります。

引き継ぎパッケージは1業務1枚・6項目

書く項目を決めておきます。
まず、業務名とAIを使っている工程で、業務全体のどこで使っているかです。

次に、使っている手段で、どのサービスのどの機能か、ボットとして保存しているならその名前も書きます。
続いて依頼文で、そのままコピーして使える形で載せます。

4つめが渡している前提で、参照させている資料の場所と事前に伝えている情報です。
5つめが人の確認する箇所と観点で、何を見て良否を判断するか、過去に間違いが出た箇所があればそれも書きます。

最後の6つめが、うまくいかなかった依頼の仕方です。
この項目を入れるのが、この様式の要点です。
成功した形だけを渡すと、なぜその形になったのかが後任には分からず、同じ試行錯誤を繰り返すことになります。

とはいえ異動の直前に6項目を書くのは現実的ではないので、日常の中に組み込んでしまいます。
まず、ボットとして保存する方法です。
依頼文と前提をボットの形で固定しておけば、工程・手段・依頼文・前提は自動的に残り、個人の履歴ではなく共有できる形になります。

次が、カタログの備考欄に書く方法です。
ボットをカタログに載せるときに、確認の観点と失敗した依頼の仕方を備考として書きます。
作った直後なら5分で書けます。
カタログそのものの設計は社内ナレッジをAIで活用する方法。ツール導入・RAG・手持ちのAIの選び方にまとめてあります。

もうひとつが、案件の記録に判断を書き出す方法です。
重要な判断が決まったらその理由を案件の記録に残し、AIとのやり取りの中に置いたままにしません。

3つとも、引き継ぎのために特別な作業をしているわけではありません。
日常の運用として意味のある作業が、そのまま引き継ぎ資料になっている状態を目指します。

既存の様式に1項目足して、異動期に確認に入る

組織としてやるべきことは、実はこれだけです。
既存の引き継ぎ資料の様式に「AIを使っている工程」という項目を1つ足します。
新しい引き継ぎ様式を作らないのがコツです。
既存の様式に足せば引き継ぎのときに必ず目に入りますが、別文書を新設すると書かれません。

そのうえで推進チームが異動の時期に確認に入ります。
例えば4月と10月の前に、AIを業務で使っている人の異動があるかを人事に確認して、該当する部門に声をかける。
ここは推進担当が主導しないと動きません。

3年ごとに定期異動がある会社で、こんな例がありました。
着手前は部門ごとにAI活用が進んでいたものの、異動のたびに一部が止まっていたのです。
特に個人が自分の工夫として使っていたものが消えます。
前任者に聞けば分かるのですが、「異動先の仕事で手一杯で、前の担当に聞きに行けなかった」という声が多く、聞きにくい状況になっていました。

やったことは3つです。
まず既存の引き継ぎ様式に「AIを使っている工程と、その依頼内容」を足しました。
次に、個人の履歴に留まっているものを、ボットとして保存し直す作業を推進チームが支援しています。
部門ごとに1日、担当者と一緒に作業する形です。

最後に、カタログに「作成者」と「引き継ぎ先」の欄を足しました。
異動が決まった時点で引き継ぎ先を埋めてもらい、埋まっていないものは推進チームが引き取る形にしています。
結果として次の異動期に止まった業務は大幅に減りました。

予想外の効果として、保存し直す作業の過程で重複が見つかりました。
部門ごとに同じ用途のものが作られていたことが、この機会に分かったわけです。
引き継ぎ対策として始めた作業が、そのまま資産の棚卸しになったのは示唆的でした。

属人化は完全には解けない。よくある失敗の型は5つ

正直に書いておきたいのですが、引き継ぎパッケージがあっても前任者と同じ成果はすぐには出ません。
依頼文と前提と判断基準を渡しても、なぜその判断基準なのかは経験に紐づいているので、後任は最初の数件で「これで本当に合っているのか」という違和感を持つはずです。
だから設計としては、最初の数件を前任者に見てもらう期間を作るほうが確実です。
1か月程度、質問できる状態にしておきます。

異動先の業務が始まっているので長くは取れませんが、数件見てもらうだけで再現度は変わります。
また、後任が判断基準を書き換えてよいと伝えておきます。
前任者の基準をそのまま守らせると、後任は自分の判断が入らないまま業務を回すことになります。
書き換えた履歴が残れば、それもそのまま資産になります。

よくある失敗の型も挙げておきます。
新しい引き継ぎ様式を作ること、判断基準を書かないこと、うまくいかなかった依頼の仕方を書かないこと、異動の直前に書かせようとすること、引き継ぎ資料だけで完結させることです。
どれも、既存の様式に1項目足して日常の運用で残し、最初の数件を見てもらう期間を作れば防げます。

前任者の依頼の仕方を後任が見つけられるように、当社の組織のAIポータル「AI Portalize」では、社内で作ったGemやGASのWebアプリを登録すると全社に公開されます。

既存の様式に1項目足すだけで、止まる業務は減らせる

AIを使った部分だけが引き継げないのは、様式にその欄がない・前任者が業務の一部だと認識していない・やり取りの中にしか情報がない、の3つが原因です。
再現に必要なのは指示・前提・判断基準の3つで、なかでも判断基準が最も抜けて、最も影響します。
引き継ぎパッケージは1業務1枚・6項目で、特に「うまくいかなかった依頼の仕方」を入れるのが要点になります。

日常の対策としては、依頼文と前提をボットとして保存し、カタログの備考に判断基準を書いて、重要な判断は案件の記録に書き出します。
引き継ぎのための特別な作業をしない設計にしておきます。

組織としてやることは、既存の引き継ぎ様式に「AIを使っている工程」を1項目足すことです。
また、異動期の前には推進チームが確認に入ります。
自部門でAIを使っている業務を1つ選んで、まずこの6項目を書いてみてください。