自動化は時間を節約することで知られており、実際にそうなることも多いです。しかし、状況を悪化させた自動化プロジェクトも見てきました。例えば、一か月間、請求書を静かに重複させていたスクリプト、Webサイトのレイアウトが変わったときに動作を止め、一週間誰も気づかなかったボット、そもそも存在すべきでなかった工程を速めるために作られた精巧なシステムなどです。
そうした結果と良い結果との違いは、ほぼ技術によるものではありません。コードを書く前に行う検討によるものです。このチェックリストは、自動化を行う前に当社がお客様と確認しているものです。開発者の有無にかかわらず、ご自身でもお使いいただけます。
1. 作業の流れを、平易な手順で説明できますか？
トリガーから最終結果までの流れを、簡単な番号付きの手順で書き出してください。各手順は誰が行うか。何を確認するか。何を判断するか。どのシステムを開くか。
これが難しいと感じるなら、それは有益な情報です。誰も説明できないプロセスは、確実に自動化できません。混乱したプロセスを自動化しても、混乱が速くなるだけです。文書化は、上司だけでなく、実際にその業務を担当する人と行ってください。回避策を含めた実際のプロセスは、その人たちの中にあります。
2. そもそもこの工程は必要ですか？
工程を速める前に、その工程が必要かどうかを問いかけてください。多くの手作業は、古いシステム、古いルール、または誰も読まないレポートのためにだけ存在しています。工程を削除することは、それを自動化するよりも安価で、確実です。これはこのリストで最も価値の高い問いであり、最もよく見落とされるものでもあります。
3. 反復的で、ルールに基づいており、十分に頻度が高い作業ですか？
適した候補には三つの特徴があります。頻繁に発生するか、発生するたびに多くの時間がかかること。文書化できるルールに従っていること。そして、入力がデジタル形式で届くこと（ファイル、メール、データベースのレコード、フォームの送信など）。
向いていない候補は、判断への依存が大きい、毎回内容が変わる、または年に一度しか起きない作業です。めったに行わない作業は、リスクが高く間違えやすいものでない限り、通常は自動化する価値がありません。
4. 「正しい」とはどのような状態ですか？
成功の基準を、確認可能な形で定義します。データ取り込みの場合は、すべての行が反映され、合計が元データと一致していること。レポートの場合は、慎重な担当者が作成するのと同じ数値になっていること。メールの振り分けの場合は、すべてのメッセージが正しいフォルダーに入り、例外にはフラグが付いていること。
明確な定義がなければ、自動化をテストすることはできず、後になってまだ正しく動いているかを判断することもできません。
5. データはどの程度整っていますか？
自動化は、与えられたものをそのまま増幅します。顧客名の表記が五通りあり、日付の形式が混在し、一部の項目が自由記述である場合、自動化は失敗するか、もっともらしい誤りを出します。きれいな例ではなく、実際のサンプルを見て、その乱れを記録してください。時には、データの整理が最初に構築すべき自動化になります。また、正しい最初の一歩がデータの入力方法の改善である場合もあります。
6. 例外はありますか？
どの業務プロセスにも、扱いにくいケースがあります。例えば、住所を二つ持つお客様、別の通貨の請求書、不完全な状態で届くファイルなどです。実際に業務を担当する人に、“何がうまくいかないか”と“うまくいかないとき、どうするか”を尋ね、一覧にしてください。
例外ごとに判断してください。その例外を自動化で処理すべきか、人に引き継ぐべきかです。最良の自動化は、一般的なケースを完全に処理し、残りは迅速に解決できるだけの情報を添えて人に引き継ぎます。すべての例外を自動化しようとすると、プロジェクトは制御不能になります。
7. どの段階で人が関与し続ける必要がありますか？
送金、レコードの削除、顧客へのメッセージ送信、価格変更など、間違えると大きな損害につながる操作があります。こうした操作には承認ステップの導入をご検討ください。自動化がすべての準備を行い、担当者が内容を確認して確定ボタンを押します。これにより、時間の節約効果の大部分を保ちつつ、ミスによる被害を抑えられます。信頼が高まれば、後から管理を緩めることもできます。
8. システムはどのように接続されますか？
自動化が必要なシステムにどのようにアクセスするかを考えてください。
- APIは最適な選択肢です。安定しており、文書化されていて、プログラム向けに設計されています。APIとシステム連携についての当社の解説もご覧ください。
- データベースへのアクセスやファイルの書き出しは、データの読み取りに適していますが、利用が許可されているかご確認ください。
- ユーザーインターフェースの自動化（人が行うように、ソフトウェアが画面を操作する方式）は最後の手段です。動作はしますが、壊れやすく、より多くの監視が必要です。
また、各システムの所有者もご確認ください。ベンダーによっては自動化されたアクセスを制限したり、API利用に料金を課したりします。構築前に把握しておくほうがよいです。
9. 失敗した場合はどうなりますか？
いずれ失敗は起きます。パスワードは期限切れになり、ベンダーはファイル形式を変更し、サーバーは不都合なタイミングで再起動します。問題は、それに気づけるかどうかです。
事前に決めておくこと:
- 障害はどのように報告され、誰に報告されますか？
- 自動化は判断に迷ったとき、どうしますか：停止、再試行、スキップのいずれですか？
- 再実行しても安全ですか？適切に作られたジョブは、重複を作らずに再実行できます。
- 何がいつ行われたかを示すログはありますか？
本当に恐ろしいのは、静かな失敗です。大きく失敗するジョブは不便ですが、静かに失敗するジョブはリスクです。
10. 認証情報と機密データはどこに保管されますか？
自動化には通常、ログインやキーが必要です。それらはコードの外で、必要最小限のアクセス権とともに安全に保管すべきです。可能な場合は自動化用に別のアカウントを使ってください。そうすれば、その動作を確認でき、個人に影響を与えずに停止できます。個人情報や機密データが関係する場合は、それをどのように扱う義務があるかを確認し、開始時に開発者に伝えてください。
11. 運用は誰が担当しますか？
自動化は構築後も、誰かが責任を持って管理する必要があります。何を行うのか、どこで動くのか、停止したときに誰へ連絡するのかを把握しておいてください。運用方法、動作確認の方法、変更方法を説明した簡潔なドキュメントを求めてください。元の構築者が不在になっても、次の担当者が引き継げるようにするためです。まさにこの理由から、当社には保守・サポートサービスがあります。
12. AIを組み込むべきですか？
大規模言語モデルは、ルールでは対応しにくい作業に役立ちます。例えば、乱雑な文書の読み取り、依頼の分類、文章の下書きなどです。一方で不確実性もあり、もっともらしく見えても誤ることがあります。業務プロセスでAIを使う場合は、重要な判断には人によるレビューを残し、信頼する前に実際の事例で検証してください。この点は、当社のAI統合の業務でも取り上げています。
13. まず小さく始めて、効果を示す
一つの業務を選び、その中核を自動化して、しばらく手作業版と並行して運用します。結果を比較し、違いのある点を修正します。その後で適用範囲を広げます。これにより信頼が生まれ、そのアイデアを続ける価値があるかどうかも早く分かります。人々が信頼する小さくて信頼性の高い自動化は、誰も信じない野心的な自動化よりはるかに価値があります。
要するに
業務プロセスを説明でき、各ステップの理由を示せ、正しい結果を定義でき、例外を処理でき、リスクのある操作を人が管理でき、後に誰が担当するかが分かっていれば、自動化は成果を生む可能性が高いです。いくつかが欠けている場合は、次の最善の一歩はコードではなく、話し合いです。
そのような会話こそ、無料の初回相談の目的です。業務プロセスをご説明いただければ、自動化する価値があるかどうか、またどのように進めるかを率直にお伝えします。業務プロセス自動化サービスの詳細をご覧いただくか、お問い合わせください。