WEBVTT

00:00:00.000 --> 00:00:03.780
あなたのデータを暗闇で増殖する厄介なゴブリンの群れだと想像してみてください

00:00:03.780 --> 00:00:06.160
これではユーザーの信頼を得ることはできません

00:00:06.160 --> 00:00:09.120
その混沌の中にコパイロットを投入しても魔法のような生産性は得られず

00:00:09.120 --> 00:00:13.700
古い契約の要約や上司が2017年のものだと勘違いするような尻滅裂な回答が吐き出されるだけです

00:00:13.700 --> 00:00:15.240
これでは信頼などづけません

00:00:15.240 --> 00:00:16.700
解決策はここにあります

00:00:16.700 --> 00:00:18.940
適切な準備と展開でそれらのゴブリンを手懐ければ

00:00:18.940 --> 00:00:21.460
コパイロットはやっと人々が求めるアシスタントとして機能し始めます

00:00:21.460 --> 00:00:24.580
理論ではなくコパイロットを実用的なものにするためのベスト10のアクションを紹介します

00:00:24.580 --> 00:00:26.540
今週からすぐ実行できる内容です

00:00:26.540 --> 00:00:30.380
宣伝ですが手順を逃がさないためにM365章で無料のチェックリストを入手してください

00:00:30.380 --> 00:00:32.680
本当の悪夢はコパイロット導入2日目ではなく

00:00:32.680 --> 00:00:35.340
誰も触れる前に導入自体が失敗することだからです

00:00:35.340 --> 00:00:37.800
なぜ導入が開始日前に失敗するのでしょうか

00:00:37.800 --> 00:00:41.620
多くのコパイロット導入はユーザーが正当に試す機会を得る前に失速しています

00:00:41.620 --> 00:00:44.240
その原因はマイクロソフトがテナントにバグを忍び込ませたことや

00:00:44.240 --> 00:00:46.460
ライセンス設定のスイッチを切り忘れたことなどではありません

00:00:46.460 --> 00:00:48.420
真の問題は期待値にあります

00:00:48.420 --> 00:00:50.120
人々はコパイロットをスイッチ一つで

00:00:50.120 --> 00:00:54.020
30個もの予算ファイルのバージョンが完璧な回答に統合される魔法のツールだと思ってやってきます

00:00:54.020 --> 00:00:55.480
それは夢の話です

00:00:55.480 --> 00:00:59.060
現実はオリンピック選手にメダルではなくチーズバーガーを与えるようなもので

00:00:59.060 --> 00:01:00.760
敬礼と後悔が待っているだけです

00:01:00.760 --> 00:01:03.120
結局のところ問題はデータに集約されます

00:01:03.120 --> 00:01:04.960
コパイロットは知識を捏造するわけではなく

00:01:04.960 --> 00:01:06.780
与えられたレコードを処理するだけだからです

00:01:06.780 --> 00:01:08.260
テナントがタグ付けされていないファイル

00:01:08.260 --> 00:01:09.500
重複するスプレッドシート

00:01:09.500 --> 00:01:11.540
放置されたシェアポイントフォルダーで溢れていれば

00:01:11.540 --> 00:01:13.500
それはゴミのビュッフェを並べているようなものです

00:01:13.500 --> 00:01:14.820
私が関わったある企業は

00:01:14.820 --> 00:01:17.180
自社の契約ライブラリは整理されていると考えていました

00:01:17.180 --> 00:01:19.700
実際には期限切れの契約や誤ったラベルのファイルがあり

00:01:19.700 --> 00:01:22.220
半分は最終フォルダーに入ったままの古いドラフトでした

00:01:22.220 --> 00:01:23.360
結果はどうなったか?

00:01:23.480 --> 00:01:26.040
コパイロットは2019年のパートナーシップが現在も有効であると

00:01:26.040 --> 00:01:27.160
自信満々に要約を吐き出しました

00:01:27.160 --> 00:01:28.540
ホーム部門は激怒しました

00:01:28.540 --> 00:01:30.120
経営層はパニックになりました

00:01:30.120 --> 00:01:32.520
そしてコパイロットへの信頼は一瞬で急落しました

00:01:32.520 --> 00:01:35.640
このような大失敗の原因はAIではなく入力データにあります

00:01:35.640 --> 00:01:37.040
コパイロットは指示通りに

00:01:37.040 --> 00:01:39.220
ゴミを洗練されたゴミに変えただけなのです

00:01:39.220 --> 00:01:42.260
危険なのはその出力があまりにも説得力を持って見えることです

00:01:42.260 --> 00:01:44.280
ユーザーは流暢な要約を聞いて信頼しますが

00:01:44.280 --> 00:01:46.260
決定的な矛盾を見つけた瞬間に裏切られます

00:01:46.260 --> 00:01:47.600
その時点でそのツールには

00:01:47.600 --> 00:01:49.320
信頼できないというレッテルが貼られます

00:01:49.320 --> 00:01:51.840
一度そのラベルが貼られると剥がすのは困難です

00:01:51.840 --> 00:01:53.920
経験や専門家の意見は全て同じ根本的な問題

00:01:53.920 --> 00:01:55.380
つまり不十分なデータガバナンスが

00:01:55.380 --> 00:01:57.600
AIプロジェクトを始める前に殺してしまうという点を指摘しています

00:01:57.600 --> 00:01:59.540
ライセンス料を払いコンサルタントを雇い

00:01:59.540 --> 00:02:01.060
華やかなキックオフ会議を開くこともできます

00:02:01.060 --> 00:02:03.760
しかしその土台となるシステムが泥沼であれば全て無意味です

00:02:03.760 --> 00:02:04.760
そして確信をつくと

00:02:04.760 --> 00:02:06.220
ユーザーはロードマップのパワーポイントや

00:02:06.220 --> 00:02:07.640
ガバナンスの枠組みなど気にしていないのです

00:02:07.640 --> 00:02:09.960
コパイロットへの最初の問い合わせで間違った回答が返ってくると

00:02:09.960 --> 00:02:11.540
ユーザーはウィンドウを閉じて離れてしまいます

00:02:11.540 --> 00:02:13.500
ユーザーから見れば話は単純です

00:02:13.500 --> 00:02:15.440
新しくて便利なアシスタントができましたと

00:02:15.440 --> 00:02:16.740
何でも聞いてくださいと

