AIが止まった後に出す報告書の項目一覧|次に効く記録の残し方

「復旧は当日のうちに済んだのですが、報告書に何を書けばよいのかで一週間止まっています」「前に出した報告書が今どこにあるのか、誰も知らないんです」——AIを業務に組み込んだ会社で、最初の停止が起きた後に必ず聞く二つの声です。どちらも、書く力の問題ではありません。報告書は起きたことを説明する反省文ではなく、次に同じ日が来たときに読まれる道具だという前提が置かれていないだけです。道具として設計されていない文書は、書き上げた瞬間から誰にも読まれず、半年後に同じ停止が起きたときにも参照されません。この記事では、社内に出す報告書に入れる項目と、時系列の書き方、原因の書き分け、再発防止の書き方、承認と保管、そして次の契約更新で効かせる残し方までを順に組み立てます。
カメ先生止まった後の報告書は、起きたことを説明するための書類だと思われがちだけれど、本当はその場にいなかった人のための書類なんだ。
カメ子その場にいなかった人、というのは、たとえばどういう人でしょうか。
カメ先生半年後にその仕組みを引き継ぐ担当者と、契約を続けるかどうかを決める人だね。二人とも当日の様子を知らないまま、この一枚だけを見て判断することになる。
カメ子起きたことを詳しく書くことと、その二人が判断できるように書くことは、どう違うのでしょうか。
- 宛先を決めてから書く。社外への告知と社内への報告は別の文書で、混ぜると両方が使えなくなる
- 時刻は3種類ある。起きた時刻・気づいた時刻・分かった時刻を分けて並べると、次に縮める場所が見える
- 再発防止は、担当と期限と確かめ方が書けるものだけを書く。書けないものは対策ではなく願望
AI活用を戦略に落とす前に、まずは導入・定着から始めませんか?
デボノはアカウント開設・初期設定など「そもそものAI導入」から社内定着まで伴走支援。マーケティング活用など一歩進んだご相談にも対応します。
出したら終わりになる報告書と、次に効く報告書の差
止まった日の対応そのものは、どの会社もそれなりにこなします。問題はその後です。多くの会社で、報告書は提出された時点で役目を終えます。決裁の欄に印が並び、共有の置き場に保存され、それきり開かれません。次に同じ停止が起きたとき、誰もその文書を探しません。探されないのは、そこに次の判断に使える材料が入っていないからです。
では、次に効く報告書には何が入っているのか。答えははっきりしていて、読んだ人が何かを決められる材料です。同じことがまた起きるのか、起きたときに何分止まるのか、そのとき何を守れば業務が回るのか、この契約を続けてよいのか。この4つのどれかに答えている文書は、半年後に必ず開かれます。どれにも答えていない文書は、出来事の説明としてどれだけ正確でも開かれません。
この差は、書きぶりの巧拙ではなく構成で決まります。だから最初にやることは、文章を上手にしようとすることではなく、誰が何を決めるために読む文書なのかを1行で決めてしまうことです。この1行が決まれば、入れる項目も、書く粒度も、承認の経路も自動的に決まります。次の節から、その1行の決め方を見ていきます。
誰に宛てて書くのかを、最初に決める
止まった後に作られる文書は、実は複数あります。社外の利用者や取引先に出す告知、契約している提供元に投げる問い合わせと回答、そして社内に出す報告書。この3つを1つの文書で兼ねようとすると、どの読み手にとっても余計な情報が半分を占める文書になります。社外向けには詳しすぎ、社内向けには薄すぎる、という状態です。
この記事が扱うのは3つ目、社内に出す報告書だけです。社外への告知は、出す順番も文面の作法も別の設計になるので、そちらは別に用意してください。ここで決めるのは、社内の誰に向けるかです。実務では、決裁をする人、情報システムを持つ人、実際に使っている部署の責任者の3者が読み手になります。3者で知りたいことが違うので、順番で解決します。
順番の作法は1つです。先頭に決裁をする人が知りたいことを置き、後ろに技術的な詳細を置きます。決裁をする人が知りたいのは、業務がどれだけ止まったか、いくらの損失か、また起きるか、という3点です。この3点が1枚目に収まっていない報告書は、決裁の場で読まれずに差し戻されます。細かい経過は2枚目以降で構いません。
全体は7つの工程で組む
宛先が決まったら、書く順番を固定します。毎回ちがう構成で書くと、比較ができなくなるからです。報告書の価値は1枚ごとの完成度ではなく、並べたときに見えてくるものにあります。同じ形で3枚たまれば、どこが繰り返しているかが一目で分かります。
起きた時刻・気づいた時刻・分かった時刻を分けて置きます。ここには推測を混ぜません。
何件処理できなかったかではなく、どの業務がどれだけ滞ったかで書きます。
提供元の停止と、自社の設定や手順の問題を、同じ欄に混ぜません。
元に戻した操作と、恒久的に変える予定を分けないと、直したつもりで残ります。
書けないものは対策ではありません。書けない理由のほうを記録します。
誰が悪かったかを書いた瞬間に、次の報告が上がってこなくなります。
この3つが空欄の文書は、書き上がった瞬間に行方が分からなくなります。
7つの工程は、書く順番であって調べる順番ではありません。調べるときは原因から入ることもありますが、文書の並びは必ず事実から始めます。原因の見立てが先頭にある文書は、後から見立てが変わったときに全体を書き直すことになります。事実が先頭にあれば、見立てが変わっても事実の部分は生き残ります。
工程1:事実は、3種類の時刻に分けて並べる
時系列を書くときに、多くの報告書が1本の線で書きます。ところが実際には、時刻には性質の違う3種類があります。実際に起き始めた時刻、こちらが気づいた時刻、そして何が起きているのか分かった時刻です。この3つを分けて置くと、次に縮めるべき場所がその場で見えます。
たとえば、起き始めたのが9時12分、気づいたのが10時40分、分かったのが11時05分だったとします。1本の線で書けば「午前中に停止」で終わりますが、3つに分ければ、気づくまでに88分かかっていることが一目で分かります。縮められるのは、ほとんどの場合この88分のほうです。原因を取り除く工事よりも、気づくまでの時間を短くするほうが、費用も期間もはるかに小さく済みます。
並べるときの約束は2つです。1つ目は、推測を時系列の欄に入れないこと。「おそらくこの時点で始まっていた」は、事実の欄ではなく原因の欄に書きます。2つ目は、時刻の根拠を添えること。記録から取ったのか、担当者の記憶なのかで、後から検証できるかどうかが変わります。記憶しかない時刻には、記憶である旨をそのまま書いてください。正確さを装った時刻は、次に読む人を誤らせます。
工程2:影響は、件数ではなく業務の単位で数える
影響の欄が「約3,000件の処理が失敗」で終わっている報告書は、決裁の場で必ず「それで何が困ったのか」と聞かれます。件数は内部の単位で、読み手が判断に使える単位ではありません。書くべきは、どの業務が、どれだけの期間、どういう形で滞ったかです。
実務では4つの軸で書くと過不足がなくなります。止まった業務の名前、滞った量を業務の言葉で表した数、締切に間に合わなかったものの有無、そして外部の相手に影響が出たかどうか。4つ目は特に重要で、社外に影響が出たかどうかで、この後の手続きと承認の経路が変わります。出ていないなら、出ていないと明記してください。書いていないと、読む人は出たかもしれないと考えます。
もう一つ、気づかれなかった影響を分けて書くという作法があります。AIを使った仕組みの停止では、答えが返らない停止だけでなく、答えは返ったが中身が不完全だった、という形が混ざります。前者は利用者が気づきますが、後者は気づかれずに後工程へ流れます。後者があった可能性を確認したか、確認した結果どうだったかを1行で残してください。ここが空欄の報告書は、数か月後に別の問題として戻ってきます。
工程3:原因は、外から来たものと自社で決めたものに分ける
原因の欄がいちばん荒れます。提供元の不具合、自社の設定、使い方の想定漏れ、連携している別の仕組みの変更。これらが1つの段落に混ざると、読み手は何を直せばよいのか判断できません。欄を2つに割ります。外から来たものと、自社が決めたことに起因するもの。この2つは、次にとれる手がまったく違うからです。
外から来たものについて書くのは3点です。提供元から出た説明の要旨、その説明が出た日時、そして自社としてその説明を確認できたかどうか。提供元の説明をそのまま自社の原因分析として書き写さないことが要点です。相手の説明は材料であって、自社の結論ではありません。確認できていない部分は、確認できていないと書きます。
自社が決めたことに起因するものは、設定・手順・想定の3つに分けます。設定は、上限や権限や接続先の値。手順は、誰がいつ何を確かめることになっていたか。想定は、こういう場面は起きない前提で作っていた、という部分です。3つのうち、いちばん見つけにくくて、いちばん再発するのが想定の漏れです。設定の値と手順の抜けだけを書いて終わっている報告書は、同じ想定でもう一度組み直されます。
「サービス側の問題でした」で止めると、同じ日がまた来る
原因の欄が、外から来たものだけで埋まっている報告書があります。事実としては正しいことが多いのですが、この形で承認まで通してしまうと、自社側にやることが何も残らない文書ができあがります。次に同じ停止が起きたとき、また同じ文書が作られます。
外の原因が確かだったとしても、自社側には必ず問う余地が残ります。気づくのが遅れなかったか。止まっている間に業務を回す代わりの手が用意されていたか。誰がどこまで判断してよいかが決まっていたか。そして、その提供元に業務を預けるという判断を、いつ誰がどういう理由で行ったか。最後の1つは責任追及ではなく、契約を見直すときの入口になります。
実務的な線の引き方はこうです。原因の欄は外と内に分けて書き、再発防止の欄には自社で着手できるものだけを書く。提供元に改善してもらう事項は、再発防止ではなく「相手に求めたこと」という別の欄に置きます。この分け方をしないと、相手任せの項目が再発防止として並び、期限も担当も空欄のまま残ります。自社で動かせない項目を対策の欄に書かない、という一線だけで、報告書の実効性は大きく変わります。
工程4:応急でやったことと、これから直すことを分ける
止めた業務を戻すためにやった操作と、同じことが起きないようにする変更は、別の欄に置きます。混ぜると、応急の操作が恒久の対策として記録されてしまうからです。再起動して戻った、別の経路に切り替えた、手作業で処理した。これらはその日を乗り切るための操作であって、次を防ぐ変更ではありません。
応急の欄で残すべきは、何をしたかに加えて、その状態が今も続いているかどうかです。切り替えたまま戻していない経路、外したまま戻していない制限、止めたまま再開していない自動処理。応急のまま放置された設定は、次の停止の原因そのものになります。戻す予定日を書く欄を、応急の欄の隣に置いてください。空欄のまま承認されるのを防げます。
これから直すことの欄には、着手の順番を添えます。順番は、効果の大きさではなく気づくのが遅れた部分から先に置くのが実務的です。原因そのものを取り除く工事には時間と費用がかかりますが、気づくまでの時間を縮める変更は、たいてい小さく早く入ります。同じ停止が起きても、88分が10分になれば被害は桁で変わります。
工程5:再発防止を「気をつける」で終わらせない
再発防止の欄でいちばん多い書き方が、注意喚起です。周知を徹底する、確認を強化する、意識を高める。これらは誰が何をいつまでに行い、行われたことをどう確かめるかが書けません。書けないということは、実行されたかどうかを後から判定できないということで、判定できない項目は実行されません。
判定できる形にする条件は3つです。担当が個人または役割で書かれていること、期限が日付で書かれていること、そして完了したことを何で確かめるかが書かれていること。3つ目が抜けやすく、ここが抜けると期限の日に「やりました」という報告だけが返ってきます。設定値を画面で見せる、手順書の該当箇所を示す、試して結果を記録する、といった確かめ方まで書きます。
- 注意喚起を行う:誰が誰に何を言えば完了なのかが決まらない。1か月後に確かめようがない
- 監視を強化する:何を、どの値を超えたら、誰に届くのかが書かれていない。仕組みとして何も変わらない
- 手順を見直す:どの手順書のどの工程を、どう書き換えるのかが決まっていない。見直しの会議だけが増える
- 提供元に改善を依頼する:自社では完了させられない。再発防止ではなく、相手に求めたことの欄に置くべき項目
- 今後は複数人で確認する:確認する人が増えるだけで、見るべき対象が決まっていない。人手が増えて再発は減らない
書けない項目が出てきたときは、無理に文言を整えずに、書けなかった理由のほうを記録します。費用の目処が立たない、判断できる人がいない、そもそも原因が特定できていない。理由が残っていれば、次に同じ停止が起きたときに議論をやり直さずに済みます。理由を書かずに体裁の整った文言だけを置くと、次の一枚も同じ文言で埋まります。
工程6:人を責めない書き方にすると、次の報告が早く上がる
事後の検証について、グーグルが公開している運用の書籍には、非難しない書き方の定義が置かれています。個人やチームを悪いこととして責めるのではなく、その出来事に寄与した原因を特定することに集中する、という考え方です。理由も明記されていて、医療と航空の実例を挙げながら、責任の割り当てから、なぜその個人やチームが不完全または不正確な情報しか持てなかったのかという体系的な理由の調査へと移ったとき、効果的な予防の計画を置くことができる、と述べられています。
これは温情の話ではありません。実務上の効き目がはっきりしているから採用されている作法です。名指しされる文書だと分かっている組織では、次の停止の報告が遅れます。遅れれば影響が広がり、報告書に書ける事実も減ります。責めない書き方は、優しさではなく、次の一報を早く受け取るための仕組みです。
書き換えの作法は単純です。人の名前が主語になっている文を、仕組みが主語になっている文に直します。「担当者が確認を忘れた」ではなく「確認が手順のどこにも組み込まれていなかった」。「設定を誤った」ではなく「誤った値を入れても警告が出ない状態だった」。同じ事実を、次に変えられるものを主語にして書き直すだけです。誰がやったかは、必要なら経過の欄に役割として残せば足ります。
工程7:承認する人・保管する場所・読み返す日を決める
同じ書籍には、事後の検証を組織で回すための運用も書かれています。初期の段階で内部に共有して経験のある担当者が査読すること、レビューされないまま残る文書を作らないこと、より広い範囲に共有すること、そしてチームや組織の保管場所に置くこと。書き上げることと、読まれる状態にすることは別の作業だという前提が置かれています。
社内で決めるのは3つです。誰が承認するか、どこに保管するか、いつ読み返すか。承認は、対策の実行を指示できる立場の人に置きます。保管は、次に停止が起きた人が5分以内に見つけられる場所が条件で、担当者の個人の領域や、電子メールの添付は条件を満たしません。読み返す日は、期限を過ぎた対策の確認と、四半期に一度の並べ読みの2種類を置きます。
並べ読みが、この文書がいちばん効く場面です。1枚では気づかないことが、3枚並べると見えます。同じ提供元で3回、同じ時間帯で2回、同じ設定の周りで2回。こうした繰り返しは、1件ごとの調査では絶対に出てきません。並べ読みのために、報告書の形を毎回同じにしておくことが要る、という話がここで効いてきます。
外から締切が来ることがある
社内の文書だから期限は自分たちで決められる、とは限りません。扱っている情報によっては、外から期限が決まってきます。個人情報保護委員会が公開している漏えい等への対応の案内では、報告が必要になる事態として、要配慮個人情報を含むもの、不正に利用されると財産的な被害が生じるおそれのあるもの、不正の目的をもって行われたおそれがあるもの、そして本人の数が1,000人を超えるもの、の4つの類型が挙げられています。
期限も示されています。速報は発覚の日から3日から5日以内、確報は発覚の日から30日以内。不正な目的で行われたおそれがある場合の確報は、発覚の日から60日以内とされています。同委員会の別の案内では、速報について「速やか(概ね3から5日以内)に」と書かれ、本人への通知は事態の状況に応じて速やかに、本人にとって分かりやすい方法で、概要とデータの項目と原因などを伝える、とされています。
ここで押さえておきたいのは手続きの細部ではなく、社内の報告書の締切が、社内の都合で決められない場合があるという一点です。AIを使う仕組みは、社内の文書と顧客の情報を同じ入口に通していることが多く、停止の場面でどちらが関わっていたかが最初は分かりません。個人情報が関わる可能性が1%でもあるなら、日数の時計はその日から動いていると考えて動き出す。関わっていなかったと後から分かったときに困ることは何もありません。
実務仕様:報告書に入れる項目と、意味がずれやすい言葉
ここまでの内容を、そのまま書式に落とします。欄の名前は自社の言葉に置き換えて構いませんが、欄そのものを減らさないことだけは守ってください。減らした欄は、次に読む人が判断できない箇所としてそのまま残ります。
| 欄 | 書く内容 | 無いと何が起きるか |
|---|---|---|
| 表題と1行の要約 | 何の仕組みが、いつ、どれだけ止まったか | 決裁の場で、まず口頭の説明から始めることになる |
| 3種類の時刻 | 起き始めた時刻・気づいた時刻・分かった時刻と、その根拠 | 気づくまでの時間が見えず、縮められる場所が特定できない |
| 影響(業務の単位) | 止まった業務名・滞った量・締切への影響・社外への影響の有無 | 件数だけが残り、被害の大きさを誰も判断できない |
| 気づかれなかった影響 | 答えは返ったが中身が不完全だったものの有無と確認結果 | 数か月後に、別の問題として戻ってくる |
| 原因(外から来たもの) | 提供元の説明の要旨・出た日時・自社で確認できたか | 相手の説明が自社の結論として残り、検証できなくなる |
| 原因(自社で決めたもの) | 設定・手順・想定の3つに分けて記載 | 設定の値だけが直り、同じ想定でまた組まれる |
| 応急でやったこと | 行った操作と、その状態が今も続いているか、戻す予定日 | 切り替えたままの設定が、次の停止の原因になる |
| これから直すこと | 変更の内容と着手の順番 | 工事の話だけが残り、小さく早く効く手が後回しになる |
| 再発防止 | 担当・期限・完了を何で確かめるか | やりましたという報告だけが返り、実行されたか判定できない |
| 相手に求めたこと | 提供元へ依頼した事項と回答の期限 | 自社で完了させられない項目が、対策の欄に残り続ける |
| 承認・保管・読み返し | 承認者、保管場所、対策の確認日と並べ読みの時期 | 書き上げた直後から、どこにあるか分からなくなる |
並びにも意味があります。上から4つが決裁をする人の読む範囲、そこから下が実務の範囲です。1枚目に上の4つが収まるように組めば、読み手ごとに別の資料を作る必要がなくなります。分量が増えたときに削るのは、下のほうではなく、経過の描写の細かさです。
ミニ用語解説:打ち合わせで意味がずれる言葉
書式が決まっても、言葉の意味が揃っていないと確認の往復が増えます。報告書をめぐる打ち合わせでは、次の6語が人によって違う意味で使われて話が噛み合わなくなります。
| 言葉 | この文書での意味 | ずれやすい使われ方 |
|---|---|---|
| 復旧 | 業務が元の手順で回るようになった状態 | 仕組みが起動した時点を復旧と呼ぶと、滞った時間が短く見える |
| 原因 | そのとき何が起きたかの説明 | 誰の落ち度かという意味で使われると、書ける内容が減る |
| 再発防止 | 自社で着手し、完了を確かめられる変更 | 提供元への依頼まで含めると、期限の空欄が並ぶ |
| 暫定対応 | その日を乗り切るために行った操作 | 恒久の対策と同じ欄に置かれると、戻し忘れが残る |
| 影響なし | 業務にも社外にも滞りが出なかったこと | 気づかれていないだけの状態にも使われる |
| 監視 | 決めた値を超えたときに、決めた人へ届く仕組み | 画面が用意されていることを監視と呼ぶと、誰も見ていない状態が残る |
定義を揃える場は、停止が起きてからでは遅くなります。最初の1枚を書くときに、この6語だけでも社内の言葉で定義して、書式の末尾に貼っておいてください。2枚目からは、この作業が要らなくなります。
下書きをAIに任せてよい範囲と、人が決める範囲
報告書の作成には、機械のほうが速い作業がいくつもあります。記録から時刻を拾って並べる、影響の件数を業務ごとに集計する、過去の報告書から同じ提供元の分を抜き出す、書式の欄が埋まっているかを点検する。このあたりは下書きを作らせて、人が確かめる形が素直に効きます。文章の整え方の提案も、材料が揃っていれば役に立ちます。
一方で、任せてはいけない部分がはっきりしています。原因の断定、影響の有無の判定、再発防止として何を選ぶか、そして外へ報告すべき事態に当たるかどうかの判断。いずれも、記録に残っていない社内の事情と契約の条件が材料になる判断で、その材料は記録のどこにも入っていません。とくに、原因の見立てをAIに出させてそのまま原因の欄に書くのは避けてください。
- 原因の断定と、外へ報告すべき事態かどうかの判断は人が行う。AIの出力を根拠にしない
- 時刻の並びや集計をAIに作らせたら、どの記録のどの範囲から取ったかを必ず書かせ、人が元の記録で照合する
- 再発防止の候補を出させるのはよいが、担当と期限と確かめ方は人が埋める。埋められない候補は採用しない
- 過去の報告書を読み込ませて要約させるときは、要約だけを回覧せず、元の1枚も同じ場所に置いておく
人が必ず確かめる範囲も先に決めます。時刻の根拠、影響の有無、原因の欄に書いた断定の裏づけ、再発防止の担当と期限の4つです。この4つさえ人の手で確かめる運用にしておけば、残りは下書きを使っても文書の信頼性は落ちません。全部を人が書き直す運用にすると、報告書を出すこと自体が重くなり、次から出なくなります。
この1枚が、次の契約更新と乗り換えで効く
報告書の最後の使い道は、契約の見直しです。更新の時期になると、続けるか、別の提供元にするか、自社の環境へ移すか、という議論が起きます。このとき判断の材料になるのは、営業資料に書かれた稼働の目標値ではなく、自社で実際に何回止まり、何分で気づき、そのとき業務がどれだけ滞ったかという自社の記録です。
だから、報告書には契約の更新で使う欄を1つ足しておくと効きます。相手からどういう説明があり、いつ出てきて、こちらが求めた改善に対してどう回答したか。止まった事実よりも、止まった後の説明の速さと誠実さのほうが、乗り換えの判断では重く効きます。これは記憶では再現できないので、その場で書いておくしかありません。
乗り換えを検討する段になったら、この記録の束をそのまま使えます。候補の提供元に対して、自社で実際に起きた3件を示し、同じことが起きたときにどう動くのかを説明してもらうという比べ方ができます。一般的な質問票よりも、はるかに相手の実力が出ます。逆に、この束が無い会社は、比較のたびに相手の資料を読み比べるところからやり直すことになります。
出す前のチェックリストと、やりがちな失敗
最後に、承認へ回す前に自分で確かめる項目を置きます。書き終えた直後は判断が甘くなるので、機械的に当てていくのが確実です。
- 1枚目だけで、どれだけ止まったか・いくらの影響か・また起きるかの3つに答えられているか
- 時刻が3種類に分かれていて、それぞれ記録から取ったのか記憶なのかが書いてあるか
- 影響の欄に、社外への影響の有無が明記されているか(無い場合も無いと書いたか)
- 答えは返ったが中身が不完全だったものの有無を、確認したうえで書いたか
- 原因の欄が、外から来たものと自社で決めたものに分かれているか
- 応急でやった操作のうち、まだ戻していないものに戻す予定日が入っているか
- 再発防止の全項目に、担当・期限・完了を確かめる方法が入っているか
- 自社で完了させられない項目が、再発防止ではなく相手に求めたことの欄にあるか
- 個人の名前が主語になっている文が残っていないか
- 承認者・保管場所・読み返す日が埋まっているか
そのうえで、この文書をめぐってよく起きる崩れ方を挙げておきます。どれも、書いた人の能力ではなく運用の設計で起きます。
- 完璧な原因が分かるまで提出しない:提出が2か月遅れ、対策の着手も2か月遅れる。分かっていない部分は分かっていないと書いて先に出す
- 社外への告知の文面を、そのまま社内の報告書として流用する:判断に要る内部の事実が全部抜け落ちたまま承認される
- 書式を毎回変える:並べ読みができなくなり、繰り返している停止に気づけない
- 再発防止の実行を確認する日を決めない:対策が実行されないまま次の停止が起き、同じ項目がもう一度書かれる
- 停止のたびに書式が重くなる:欄が増え続けて提出が苦行になり、小さな停止が報告されなくなる
まとめ
AIが止まった後に出す報告書は、その場にいなかった人が判断するための道具として組むと、次に効く一枚になります。宛先を決め、時刻を起きた・気づいた・分かったの3種類に分け、影響を業務の単位で数え、原因を外から来たものと自社で決めたものに分け、応急と恒久を分け、再発防止には担当と期限と確かめ方を入れる。そのうえで、人ではなく仕組みを主語にして書き直し、承認する人と保管する場所と読み返す日を埋める。個人情報が関わる可能性があるときは、社内の都合とは別に日数の時計が動いていることも忘れないでください。まずは、過去にいちばん大きく止まった一件を選んで、その3種類の時刻を書き出してみるところから始めてみてください。
※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。
AI活用を戦略に落とす前に、まずは導入・定着から始めませんか?
デボノはアカウント開設・初期設定など「そもそものAI導入」から社内定着まで伴走支援。マーケティング活用など一歩進んだご相談にも対応します。
