「この作業、AIで自動化できそう」。
そう思うと、どんなツールを使うか、どうつなぐかを考えたくなります。でも、その前に一つ確かめたいことがあります。
その作業は、今の形のまま続ける必要があるのでしょうか。
自動化できることと、自動化した方がよいことは、必ずしも同じではありません。作業そのものを減らせるなら、複雑な仕組みを作らずに済むかもしれません。
今回は、自動化の方法を選ぶ前に、何を残し、何を変えるかを考えてみます。
BLOG / 続けられる仕組み
自動化する前に、作業そのものを見直す。やめる・減らす・手順を変える・手作業を残す選択肢と、仕組みを維持する負担や収益へのつなぎ方を考えます。
「この作業、AIで自動化できそう」。
そう思うと、どんなツールを使うか、どうつなぐかを考えたくなります。でも、その前に一つ確かめたいことがあります。
その作業は、今の形のまま続ける必要があるのでしょうか。
自動化できることと、自動化した方がよいことは、必ずしも同じではありません。作業そのものを減らせるなら、複雑な仕組みを作らずに済むかもしれません。
今回は、自動化の方法を選ぶ前に、何を残し、何を変えるかを考えてみます。
前の記事では、リサーチや文書作成、企画出しをAIに任せることで、初動までの時間が大きく短くなったという使用感を書きました。
その便利さを活かすためにも、ときどき作業の目的へ戻って考えたいです。
たとえば、同じ情報を複数の場所に転記する仕事があるとします。転記を自動化する方法もあれば、保存場所を整理して、同じ情報を参照できるようにする方法もあります。
もちろん、別々に記録する必要がある場合もあります。ただ、「今こうしているから、そのまま自動にする」以外の選択肢も持っておきたいところです。
英国政府のサービス設計基準でも、技術や製品ではなく、利用する人の必要から設計することが示されています。AIも例外ではないと明記されています。
GOV.UK:Solve a whole problem for users
行政サービス向けの基準ですが、道具からではなく目的から考える、という視点は日々の制作や運営にも応用できそうです。
見直す入り口として、次のように書いてみます。
誰が、何を判断したり進めたりするための作業なのか。
「情報を集めるために、情報を集める」ではなく、「次に作る記事のテーマを選ぶために、情報を集める」。
後者なら、何を残すか考えやすくなります。毎日集める必要があるのか。件数を増やすべきなのか。それとも、少数の候補を比べられる方が役に立つのか。
作業の目的を言葉にすると、自動化する前に変えられる部分も見えてくるかもしれません。
目的が見えたら、次の選択肢を比べてみます。
表が画面に収まらない場合は、横にスクロールして読めます。
| 選択肢 | たとえば | 確かめたいこと |
|---|---|---|
| やめる | 使われていない一覧を作らない | 必要な記録や確認まで失わないか |
| 回数を減らす・まとめる | 判断するタイミングに合わせて情報をまとめる | 間隔が空くことで困ることはないか |
| 手順を変える | 同じ情報の転記を減らす | 権限やバックアップ、使う人の動きに無理がないか |
| 手作業を残す | 変化の大きい部分や判断を人が担う | 自動化を維持する負担と比べてどうか |
| 自動化する | 必要で、繰り返す部分を仕組みに任せる | 結果を確認でき、失敗に気づけるか |
これは任せ方を考えるための整理案です。上から順番に選ぶ決まりではなく、一つの作業の中で組み合わせることもできます。
情報の収集は自動にする。何を採用するかは人が決める。その前に、転記先を一つ減らす。こうした分け方も考えられます。
ただし、安全性や権限管理のために必要な確認まで、手間だからという理由で削らないようにします。「なくすと楽になる」と「なくしても問題ない」は別です。
ここで、記事のテーマを探す作業を仮の例にしてみます。実際の運用成果ではなく、見直し方を考えるための場面です。
もし、情報を集めた一覧が増える一方で、次に何を書くか決めにくいなら、収集量を増やすことが先とは限りません。
目的を「たくさん集める」から「読者の疑問に答えるテーマを選べる」に置き直すと、こんな案が考えられます。
そうすれば、確かめたいことも変わります。何件集めたかだけでなく、テーマを選びやすくなったか。確認の手間が増えすぎていないか。実際の制作につながったか。
毎日の収集が必要な題材もあります。頻度や件数を減らすこと自体を正解にせず、目的に合っているかを小さく試して確かめます。
自動化の判断では、最初に作る時間だけでなく、使い続ける負担も見ておきたいです。
結果の確認、元のサービスが変わったときの修正、失敗したときのやり直し。ツールやAPIの費用がかかる場合もあります。
減る作業と、残る作業、新しく増える作業。それぞれを分けて書き出してみると、「全部自動にするか、しないか」以外の判断がしやすくなりそうです。
Microsoftの価値評価資料でも、導入費用と便益を比べ、目的に合う指標で定期的に見直すことが挙げられています。
Microsoft Learn:Choose the best methods and tools to measure business value
時短だけでなく、ミスを減らすことや、必要な情報を確認しやすくすることを重視する場合もあります。何をもって役に立ったと考えるかは、先に決めておきたいところです。
事業として取り組むなら、負担を減らした先も考える必要があります。
時間が空くことと、収益が増えることは別です。
読者の疑問を調べる。商品やコンテンツを改善する。必要な人に届ける方法を試す。空いた時間を何へ振り向け、どんな変化を確かめるのかまで考えておくと、自動化を作ることだけで終わりにくくなるのではないでしょうか。
手間が減ったからといって、売上や利益が増えたと扱うことはできません。そのつながりは、実際の結果から見直していくものです。
十分に整理できるまで、自動化を試してはいけない、という話ではありません。小さく動かして初めて、必要な確認や、思ったより面倒な部分が見えてくることも考えられます。
まず一つの作業について、次の三つを書いてみるところから始められます。
自動化することは、目的へ近づくための手段の一つです。
今ある手順をそのまま速くするだけでなく、何を残し、何を変えるかも考える。
そんな視点を持っておくと、仕組みを増やすだけではない、負担の減らし方を探せそうです。
この記事の具体例や比較表は、作業の見直し方を考えるための案です。特定の運用での改善効果や収益を実証したものではありません。
思考・試行ログに戻る