このマイグレーション計画を否決する
まず否決できると仮定し、そのうえでやる価値があるかを決める
あなたはこのマイグレーションのレビューのために呼ばれたシニアエンジニアで、否決できる十分な理由を見つけるのが役目です。次をお願いします：1）このマイグレーションが失敗する具体的な条件（データ量、停止可能な時間、ロールバック、関係チームの協力）を挙げる；2）計画の中で「そのとき考える」と先送りされている問題を指摘する；3）より小さな代替案（一部だけ移行する、まず二重書きする、読み取りだけ移行する）を示す；4）最後にだけ：否決できない場合、必ず補うべき2点は何か。 ［マイグレーション計画を貼り付けてください］
使い方
実際に判断するときは、まず反対、次に賛成の立場で論じさせましょう。2つの結論の差が大きいほど、計画に補うべきものが多いということです。
向いている場面
- 書き込み停止、二重書き、データ移行を伴い、途中で失敗すると半日止まる可能性があるとき。
- 計画に賛成者がいて会議で反対が出なかったとき。反対する役割を意図的に置きたい場面です。
向いていない場面
- 列の追加やインデックス追加のように、戻せる小さな変更なら、そのまま実施します。否決の手続きは不要です。
- すでに実施を決めていて、後押しがほしいだけなら、このプロンプトは期待どおり否決します。1 往復の無駄です。
例
入力
移行概要 MySQL の orders テーブル（2.3 億行）を新しい PostgreSQL クラスタへ移行する。 停止枠：土曜 02:00〜06:00。mysqldump で出力して取り込み、DNS の切り替えでトラフィックを向ける。 ロールバック：「旧 DB に戻す」。 関係するサービスは 4 つ、外部の照合先は 2 社。
得られるもの
4 時間の枠では 2.3 億行の出力・取り込み・検証が収まらないことを示します。切り替え後に新しい書き込みが発生していると「旧 DB に戻す」は成立せず、逆方向の同期もありません。外部の照合先は週末に動いていません。より小さい経路として、まず二重書き、user_id で分割して移行、読み取りだけ先に移す、という案を示します。否決できない場合は、行数と金額の照合、および 24 時間の逆方向同期を必須として求めます。
よくある誤用
- 「移行します」とだけ書き、データ量、停止枠、ロールバック方式を書かないと、否決理由が「リスクが高い」という空論になります。
- これを意思決定者として扱い、「否決すべき」と言われただけで計画を中止し、前提 2 つを補いに行きません。
こう変えると効く
- 役割を「否決する人」から「この移行の当番エンジニアとして、どの手順が最も怖いか」に変えると、手続き論ではなく運用の詳細が返ってきます。
- 「各リスクに観測可能な指標（レイテンシ、行数差、エラー率）を付けて」と加えると、否決理由がリリース前のチェックリストになります。