【ITニュース解説】A reminder can fire while your workflow keeps waiting

システム開発において、特定の時間に何かを実行するよう設定する場面は多くある。例えば、「明日の朝9時にレポートを作成する作業を開始する」といった指示をシステムに出す場合がこれに当たる。しかし、この「指示」が実際にどのレベルまで達成されたと判断できるのかは、実は非常に重要な問題となる。単純にシステムが「通知を送った」だけで満足してはいけないケースが多く、この認識のずれが後々のトラブルにつながることがある。

スケジュールされた処理が、一体何をもって「成功」と見なされるのか、その「約束」を明確にすることが肝要だ。考えられる「約束」は主に三つのレベルに分けられる。一つ目は「通知（Notification）」の約束である。これは最も基本的なもので、単に「作業が期日であることを誰かに知らせる」ことだけを目的とする。例えば、担当者に「レポート作成の時期です」というメールを送ったり、チャットツールにメッセージを投稿したりするような場合だ。この約束が果たされた証拠は、通知システムがメッセージを正常に送信したという記録があれば十分だろう。重要なのは、この通知が送られたからといって、実際の作業が始まったわけではないという点だ。

二つ目の約束は「ワークフローの準備（Workflow Readiness）」である。これは一歩進んで、通知を出すだけでなく、システム全体の一連の作業の流れである「ワークフロー」を、次の作業を開始できる状態にまで進めることを指す。例えば、ワークフロー管理システム上で、あるタスクの状態を「待機中」から「処理可能」へと変更するような場合だ。この約束が果たされた証拠は、ワークフローの状態を管理するデータベースや記録に、意図した状態への遷移が明確に記録されていることである。しかし、ワークフローが準備状態になったとしても、実際の作業がまだ開始されていない可能性も考慮する必要がある。

そして三つ目の約束は「作業の実行・完了（Work Completion）」である。これは最も包括的なレベルで、通知を出し、ワークフローを準備状態にするだけでなく、実際にその作業を実行し、期待される結果を出すところまでを責任範囲とする。例えば、レポート作成の例であれば、実際にレポートが生成され、指定された場所に保存される、といった具体的な成果物が出るところまでだ。この約束が果たされた証拠は、作業が正常に実行されたことを示すログや、生成されたレポートファイルそのものなど、具体的な成果物によって確認される必要がある。

これらの三つの約束はそれぞれ独立しており、上のレベルの約束を果たすには、その手前のレベルの約束も含まれることが多いが、それぞれの成功の証拠は別々に確認すべきである。通知が成功したからといって、ワークフローが進んだり、作業が完了したりしたことにはならないのだ。

この概念をより具体的に理解するために、簡易的なシミュレーションが行われた。これはSQLiteという軽量なデータベースを使い、ワークフローの状態変化を再現するもので、実際の複雑なシステムを動かすことなく、それぞれの段階の境界を明確に示している。シミュレーションでは、一つのワークフローの状態を管理するテーブルを用意し、phase（現在の状態）、notifications（通知回数）、executions（実行回数）という三つの情報を保持する。初期状態は「WAITING」（待機中）であり、通知も実行もされていない状態、つまりnotificationsとexecutionsはそれぞれ0である。

まず、record_notificationという関数が呼ばれると、notificationsの数値が1増えるが、ワークフローのphaseはWAITINGのままであることが示される。これは、「通知を送る」という約束は果たされたが、ワークフロー自体はまだ次の段階に進んでいない、ということを明確に表している。

次に、advance_workflowという関数が呼ばれると、ワークフローのphaseがWAITINGから「READY」（準備完了）に変化する。ただし、この変化はワークフローのphaseがWAITINGである場合にのみ成功する。一度READYになれば、この関数を再度呼び出してもワークフローの状態は変化しない。これは、ワークフローの条件付きの遷移、つまり特定の状態にあるときだけ次の状態に進めるという仕組みを示している。このREADYになった時点でも、executionsは0のままであり、作業が完了したわけではないことを再確認できる。

最後に、record_executionという関数が呼ばれると、ワークフローのphaseがREADYから「DONE」（完了）に変化し、executionsの数値が1増える。これもまた、ワークフローのphaseがREADYである場合にのみ成功する。つまり、WAITINGの状態でこの関数を呼んでも何も起こらない。このシミュレーションは、READYになったとしても、すぐにDONEになるわけではなく、その間に「実際の作業（この例ではレポート生成など）が行われるべきギャップ」が存在することを示唆している。

このシミュレーション結果から、三つの状態「WAITING」「READY」「DONE」がそれぞれ明確に区別され、それぞれの状態変化が独立した操作によって行われることが理解できる。この区別は、実際のシステム設計においても非常に重要となる。

現実のシステムでは、スケジュールされた処理が何を実行するのか、そしてその結果を誰がどのように確認するのかという「統合の契約」を明確にする必要がある。スケジュールされた処理が単に通知を出すだけでよいのか、それともワークフローの状態を変更する責任まで持つのか。ワークフローがREADY状態になったら、それを誰が（どのワーカーやサービスが）受け取って実際に作業を開始するのか。そして「作業が完了した」という判断は、単にデータベースのDONEという状態だけではなく、期待される具体的な成果物（例えば、生成されたレポートファイル）によって検証されなければならない。

この考察は、システム開発者がスケジュールされた処理を設計・実装する際に、次の三つの重要な教訓を心に留めるべきだと教えてくれる。一つは、約束された結果（通知、ワークフローの準備、作業の完了）を具体的に言葉にして明確にすること。二つ目は、その約束が実際に果たされたことを証明する「信頼できる証拠」を、その約束の範囲内で厳密に確認すること。そして三つ目は、ワークフローが準備状態になった時点と、実際に作業が完了した時点の間には、まだ行うべき作業が残っている可能性があるため、この二つの段階を常に区別して考えることである。これらの考え方を持つことで、システム間の連携がより明確になり、システム全体の信頼性が向上し、問題が発生した際の原因究明や対応も格段に容易になるだろう。