ドライランとは何か、通常のテストとどう違うのか？
ドライランとは、自動化フローを実際のデータや実際の動作に本格適用する前に、フローの完全なロジックを一度実行するが、「実際に動作を実行する」という最後のステップで遮断し、実際には発生させないことを指す。例えばバッチメール送信の自動化フローでは、ドライランは実際の受信者リストを普段通り読み込み、各自がどのメールを受け取るべきか普段通り判断するが、最後に実際には送信せず、「今回誰に何を送信するか」のリストを生成する。実際に送信する前にこのリストが妥当か確認できる。
通常のテストとの最大の違いは、ドライランが実際のデータと実際のトリガー条件を使い、副作用を生む最後の動作だけを遮断し、他のすべてのロジックは本番フローと同じように実行される点だ。通常のテストは架空の簡略化されたテストデータを使うことが多く、実際の状況とずれが生じることがある。ドライランは実際のデータを使うため、このフローが実際の状況下で予期しないことをしないかをより正確に暴き出せる。
ドライランにはどんな限界があり、最も見落とされやすいのはどれか？
最も見落とされやすいのは、遮断層をどのステップに設けるかが重要で、早すぎると後半のロジックをテストできないことだ。ドライランがフローの最初の段階で遮断してしまうと、トリガー条件が正しいかしか確認できず、その後の誰に何をすべきかを判断するロジックは全く検証されない。このようなドライランは実は最もエラーが起きやすい部分をテストできていない。遮断層はできるだけ最後のステップに設け、フローがほぼすべてのロジック判断を経てから、実際に副作用が発生する瞬間にだけ遮断すべきである。
2つ目に見落とされやすい限界は、ドライランの「エラーが出たか」だけを見るのでは不十分で、生成された「実行される動作のリスト」の内容自体が妥当かを注意深く見る必要があることだ。ドライランがエラーを出さないことは、ロジック設計が正しいことを意味しない。ロジック自体に問題があれば、例えば通知を受け取るべきでない人までリストに含めてしまっても、技術的にはエラーが起きていないためフロー実行時にエラーメッセージは全く出ない。この種の問題はリストの内容を注意深く確認して初めて見つけられる。
どのような場合にドライランを使うべきで、どのような場合には不要なのか？
核心となる判断基準は、その自動化フローが大量のデータに関わるか、または簡単に元に戻せない副作用のある動作を伴うかどうかである。数千人の顧客へのバッチ通知メール送信、データベース内の大量レコードのバッチ変更、バッチ課金処理といったフローは、一度誤りが起きると影響範囲が広く復旧コストが高い。ドライランは実際に実行する前に完全な動作リストを見られ、問題を発生前に食い止められる。
不要なのは、フロー自体がシンプルで影響範囲が小さく、簡単に元に戻せる場合である。単一のテストデータを更新するだけ、または動作自体に副作用がない場合、誤りのコストは非常に低く、ドライランの仕組みを設計する余分な労力はかえって不要なエンジニアリング負担になる。簡単な判断法は、このフローが誤って動作した場合、復旧にどれだけの労力がかかるかを自問することだ。復旧コストが高ければドライランを使うべきで、復旧コストが低ければ不要である。
上級者はドライランをどう設計すれば、本当にロジックの問題を見つけられるか？
上級者の要点は、ドライランの出力リストを、明らかな異常がないかざっと見るだけでなく、サンプリングチェックと主要指標チェックの両方を組み合わせて見ることだ。サンプリングチェックはランダムに数件の結果を選び、人手でロジックが正しいか確認する。主要指標チェックはリスト全体の総数や分類比率などの数字を集計し、期待値と一致するか確認する。例えば今回は約200人の顧客が条件に合致し通知を受け取るはずだが、ドライラン結果では50人しか表示されていないといった規模の食い違いは、1件ずつのサンプリングより体系的なロジックの誤りを発見しやすいことが多い。
もう一つの上級テクニックは、ドライランの遮断メカニズムを再利用可能な固定モジュールとして設計することで、自動化フローごとに毎回遮断ロジックを設計し直さないことだ。具体的には、統一した環境変数や設定スイッチで今回はドライランか本番実行かを制御し、実際に副作用を生むすべての動作がまずこのスイッチを確認するようにする。ドライランモードでは常にプレビューリストの生成に誘導し実行しない。こうすれば新しい自動化フローを追加する際、毎回ドライランのロジックを設計し直す必要がない。
月次で資格のある会員に契約更新のリマインダーメールを自動送信し、データベースに送信済みとマークする自動化フローを設計したとする。初めて本番適用する前にドライランを一度実行した。フローは全会員データを普段通り読み込み、誰が更新リマインダーの資格を持つか普段通り判断したが、最後のステップでは実際には送信せずリストを生成した。リストを確認すると、合計850人の会員がリストアップされていたが、もともと今月は約300人程度が対象になると見積もっていた。約3倍もの差があった。ロジックを見直すと、資格判定条件が間違って書かれていたことが判明した。契約満了日が今後30日以内とすべきところを契約満了日が過去30日以内と誤って書いてしまい、すでに契約が切れておりリマインダーを受け取るべきでない大量の会員を拾ってしまっていた。ドライランがあったおかげで、このロジックの誤りは実際に送信する前に発見され修正され、850通のメールが誤った受信者に実際に送られることはなかった。実務上の要点は、大量のデータをバッチ処理する自動化フローについて、ドライラン結果の総数や比率が妥当かをまず確認する習慣をつけることが、1件ずつのサンプリングチェックより体系的なロジックの誤りを素早く見つけられることが多いということだ。
ドライラン最大の利点は、実際の副作用が発生する前に実データでロジック全体の連鎖が正しいか検証できることで、特に大量のデータが絡む、または元に戻しにくい動作を伴うフローでは、この保護の価値が非常に高い。代償は遮断メカニズムを追加で設計する必要があり、ドライラン結果のリスト内容を確認する時間もかかることで、動作がシンプルで元に戻しやすいフローにとっては不要な負担になる。適するのは、大量のデータが絡む、または副作用のある動作で復旧コストが高い場合である。設計に労力をかける価値がないのは、動作がシンプルで影響範囲が小さく元に戻しやすい場合である。