毎日、手作業でやっていることはないでしょうか。データを取ってきて、まとめて、どこかへ送る。プログラムでやれるはずのことを毎日自分の手でやっていて、自分が休むと止まる。
「自動化したい」は、プログラミングを学ぶ動機の中でも特に筋のいいものです。ただし、自動化には初心者が必ず踏む落とし穴が1つあります。この講のゴールは、自動化の最小構成を知ること。そして、その落とし穴・・・"静かな失敗"への備えまでを、自動化の定義に含めることです。
タイマー式の炊飯器にたとえます。
夜、米を研いで、朝6時に予約する。朝、炊きたてのご飯ができている。これが自動化の幸せな姿です。プログラムの世界では、定期実行（決めた時刻や間隔で、処理を自動で動かす仕組み）がこのタイマーにあたります。毎日のあの手作業は、「何を（処理）」と「いつ（時刻）」の2つを設定すれば、あなたが寝ていても走るようになります。
ところで、炊飯器の予約には、嫌な思い出がないでしょうか。停電していた。コンセントが抜けていた。予約したつもりが、されていなかった。そして最悪なのは、それに気づくのが夕食どき・・・つまり、ご飯が必要になった瞬間だということです。
自動化された処理も、まったく同じ壊れ方をします。しかも質が悪いことに、手作業と違って、失敗した瞬間にあなたはその場にいません。第11講の言葉で言えば、ログには失敗がちゃんと記録されている。でも、誰も読んでいない。こうして「動いているつもりの、止まった自動処理」が生まれます。数ヶ月後、その結果が必要になった日に、ずっと止まっていたことを知る。第17講の証明書で見たのと同じ、静かな失敗です。自動化の事故は、ほぼ全部この形をしています。
だから、この講座では自動化をこう定義します。"失敗したら知らせてくる"ところまで作って、自動化。タイマーで炊けるようにしただけでは、半分です。炊けなかった朝に、朝のうちに教えてくれる仕組み・・・失敗したときだけメールや通知が飛ぶ設定までがワンセット。なお、成功の通知は要りません。毎日届く「成功しました」は3日で読まなくなり、読まない通知は無いのと同じだからです。知らせるべきは、失敗だけ。
すでに定期実行を持っている人は、その設定画面を開いてください。読み取ることは3つです。何が動くか。いつ動くか。失敗したら、どうやって知るか。3つ目に答えが無ければ、それが今日の発見です。質問例2で、失敗通知の付け方を出してもらってください。
まだ自動処理を持っていない人は、設計図の演習をします。紙に、3行だけ書いてください。
3行目まで書けたら、それはもう発注書です。いつか作る日が来たら、質問例1と一緒にAIに渡してください。最小構成を案内してもらえます。
そのまま貼って使えます。
3つ目は少し先回りの質問ですが、効きます。「動かない」だけでなく、「動いたが中身が空っぽ」のような、通知をすり抜ける失敗まで洗い出せるからです。
失敗しても気づかない設計のまま、運用に乗せること。
もう十分に話しましたが、事故の形だけ具体的に覚えておいてください。毎晩動くはずの記録の処理が、外部サービスの仕様変更で止まる。通知は無い。3ヶ月後、記録を見返す用事ができて開いたら、3ヶ月分が空白だった。データは後から取り直せないことが多いので、この空白は永久に埋まりません。
そしてもう1つ、逆側の注意も。自動化に慣れると、なんでも自動にしたくなります。でも、自動化は第2講で言う"飼う対象"を1つ増やす行為でもあります。月に1回しかやらない作業は、手作業のままでいいことも多い。自動化するのは、毎日・毎週やる作業から順に、が原則です。