Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / Microsoft Copilot 導入を成功させる方法：データの混乱を整理し、ユーザーの信頼を勝ち取る10の実践策（AI吹き替え）

Transcript

Microsoft Copilot 導入を成功させる方法：データの混乱を整理し、ユーザーの信頼を勝ち取る10の実践策（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
あなたのデータを暗闇で増殖する厄介なゴブリンの群れだと想像してみてください
0:03
これではユーザーの信頼を得ることはできません
0:06
その混沌の中にコパイロットを投入しても魔法のような生産性は得られず
0:09
古い契約の要約や上司が2017年のものだと勘違いするような尻滅裂な回答が吐き出されるだけです
0:13
これでは信頼などづけません
0:15
解決策はここにあります
0:16
適切な準備と展開でそれらのゴブリンを手懐ければ
0:18
コパイロットはやっと人々が求めるアシスタントとして機能し始めます
0:21
理論ではなくコパイロットを実用的なものにするためのベスト10のアクションを紹介します
0:24
今週からすぐ実行できる内容です
0:26
宣伝ですが手順を逃がさないためにM365章で無料のチェックリストを入手してください
0:30
本当の悪夢はコパイロット導入2日目ではなく
0:32
誰も触れる前に導入自体が失敗することだからです
0:35
なぜ導入が開始日前に失敗するのでしょうか
0:37
多くのコパイロット導入はユーザーが正当に試す機会を得る前に失速しています
0:41
その原因はマイクロソフトがテナントにバグを忍び込ませたことや
0:44
ライセンス設定のスイッチを切り忘れたことなどではありません
0:46
真の問題は期待値にあります
0:48
人々はコパイロットをスイッチ一つで
0:50
30個もの予算ファイルのバージョンが完璧な回答に統合される魔法のツールだと思ってやってきます
0:54
それは夢の話です
0:55
現実はオリンピック選手にメダルではなくチーズバーガーを与えるようなもので
0:59
敬礼と後悔が待っているだけです
1:00
結局のところ問題はデータに集約されます
1:03
コパイロットは知識を捏造するわけではなく
1:04
与えられたレコードを処理するだけだからです
1:06
テナントがタグ付けされていないファイル
1:08
重複するスプレッドシート
1:09
放置されたシェアポイントフォルダーで溢れていれば
1:11
それはゴミのビュッフェを並べているようなものです
1:13
私が関わったある企業は
1:14
自社の契約ライブラリは整理されていると考えていました
1:17
実際には期限切れの契約や誤ったラベルのファイルがあり
1:19
半分は最終フォルダーに入ったままの古いドラフトでした
1:22
結果はどうなったか?
1:23
コパイロットは2019年のパートナーシップが現在も有効であると
1:26
自信満々に要約を吐き出しました
1:27
ホーム部門は激怒しました
1:28
経営層はパニックになりました
1:30
そしてコパイロットへの信頼は一瞬で急落しました
1:32
このような大失敗の原因はAIではなく入力データにあります
1:35
コパイロットは指示通りに
1:37
ゴミを洗練されたゴミに変えただけなのです
1:39
危険なのはその出力があまりにも説得力を持って見えることです
1:42
ユーザーは流暢な要約を聞いて信頼しますが
1:44
決定的な矛盾を見つけた瞬間に裏切られます
1:46
その時点でそのツールには
1:47
信頼できないというレッテルが貼られます
1:49
一度そのラベルが貼られると剥がすのは困難です
1:51
経験や専門家の意見は全て同じ根本的な問題
1:53
つまり不十分なデータガバナンスが
1:55
AIプロジェクトを始める前に殺してしまうという点を指摘しています
1:57
ライセンス料を払いコンサルタントを雇い
1:59
華やかなキックオフ会議を開くこともできます
2:01
しかしその土台となるシステムが泥沼であれば全て無意味です
2:03
そして確信をつくと
2:04
ユーザーはロードマップのパワーポイントや
2:06
ガバナンスの枠組みなど気にしていないのです
2:07
コパイロットへの最初の問い合わせで間違った回答が返ってくると
2:09
ユーザーはウィンドウを閉じて離れてしまいます
2:11
ユーザーから見れば話は単純です
2:13
新しくて便利なアシスタントができましたと
2:15
何でも聞いてくださいと
2:16
そこで彼らはサプライヤーXとの進行中の契約を見せて
2:19
といった基本的なことを試します
2:20
するとコパイロットは期限切れの取引や欠落した情報
2:22
執行した条件などを混ぜ合わせて返してきます
2:24
考えてみてください
2:25
その後でもう一度使おうと思いますか
2:27
おそらく思わないでしょう
2:28
社内でただの流行り物という噂が広まれば
2:30
導入はそこで止まってしまいます
2:31
ではどうすればいいのでしょうか
2:33
小さく始めることです
2:34
先ほどの散らかった契約書ライブラリの例を考えてみましょう
2:36
もし思い当たる節があるなら
2:38
全社的な整理に乗り出さないでください
2:39
代わりにトリアージを行うのです
2:41
2日で修正できるフォルダを1つ選んでください
2:43
ラベルを統一し日付を最新にし
2:44
ドラフトを削除しましょう
2:45
そしてその小さな範囲にコパイロットを接続して
2:47
同じテストを実行します
2:48
違いは一目瞭然であり
2:49
何よりユーザーの信頼を取り戻すことができます
2:52
害虫駆除のようなものだと考えてください
2:54
不足しているメタデータ
2:55
重複するスプレッドシート
2:56
そして最終版V2のようなファイルは
2:58
地下室で暴れ回るゴブリンと同じです
3:00
上層部が新しいAIの導入を祝っている間にも
3:03
地下室ではゴブリンたちが配線をかじり
3:05
フォルダをめちゃくちゃにしています
3:06
そんな状態でコパイロットを解き放てば
3:08
ゴブリンにメガホンを渡すようなものです
3:10
結論は単純です
3:11
不適切なデータは
3:12
一度の劇的なクラッシュで導入を失敗させるわけではありません
3:22
すぐに誰も使おうとしなくなるのです
3:23
つまり隠れた第一歩はライセンス付与やトレーニングではなく
3:26
ゴブリンを退治することなのです
3:27
少量のレコードを整理してください
3:28
構成を整えるのです
3:30
規模を拡大する前に
3:31
綺麗なデータでツールが機能することを証明してください
3:33
それを怠れば導入は初日から失敗に終わるでしょう
3:35
しかしこの問題にはもう一つ指摘すべき側面があります
3:38
データが準備できていても
3:39
ユーザー自身にその気がない限り
3:41
積極的に使おうとはしません
3:43
そこでより難しい疑問が生じます
3:45
なぜわざわざコパイロットを無視せずに
3:47
使おうとする人がいるのでしょうか
3:48
そして組織はどうやって
3:49
コパイロットを使いたいと思わせたのでしょうか
3:51
一部の組織で状況を一変させた理由はシンプルです
3:54
彼らはコパイロットを単に許容させるのではなく
3:56
人々に使いたいと思わせたのです
3:57
これはITの世界では稀なことです
3:59
通常新しいツールを導入しても
4:01
それは誰も頼んでいない不要なアプリのように
4:03
ツールバーに居座るだけです
4:04
しかしユーザーが即座に価値を感じ
4:06
実際に時間が短縮されると
4:08
彼らはそれを無視しなくなり
4:09
なぜ自分の部署にはまだないのかと
4:11
上司に尋ね始めるのです
4:12
ここが重要な違いです
4:13
我慢して使うツールはデスクトップで誇りをかぶり
4:16
上司に言われた時しか開かれません
4:18
求められるツールは
4:19
廊下の会話で話題に上ります
4:20
ねえこれのおかげで1時間も短縮できたよと
4:22
こうした変化は理論ではなく
4:24
目に見える成果
4:24
つまり人々が実感できる実践的な価値から生まれます
4:27
例えば月次レポートの作成時間を
4:29
8時間から2時間に短縮したり
4:30
進捗報告を自動化して承認を丸1日早めたり
4:33
あるいは経理チームがパソコンを窓から
4:35
投げ出したくなるような
4:36
称号作業のミスを減らしたりすることです
4:38
そうした成果こそが
4:39
好奇心を真の活用意欲に変えていくのです
4:41
多くのIT導入プロジェクトは
4:43
おかみの命令で利用が進むと考えがちです
4:45
ライセンスを割り当て
4:46
広報チームが月曜朝に明るいメールを送り
4:47
誰かが熱意の広まりを期待する
4:49
そんなものは広まりません
4:50
ユーザーは戦略資料など気にしません
4:52
彼らが気にするのは
4:53
30ものスプレッドシートを追いかけ回さずに済んで
4:54
金曜の夜が守られたかどうかです
4:56
そこを見失えば
4:57
コパイロットはチャンスを得る前に無視されて終わります
4:59
その対局にあるのが
5:00
現場の需要に基づいた導入です
5:02
ある金融機関が
5:03
特定の部署でコパイロットの
5:04
小規模な試験導入を行いました
5:06
数人のアナリストは
5:07
エクセルのタブに埋もれる日々から一点
5:09
面倒な作業の半分を
5:10
コパイロットに任せるようになりました
5:11
レポートは宣伝され
5:12
大流案件は減り
5:13
何より素晴らしいことに
5:14
その噂が試験グループの外へと漏れ伝わったのです
5:16
タブ署のスタッフが上司に詰め寄り
5:18
なぜ彼らは使えて
5:19
私たちは使えないのか
5:20
と問い詰め始めました
5:21
すると突然
5:21
無理やり導入を推進する必要はなくなり
5:23
殺到する要望を整理する側に回ることになりました
5:25
もしそのプレイブックを知りたいなら
5:26
彼らがどうやったかを教えしましょう
5:28
アナリスト6名
5:28
3週間の試験運用
5:29
実際の業務での活用
5:30
そして日々のフィードバックループです
5:32
絞り込まれた範囲
5:33
迅速な反復
5:34
目に見える成果
5:35
これがカフェテリア効果です
5:37
冷めた正体不明の料理には誰も興味を示しませんが
5:39
タコスバーが登場すれば行列ができます
5:41
価値が証明されているからこそ定着するのであり
5:44
企業からのメール通知が理由ではありません
5:46
あなた自身のタコスバーを始めるための試験運用チェックリストが必要ですか
5:48
M365章で手に入れてください
5:50
賢いチームが頼りにしたのは以下のポイントです
5:52
第一にIT担当者ではなく現場の推進役
5:54
チャンピオン
5:55
お使い
5:55
今朝これのおかげで1時間助かった
5:56
という生の声を示したこと
5:57
第二に他人の目に見える成果を選んだこと
5:59
レポートの早期提出
6:00
承認の迅速化
6:02
準備時間の半減などです
6:03
第三にその証拠が自然と広まるようにしたこと
6:05
チームのチャットや打ち合わせでの口コミは
6:07
どんなに立派な告知よりも強力に響きます
6:10
大切なのはマーケティングではなく
6:11
仲間による実証で信頼を築くことです
6:13
人々がコパイロットを求めるようになったのは
6:15
単なる新しいログイン画面ではなく
6:17
退屈なデータ作業から自分たちを救ってくれる存在だと気づいたからです
6:20
こうした成果を可視化した組織は
6:21
導入に対する姿勢そのものを完全に変えてしまったのです
6:23
IT部門が導入を促すのではなく
6:25
ユーザーが酸素を求めるように
6:27
日常業務へコパイロットを取り入れていました
6:28
これこそが本質的な導入であり
6:30
無理に作り出す必要のない勢いなのです
6:32
もちろん成果を示すことと
6:33
売り込みのように感じさせない展開の仕方を構成することは別物です
6:36
そこで重要になるのが適切なフレームワークです
6:39
売り込みのように聞こえないフレームワークのことです
6:42
変更管理のスライドを見ていて
6:43
まるでMBAのグループ課題だなと思ったことはありませんか
6:46
私も同じです
6:47
AIの導入はシンプルであるべきです
6:50
ツールができることを見せ
6:51
試す準備をさせ
6:52
行き詰まったらサポートするのです
6:54
それなのに実際は
6:55
無数の矢印や同心円が並び
6:56
マイクロソフトの製品名変更集並みに
6:58
流行り言葉が詰まった資料ばかりです
6:59
そんな騒音は副社長を感心させるかもしれませんが
7:02
実際にスプレッドシートと格闘する人々の助けにはなりません
7:04
本当に役立つのは
7:05
不要なものをそぎ落とし
7:06
現実の課題に焦点を当て
7:07
従業員が飽きない短さで構築されたフレームワークです
7:09
ADKARは
7:10
実践へと無理なく移行できる数少ない手法の一つでした
7:12
理論上は
7:13
認知、意欲、知識、能力、定着の5段階です
7:16
コパイロットの世界では
7:17
それは次のような意味を持ちます
7:19
認知とは
7:20
将来の生産性についての華やかな動画ではなく
7:22
その人の役割に対して
7:23
コパイロットで何ができるかを具体的に示すデモのことです
7:26
意欲とは
7:27
嫌な作業が半分で済む様子を見せるなど
7:29
即座にメリットを感じさせることです
7:31
知識とは
7:31
膨大な資料で疲れさせるのではなく
7:33
マイクロラーニングであるべきです
7:34
5分で読めるチェックリストやチートシート
7:36
ツールチップを提供しましょう
7:37
能力とは
7:38
サンドボックス環境で
7:39
架空のデータや重要でない作業を使って練習させることです
7:42
誤ったクリックでプロジェクトが台無しになる不安を取り除きます
7:45
定着とは
7:45
また別の社内メールを出すことではなく
7:47
テンプレートやショートカット
7:48
あるいは誰かが成功した時に上司が賞賛することです
7:50
頭文字という鎧を脱ぎ捨てれば
7:52
ADKARは決して理論だけのものではありません
7:54
それは
7:54
それが何か
7:55
なぜ日常が改善されるか
7:57
使い方を教え
7:58
恐れずに練習させ
7:59
使い続けることを褒める
8:00
というロードマップなのです
8:01
ここでのチェックポイントは単純です
8:03
展開する前に
8:04
コパイロットによって結果が確実に向上する
8:06
具体的なタスクを少なくとも2つ挙げられるようにしてください
8:08
数字は10%でも20%でも構いません
8:10
自分で設定してください
8:11
パイロット運用でそれを証明できなければ
8:13
フレームワークは単なるスローガンに終わってしまいます
8:15
ある中堅企業が営業部門にコパイロットを導入した際
8:17
これがうまく機能するのを目の当たりにしました
8:18
月曜日に
8:19
頑張ってください
8:20
というメールとともに丸投げしたりはしませんでした
8:21
その代わりに
8:22
要点を絞ったデモを行いパイプライン報告という
8:24
一つの実務に焦点を当て
8:25
サンドボックス環境を用意したのです
8:26
アナリストは
8:27
何も壊れる心配のないサンプルアカウントでテストを行いました
8:29
私はそれらのレポート作成にかかっていた時間を追跡し
8:32
どれだけ短縮されたかを測定しました
8:33
リーダー層は
8:34
テンプレートを活用して正しい利用法を定着させることで
8:36
その習慣を強化しました
8:37
本格導入の時期には
8:38
誰もそのツールを恐れていませんでした
8:39
すでに彼らのワークフローの一部になっていたからです
8:41
コッターの短期的な勝利
8:42
ショートウィンズ
8:43
アプローチは現場でも効果を発揮しました
8:44
これは
8:45
誰も価値を実感できないまま忍耐が尽きてしまうような
8:47
年単位の変革に対する特効薬です
8:49
このモデルは
8:50
どんな華やかなキャンペーンよりも早く広がる
8:52
初期の目に見える成果に欠けています
8:53
コパイロットで言えば
8:54
1週間で成果を出すことだと考えてください
8:56
チームが終時レポートを4時間から1時間に短縮したり
8:59
プロジェクトリーダーが
9:00
コパイロットの要約機能で終わりのない
9:01
状況報告メールを廃止したりすることです
9:03
こうした迅速な成果は
9:04
単なる見せかけではありません
9:06
それらは口コミで広がります
9:07
そして会議的だった人々が
9:08
同僚が取り戻した時間について自慢するのを聞くと
9:10
抵抗感は和らぎます
9:11
人々は発表に対して呆れるのをやめ
9:13
自分たちでその話をするようになります
9:14
ここでのコツは
9:15
適切なブランドモデルを選ぶことではありません
9:17
シンプルなフレームワークを選び
9:18
日々の摩擦に対抗する武器にすることです
9:20
それはつまり短いサイクル
9:21
目に見えるインパクト
9:22
そして過度な作り込みをしないということです
9:23
フェーズの壁を押し付けたり
9:24
ユーザーがどの段階にいるかを気にしているフリをしたりしてはいけません
9:27
彼らはそんなことは気にしていません
9:28
彼らの仕事の苦労が少しでも減る部分を見せ
9:30
それを自然に感じられる構造で支えるのです
9:32
その時こそフレームワークは単なる
9:33
壁紙ではなくテコになります
9:35
時間が経つにつれ私たちはその違いに気づきました
9:37
導入の様子は役員がパワーポイントのメモを読み上げるのではなく
9:40
同僚同士が成功体験を共有し合うものへと変わっていきました
9:42
それこそが目標です
9:43
流行語やラミネート加工された図表ではなく
9:45
ユーザーの悩みの現実に即して調整されたフレームワークが必要です
9:48
モデルはシンプルかつ人間味のあるものに保つ
9:50
そうすれば強制されたものではなく自然な勢いが生まれます
9:53
もちろん全てはトレーニングが機能してこそ意味があります
9:56
紙の上のフレームワークは研修の場で人々が関心を失った瞬間に死に絶えます
9:59
信じてください
10:00
1日中続くコパイロットのトレーニングセッションにユーザーが閉じ込められたらどうなるか
10:03
私たちはみんな知っています
10:04
午前中の半ばには参加者の半分はすでに受信トレーに埋もれて
10:07
時間が過ぎるのを待っている状態です
10:08
呆れられないトレーニングとは
10:10
トレーニングは多くの導入プロセスで気まずい瞬間となります
10:12
それが重要であることは誰もが知っていますが
10:14
やり方を間違えるとユーザーがコパイロットを実際に試すか
10:16
静かに無視するかを決める分かれ道になってしまいます
10:18
このセクションではトレーニングを効果的な要素だけに絞り込み
10:21
人々を疲れさせることなく
10:22
十分な実践的証拠を提供する方法について説明します
10:24
まずは大きな罠である歴レースのデモから始めましょう
10:27
コパイロットが完璧なレポートを自動作成したり
10:29
何もないところから契約書を取り出したりする
10:31
あの完璧な例のことです
10:32
見栄えは良いですが
10:33
現実世界のユーザーは磨き上げられたデモの世界には住んでいないため
10:35
信頼をすぐに失墜させます
10:36
彼らは予算2020最終版v13といったファイルや
10:39
リリーfwd緊急のお願いといった懸命のメールの山に囲まれて生きています
10:42
作り込まれたデモは非現実的な期待を抱かせるだけです
10:45
代わりに彼らの実際の業務データを使ってトレーニングしましょう
10:47
実践例として散らかったスプレッドシートを一つ持ち込み
10:50
コパイロットに問題を要約させてみてください
10:52
一貫して有益な要約が出るまで繰り返します
10:54
これこそがユーザーが信頼できるトレーニングです
10:57
さらに重要なのはトレーニングに未データを使うと
10:59
たとえコパイロットが失敗しても人々が前のめりになるという点です
11:01
私が支援したある企業では見栄えの良いサンプル資料を捨て
11:05
実際の営業パイプラインのメールやバックログの表計算ファイルを使いました
11:08
従業員はコパイロットが苦戦し
11:09
適応し彼らが嫌っていた面倒な作業のステップを少しずつ削減していく様子を目の当たりにしました
11:13
魔法ではありませんでしたが誠実な体験でした
11:15
すると会議室から退屈や冷めた空気は消え去りました
11:17
みんなが興味津々になったのです
11:19
その変化はこんなこともできるという華やかなデモを見せるよりもずっと価値があります
11:23
伝え方も重要です
11:24
大げさな売り文句で始めたトレーナーは
11:26
コパイロットが気まずい回答をした瞬間に信頼を失いました
11:28
解決策は非常にシンプルです
11:30
どのセッションの冒頭でもこのフレーズを使ってください
11:39
いかに役立てるかを探り始めます
11:41
うまくいかない結果は失敗ではなく学習曲線の一部となります
11:44
その考え方が不完全なドラフトを拒絶ではなく学びの機会へと変えるのです
11:48
定着させたいなら研修を1回限りのワークショップではなく
11:51
日々の業務を有利に進めるための裏技を教える場だと考えてください
11:54
長時間の会議室での研修は熱意を冷ましてしまいます
11:57
短く頻繁なセッションこそが熱意を生み出します
11:59
具体的なコツをいくつか伝えるのが最も効果的です
12:01
トレーニングには本物のファイルを使ってください
12:03
最初に期待値をコントロールしましょう
12:04
丸1日の苦行のような研修ではなく15から30分のマイクロセッションを行いましょう
12:08
ノイズの多い不完全なデータを備えたサンドボックス環境を作り恐れずに試せるようにします
12:12
コパイロットのファクトチェック用チートシートを配布しましょう
12:15
そうすれば研修の目的はコパイロットを魔法使いに仕立てることではなく
12:18
上司の前で恥をかかずに優秀な相棒として使う方法を示すことになります
12:22
チェックリスト形式にすれば研修室を出た後もポイントを忘れません
12:25
3時間のスライドデッキを後で見返す人はいませんが
12:28
1枚のチートシートならモニターの上に貼っておくはずです
12:30
こうした変化から生まれるのは意識の転換です
12:33
長いデモを見せられる代わりにユーザーは自分たちの痛みを解消できるタスクを自ら試し始めます
12:38
メールのドラフト作成時間を半分にする
12:40
プロジェクトの進捗を要約するあるいは山のような表から答えを見つけ出すといったことです
12:43
一つ一つの小さな成功がコパイロットはマイクロソフトの広告の中だけでなく
12:47
自分たちの業務に必要なものだという証拠になります
12:55
このパターンこそが導入曲線を押し上げる要因であることが経験からわかっています
12:59
誠実な例と短いサイクルでトレーニングを行うチームはこれは本当に役立つと言って現場に戻ります
13:03
一方マーケティング的な演出に終始するチームは不満を抱えて戻ることになります
13:06
単純なことです
13:07
好奇心旺盛なユーザーは探求心を持つユーザーになります
13:10
探求するユーザーは日常的に使うユーザーとなり
13:12
彼らが作る物語はどんな社内広報よりも早く広がります
13:15
独自のトレーニングを実施するためのワークシートが必要ですか
13:18
M365章のTLDRニュースレターに登録するか
13:20
M365章のページをフォローしてMVPが深掘りするライブ配信をご覧ください
13:24
これによりプロジェクトごとに何をすべきか推測したり
13:26
車輪の再発明をしたりする必要がなくなります
13:28
つまり冷ややかな目で見られることなく
13:30
2ファイルと現実的な設定を用い価値を早期に示す小規模なセッションを繰り返すトレーニングです
13:33
それをうまくやればコパイロットは単なるITの宣伝ではなく
13:36
チームの一員のように感じられるようになります
13:38
トレーニングを適切に構成すればユーザーに自信を持たせることができます
13:41
しかしそれを無視すれば導入の物語は一変します
13:44
土台を準備せずにスイッチを入れることほど計画を脱線させるものはありません
13:48
難しい部分を飛ばすとどうなるでしょうか
13:50
ここから事態が悪化します
13:52
企業が難しい作業を省きクリーンアップも準備もロードマップもなしに
13:56
金曜の無料ドーナツのように全テナントでライセンスを有効化してしまう場合です
14:00
誰かがチームで祝福のメッセージを投稿する頃には
14:02
ユーザーはすでに第4四半期の財務を要約してから休暇規定を教えてまで
14:06
あらゆる質問をコパイロットに浴びせています
14:08
帰ってくる答えは何でしょうか
14:09
ゴミです
14:10
古いゴミ
14:11
誤解を招くゴミです
14:12
突然コパイロットは役立つアシスタントではなく
14:14
IT部門が冗談で仕込んだいたずらボットのように見えてきます
14:17
なぜこうなるのでしょうか
14:19
退屈な基礎固めが全てスキップされたからです
14:21
古いドキュメントライブラリの選別も明らかなエラーを見つけるためのテストも
14:25
コパイロットの草案には事実確認が必要だと伝えるマイクロトレーニングもありません
14:28
その代わりシェアポイントホルダーが2007年の社内タイムマシンのように機能し
14:32
古いエクセルファイルが真実のように浮上し
14:34
コパイロットがそれを新鮮な洞察として喜んで提供してしまいます
14:37
ユーザーの立場からすればタキシードを着てゴミを漁っているような気分です
14:41
IT部門の立場からすればヘルプデスクへの集中攻撃が始まるような気分です
14:44
経営陣が役員向けに直接導入すると主張したことで
14:47
導入が完全に失敗したケースを一つ見ました
14:49
CFOが最初に投げた質問は
14:51
第4四半期の財務を要約して
14:53
最新の数字ではなく
14:54
コパイロットは3年前の合併前のアーカイブから
14:57
2017年以降存在しない企業構造のデータを拾い上げてきました
15:00
それは権威あるように見えましたが完全に間違いであり
15:02
会議の場でそのまま露呈しました
15:03
その状況を説明してみてください
15:05
そうやって信頼は急速に失われていくのです
15:07
重要な質問で一度でも誤った回答をすれば
15:09
たちまち導入全体が見かけ倒しというレッテルを貼られてしまいます
15:12
採用は停滞し
15:12
チームチャットは成果の報告ではなくミームであふれ
15:15
IT部門には苦情の電話が殺到します
15:16
そんな状況に陥った時
15:18
言い訳をせずに経営層へ提出できる緩和策のスクリプトがこちらです
15:21
信頼性の低い回答の原因となっていたデータソースを修正するため
15:23
展開を一時停止しました
15:25
検証可能な成果とともに段階的に再開する予定です
15:27
こういえばIT部門の失敗という物語が
15:29
IT部門が制御を掌握したという話に変わります
15:31
ITのリカバリーは泥臭いものですが十分に可能です
15:33
結局のところそれはシンプルで無骨な4ステップのプレイブックに集約されます
15:36
広範囲な展開を一時停止し
15:37
明らかに古いソースをトリアージしてアーカイブし
15:39
期待値を明確にして小規模なパイロット版で再開し
15:41
透明性を持ってコミュニケーションを取り
15:43
ユーザーのフィードバックを収集する
15:44
この4行があるかないかで
15:46
事態を静かに収束させられるか
15:47
コパイロットの評判に消えない傷を残すかが決まります
15:50
そのプレイブックの中で
15:51
IT部門はいくつかの中心的なクリーンアップを行いました
15:53
重要なデータストアを整理し
15:55
有効なものとアーカイブを分類し
15:56
コパイロットの対象を統制されたグループに限定し
15:58
サンドボックス形式で再始動するのです
16:00
目標は完璧さではなく封じ込めです
16:02
誇りをかぶったアーカイブをすなどらせて
16:04
それをさも真実であるかのように出力させてはなりません
16:06
信頼を築けるよう
16:07
整理された環境の中で機能させる必要があります
16:09
コミュニケーションの転換も同じくらい重要です
16:12
賢いチームは過度な古代広告を行いません
16:14
彼らは最初から明確に期待値を設定します
16:15
コパイロットは草案を作成します
16:17
裏付けを取るのはあなたです
16:19
古い情報の見分け方はこちら
16:20
誤った出力があった場合の報告先はこちら
16:22
という誠実さは幹部のどんな応援よりも響きます
16:24
なぜならユーザーにシンプルな行動指針を与えたからです
16:27
誰も草案生成AIに完璧さは求めませんが
16:30
予測可能性は求めます
16:31
その予測可能性こそが信頼を再構築するのです
16:34
パイロットサイクルで小さくても目に見える成果が出れば
16:37
プロジェクトリーダーが状況報告の時間を半分に短縮したり
16:45
広報イベントではなく廊下での雑談やチームのスレッドを通じて
16:49
CIOのスローガンではなくこれのおかげで
16:51
嫌だった作業が何時間も短縮できたという同僚の声が採用を加速させるのです
16:54
それは演出された成功ストーリーよりも遥かに強力です
16:58
教訓はこうです
16:59
初日に大変な作業を飛ばせば派手なローンチと引き換えにすぐさまどん底に落ちます
17:03
クリーンアップを行い再起動すれば出足は遅くとも確かな信頼を勝ち取れます
17:07
そして信頼こそがコパイロットを企業のおもちゃ箱から
17:10
日々のワークフローへと昇格させる唯一の要素なのです
17:12
結局のところ成功するかどうかを決めるのはAIではなく
17:15
現場の人間がそれを使い続けられるほど信頼しているかどうかなのですから
17:18
その一つの要因こそが成功の真の指標です
17:21
まとめは以上です
17:22
コパイロットの導入が失敗するか定着するかの違いは魔法ではなく実行力にあります
17:27
マーケティングの喧騒は忘れ実際に効果のある銃のアクションを覚えておきましょう
17:31
ソースの範囲を絞り最も汚れたホルダから整理し
17:33
試験運用を行い推進者を選び目に見える成果を示し
17:37
未データでトレーニングし適切な期待値を設定し
17:39
安全なサンドボックスを作り結果を測定共有し
17:42
ロールバック計画を立てることです
17:43
これらを行えば導入は混乱ではなく意図的なものとなります
17:47
M365章のニュースレターに登録し
17:49
MVPによるより深い解説が見られるM365章のリンクトインをフォローしてください
17:53
全てのデータゴブリンを駆除することはできませんが
17:55
最悪なものを封じ込め登録ボタンをワンクリックするだけで
17:57
コパイロットに真の仕事を行わせることは可能です