社内でAIを教えるとき|誰に何から教えるか

教える順番 社内での導入と運用

研修をやったのに使われない。この相談をよく受けます。

原因は教える内容ではなく、順番と対象にあることが多い。

全員に同じことを教えない

まず、対象を分けます。

層 知りたいこと 教える内容
すでに使っている人 もっとうまい使い方 失敗例と、その回避
試したが続かなかった人 なぜ自分は使えなかったのか 向いている作業の見分け方
触っていない人 そもそも何ができるのか 自分の業務での実例1つ
管理する立場の人 どこまで許してよいか 入れてよい情報と、確認の工程
同じ研修で全部を扱おうとすると、誰にも刺さらない

2番目の層がいちばん多く、いちばん取りこぼされています。一度触って「思ったほどではない」と判断した人たち。ここに効くのは機能の説明ではなく、向いている作業の見分け方です。

最初に教えること

操作方法から入ると、たいてい定着しません。押し方が分かっても、何に使うかが分からないからです。

最初に伝えるべきは、向いている作業と向いていない作業の線引きでしょう。

出てきた答えが正しいかを人がすぐ判断できる仕事は安全です。文章の下書き、要約、言い換え、翻訳。読めば間違いが分かります。

確認するほうが自分でやるより手間のかかる仕事は危ない。数値の突き合わせ、法令の条番号、出典集め。この区別だけ先に伝えておくと、変な使い方で失望する人が減ります。

その人の業務で1つ動かす

一般的な例では動きません。「議事録が作れます」と言われても、自分の議事録が作れるかは分からない。

研修の場で、その人が実際に抱えている作業を1つ持ってきてもらう。それをその場で処理してみせる。うまくいかなければ、なぜうまくいかないかを一緒に見る。

これができれば、その1つは翌日から使われます。10個の機能説明より効果があります。

失敗の型を先に見せる

できることだけを教えると、最初の失敗で離れます。

先に見せておく。書かれていないことを補うこと。出典が存在しないことがあること。数字がわずかにずれること。同じ質問でも答えが変わること。

これらは不具合ではなく仕組みから来る性質だ、と伝えておくと、遭遇したときに「壊れている」ではなく「そういうものだ」と受け止められます。

失望は、期待と実際のずれから生まれます。期待を先に調整しておくのが早い。

教える人を作る

外部の講師を呼ぶより、社内に分かる人を作るほうが長続きするようです。

理由は、質問が業務に紐づいているからです。「この帳票をどう処理させるか」という問いに答えられるのは、その帳票を知っている人だけ。一般論では届きません。

選ぶなら、すでに自分で使い始めている人。指名して育てるより、勝手に触っている人を見つけて役割を与えるほうが早い。

その人が困ったときに聞ける先も用意しておくこと。全部を抱えさせると潰れます。

ルールは短く

研修と同時に配るルールは、1枚に収めます。

入れてよい情報の線引き、使ってよいサービス、出力の確認、迷ったときの相談先。この4つで足ります。

禁止事項を並べたルールは読まれないうえ、書いていない場面が必ず出てきます。許可するものを挙げる形にすると、それ以外は相談に回るので列挙漏れが起きません。

教えたあと

研修の効果は、その日ではなく2週間後に出ます。

「うまくいった例」を集める場所を作っておく。誰かが見つけた使い方が共有されると、他の人も試します。機能の説明より、同僚の実例のほうが人を動かす。

逆に、うまくいかなかった例も集めておく。同じところで詰まる人が減ります。

研修を増やすより、この場を1つ作るほうが定着します。

効果を測る

研修をやった、で終わらせないために、何を見るかを決めておきます。

受講者数や満足度では、次につながりません。見るなら、ある業務にかかる時間が変わったか。手戻りが減ったか。同じ人数で処理できる件数が増えたか。

研修の前に、いまの状態を測っておくのが肝心です。後から比べようとしても、前がどうだったか誰も覚えていません。

利用率を指標にするのは勧めません。ひとりで増やせる数字は、指標として弱いからです。

数字が動かなくても、失敗ではありません。どの業務に効かないかが分かったということです。次はそこを外して試せます。

研修は一度で終わらせず、半年後にもう一度やる。使い方も道具も変わっているので、そのときには別の内容になっているはずです。

出典

仕組みから来る性質については下記の論文、社内ルールの観点は下記の資料に基づきます。

タイトルとURLをコピーしました