00:02:16.740 --> 00:02:19.160
そこで彼らはサプライヤーXとの進行中の契約を見せて

00:02:19.160 --> 00:02:20.420
といった基本的なことを試します

00:02:20.420 --> 00:02:22.720
するとコパイロットは期限切れの取引や欠落した情報

00:02:22.720 --> 00:02:24.440
執行した条件などを混ぜ合わせて返してきます

00:02:24.440 --> 00:02:25.480
考えてみてください

00:02:25.480 --> 00:02:27.480
その後でもう一度使おうと思いますか

00:02:27.480 --> 00:02:28.700
おそらく思わないでしょう

00:02:28.700 --> 00:02:30.760
社内でただの流行り物という噂が広まれば

00:02:30.760 --> 00:02:31.860
導入はそこで止まってしまいます

00:02:31.860 --> 00:02:33.360
ではどうすればいいのでしょうか

00:02:33.360 --> 00:02:34.580
小さく始めることです

00:02:34.580 --> 00:02:36.900
先ほどの散らかった契約書ライブラリの例を考えてみましょう

00:02:36.900 --> 00:02:38.040
もし思い当たる節があるなら

00:02:38.040 --> 00:02:39.400
全社的な整理に乗り出さないでください

00:02:39.400 --> 00:02:41.060
代わりにトリアージを行うのです

00:02:41.060 --> 00:02:43.060
2日で修正できるフォルダを1つ選んでください

00:02:43.060 --> 00:02:44.840
ラベルを統一し日付を最新にし

00:02:44.840 --> 00:02:45.800
ドラフトを削除しましょう

00:02:45.800 --> 00:02:47.820
そしてその小さな範囲にコパイロットを接続して

00:02:47.820 --> 00:02:48.820
同じテストを実行します

00:02:48.820 --> 00:02:49.980
違いは一目瞭然であり

00:02:49.980 --> 00:02:52.020
何よりユーザーの信頼を取り戻すことができます

00:02:52.020 --> 00:02:54.000
害虫駆除のようなものだと考えてください

00:02:54.000 --> 00:02:55.140
不足しているメタデータ

00:02:55.140 --> 00:02:56.400
重複するスプレッドシート

00:02:56.400 --> 00:02:58.900
そして最終版V2のようなファイルは

00:02:58.900 --> 00:03:00.680
地下室で暴れ回るゴブリンと同じです

00:03:00.680 --> 00:03:03.480
上層部が新しいAIの導入を祝っている間にも

00:03:03.480 --> 00:03:05.520
地下室ではゴブリンたちが配線をかじり

00:03:05.520 --> 00:03:06.860
フォルダをめちゃくちゃにしています

00:03:06.860 --> 00:03:08.600
そんな状態でコパイロットを解き放てば

00:03:08.600 --> 00:03:10.280
ゴブリンにメガホンを渡すようなものです

00:03:10.280 --> 00:03:11.540
結論は単純です

00:03:11.540 --> 00:03:12.400
不適切なデータは

00:03:12.400 --> 00:03:14.820
一度の劇的なクラッシュで導入を失敗させるわけではありません

00:03:22.020 --> 00:03:23.700
すぐに誰も使おうとしなくなるのです

00:03:23.700 --> 00:03:26.000
つまり隠れた第一歩はライセンス付与やトレーニングではなく

00:03:26.000 --> 00:03:27.220
ゴブリンを退治することなのです

00:03:27.220 --> 00:03:28.860
少量のレコードを整理してください

00:03:28.860 --> 00:03:30.220
構成を整えるのです

00:03:30.220 --> 00:03:31.140
規模を拡大する前に

00:03:31.140 --> 00:03:33.040
綺麗なデータでツールが機能することを証明してください

00:03:33.040 --> 00:03:35.580
それを怠れば導入は初日から失敗に終わるでしょう

00:03:35.580 --> 00:03:38.660
しかしこの問題にはもう一つ指摘すべき側面があります

00:03:38.660 --> 00:03:39.920
データが準備できていても

00:03:39.920 --> 00:03:41.720
ユーザー自身にその気がない限り

00:03:41.720 --> 00:03:43.040
積極的に使おうとはしません

00:03:43.040 --> 00:03:45.120
そこでより難しい疑問が生じます

00:03:45.120 --> 00:03:47.120
なぜわざわざコパイロットを無視せずに

00:03:47.120 --> 00:03:48.480
使おうとする人がいるのでしょうか

00:03:48.480 --> 00:03:49.820
そして組織はどうやって

00:03:49.820 --> 00:03:51.680
コパイロットを使いたいと思わせたのでしょうか

00:03:51.680 --> 00:03:54.180
一部の組織で状況を一変させた理由はシンプルです

00:03:54.180 --> 00:03:56.020
彼らはコパイロットを単に許容させるのではなく

00:03:56.020 --> 00:03:57.760
人々に使いたいと思わせたのです

00:03:57.760 --> 00:03:59.760
これはITの世界では稀なことです

00:03:59.760 --> 00:04:01.760
通常新しいツールを導入しても

00:04:01.760 --> 00:04:03.780
それは誰も頼んでいない不要なアプリのように

00:04:03.780 --> 00:04:04.980
ツールバーに居座るだけです

00:04:04.980 --> 00:04:06.840
しかしユーザーが即座に価値を感じ

00:04:06.840 --> 00:04:08.460
実際に時間が短縮されると

00:04:08.460 --> 00:04:09.600
彼らはそれを無視しなくなり

00:04:09.600 --> 00:04:11.160
なぜ自分の部署にはまだないのかと

00:04:11.160 --> 00:04:12.240
上司に尋ね始めるのです

00:04:12.240 --> 00:04:13.880
ここが重要な違いです

00:04:13.880 --> 00:04:16.540
我慢して使うツールはデスクトップで誇りをかぶり

00:04:16.540 --> 00:04:18.320
上司に言われた時しか開かれません

00:04:18.320 --> 00:04:19.340
求められるツールは

00:04:19.340 --> 00:04:20.780
廊下の会話で話題に上ります

00:04:20.780 --> 00:04:22.940
ねえこれのおかげで1時間も短縮できたよと

00:04:22.940 --> 00:04:24.080
こうした変化は理論ではなく

00:04:24.080 --> 00:04:24.900
目に見える成果

