目次
業務自動化の相談で語られるのは、たいてい「何を自動化するか」です。請求書の生成、日報の集計、データの転記——どれも効果が見えやすく、増やしたくなります。
けれど、自動化した処理には、作った瞬間から別の問題がついて回ります。壊れたときに、誰かが気づけるかです。人がやっている作業なら、止まればすぐ分かります。自動化された処理は、止まっても誰も困った顔をしません。数字が更新されていないことに、月末になって気づく——そういう壊れ方をします。
先日、社内で動かしている自動処理を棚卸ししました。全23本。結果は、想像より悪いものでした。
この記事の結論
- 自動化は失敗が人に届く経路とセットで初めて完成する
- 棚卸しの結果、23本中22本が失敗しても無言だった
- 増やす前に「通知が付いている本数」を数える
何をしたか：自動処理23本の通知経路を1本ずつ数えた
やったことは単純です。社内で動いている自動処理を一覧にし、1本ずつ「失敗したとき、誰に、どこに届くか」を書き出しました。技術的な調査ではなく、ただの数え上げです。
結果はこうでした。
| 状態 | 本数 |
|---|---|
| 失敗が人に届く | 1本 |
| 失敗しても人に届かない | 22本 |
| うち、通知を一切出さない設定 | 6本 |
22本は、失敗しても誰にも知らせていませんでした。うち6本にいたっては通知の設定そのものが無く、壊れたまま無言で止まる状態です。
念のため補足すると、これらは動かなくなっていたわけではありません。今日時点では動いている。ただ、明日止まったときに気づく手段がなかった、という話です。自動化を積み上げてきた会社ほど、この状態になりやすいと思います。
自動化が「無言で止まる」原因
なぜこうなるのか。棚卸しをして分かった原因は3つでした。
1. 作った直後は動いているから
自動化は、作ったその場では必ず動きます。動作確認をして、うまくいったので次の業務へ移る。失敗したときの動きを試す機会がないまま、本番運用に入ります。
2. 通知は「後で付ける」ものとして扱われるから
通知は本来の目的（請求書を作る、データを集める）ではありません。だから毎回、後回しになります。そして後で付けられることはほとんどありません。
3. 1本ずつ手で付けるので、付け忘れる
通知の書き方が処理ごとにバラバラだと、新しい処理を作るたびに同じ設定を書き直すことになります。人の手が入る以上、必ず抜けが出ます。実際、通知が付いていた1本と付いていない22本の差は、意識の差ではなく仕組みがなかっただけでした。
失敗通知の設計｜共通の通知処理を作って全ジョブに一律で付ける
対策はシンプルです。通知の処理を1つだけ作り、すべての自動処理から呼ぶ形にしました。今回は共通処理（composite action）として用意し、全ジョブに一律で組み込んでいます。
ポイントは3つです。
- 通知の作り方を1か所に集約する：各処理は「通知を呼ぶ」だけ。文面や送り先を直したいときも、直す場所は1つで済みます
- 失敗時だけ鳴らす：成功のたびに通知が来ると、すぐ誰も見なくなります。平常時は無音、鳴ったら異常、という状態を保ちます
- 新しい処理にも最初から付く：作るときのひな形に通知を含めておけば、付け忘れが構造的に起きません
なお、具体的な実装方法（GitHub Actionsの共通処理の書き方など）は各サービスの仕様に依存し、仕様は変わるため最新は公式ドキュメントで確認してください。大事なのは実装手段ではなく、通知を1か所にまとめて全部に付けるという考え方のほうです。
導入初日に、実際のバグが1つ見つかった
通知を全ジョブに付けたその日に、さっそく1件検知されました。内容は、コマンドの実行方法が、想定した成否判定になっていなかったというものです。処理としては失敗しているのに、仕組み上は成功として扱われていた。つまり、通知を付けるまで「うまくいっている」と信じていた処理でした。
ここが一番の学びだったと思っています。失敗通知は、壊れたときのための保険だと思われがちですが、実際にはいま壊れていることに気づかせてくれる装置でもあります。付けた初日に見つかるということは、それまでの期間、気づかないまま運用していたということです。
棚卸しのやり方：3ステップ
同じことは、専門知識がなくてもできます。必要なのは表計算ソフト1枚です。
- 一覧を作る：社内で自動的に動いているものを、思いつく限り書き出します。定期実行のスクリプト、SaaSの自動連携、フォーム送信時の自動処理など。「気づいたら誰も触っていないが動いているもの」も忘れずに入れます
- 通知経路を書き込む：各行に「失敗したら、誰に、どこに届くか」を書きます。書けない行は、そのまま無言の処理です
- 空欄を埋める：全部を一気に直す必要はありません。止まったときの影響が大きい順に、通知を付けていきます
この作業の価値は、リスクが本数で見えることです。「たぶん大丈夫」が「22本が無言」に変わると、優先順位を決められます。
中小企業が持ち帰る判断軸：増やす前に、数える
自動化は本数が増えるほど効果が出ます。同時に、見えない故障箇所も本数分だけ増えます。人が減った分、異常に気づく目も減っているからです。
だから判断軸はこうなります。
自動化の本数を増やす前に、失敗が人に届く経路が全本にあるかを数えて確認する。
新しい自動化を1本作る前に、既存の1本に通知を付けるほうが、効果が大きい場面は少なくありません。通知のない自動化は、成果を生む仕組みであると同時に、誰も見ていない故障予備軍でもあります。
外注して自動化を導入する場合も、確認すべきことは同じです。「失敗したとき、誰にどう届きますか」。この質問に即答できる設計であれば、運用に乗る可能性は高いと考えていいと思います。
よくある質問
Q. 自動化の失敗通知はどこに送るのがいいですか？ 毎日必ず見る場所に送るのが基本です。メールは埋もれやすいため、社内で使っているチャットの専用チャンネルに集約するのが確実です。まずは経路を1本に絞り、実際に失敗させて届くところまで確認します。
Q. 全部の処理に通知を付けると、通知が多すぎませんか？ 成功時は通知せず、失敗時だけ鳴らす設計にすれば、平常時はほぼ無音になります。鳴ったら異常という状態を保てるため、かえって見落としが減ります。多すぎる場合は警告レベルの通知から削ります。
Q. 自社の自動化がいまどうなっているか、どう調べればいいですか？ まず一覧表を作り、1本ずつ「失敗したら誰にどう届くか」を記入します。空欄が残った行が、そのままリスクです。技術的な調査より先に、本数と通知経路を数える作業から始めるのが近道です。
まとめ
- 自動化は、失敗が人に届く経路があって初めて運用に乗る
- 社内23本を棚卸ししたところ、22本が無言。うち6本は通知の設定自体がなかった
- 対策は共通の通知処理を1つ作り、全ジョブに一律で付けること。付け忘れが構造的に起きない形にする
- 通知を付けた初日に、成否判定が正しくない処理が1件見つかった。通知は保険ではなく発見装置
- 増やす前に数える。「失敗が届く経路は全本にあるか」を確認してから次を作る
RENOYでは、自動化の新規開発だけでなく、すでに動いている仕組みの棚卸しと運用設計もご相談いただけます。「作ったはいいが、いま正しく動いているか分からない」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。