INSIGHT
一人では動いた。二人が同時に使ったら？——同時更新を確かめる
同時操作でも、守るべき予約や残高の条件が崩れないか。
会議室の予約アプリを一人で試す。空いている時間を選び、保存し、取り消す。どの操作も正しく動いた。ところが二人が同じ時間を開き、ほぼ同時に予約したら、両方に「予約できました」と表示されるのか。一方が先に編集した内容を、もう一方が古い画面から上書きするのか。
これは利用者が増えると画面が遅くなる話ではない。同じ情報へ同じ頃に操作が届いたとき、業務上ひとつであるはずの結果をどう守るかという問題である。
複数人へ広げる前に、二つの操作のどちらを通し、どちらを止め、利用者へ何を返すかを業務の言葉で決める。
同時更新で守りたい結果を、先に一文にする
同時操作への対策を技術の名前から選ぶ前に、起きてはいけない結果を書く。
会議室なら「同じ部屋・同じ時間に有効な予約は一件だけ」。在庫なら「確定後の残数はゼロを下回らない」。顧客メモなら「他の担当者が先に保存した変更を、警告なく消さない」。同じ更新でも、守る結果は違う。
この一文を業務上の不変条件として、業務担当と開発担当が共有する。競合が起きたとき、一方をエラーにするのか、最新状態を見せてやり直してもらうのか、二つの変更を合わせられるのかも決める。どちらの操作を優先するかを、到着順、権限、業務上の優先度のどれで決めるか曖昧にしない。
一人での成功記録は、通常操作の確認として残せる。ただし、不変条件を同時操作で守れた証拠とは分ける。
「最後に保存した方が勝つ」で失うものを見る
二人が同じ顧客メモを開き、Aさんが電話番号を直し、Bさんが配送条件を追記したとする。Bさんの画面が古いまま全体を保存すれば、Aさんの訂正が黙って消えることがある。これを更新の消失として捉えると、単に保存が成功したかでは足りないと分かる。
予約や残数では、二人が同じ「空き1」を読み、それぞれが1件を確定すると、最終結果が業務条件と合わなくなる可能性がある。画面上では二人とも成功に見えても、後で片方を取り消す作業が発生する。
守り方は一つではない。更新前に読んだ版番号が現在も同じか確かめ、違えば保存を止める方法。対象を処理中として他の更新を待たせる方法。データベースの制約で同じ予約を二件成立させない方法。処理を順番に受け付ける方法がある。方式名だけで選ばず、不変条件、利用者の待ち時間、競合時のやり直しを合わせて決める。
保存ボタンが二回成功することより、先に成立した変更を消さず、業務上許さない結果を確定させないことを優先する。
基盤の設定名だけで、競合対策済みにしない
PostgreSQL 18のTransaction Isolation文書 は、同時に動く処理が互いの変更をどう見るかを分離レベルごとに説明している。Read Committedが既定であること、Repeatable ReadやSerializableでは競合によって処理が取り消され、アプリ側が処理全体を再試行する必要がある場合も記載されている。
これはPostgreSQL 18の仕様である。他のデータベース、外部サービス、採用している設定が同じ挙動とは限らない。また、最も強い分離レベルを選べば、業務上の競合が条件なしに解決するという意味でもない。処理が取り消された後に、利用者へ何を見せ、どこから再試行するかはアプリ側の仕事として残る。
まず、実際に使っている保存先と設定を確認する。次に、予約の一意性や版番号の確認がどこで実行されるかを追う。画面側だけで「空き」と確認し、保存時にもう一度条件を確かめていなければ、二人の画面は同じ古い状態を見ているかもしれない。
二つの画面を止めて、同じ瞬間を作る
同時更新の確認では、二人が偶然同時に押すのを待たない。二つの利用者、同じ初期データ、同じ対象を用意し、読み取り後と保存前で処理を止められるようにする。
この操作は、本番の予約や在庫を使わず、検証用のデータで開発・保守担当と行う。利用部門が用意するのは、二人とも予約できてはいけない場面や、消されて困る訂正の例でよい。処理を止める仕掛けまで利用者が自作する必要はない。
予約の例なら、両方の画面で空きを表示する。Aを保存直前で待たせ、Bを先に確定する。その後Aを進め、二件目が拒否されるか、最新状態を示して選び直せるか、最終的な予約が一件かを確認する。順番を入れ替え、同じ結果になるかも試す。
編集の例なら、AとBが別の項目を変えた場合、同じ項目を違う値へ変えた場合を分ける。自動で統合するなら、どの条件なら安全かを決める。統合できないなら、利用者へ競合箇所を示し、再入力や担当への連絡へ進める。
記録には、初期状態、各利用者が読んだ版、操作内容、保存順、画面に返った結果、最終データ、訂正が必要になった場合の担当を残す。処理が失敗したことだけでなく、利用者が次に何をすればよいかまで見る。
利用を広げる条件を、関係者へ渡す
同時更新の結果は、技術担当だけが持たない。業務責任者には、守る不変条件と、競合時にどちらを優先するかを確認してもらう。利用部門には、保存できなかったときの表示と訂正方法を試してもらう。保守担当には、競合記録をどこで確認し、問い合わせを誰へ渡すかを決めてもらう。
確認できていない間は、一件を一人だけが編集する、予約を担当者が確定する、同じ対象を扱う時間帯を分けるなど、競合が起きにくい範囲で使う。利用人数を増やす基準は、同時接続数ではなく、主要な同時操作で不変条件が守られ、競合した利用者が仕事へ戻れた記録があることだ。
次の変更で保存方法やデータベースの設定が変われば、同じ試験をやり直す。競合対策は一度の設定名ではなく、業務上の結果を継続して確かめる仕事になる。
広げる判断は、二人とも成功したかではなく、一方を止める必要がある場面で正しく止まり、利用者が次の操作を選べたかで行う。
二人の操作を重ね、競合した後にやり直せるところまで試す
一人で動いた試作品は、大切な出発点である。複数人で使う前には、同じ対象を同時に読んだ二人が、それぞれの判断で更新する場面を加える。
許さない結果を一文にし、実際の基盤と設定を確認し、二つの操作を意図的に重ねる。競合を完全に見えなくすることより、必要な場面で止め、最新状態を示し、利用者がやり直せることまで確かめれば、関係者は利用を広げる条件を具体的に合意できる。