Dry Run

ドライランとは、スケジュールされたタスクに完全な実行ロジック——データの読み込み、判断、対外的にどんな動作を取るかの決定——を通らせつつ、本当に結果を生む段階（メール送信、データベースへの書き込み、外部APIの呼び出し）はすべて「記録するだけで実際には実行しない」に置き換え、最後にもしこれが本番の実行だったら何が起きるかを一覧にして見せてくれることを指す。本番実行との違いはただ一つ、実際に外部の世界に触れるかどうかだけだ。これは retry policy や trigger condition が扱う問題の階層とも異なる。あの二つは既に本番稼働しているタスクが失敗やトリガーのタイミングにどう対応すべきかを扱うが、ドライランは本番稼働前の期間を扱い、本当のリスクを負うことなく、ロジック全体が期待どおりに動くかを事前に確認するためのものだ。

この仕組みが必要とされるのは、スケジュールタスクが一度本番稼働すると、誤りの代償が手動操作よりはるかに高くなることが多いからだ。手作業で間違ったメールを一通書いても、送信を押す前に思い直せる。しかしスケジュールタスクにロジックの誤りがあれば、何日も連続して、数百人の受信者に同じ誤りを繰り返し送り続けてしまうかもしれない。誰かが気づいたときには既に被害は出ていて、取り消すのは難しい。ドライランが存在する理由は、「このロジックは本当に正しいか」を検証するタイミングを「本番稼働後に発見する」から「稼働前に完全な結果を見られる」へと前倒しし、実際の結果を負うことなく「このロジックのとおりに実行したら何が起きるか」を先に確認し、明らかな誤りを本番稼働前に食い止められるようにすることにある。

実務では三点を確認して初めて完全なドライランと言える。第一に、ロジックのすべての判断分岐が実際に通っているかを確認する。最も順調な経路だけをテストするのではない。タスクに「金額がある閾値を超えたら特別処理する」という分岐があれば、ドライランはその分岐を本当にトリガーするデータでテストする必要があり、正常なケースのデータで一度実行しただけで終わらせてはならない。第二に、副作用を生む段階がすべて正しく遮断され、実行ではなく記録に置き換えられているかを確認する。メール送信の段階では本当に何も送られていないか、書き込みの段階では本当にデータベースに変更がないかを確認する。この段階自体も検証が必要だ。遮断の仕組み自体に穴があれば、ドライランは「テスト済み」という偽の安心感を与えながら、一部の段階は静かに本当に実行されてしまう。第三に、出力される一覧が十分に具体的で、その一覧を見るだけでロジックが正しいか判断できるかを確認する。一覧には「47人の受信者に送信予定、件名は何々」と書くべきで、単に「メールを送信予定」とだけ書いても、それが本当に求めている結果かを照合するには情報量が足りない。

あなたにとって、ドライランの本当の価値は、「このロジックは正しいか」というデバッグのコストを、実際のデータや実際の受信者に影響を与えた後から、まだ何の結果も生じていない段階へと前倒しできる点にある。ドライランがなければ、スケジュールタスクのロジックの誤りは、事後に誰かが異常に気づいて遡って調査するか（既に代償は発生している）、稼働前に自分でコードをじっと見つめてあらゆる可能性を頭の中で推演するか（境界ケース、特に自分が思いもよらなかった組み合わせを見落としやすい）のどちらかに頼ることになる。ドライランがあれば、このロジックのとおりに実行したら何が送られ、何が書き込まれるかを実際に目で見て確認でき、頭の中の想像で推し量る必要がない。注意すべきは、ドライランが検証するのは「ロジックそのものが正しいか」であって、「このロジックが将来テストされていない状況に遭遇しないか」ではない点だ。本番稼働後はデータの形やデータ量がテスト時と異なる可能性があり、ドライランは稼働後に初めて必要になる retry policy や fallback instruction といった仕組みの代わりにはならない。三つは異なる段階のリスク管理であり、どれか一つだけをやって完全だと思い込んではならない。