00:04:24.900 --> 00:04:27.100
つまり人々が実感できる実践的な価値から生まれます

00:04:27.100 --> 00:04:29.280
例えば月次レポートの作成時間を

00:04:29.280 --> 00:04:30.880
8時間から2時間に短縮したり

00:04:30.880 --> 00:04:33.860
進捗報告を自動化して承認を丸1日早めたり

00:04:33.860 --> 00:04:35.740
あるいは経理チームがパソコンを窓から

00:04:35.740 --> 00:04:36.640
投げ出したくなるような

00:04:36.640 --> 00:04:38.520
称号作業のミスを減らしたりすることです

00:04:38.520 --> 00:04:39.620
そうした成果こそが

00:04:39.620 --> 00:04:41.920
好奇心を真の活用意欲に変えていくのです

00:04:41.920 --> 00:04:43.300
多くのIT導入プロジェクトは

00:04:43.300 --> 00:04:45.140
おかみの命令で利用が進むと考えがちです

00:04:45.140 --> 00:04:46.000
ライセンスを割り当て

00:04:46.000 --> 00:04:47.860
広報チームが月曜朝に明るいメールを送り

00:04:47.860 --> 00:04:49.240
誰かが熱意の広まりを期待する

00:04:49.240 --> 00:04:50.520
そんなものは広まりません

00:04:50.520 --> 00:04:52.300
ユーザーは戦略資料など気にしません

00:04:52.300 --> 00:04:53.060
彼らが気にするのは

00:04:53.060 --> 00:04:54.940
30ものスプレッドシートを追いかけ回さずに済んで

00:04:54.940 --> 00:04:56.220
金曜の夜が守られたかどうかです

00:04:56.220 --> 00:04:57.080
そこを見失えば

00:04:57.080 --> 00:04:59.200
コパイロットはチャンスを得る前に無視されて終わります

00:04:59.200 --> 00:05:00.420
その対局にあるのが

00:05:00.420 --> 00:05:02.280
現場の需要に基づいた導入です

00:05:02.280 --> 00:05:03.340
ある金融機関が

00:05:03.340 --> 00:05:04.780
特定の部署でコパイロットの

00:05:04.780 --> 00:05:06.340
小規模な試験導入を行いました

00:05:06.340 --> 00:05:07.440
数人のアナリストは

00:05:07.440 --> 00:05:09.140
エクセルのタブに埋もれる日々から一点

00:05:09.140 --> 00:05:10.400
面倒な作業の半分を

00:05:10.400 --> 00:05:11.700
コパイロットに任せるようになりました

00:05:11.700 --> 00:05:12.700
レポートは宣伝され

00:05:12.700 --> 00:05:13.640
大流案件は減り

00:05:13.640 --> 00:05:14.660
何より素晴らしいことに

00:05:14.660 --> 00:05:16.660
その噂が試験グループの外へと漏れ伝わったのです

00:05:16.660 --> 00:05:18.060
タブ署のスタッフが上司に詰め寄り

00:05:18.060 --> 00:05:19.000
なぜ彼らは使えて

00:05:19.000 --> 00:05:20.180
私たちは使えないのか

00:05:20.180 --> 00:05:21.300
と問い詰め始めました

00:05:21.300 --> 00:05:21.920
すると突然

00:05:21.920 --> 00:05:23.660
無理やり導入を推進する必要はなくなり

00:05:23.660 --> 00:05:25.380
殺到する要望を整理する側に回ることになりました

00:05:25.380 --> 00:05:26.740
もしそのプレイブックを知りたいなら

00:05:26.740 --> 00:05:28.020
彼らがどうやったかを教えしましょう

00:05:28.020 --> 00:05:28.700
アナリスト6名

00:05:28.700 --> 00:05:29.800
3週間の試験運用

00:05:29.800 --> 00:05:30.860
実際の業務での活用

00:05:30.860 --> 00:05:32.120
そして日々のフィードバックループです

00:05:32.120 --> 00:05:33.080
絞り込まれた範囲

00:05:33.080 --> 00:05:34.080
迅速な反復

00:05:34.080 --> 00:05:35.060
目に見える成果

00:05:35.060 --> 00:05:37.060
これがカフェテリア効果です

00:05:37.060 --> 00:05:39.780
冷めた正体不明の料理には誰も興味を示しませんが

00:05:39.780 --> 00:05:41.780
タコスバーが登場すれば行列ができます

00:05:41.780 --> 00:05:44.040
価値が証明されているからこそ定着するのであり

00:05:44.040 --> 00:05:46.120
企業からのメール通知が理由ではありません

00:05:46.120 --> 00:05:48.840
あなた自身のタコスバーを始めるための試験運用チェックリストが必要ですか

00:05:48.840 --> 00:05:50.520
M365章で手に入れてください

00:05:50.520 --> 00:05:52.560
賢いチームが頼りにしたのは以下のポイントです

00:05:52.560 --> 00:05:54.540
第一にIT担当者ではなく現場の推進役

00:05:54.540 --> 00:05:55.160
チャンピオン

00:05:55.160 --> 00:05:55.540
お使い

00:05:55.540 --> 00:05:56.760
今朝これのおかげで1時間助かった

00:05:56.760 --> 00:05:57.800
という生の声を示したこと

00:05:57.800 --> 00:05:59.920
第二に他人の目に見える成果を選んだこと

00:05:59.920 --> 00:06:00.980
レポートの早期提出

00:06:00.980 --> 00:06:02.020
承認の迅速化

00:06:02.020 --> 00:06:03.240
準備時間の半減などです

00:06:03.240 --> 00:06:05.840
第三にその証拠が自然と広まるようにしたこと

00:06:05.840 --> 00:06:07.780
チームのチャットや打ち合わせでの口コミは

00:06:07.780 --> 00:06:10.060
どんなに立派な告知よりも強力に響きます

00:06:10.060 --> 00:06:11.580
大切なのはマーケティングではなく

00:06:11.580 --> 00:06:13.740
仲間による実証で信頼を築くことです

00:06:13.740 --> 00:06:15.500
人々がコパイロットを求めるようになったのは

00:06:15.500 --> 00:06:17.120
単なる新しいログイン画面ではなく

00:06:17.120 --> 00:06:20.020
退屈なデータ作業から自分たちを救ってくれる存在だと気づいたからです

