開発現場では、テストのためにデータを作成する機会がよくあります。
多くの場合は軽い作業として扱われがちですが、データベースの仕組みを十分に理解していないと、思わぬトラブルを引き起こすことがあります。
今回は、SQLのシーケンスを理解していなかったことで共有テスト環境を不安定な状態にしてしまった経験について振り返ります。
発生した現象
当時、私は動作確認のためにテスト環境でテスト用レコードを作成していました。
方法は、A5:SQLというツールの機能を使って直接レコードを新規作成するというものです。
普段は1つか2つレコードを追加する程度で、しかも自分専用のテスト環境があったため、特に問題になることはありませんでした。
しかし当時の私は、SQLにおける「シーケンス」という概念を理解していませんでした。
テーブルのIDは一意である必要があり、そのために自動採番の仕組みが使われていることを知らなかったのです。
実はこの時点で兆候はありました。
テスト環境で画面からレコード作成を行うと、時々エラー画面に遷移して登録できないことがあったのです。
ただし数回やり直すと成功するため、私はそれを「謎のバグ」と認識して放置していました。
自分はその機能に変更を加えていないため、自分が原因ではないだろうと考えてしまったのです。
その後、開発が進みテスト段階に入った際、共有のテスト環境で約60件のレコードが必要になりました。
しかも10件刻みのデータが必要で、境界値チェックも行う必要があったため、私はツールを使って手作業でレコードを作成しました。
すると、その操作によってシーケンスが大きくずれてしまい、アプリケーション側の通常処理が正常に動作しなくなってしまいました。正確には、約60回ほど通常の登録処理を実行すればシーケンスが追いつき、元の状態に戻るという状況でした。
この異常に気づいた上長が調査を行い、原因が私の作成したレコードであることが判明しました。その後、注意と指導を受けることになり、非常に恥ずかしい思いをしたのを覚えています。
幸いにも、本番環境やリリースには影響がなく、比較的短時間で原因が特定できたことが救いでした。
原因
原因は大きく二つありました。
一つ目は、SQLの仕様を十分に理解していなかったことです。
シーケンスの仕組みを知らないままツールで直接レコードを追加したことで、自動採番の状態とテーブルの実データにズレが発生してしまいました。
二つ目は、「謎のバグ」を放置してしまったことです。
エラーが発生している時点で何らかの異常が起きている可能性があったにもかかわらず、深く調査せずに見過ごしてしまいました。
対策
この出来事をきっかけに、SQLのシーケンスについて改めて調査し、データベースの仕様を理解するようにしました。
また、テスト用レコードが必要な場合は、アプリケーションの通常画面から正規の手順で作成するか、SQLのINSERT文を明示的に実行するように運用を見直しました。
これにより、自動採番との整合性を保ったままデータを作成できるようになりました。
結論
チーム内で相談した結果、レコード数が少ない場合はアプリケーションの正規手順で作成し、大量のデータが必要な場合はSQLのINSERT文を使用するというルールになりました。
それ以降、シーケンスのズレが原因となる同様の問題は発生していません。
また、この経験をきっかけに「よく分からない現象」を放置せず、どんなに小さなことでもチームに共有するようになりました。
結果として、学びの機会が増え、チームに迷惑をかけるようなトラブルも減ったと感じています。
学んだこと
今回の出来事で最も強く感じたのは、「小さな違和感を放置してはいけない」ということです。
目先のタスクに直接関係ないからといって問題を無視してしまうと、後でより大きな形で問題が表面化する可能性があります。
仮に自分で調査や修正を行わなかったとしても、まずはチームに共有することが重要です。
そうすれば、その問題が自分だけに発生しているものなのか、それとも環境全体の問題なのかを判断することができます。
また、チームとしてどのように対応すべきかも議論できるでしょう。
最終的には自分の知識不足が原因でしたが、それ以上に反省したのは、自己判断で問題を無視してしまったことです。
ソフトウェア開発は個人ではなく、チームで行うものです。
この経験を通して、「困ったらまず共有する」という基本の大切さを改めて実感しました。
今では、小さな違和感こそ早めに相談することを心がけています。
それが結果としてチーム全体の品質を守ることにつながると考えているからです。
