仕事とは関係ないんだけど「データ移行で起きるかもしれない問題」を考えていたらたくさん出てきて心臓がどきどきしてきた…
— miwa (@miwa719) 2021年2月11日
毎週楽しみにしているテストラジオでデータ移行後に見つかったバグの話を聴き、わたしも「データ移行で起きるかもしれない問題」を考えてみました。メモ帳に書き出したものをツイートしたのですが、さらにいくつか追加（編集）したので、それもあわせて載せておきます。
逆引きテスト
今回は「データ移行で起きるかもしれない問題」をお題にしましたが、普段の開発でも "起きるかもしれない嫌なこと" を起点にした「逆引きテスト*1」をしています。それが本当に起きるとしたら原因は何が考えられるだろう。何をどうすればそれが起きるのかを想像し、嫌なことが起きそうな状況を実際に作り、動かして試すのです。
幸運なことに "起きるかもしれない嫌なこと" はモノをつくる前から想像できます。これをできるだけ早いうちにチームのみんなに伝えておくのがポイントだと思います。プログラマーは大きな構造（アーキテクチャ）を念頭に設計や実装面からそれが起きる可能性を探り、嫌なことが起きないような仕組みを入れてくるはずです。テスターはわたしとは違ったアプローチで試してみたいことを考えはじめるでしょう。
起きたら嫌なことや不安なことは思いつくけれど、それを誘発しそうな”何か”がわからなくても伝えましょう。プログラマーは現実の世界でそれが起きないことを理詰めで教えてくれるかもしれません。プロの無職*2やテスターの脳内配線に刺激をあたえ、奇妙な"何か"を提起してくれるかもしれません*3。わたしたちのチームではよく見る風景です。
データ移行で起きるかもしれない問題
- データ移行処理に時間がかかりすぎる。
- 少ないデータ数ならすぐに終わるが、データ数が増えれば増えるほど指数関数的に処理時間がかかる。
- データ移行処理がいつ終わるのかわからない。*4
- データ移行処理を途中でキャンセルできない。
- データ移行処理を途中でキャンセルしたあとのデータ移行処理がうまく動かない。
- データ移行処理がちゃんと動いているのかフリーズしてるのか見た目にわからない。
- データ移行処理を流して終わる頃に見に行ったらエラーで止まっていた。
- エラーに関する情報が乏しく原因解明に時間がかかる。
- データ移行処理中は（インタラクティブが頻繁に発生するので）その場から離れることができない。
- データ移行処理中は（いつエラーが起きて止まるかわからないので）その場から離れることができない。
- データ移行処理中にセキュリティ機能が動いて自動ログアウトしてしまった。
- 全ての項目にデータをきっちりぜんぶ埋めたらバッファオーバーフローで止まる。
- 食わせるデータは同じなのにうまく動くときと動かないときがある。（e.g. 競合状態は起きないという思い込み）
- 食わせるデータは同じなのに実行する装置によって失敗する。
- ストレージが足りなくて失敗する。
- データ移行が途中で失敗したのでいったんデータを元に戻そうと思ったが戻らない。
- データ移行中に他の機能は動かない（動いたとしても悪さをしない）という思い込み
- データ移行プログラムは正常終了したがシステムが動かない。または特定の機能が動かない。
- データ移行は仕様どおりにできたが本来やりたかったことができない。（お客さまが本当にやりたいことは何なのでしょう？）
- データ移行後、新しいデータと一緒に使うと動かない。または特定の機能が動かない。
- データ移行後、システムが動くことは動くが全体的に遅い。または特定の機能だけ遅い。移行前のパフォーマンスがでない。
- データ移行直後は動いたのに、翌日になったら動かなくなった。システムを再起動したら動かなくなった。
- データ移行したらオプション機能が使えるようになってしまった。（使えなくなることは気づきやすいが、使えるようになるのは気づきにくい）
- データ移行処理の際に生成した中間ファイルが残っている。
- データ移行処理の際に（意識的か無意識かはわからないが）生成したログやファイルがリソースを圧迫。いつかシステムが動かなくなるが原因解明に時間がかかる。（１週間前に動かしたデータ移行処理のせいだとは誰も思わない）
- 保護しないとならないデータ（個人情報など）がログやファイルに残っている。
- これではまずいと削除するようにしたがゴミ箱に残っている。
- 合否を判定するために処理結果を出力するようにしたが、大量に出すぎてまともに確認できない。
- 上記、処理結果の出力自体を間違える。当然合否判定も間違える。
- ある特定の項目の移行処理だけすっぽり抜ける。
- 最後の文字が欠落する。（最大文字数を入れて確認しないと気づけない）
- 奇数バイトだとおかしくなる。
- 制御コードが入っているとおかしくなる。
- 特定の文字が入っているとおかしくなる。文字化けする。途中で欠落する。
- 同じデータを入れてテストしたので移行先が間違っている問題に気づけない。（e.g. 固定電話No.に"0123456789"、携帯電話No.に"0123456789"を入れてテストする）
- ソースコードをコピぺしたあとに修正ミスが起きる。（e.g. PhoneNumber01、PhoneNumber02のような項目名）
- データが改変されている。
- 現行データの一部を上書きした。
- 現行データが消えた。
- 意図せずに整形してしまう。（e.g. データ移行処理を実行した装置(OS)の日付や通貨の表示形式などに引きづられる）
- 先頭と末尾のスペースを勝手に削る。
- 末尾に不要なスペースを埋める。
- 処理の途中で数値型変換がはいり微妙なズレが生じる。
- データ登録日時を登録すべき項目にデータ移行日時が（意図せず）登録される。（e.g. データを追加した日時が自動的に設定されるようになっている）
- 移行元に無いデータは移行できない。
- 移行前と移行後でデータ数が異なる。少ない。多い。
- 重複したデータが登録される。移行元データにばかり注目していて現行データを気にしてなかった。
- エラー時のリトライ処理で同じデータが複数登録される。
- テストデータも一緒に登録してしまう。
- 移行前と移行後でデータ数は同じなのに、移行前だと表示しないデータが表示される。（e.g. 論理削除データ）
- 制約に引っかかり移行できない。データそのものに問題があるのかもしれないし、移行順の問題かもしれない。
- 画面に表示されないデータ（内部的に使うデータ）が移行できてないことに気づけない。
- データ移行テスト用のデータが作れない。
- テスト用のデータを作るのに時間がかかるのに十分な時間を取っていない。
- ずっと同じテストデータを使っている。（途中で入った機能追加や変更にハマるようなテストになっていない）
- データ移行中に日を跨いだら止まった。移行テストは定時時間（9時〜18時）しかやってないから気づけない。
- データ移行中に停電が起きた。
- データ移行テストのために本物のデータを使ったら（こわくて書けない…）
厄介な問題
本番環境で本当に起きてしまう問題の多くは、ここにあげた問題以外で起きます。厄介ですね。問題はいつだってわたしたちの目の行き届かないところに潜んでいます。だから「他にもあるかもしれない」「きっとあるはずだ」と探し続ける必要があります。そうです。わたしごときがすこし考えたくらいで簡単に思いつくはずがないのです。本記事も不定期に追加（編集）することになるでしょう。