00:06:20.020 --> 00:06:21.440
こうした成果を可視化した組織は

00:06:21.440 --> 00:06:23.800
導入に対する姿勢そのものを完全に変えてしまったのです

00:06:23.800 --> 00:06:25.580
IT部門が導入を促すのではなく

00:06:25.580 --> 00:06:27.040
ユーザーが酸素を求めるように

00:06:27.040 --> 00:06:28.740
日常業務へコパイロットを取り入れていました

00:06:28.740 --> 00:06:30.320
これこそが本質的な導入であり

00:06:30.320 --> 00:06:32.320
無理に作り出す必要のない勢いなのです

00:06:32.320 --> 00:06:33.940
もちろん成果を示すことと

00:06:33.940 --> 00:06:36.860
売り込みのように感じさせない展開の仕方を構成することは別物です

00:06:36.860 --> 00:06:39.600
そこで重要になるのが適切なフレームワークです

00:06:39.600 --> 00:06:42.080
売り込みのように聞こえないフレームワークのことです

00:06:42.080 --> 00:06:43.660
変更管理のスライドを見ていて

00:06:43.660 --> 00:06:46.540
まるでMBAのグループ課題だなと思ったことはありませんか

00:06:46.540 --> 00:06:47.860
私も同じです

00:06:47.860 --> 00:06:50.080
AIの導入はシンプルであるべきです

00:06:50.080 --> 00:06:51.300
ツールができることを見せ

00:06:51.300 --> 00:06:52.540
試す準備をさせ

00:06:52.540 --> 00:06:54.120
行き詰まったらサポートするのです

00:06:54.120 --> 00:06:55.080
それなのに実際は

00:06:55.080 --> 00:06:56.740
無数の矢印や同心円が並び

00:06:56.740 --> 00:06:58.540
マイクロソフトの製品名変更集並みに

00:06:58.540 --> 00:06:59.900
流行り言葉が詰まった資料ばかりです

00:06:59.900 --> 00:07:02.100
そんな騒音は副社長を感心させるかもしれませんが

00:07:02.100 --> 00:07:04.520
実際にスプレッドシートと格闘する人々の助けにはなりません

00:07:04.520 --> 00:07:05.380
本当に役立つのは

00:07:05.380 --> 00:07:06.460
不要なものをそぎ落とし

00:07:06.460 --> 00:07:07.660
現実の課題に焦点を当て

00:07:07.660 --> 00:07:09.760
従業員が飽きない短さで構築されたフレームワークです

00:07:09.760 --> 00:07:10.700
ADKARは

00:07:10.700 --> 00:07:12.980
実践へと無理なく移行できる数少ない手法の一つでした

00:07:12.980 --> 00:07:13.700
理論上は

00:07:13.700 --> 00:07:16.720
認知、意欲、知識、能力、定着の5段階です

00:07:16.720 --> 00:07:17.780
コパイロットの世界では

00:07:17.780 --> 00:07:19.480
それは次のような意味を持ちます

00:07:19.480 --> 00:07:20.140
認知とは

00:07:20.140 --> 00:07:22.580
将来の生産性についての華やかな動画ではなく

00:07:22.580 --> 00:07:23.980
その人の役割に対して

00:07:23.980 --> 00:07:26.460
コパイロットで何ができるかを具体的に示すデモのことです

00:07:26.460 --> 00:07:27.080
意欲とは

00:07:27.080 --> 00:07:29.360
嫌な作業が半分で済む様子を見せるなど

00:07:29.360 --> 00:07:31.160
即座にメリットを感じさせることです

00:07:31.160 --> 00:07:31.820
知識とは

00:07:31.820 --> 00:07:33.420
膨大な資料で疲れさせるのではなく

00:07:33.420 --> 00:07:34.820
マイクロラーニングであるべきです

00:07:34.820 --> 00:07:36.480
5分で読めるチェックリストやチートシート

00:07:36.480 --> 00:07:37.900
ツールチップを提供しましょう

00:07:37.900 --> 00:07:38.620
能力とは

00:07:38.620 --> 00:07:39.700
サンドボックス環境で

00:07:39.700 --> 00:07:42.280
架空のデータや重要でない作業を使って練習させることです

00:07:42.280 --> 00:07:45.180
誤ったクリックでプロジェクトが台無しになる不安を取り除きます

00:07:45.180 --> 00:07:45.820
定着とは

00:07:45.820 --> 00:07:47.460
また別の社内メールを出すことではなく

00:07:47.460 --> 00:07:48.600
テンプレートやショートカット

00:07:48.600 --> 00:07:50.900
あるいは誰かが成功した時に上司が賞賛することです

00:07:50.900 --> 00:07:52.380
頭文字という鎧を脱ぎ捨てれば

00:07:52.380 --> 00:07:54.520
ADKARは決して理論だけのものではありません

00:07:54.520 --> 00:07:54.880
それは

00:07:54.880 --> 00:07:55.700
それが何か

00:07:55.700 --> 00:07:57.180
なぜ日常が改善されるか

00:07:57.180 --> 00:07:58.160
使い方を教え

00:07:58.160 --> 00:07:59.200
恐れずに練習させ

00:07:59.200 --> 00:08:00.440
使い続けることを褒める

00:08:00.440 --> 00:08:01.400
というロードマップなのです

00:08:01.400 --> 00:08:03.300
ここでのチェックポイントは単純です

00:08:03.300 --> 00:08:04.300
展開する前に

00:08:04.300 --> 00:08:06.100
コパイロットによって結果が確実に向上する

00:08:06.100 --> 00:08:08.400
具体的なタスクを少なくとも2つ挙げられるようにしてください

00:08:08.400 --> 00:08:10.620
数字は10%でも20%でも構いません

00:08:10.620 --> 00:08:11.900
自分で設定してください

00:08:11.900 --> 00:08:13.380
パイロット運用でそれを証明できなければ

00:08:13.380 --> 00:08:15.040
フレームワークは単なるスローガンに終わってしまいます

00:08:15.040 --> 00:08:17.140
ある中堅企業が営業部門にコパイロットを導入した際

00:08:17.140 --> 00:08:18.680
これがうまく機能するのを目の当たりにしました

00:08:18.680 --> 00:08:19.360
月曜日に

00:08:19.360 --> 00:08:20.080
頑張ってください

00:08:20.080 --> 00:08:21.840
というメールとともに丸投げしたりはしませんでした

