毎日、決まった時間になると自動で動くプログラムは非常に便利な存在です。しかし、その裏側では常に不安がつきまといます。「本当に正しく動いているのか」と心配になるのです。私は以前、社内のデータ集計を自動化しました。バッチ処理をPythonで作成したのです。これで楽になれると確信していました。しかし現実はそう甘くはありません。自動化によって作業時間は減りました。その一方で、別の種類のストレスが私の朝を支配するようになったのです。
それは、バッチの実行結果を確認するという作業でした。地味で精神を削るルーティンだったのです。プログラムが夜中に動きます。翌朝に出社するまでは成功したかどうかが分かりません。もしエラーで止まっていれば大変です。朝一番でその修正に追われることになります。そんな不安定な状況が続きました。上司や同僚からは「昨日のデータはもう見られる？」と声をかけられます。そのたびに私は自分の作業を止めました。そして確認作業に入らなければならなかったのです。
この記事では、そんな私の体験を共有します。「翌朝の確認作業」に疲れ果てた時のことです。PythonとSlackを連携させました。そうして心の平穏を取り戻した過程をお話しします。最初は簡単な通知から始めました。失敗を繰り返しながら多くを学んだのです。「本当に意味のある通知」とは何かを模索しました。その過程を等身大でお伝えします。
深夜の集計、朝の確認、上司の問いの罪悪感
私が作成した自動集計プログラムの稼働時間は深夜でした。毎日深夜の2時に動くように設定しています。翌朝の始業時間にはスプレッドシートに反映されます。すべてのデータが揃っているはずの仕組みです。しかし、どれだけ入念にテストをしてもエラーは起きます。ネットワークの瞬断やサーバーの気まぐれな挙動が原因です。月に数回は必ずエラーが発生していました。そのため、私の出社後の第一仕事は確認になります。プログラムが完走したかどうかを真っ先に確かめたのです。
出社してPCを起動している最中のことです。隣の席の上司から声をかけられました。「今日の集計、昨日の夜にエラー出てなかった？」と聞かれます。これが一番のストレスでした。自分でもまだ確認できていない状態です。そんな時に聞かれると、言いようのない罪悪感に襲われました。まるで自分の責任で仕事が滞っているように感じたのです。そのたびにコーヒーを淹れる暇もありません。焦ってサーバーの深い階層まで潜り込んでいました。
アナログログ確認の苦行
当時の確認作業は、非常に非効率なものでした。まず、社内の共有サーバーに接続します。リモートデスクトップを利用するのです。そこから特定のディレクトリを辿ります。その日に出力されたテキストファイルを探さなければなりません。それを開いて、一番下までスクロールしました。「Process Finished Successfully」の文字を探します。その文字列が刻まれていることを確認するのです。文字にすれば数分の作業になります。しかし毎朝欠かさずこれを行うのは苦行に近いものがありました。
守衛のログ見回り
特に週明けの月曜日は最悪でした。土日の二日分のログを確認しなければならないからです。もし土曜日にエラーが出ていれば厄介になります。日曜日の分も正しく動いていない可能性が高いからです。タイムスタンプを確認しました。極端にサイズが小さくないかもチェックするのです。そんなアナログな作業を繰り返しました。そのうちに私は自分自身の仕事に疑問を感じ始めます。デジタルな自動化ツールを使っているはずです。なのにやっていることは守衛さんの見回りのような点検作業でした。
VBA・Pythonをもっと本格的に学ぶなら
VBAやPythonを実務レベルまで引き上げたい方には「侍エンジニア」がおすすめです。マンツーマン指導・オーダーメイドカリキュラムで、文系出身でも挫折しにくい環境が整っています。無料カウンセリングだけでも学習ロードマップが明確になります。
PythonとSlack連携、驚きの簡単さ
PythonからSlackにメッセージを送る方法は簡単です。Incoming Webhooksという機能を使います。これはSlackが提供している特定のURLを利用する仕組みです。Python側からテキストデータを送信するだけでした。最初は自分のような素人には敷居が高すぎると身構えていました。プログラミングで外部サービスと連携させるからです。しかし、実際に調べてみて驚きました。驚くほど短い手順で実装できることが分かったのです。
PythonでSlack通知設定
まずSlackの管理画面に入ります。メッセージを投稿したいチャンネルを選びました。そしてWebhook URLを発行するのです。このURLは、言わば「そのチャンネル専用の魔法の電話番号」になります。あとはPython側からデータを送るだけでした。requestsという有名なライブラリを使います。そのURLに向けて処理を実行しました。たった数行のコードを追加したのです。私のプログラムは世界と繋がる力を手に入れました。設定を開始してから時間はかかりませんでした。最初のテストメッセージがスマホに届くまであっという間でした。
設定を始めてから10分ほどで、スマホのSlackに最初の通知が届きました。
requestsでURLに投げるだけなので、書いたコードは5行もありませんでした。
完了」通知の落とし穴
待ち望んでいたSlack通知が届くようになった翌日のことです。私は結局ログファイルを確認していました。リモートデスクトップを立ち上げます。理由はシンプルでした。届いたメッセージが「完了しました」の一言だけだったからです。これを見ただけでは何も判断できません。処理すべき100件のデータが全て処理されたのか分からないのです。処理対象が0件で一瞬で終わったのかも不明でした。
通知が来たことに安心して業務を始めました。すると昼過ぎに営業担当から連絡が入ります。「今日のデータ、1件も更新されていないみたいだけど」と言われました。慌ててログを確認したのです。プログラム自体は正常終了していました。しかし入力元となるファイルが空になっています。そのため実質的な処理が何も行われていませんでした。通知を信じて「終わりました」と言い切ってしまった手前です。平謝りするしかありませんでした。
バッチ処理通知の詳細化と可視化
通知の質を向上させるために、メッセージの内容を見直しました。単なる完了報告ではなく、健康診断結果を含めることにしたのです。バッチ処理の結果を1つのメッセージに凝縮しました。具体的には、処理したデータの総件数を載せます。そのうち成功した件数と失敗した件数も追加しました。さらに全体の実行時間も盛り込むのです。これらの情報を整理するために、ある機能を利用します。Slackの「Block Kit」という機能です。見やすく構造化されたレイアウトを作成しました。
例えば「処理件数：1,250件」という情報があります。そこに「成功 1,248件 / 失敗 2件」と併記しました。この情報があれば、見た瞬間に状況が把握できます。「2件失敗しているけれど、許容範囲内だ」と分かるのです。そうした判断が、Slack上で完結するようになりました。また、実行時間を載せる工夫も効果的です。普段は10分で終わる処理が1時間かかったとします。その場合に「何か異常があったのではないか」と察知できるのです。そのための貴重なヒントにもなりました。
処理件数・成功件数・失敗件数・実行時間・実行日時の5項目を1通に収めました。
tracebackでエラー原因を瞬時特定
情報の整理が進むと、次なる課題が見えてきました。「エラーが起きたときに何をすべきか」というアクションの迅速化です。以前は、エラー通知が届いた後にサーバーへログインしていました。ログファイルを解析して原因を特定していたのです。しかし、Pythonにはtracebackというモジュールがあります。これは非常に便利な機能になります。プログラムがどこで停止したのか分かるのです。どんなエラーによって止まったのかも判明しました。そうした詳細な情報を、文字列として取得できるのです。
私はこの使い道に気づき、バッチが異常終了した際の処理を変えました。そのエラー内容を丸ごとSlackに投稿するようにしたのです。これにより、手元には答え合わせの結果がダイレクトに届きます。「どこが悪いか」という情報がすぐに手に入るようになりました。例えば「データベースのパスワードが間違っています」という内容です。「参照先のファイルが見つかりません」といった原因も分かります。具体的なエラーが、私のデスクに座る前に判明するようになったのです。
上司の質問が消えた朝
Slack通知を本格的に運用し始めてから1ヶ月が過ぎた頃です。その頃、ふと気づいたことがありました。毎朝、私のデスクにやってくる上司がいます。「昨日のバッチ、大丈夫だった？」と聞いていた上司でした。その上司が、全く質問に来なくなったのです。最初は「上司が忙しいだけかな」と考えていました。しかし、そうではないのです。上司もSlackのチャンネルに参加していました。毎朝の整理された通知を自分自身で確認するようになっていたのです。
ある日の午前中、上司と廊下ですれ違いました。「今日の通知、緑色だったから安心したよ」と声をかけられます。「わざわざ聞きに行かなくて済むから助かるね」と言われました。自分が便利になるために始めたことでした。しかし実は周囲の人たちも気を遣っていたのです。私に状況を聞きに行くことを心苦しく思っていました。手間だと感じていたりしたのだと気づかされた瞬間です。
通知過多の教訓
もちろん、すべてが順風満帆だったわけではありません。通知の便利さに味をしめた私は、やりすぎてしまいました。その後、ありとあらゆる処理の節目でメッセージを送るようにしたのです。「ファイルを開きました」「100件処理しました」といった具合でした。「半分終わりました」などと細かく送るのです。その結果、1回のバッチ処理で数十件の通知が飛び交うようになります。Slackのチャンネルはあっという間に未読の山で埋め尽くされました。
良かれと思って細かく通知を送っていました。しかしある日、同僚から指摘を受けます。「通知がうるさくて、大事な連絡が埋もれてしまう」と言われました。そのためミュートにしたと告げられたのです。一番見てほしい、本当に深刻なエラー通知までミュートされました。結局、重大な障害の発見が遅ることになります。「情報は多いほど良い」という思い込みが招いた失敗でした。
報告スリム化の教訓
今は毎朝の完了報告を1通だけにしています。エラーが出た時だけ詳細を送る設計に絞りました。情報を届けることと手間をかけることは別物でした。
通知は、相手の時間をもらう行為です。その1通を見て、何か判断や安心が得られなければノイズになります。自分の場合はその事実を失敗してから学びました。まずは1本だけ送ることから始めて、相手の反応を見ながら少しずつ調整するのが一番マシなやり方だと今は思っています。
関連リンクとチェックリスト
関連記事
Slack Webhookの基本設定から実装コードまでをもう少し丁寧に確認したい場合は、こちらの記事もあわせて読むと流れがつかみやすいです。
学習サービスとアンケート
このスキルを活かしてさらに前へ進むなら
PythonやExcel自動化スキルを持ったまま、ITエンジニアとして転職したい方には「EBAエデュケーション」が選択肢です。企業が求めるエンジニア像に合わせたカリキュラムで、実務直結のスキルを習得できます。
[アンケート] この記事は役に立ちましたか？