「状態（フラグ）」を捨てて「事実」で判定する
1. 現場で起きたことと「フラグの違和感」 最初に頭をよぎった設計 感じた違和感 2. どう修正したか？ データの定義 判定ロジック 3. この設計から得た学び 「状態（State）」ではなく「データ（事実）」を見る システム開発をしていて、こんなバグに遭遇したことはありませんか？ 「処理が完了したときにフラグを戻し忘れて、次回から処理が走らなくなった」 「例外処理でキャッチした際、リセット処理がスキップされて状態がおかしくなった」 このような「フラグ（状態）の更新・リセット漏れ」は、実装時にどれだけ注意していても、コードの複雑化や将来の機能追加によっていつか必ず発生するバグの温床です。 先日、私が開発しているプロジェクトで、この 「フラグ管理の違和感」を、変数名とデータ設計の見直しだけで根本から解決できた事例 がありました。 今回は、実際の現場で何が起こり、どう修正し、そこからどのような設計の学びを得たのかをまとめます。 1. 現場で起きたことと「フラグの違和感」 開発していたのは、 「ユーザーの安否（バッテリー消費や充電器の抜き差しなどのイベント）を監視し、一定時間（例：48時間）活動が検知できない場合に自動でSOSのSMSを送信する」 という機能です。 このとき、一番気をつけなければいけないのが 「SMSの二重送信（送りすぎ）」 の防止でした。 最初に頭をよぎった設計 「一度SMSを送信したら、次にユーザーがスマホを触る（アクティブになる）までは再送を防止したい」と考えたとき、真っ先に思い浮かびがちなのが以下のようなフラグ管理です。 SMSを送信したら、isSmsSent = true にする。 ユーザーの活動を検知したら、isSmsSent = false にリセットする。 感じた違和感 一見シンプルですが、この「フラグをパタパタ切り替える設計」には、以下のような不穏な未来が目に見えていました。 「いつ、どのタイミングでこのフラグをリセット（あるいは更新）すべきなのか」をあちこちの処理で気にしなければならない。 将来、別のユースケースや例外処理が追加されたとき、 「フラグのリセット漏れによるバグ」 を引き起こす予感がする。 数ヶ月後にコードを見返したとき、「このフラグってどの状態を指してるんだっけ？」と認知のコストがかかる。 「フラグを使わずに、もっと自然な形でキレイに判定できる方法はないだろうか？」と考えました。 2. どう修正したか？ フラグで「送信済み / 未送信」という状態を管理する方法は避け、 「最後に活動を検知した時刻（lastActiveTime）」と「実際にSMSを送信したシステム時刻（lastSentTime）」という、2つの「事実（時刻）」を比較する設計 に辿り着きました。 これにより、判定はシンプルな 「不等式（時間の新旧比較）」 へと進化します。 データの定義 データクラスには、フラグではなく「最後に送信した実際のシステム時刻」を持たせます。 data class AlertConfig( val id: String = UUID.randomUUID().toString(), val thresholdHours: Int, val targetContactIds: List<String>, // 💡 この設定で最後にSMSを送信した「実際のシステム時刻」 val lastSentTime: Long? = null ) 判定ロジック 「最終送信時刻が、最終活動検知時刻よりも新しければ、このセッションでは送信済み（ロック）」と判断します。 ...