00:08:21.840 --> 00:08:22.480
その代わりに

00:08:22.480 --> 00:08:24.420
要点を絞ったデモを行いパイプライン報告という

00:08:24.420 --> 00:08:25.480
一つの実務に焦点を当て

00:08:25.480 --> 00:08:26.960
サンドボックス環境を用意したのです

00:08:26.960 --> 00:08:27.520
アナリストは

00:08:27.520 --> 00:08:29.960
何も壊れる心配のないサンプルアカウントでテストを行いました

00:08:29.960 --> 00:08:32.100
私はそれらのレポート作成にかかっていた時間を追跡し

00:08:32.100 --> 00:08:33.400
どれだけ短縮されたかを測定しました

00:08:33.400 --> 00:08:34.040
リーダー層は

00:08:34.040 --> 00:08:36.140
テンプレートを活用して正しい利用法を定着させることで

00:08:36.140 --> 00:08:37.080
その習慣を強化しました

00:08:37.080 --> 00:08:38.100
本格導入の時期には

00:08:38.100 --> 00:08:39.560
誰もそのツールを恐れていませんでした

00:08:39.560 --> 00:08:41.620
すでに彼らのワークフローの一部になっていたからです

00:08:41.620 --> 00:08:42.840
コッターの短期的な勝利

00:08:42.840 --> 00:08:43.420
ショートウィンズ

00:08:43.420 --> 00:08:44.940
アプローチは現場でも効果を発揮しました

00:08:44.940 --> 00:08:45.240
これは

00:08:45.240 --> 00:08:47.760
誰も価値を実感できないまま忍耐が尽きてしまうような

00:08:47.760 --> 00:08:49.540
年単位の変革に対する特効薬です

00:08:49.540 --> 00:08:50.160
このモデルは

00:08:50.160 --> 00:08:52.040
どんな華やかなキャンペーンよりも早く広がる

00:08:52.040 --> 00:08:53.580
初期の目に見える成果に欠けています

00:08:53.580 --> 00:08:54.540
コパイロットで言えば

00:08:54.540 --> 00:08:56.780
1週間で成果を出すことだと考えてください

00:08:56.780 --> 00:08:59.340
チームが終時レポートを4時間から1時間に短縮したり

00:08:59.340 --> 00:09:00.300
プロジェクトリーダーが

00:09:00.300 --> 00:09:01.780
コパイロットの要約機能で終わりのない

00:09:01.780 --> 00:09:03.620
状況報告メールを廃止したりすることです

00:09:03.620 --> 00:09:04.840
こうした迅速な成果は

00:09:04.840 --> 00:09:06.080
単なる見せかけではありません

00:09:06.080 --> 00:09:07.560
それらは口コミで広がります

00:09:07.560 --> 00:09:08.760
そして会議的だった人々が

00:09:08.760 --> 00:09:10.560
同僚が取り戻した時間について自慢するのを聞くと

00:09:10.560 --> 00:09:11.480
抵抗感は和らぎます

00:09:11.480 --> 00:09:13.120
人々は発表に対して呆れるのをやめ

00:09:13.120 --> 00:09:14.780
自分たちでその話をするようになります

00:09:14.780 --> 00:09:15.540
ここでのコツは

00:09:15.540 --> 00:09:17.420
適切なブランドモデルを選ぶことではありません

00:09:17.420 --> 00:09:18.740
シンプルなフレームワークを選び

00:09:18.740 --> 00:09:20.400
日々の摩擦に対抗する武器にすることです

00:09:20.400 --> 00:09:21.660
それはつまり短いサイクル

00:09:21.660 --> 00:09:22.480
目に見えるインパクト

00:09:22.480 --> 00:09:23.980
そして過度な作り込みをしないということです

00:09:23.980 --> 00:09:24.920
フェーズの壁を押し付けたり

00:09:24.920 --> 00:09:27.120
ユーザーがどの段階にいるかを気にしているフリをしたりしてはいけません

00:09:27.120 --> 00:09:28.640
彼らはそんなことは気にしていません

00:09:28.640 --> 00:09:30.380
彼らの仕事の苦労が少しでも減る部分を見せ

00:09:30.380 --> 00:09:32.200
それを自然に感じられる構造で支えるのです

00:09:32.200 --> 00:09:33.740
その時こそフレームワークは単なる

00:09:33.740 --> 00:09:35.320
壁紙ではなくテコになります

00:09:35.320 --> 00:09:37.660
時間が経つにつれ私たちはその違いに気づきました

00:09:37.660 --> 00:09:40.300
導入の様子は役員がパワーポイントのメモを読み上げるのではなく

00:09:40.300 --> 00:09:42.620
同僚同士が成功体験を共有し合うものへと変わっていきました

00:09:42.620 --> 00:09:43.980
それこそが目標です

00:09:43.980 --> 00:09:45.760
流行語やラミネート加工された図表ではなく

00:09:45.760 --> 00:09:48.480
ユーザーの悩みの現実に即して調整されたフレームワークが必要です

00:09:48.480 --> 00:09:50.760
モデルはシンプルかつ人間味のあるものに保つ

00:09:50.760 --> 00:09:53.760
そうすれば強制されたものではなく自然な勢いが生まれます

00:09:53.760 --> 00:09:56.340
もちろん全てはトレーニングが機能してこそ意味があります

00:09:56.340 --> 00:09:59.960
紙の上のフレームワークは研修の場で人々が関心を失った瞬間に死に絶えます

00:09:59.960 --> 00:10:00.840
信じてください

00:10:00.840 --> 00:10:03.620
1日中続くコパイロットのトレーニングセッションにユーザーが閉じ込められたらどうなるか

00:10:03.620 --> 00:10:04.660
私たちはみんな知っています

00:10:04.660 --> 00:10:07.300
午前中の半ばには参加者の半分はすでに受信トレーに埋もれて

00:10:07.300 --> 00:10:08.740
時間が過ぎるのを待っている状態です

00:10:08.740 --> 00:10:10.220
呆れられないトレーニングとは

00:10:10.220 --> 00:10:12.860
トレーニングは多くの導入プロセスで気まずい瞬間となります

00:10:12.860 --> 00:10:14.540
それが重要であることは誰もが知っていますが

00:10:14.540 --> 00:10:16.860
やり方を間違えるとユーザーがコパイロットを実際に試すか

