はじめに
この記事は、株式会社スピードリンクジャパン Advent Calendar 2025 の7日目の記事です。
タイトルの通り、新人の頃の失敗談をお話します。
どう対応したか、どうすべきだったかなどもまとめていますので、参考になれば幸いです！
やらかしたこと
あれはSESエンジニアとして就職して2年目、初めて行けた開発現場でのことです。
チームメンバー6人くらいで、既存の運用されているツールをExcelからWEBアプリに移行するプロジェクトでした。
各機能で担当が決められていて、まずはローカル環境でコーディング、動作確認をした後、メンバー共通のステージング（検証）環境に反映してテストするという流れです。
そのステージング環境のDBの、1つのテーブルのレコードを、全消ししてしまいました。
なぜそうなったか。
もう記憶が曖昧なのですが確か、（覚えとけ）
SSMS（SQL Serverを操作できるDB管理ツール）でデータの一部を削除したかったんですね。
それでクエリにDELETE文を書いたんですが、
DELETE FROM {テーブル名}
WHERE {カラム名} = 1;
SSMSって、書いたクエリ全体ではなく選択した部分だけで実行することができるんですね。
なので下記のように1行目を選択した状態で実行するとWHERE句は含まれず全データ削除になるんですね。
確かこれをやらかしたんだと思います。（覚えとけ）
どう対応したか
まず、めちゃくちゃ焦りました。
そして最初に考えたことはこうです。
「報告したら評価が下がってしまうかもしれない。無かったことにできないか。」
私は考えました。
まず、機能で役割分担していて、今そのテーブルのデータを見たり触ったりしているのは自分だけなはず。
そして、このテーブルのデータはテストデータで、単純な内容だった。
例えるなら、
社員テーブルがあって、（こちらは消していない）
| id | name | gender |
|---|---|---|
| 1 | 佐藤A太郎 | 男性 |
| 2 | 田中B之介 | 男性 |
| 3 | 山田C子 | 女性 |
| 4 | 吉田D美 | 女性 |
| ... | ... | ... |
社員テーブルの付随情報として好きな食べ物テーブルがあって、こちらだけ消したイメージ。
| employee_id | food |
|---|---|
| 1 | カレー |
| 2 | カレー |
| 3 | オムライス |
| 4 | オムライス |
| ... | ... |
テストデータだったので、男性は全員カレーが好き！女性は全員オムライスが好き！
みたいな状態だったのです！
（めっちゃ偏見みたいな例になってしまった）
...いける。
大量のINSERT文を頑張ってExcelとかで作ってもよかったのですが、
データの量は多かったので一括で復元する方法がないか調べました。
そして辿り着いたのが、SELECT INSERTでした。
テーブルのデータをSELECTで取得しつつ、その結果を利用しながら別のテーブルにINSERTするというものです。
まず、社員テーブルから男性のIDを取得し、カレーで登録します。
その後、女性のIDを取得し、オムライスで登録します。
# 男性だけ復旧
INSERT INTO 好きな食べ物テーブル (employee_id, food)
SELECT id, 'カレー'
FROM 社員テーブル
WHERE gender = '男性';
# 女性だけ復旧
INSERT INTO 好きな食べ物テーブル (employee_id, food)
SELECT id, 'オムライス'
FROM 社員テーブル
WHERE gender = '女性';
はい、これで元通り。
| employee_id | food |
|---|---|
| 1 | カレー |
| 2 | カレー |
| 3 | オムライス |
| 4 | オムライス |
| ... | ... |
CASEを使えば一発で戻すこともできますが、当時そんなことしてなかったような気がします。
いやどうだろう、やったかも。（ここも曖昧なんかい）
INSERT INTO 好きな食べ物テーブル (employee_id, food)
SELECT id,
CASE gender
WHEN '男性' THEN 'カレー'
WHEN '女性' THEN 'オムライス'
END
FROM 社員テーブル;
内心めちゃくちゃ焦っていましたが、別に何もありませんよ？みたいな顔でこのような対応をしました。
結局、この件は誰にも報告せず、指摘されることもありませんでした。
完全犯罪。
どうすべきだったか
私のように隠蔽...ではなく、
やらかしたことが分かった時点で報告しましょう。
この件はまだ限られたメンバーしか触らないDBで、元々手作りのテストデータだったなどもあり問題になりませんでしたが、
新人の頃だと自分は問題なく戻せたつもりでも、
「実は一部不備があった」「実はこういうところにも影響があった」
など考慮不足な可能性が十分にあります。
後からそういったことが発覚し大きな問題になるのが一番よくないです。
それよりは、すぐに上司に相談して対応しましょう。
未然に防ぐためには
1. 実行前に対象を確認
ある程度自由に触っていいデータであれば、事前にSELECT文で対象を確認してから、DELETE文を実行しましょう。
# 対象を確認
SELECT * FROM {テーブル名}
WHERE {カラム名} = 1;
# 対象を削除
DELETE FROM {テーブル名}
WHERE {カラム名} = 1;
2. トランザクションを張る
慎重な作業が必要な場合は、トランザクションを使いましょう。
# トランザクション開始
BEGIN TRANSACTION;
# 対象を確認
SELECT * FROM {テーブル名}
WHERE {カラム名} = 1;
# 対象を削除
DELETE FROM {テーブル名}
WHERE {カラム名} = 1;
# 削除されたか確認
SELECT * FROM {テーブル名}
WHERE {カラム名} = 1;
# 問題なければコミット
COMMIT TRANSACTION;
# 異常があればロールバック
ROLLBACK TRANSACTION;
3. バックアップを取っておく
SQL Serverの場合はSSMSのGUI操作でバックアップが可能です。
- バックアップ時
- SSMS を開く
- 対象データベースを右クリック
- タスク（Tasks） → バックアップ（Back Up...）
- 復元時
- データベースを右クリック
- データベースの復元（Restore Database...）
- デバイスから（From device） を選ぶ
- .bak ファイルを選択
4. 見てもらいながら作業する
自信がない場合は、メンバーや上司にお願いして作業を見てもらいながらやるのも有効だと思います。
もちろん、これらを組み合わせるのもよいと思います。
まとめ
- SELECT INSERTは救世主
- やらかした時は報告しましょう
- こういったミスを未然に防ぐために対策しましょう
- 実行前に対象を確認
- トランザクションを張る
- バックアップを取っておく
- 見てもらいながら作業する
最後まで読んでいただき、ありがとうございました！
少しでもお役に立てれば幸いです！