…いや、実際に「やっている」という話ではないのですが。
今、とあるシステムの移行を進めているのですが、「人力作業用」の手順書が…すでに4～5テイク目というのに、出るわ出るわ、もりもりと。
といっても、Gitの「うんこもりもり」ではなくて…未だに致命的な手順の間違いがもりもり出てきます。
作っている当人は「ちゃんと見直して間違いがないことを確認しました！」と言ってましたが（私が「本当に大丈夫だよね？」と煽ったので半ばキレながら…）、作業1項目めから既にタイポがいくつか。
…ああ、頭がくらくらする。
人がすることなので、「実際にその手順書に沿って手を動かしてみないと本当に手順通り実行できるかどうかわからない」のは、ある程度仕方がないのですが。
というわけで、やっぱり「システム移行のような『一度しか本番利用しない』作業もコード化する」のが1つの解なのかな、と思います。
デバッグは大変ですが、一度完全に動いてしまえばケアレスミスで失敗する確率もかなり低くなりますし、「作業本番になって初めて手順のミスに気付いて詰む」ということもなくて、精神衛生上よろしいかと。
エラーリカバリとかが考えられていなかったり雑だったりすると、コードが止まった時にかえって焦る可能性もありますが、「事前にデバッグできる」というのは大きな強みです。
もちろん、人力でも、大事な作業の前にはリハーサルをして手順書の問題点を可能な限り洗い出すのですが…それでも、本番と心理状態は違う上に、一度通すのにそれなりの時間と負荷がかかりますし、そこで出た指摘が全て修正されずに間違いが残ってしまう可能性もあります。
実際、今回、目視チェックの4～5テイク目でも、以前指摘した事項が修正されずにそのままいくつか目の前にやってきましたから…。
そういえば、はてなのMackerelでも、少し前にシステム移行で障害を発生させていましたね…。
我々のような弱小（ザコ）部隊ではなくプロがそろった現場でもこうなる（こともある）ので、相当気を引き締めて実行しないと。
※話はそれますが、こうやって「事故」を詳細に報告してもらえるのはありがたいです。最近メルカリのCDN絡みの事故がありましたが、他社からのものも含めて、このような情報がミスや勘違いの発見・防止にすごく役立っています。
とかくシステム移行は「移行がゴール」という気持ちで、移行直前は駆け込みでタスクを「淡々とこなす」「やっつける」となりがちですが、本当は「移行がスタート」なので、移行準備の間に知見を蓄えてサービスインするぐらいの気持ちでないと、移行後に地獄が待っていることもあります（数年前、実際に「事件」が起きてロールバックしましたが）。