00:10:16.860 --> 00:10:18.640
静かに無視するかを決める分かれ道になってしまいます

00:10:18.640 --> 00:10:21.160
このセクションではトレーニングを効果的な要素だけに絞り込み

00:10:21.160 --> 00:10:22.260
人々を疲れさせることなく

00:10:22.260 --> 00:10:24.740
十分な実践的証拠を提供する方法について説明します

00:10:24.740 --> 00:10:27.620
まずは大きな罠である歴レースのデモから始めましょう

00:10:27.620 --> 00:10:29.540
コパイロットが完璧なレポートを自動作成したり

00:10:29.540 --> 00:10:31.220
何もないところから契約書を取り出したりする

00:10:31.220 --> 00:10:32.360
あの完璧な例のことです

00:10:32.360 --> 00:10:33.100
見栄えは良いですが

00:10:33.100 --> 00:10:35.480
現実世界のユーザーは磨き上げられたデモの世界には住んでいないため

00:10:35.480 --> 00:10:36.700
信頼をすぐに失墜させます

00:10:36.700 --> 00:10:39.460
彼らは予算2020最終版v13といったファイルや

00:10:39.460 --> 00:10:42.760
リリーfwd緊急のお願いといった懸命のメールの山に囲まれて生きています

00:10:42.760 --> 00:10:45.480
作り込まれたデモは非現実的な期待を抱かせるだけです

00:10:45.480 --> 00:10:47.960
代わりに彼らの実際の業務データを使ってトレーニングしましょう

00:10:47.960 --> 00:10:50.720
実践例として散らかったスプレッドシートを一つ持ち込み

00:10:50.720 --> 00:10:52.560
コパイロットに問題を要約させてみてください

00:10:52.560 --> 00:10:54.900
一貫して有益な要約が出るまで繰り返します

00:10:54.900 --> 00:10:57.180
これこそがユーザーが信頼できるトレーニングです

00:10:57.180 --> 00:10:59.300
さらに重要なのはトレーニングに未データを使うと

00:10:59.300 --> 00:11:01.900
たとえコパイロットが失敗しても人々が前のめりになるという点です

00:11:01.900 --> 00:11:05.000
私が支援したある企業では見栄えの良いサンプル資料を捨て

00:11:05.000 --> 00:11:08.340
実際の営業パイプラインのメールやバックログの表計算ファイルを使いました

00:11:08.340 --> 00:11:09.940
従業員はコパイロットが苦戦し

00:11:09.940 --> 00:11:13.320
適応し彼らが嫌っていた面倒な作業のステップを少しずつ削減していく様子を目の当たりにしました

00:11:13.320 --> 00:11:15.540
魔法ではありませんでしたが誠実な体験でした

00:11:15.540 --> 00:11:17.960
すると会議室から退屈や冷めた空気は消え去りました

00:11:17.960 --> 00:11:19.660
みんなが興味津々になったのです

00:11:19.660 --> 00:11:23.080
その変化はこんなこともできるという華やかなデモを見せるよりもずっと価値があります

00:11:23.080 --> 00:11:24.500
伝え方も重要です

00:11:24.500 --> 00:11:26.040
大げさな売り文句で始めたトレーナーは

00:11:26.040 --> 00:11:28.460
コパイロットが気まずい回答をした瞬間に信頼を失いました

00:11:28.460 --> 00:11:30.160
解決策は非常にシンプルです

00:11:30.160 --> 00:11:32.480
どのセッションの冒頭でもこのフレーズを使ってください

00:11:39.940 --> 00:11:41.540
いかに役立てるかを探り始めます

00:11:41.540 --> 00:11:44.780
うまくいかない結果は失敗ではなく学習曲線の一部となります

00:11:44.780 --> 00:11:48.900
その考え方が不完全なドラフトを拒絶ではなく学びの機会へと変えるのです

00:11:48.900 --> 00:11:51.400
定着させたいなら研修を1回限りのワークショップではなく

00:11:51.400 --> 00:11:54.500
日々の業務を有利に進めるための裏技を教える場だと考えてください

00:11:54.500 --> 00:11:57.400
長時間の会議室での研修は熱意を冷ましてしまいます

00:11:57.400 --> 00:11:59.660
短く頻繁なセッションこそが熱意を生み出します

00:11:59.660 --> 00:12:01.680
具体的なコツをいくつか伝えるのが最も効果的です

00:12:01.680 --> 00:12:03.320
トレーニングには本物のファイルを使ってください

00:12:03.320 --> 00:12:04.940
最初に期待値をコントロールしましょう

00:12:04.940 --> 00:12:08.380
丸1日の苦行のような研修ではなく15から30分のマイクロセッションを行いましょう

00:12:08.380 --> 00:12:12.280
ノイズの多い不完全なデータを備えたサンドボックス環境を作り恐れずに試せるようにします

00:12:12.280 --> 00:12:15.060
コパイロットのファクトチェック用チートシートを配布しましょう

00:12:15.060 --> 00:12:18.880
そうすれば研修の目的はコパイロットを魔法使いに仕立てることではなく

00:12:18.880 --> 00:12:22.220
上司の前で恥をかかずに優秀な相棒として使う方法を示すことになります

00:12:22.220 --> 00:12:25.760
チェックリスト形式にすれば研修室を出た後もポイントを忘れません

00:12:25.760 --> 00:12:28.320
3時間のスライドデッキを後で見返す人はいませんが

00:12:28.320 --> 00:12:30.900
1枚のチートシートならモニターの上に貼っておくはずです

00:12:30.900 --> 00:12:33.660
こうした変化から生まれるのは意識の転換です

00:12:33.660 --> 00:12:38.340
長いデモを見せられる代わりにユーザーは自分たちの痛みを解消できるタスクを自ら試し始めます

00:12:38.340 --> 00:12:40.040
メールのドラフト作成時間を半分にする

00:12:40.040 --> 00:12:43.820
プロジェクトの進捗を要約するあるいは山のような表から答えを見つけ出すといったことです

00:12:43.820 --> 00:12:47.220
一つ一つの小さな成功がコパイロットはマイクロソフトの広告の中だけでなく

00:12:47.220 --> 00:12:49.480
自分たちの業務に必要なものだという証拠になります

00:12:55.760 --> 00:12:59.220
このパターンこそが導入曲線を押し上げる要因であることが経験からわかっています

00:12:59.220 --> 00:13:03.160
誠実な例と短いサイクルでトレーニングを行うチームはこれは本当に役立つと言って現場に戻ります

00:13:03.160 --> 00:13:06.260
一方マーケティング的な演出に終始するチームは不満を抱えて戻ることになります

00:13:06.260 --> 00:13:07.320
単純なことです

00:13:07.320 --> 00:13:10.000
好奇心旺盛なユーザーは探求心を持つユーザーになります

00:13:10.000 --> 00:13:12.280
探求するユーザーは日常的に使うユーザーとなり

00:13:12.280 --> 00:13:15.240
彼らが作る物語はどんな社内広報よりも早く広がります

00:13:15.240 --> 00:13:18.060
独自のトレーニングを実施するためのワークシートが必要ですか

00:13:18.060 --> 00:13:20.740
M365章のTLDRニュースレターに登録するか

00:13:20.740 --> 00:13:24.780
M365章のページをフォローしてMVPが深掘りするライブ配信をご覧ください

00:13:24.780 --> 00:13:26.860
これによりプロジェクトごとに何をすべきか推測したり

00:13:26.860 --> 00:13:28.600
車輪の再発明をしたりする必要がなくなります

00:13:28.600 --> 00:13:30.100
つまり冷ややかな目で見られることなく

00:13:30.100 --> 00:13:33.820
2ファイルと現実的な設定を用い価値を早期に示す小規模なセッションを繰り返すトレーニングです

00:13:33.820 --> 00:13:36.300
それをうまくやればコパイロットは単なるITの宣伝ではなく

00:13:36.300 --> 00:13:38.040
チームの一員のように感じられるようになります

00:13:38.040 --> 00:13:41.180
トレーニングを適切に構成すればユーザーに自信を持たせることができます

00:13:41.180 --> 00:13:44.140
しかしそれを無視すれば導入の物語は一変します

00:13:44.140 --> 00:13:48.300
土台を準備せずにスイッチを入れることほど計画を脱線させるものはありません

00:13:48.300 --> 00:13:50.680
難しい部分を飛ばすとどうなるでしょうか

00:13:50.680 --> 00:13:52.260
ここから事態が悪化します

00:13:52.260 --> 00:13:56.440
企業が難しい作業を省きクリーンアップも準備もロードマップもなしに

00:13:56.440 --> 00:14:00.160
金曜の無料ドーナツのように全テナントでライセンスを有効化してしまう場合です

00:14:00.160 --> 00:14:02.380
誰かがチームで祝福のメッセージを投稿する頃には

00:14:02.380 --> 00:14:06.340
ユーザーはすでに第4四半期の財務を要約してから休暇規定を教えてまで

00:14:06.340 --> 00:14:08.020
あらゆる質問をコパイロットに浴びせています

00:14:08.020 --> 00:14:09.760
帰ってくる答えは何でしょうか

00:14:09.760 --> 00:14:10.460
ゴミです

00:14:10.460 --> 00:14:11.280
古いゴミ

00:14:11.280 --> 00:14:12.700
誤解を招くゴミです

00:14:12.700 --> 00:14:14.960
突然コパイロットは役立つアシスタントではなく

00:14:14.960 --> 00:14:17.660
IT部門が冗談で仕込んだいたずらボットのように見えてきます

00:14:17.660 --> 00:14:19.160
なぜこうなるのでしょうか

00:14:19.160 --> 00:14:21.560
退屈な基礎固めが全てスキップされたからです

00:14:21.560 --> 00:14:25.020
古いドキュメントライブラリの選別も明らかなエラーを見つけるためのテストも

00:14:25.020 --> 00:14:28.580
コパイロットの草案には事実確認が必要だと伝えるマイクロトレーニングもありません

00:14:28.580 --> 00:14:32.380
その代わりシェアポイントホルダーが2007年の社内タイムマシンのように機能し

00:14:32.380 --> 00:14:34.580
古いエクセルファイルが真実のように浮上し

00:14:34.580 --> 00:14:37.720
コパイロットがそれを新鮮な洞察として喜んで提供してしまいます

00:14:37.720 --> 00:14:41.120
ユーザーの立場からすればタキシードを着てゴミを漁っているような気分です

00:14:41.120 --> 00:14:44.500
IT部門の立場からすればヘルプデスクへの集中攻撃が始まるような気分です

00:14:44.500 --> 00:14:47.140
経営陣が役員向けに直接導入すると主張したことで

00:14:47.140 --> 00:14:49.280
導入が完全に失敗したケースを一つ見ました

00:14:49.280 --> 00:14:51.200
CFOが最初に投げた質問は

00:14:51.200 --> 00:14:53.100
第4四半期の財務を要約して

00:14:53.100 --> 00:14:54.760
最新の数字ではなく

00:14:54.760 --> 00:14:57.140
コパイロットは3年前の合併前のアーカイブから

00:14:57.140 --> 00:15:00.440
2017年以降存在しない企業構造のデータを拾い上げてきました

00:15:00.440 --> 00:15:02.500
それは権威あるように見えましたが完全に間違いであり

00:15:02.500 --> 00:15:03.840
会議の場でそのまま露呈しました

00:15:03.840 --> 00:15:05.500
その状況を説明してみてください

00:15:05.500 --> 00:15:07.620
そうやって信頼は急速に失われていくのです

00:15:07.620 --> 00:15:09.540
重要な質問で一度でも誤った回答をすれば

00:15:09.540 --> 00:15:12.000
たちまち導入全体が見かけ倒しというレッテルを貼られてしまいます

00:15:12.000 --> 00:15:12.940
採用は停滞し

00:15:12.940 --> 00:15:15.080
チームチャットは成果の報告ではなくミームであふれ

00:15:15.080 --> 00:15:16.940
IT部門には苦情の電話が殺到します

00:15:16.940 --> 00:15:18.200
そんな状況に陥った時

00:15:18.200 --> 00:15:21.360
言い訳をせずに経営層へ提出できる緩和策のスクリプトがこちらです

00:15:21.360 --> 00:15:23.940
信頼性の低い回答の原因となっていたデータソースを修正するため

00:15:23.940 --> 00:15:25.040
展開を一時停止しました

00:15:25.040 --> 00:15:27.420
検証可能な成果とともに段階的に再開する予定です

00:15:27.420 --> 00:15:29.440
こういえばIT部門の失敗という物語が

00:15:29.440 --> 00:15:31.460
IT部門が制御を掌握したという話に変わります

00:15:31.460 --> 00:15:33.580
ITのリカバリーは泥臭いものですが十分に可能です

00:15:33.580 --> 00:15:36.440
結局のところそれはシンプルで無骨な4ステップのプレイブックに集約されます

00:15:36.440 --> 00:15:37.860
広範囲な展開を一時停止し

00:15:37.860 --> 00:15:39.740
明らかに古いソースをトリアージしてアーカイブし

00:15:39.740 --> 00:15:41.860
期待値を明確にして小規模なパイロット版で再開し

00:15:41.860 --> 00:15:43.420
透明性を持ってコミュニケーションを取り

00:15:43.420 --> 00:15:44.720
ユーザーのフィードバックを収集する

00:15:44.720 --> 00:15:46.040
この4行があるかないかで

00:15:46.040 --> 00:15:47.820
事態を静かに収束させられるか

00:15:47.820 --> 00:15:50.360
コパイロットの評判に消えない傷を残すかが決まります

00:15:50.360 --> 00:15:51.440
そのプレイブックの中で

00:15:51.440 --> 00:15:53.820
IT部門はいくつかの中心的なクリーンアップを行いました

00:15:53.820 --> 00:15:55.300
重要なデータストアを整理し

00:15:55.300 --> 00:15:56.800
有効なものとアーカイブを分類し

00:15:56.800 --> 00:15:58.960
コパイロットの対象を統制されたグループに限定し

00:15:58.960 --> 00:16:00.680
サンドボックス形式で再始動するのです

00:16:00.680 --> 00:16:02.920
目標は完璧さではなく封じ込めです

00:16:02.920 --> 00:16:04.300
誇りをかぶったアーカイブをすなどらせて

00:16:04.300 --> 00:16:06.460
それをさも真実であるかのように出力させてはなりません

00:16:06.460 --> 00:16:07.480
信頼を築けるよう

00:16:07.480 --> 00:16:09.780
整理された環境の中で機能させる必要があります

00:16:09.780 --> 00:16:12.060
コミュニケーションの転換も同じくらい重要です

00:16:12.060 --> 00:16:14.020
賢いチームは過度な古代広告を行いません

00:16:14.020 --> 00:16:15.960
彼らは最初から明確に期待値を設定します

00:16:15.960 --> 00:16:17.620
コパイロットは草案を作成します

00:16:17.620 --> 00:16:19.080
裏付けを取るのはあなたです

00:16:19.080 --> 00:16:20.780
古い情報の見分け方はこちら

00:16:20.780 --> 00:16:22.680
誤った出力があった場合の報告先はこちら

00:16:22.680 --> 00:16:24.800
という誠実さは幹部のどんな応援よりも響きます

00:16:24.800 --> 00:16:27.660
なぜならユーザーにシンプルな行動指針を与えたからです

00:16:27.660 --> 00:16:30.160
誰も草案生成AIに完璧さは求めませんが

00:16:30.160 --> 00:16:31.500
予測可能性は求めます

00:16:31.500 --> 00:16:34.540
その予測可能性こそが信頼を再構築するのです

00:16:34.540 --> 00:16:37.240
パイロットサイクルで小さくても目に見える成果が出れば

00:16:37.240 --> 00:16:40.320
プロジェクトリーダーが状況報告の時間を半分に短縮したり

00:16:45.960 --> 00:16:49.320
広報イベントではなく廊下での雑談やチームのスレッドを通じて

00:16:49.320 --> 00:16:51.320
CIOのスローガンではなくこれのおかげで

00:16:51.320 --> 00:16:54.920
嫌だった作業が何時間も短縮できたという同僚の声が採用を加速させるのです

00:16:54.920 --> 00:16:58.140
それは演出された成功ストーリーよりも遥かに強力です

00:16:58.140 --> 00:16:59.280
教訓はこうです

00:16:59.280 --> 00:17:03.340
初日に大変な作業を飛ばせば派手なローンチと引き換えにすぐさまどん底に落ちます

00:17:03.340 --> 00:17:07.380
クリーンアップを行い再起動すれば出足は遅くとも確かな信頼を勝ち取れます

00:17:07.380 --> 00:17:10.200
そして信頼こそがコパイロットを企業のおもちゃ箱から

00:17:10.200 --> 00:17:12.420
日々のワークフローへと昇格させる唯一の要素なのです

00:17:12.420 --> 00:17:15.480
結局のところ成功するかどうかを決めるのはAIではなく

00:17:15.480 --> 00:17:18.800
現場の人間がそれを使い続けられるほど信頼しているかどうかなのですから

00:17:18.800 --> 00:17:21.700
その一つの要因こそが成功の真の指標です

00:17:21.700 --> 00:17:22.900
まとめは以上です

00:17:22.900 --> 00:17:27.480
コパイロットの導入が失敗するか定着するかの違いは魔法ではなく実行力にあります

00:17:27.480 --> 00:17:31.320
マーケティングの喧騒は忘れ実際に効果のある銃のアクションを覚えておきましょう

00:17:31.320 --> 00:17:33.940
ソースの範囲を絞り最も汚れたホルダから整理し

00:17:33.940 --> 00:17:37.280
試験運用を行い推進者を選び目に見える成果を示し

00:17:37.280 --> 00:17:39.840
未データでトレーニングし適切な期待値を設定し

00:17:39.840 --> 00:17:42.440
安全なサンドボックスを作り結果を測定共有し

00:17:42.440 --> 00:17:43.860
ロールバック計画を立てることです

00:17:43.860 --> 00:17:47.120
これらを行えば導入は混乱ではなく意図的なものとなります

00:17:47.120 --> 00:17:49.140
M365章のニュースレターに登録し

00:17:49.140 --> 00:17:53.180
MVPによるより深い解説が見られるM365章のリンクトインをフォローしてください

00:17:53.180 --> 00:17:55.260
全てのデータゴブリンを駆除することはできませんが

00:17:55.260 --> 00:17:57.960
最悪なものを封じ込め登録ボタンをワンクリックするだけで

00:17:57.960 --> 00:17:59.940
コパイロットに真の仕事を行わせることは可能です