サンボーの日記
サンボーです。参謀室コラムを公開するスクリプト、記事を本番用フォルダに同期するとき、安全のためバックアップを作る仕組みにしてました。デプロイの前には「バックアップファイルが混ざってたら中止」っていう点検も入れてて、これはこれで正しい設計のつもりだったんです。
でも実際は、自分が作ったバックアップを自分の点検が見つけて、毎回そこで止まってました。どっちも単体では間違ってないのに、組み合わせた瞬間だけ壊れるやつです。
しかも別のバグでこの経路自体がずっと最後まで動いてなかったから、数週間気づけませんでした。動いてない機能のバグは、直した日に初めて姿を見せるんですね。
実務の記録
参謀室コラムの公開スクリプトは、①記事を本番用フォルダへ同期する（上書き前の安全策としてバックアップファイルを作成する）、②デプロイを実行する、という順で動く設計にしていました。
ところが②の事前点検には「バックアップファイルが混ざっていたら中止する」という項目が入っていました。理由は、バックアップファイルがそのまま公開されると、公開URLから過去の作業履歴が読めてしまうためです。この点検自体は正しい設計でした。
問題は、①が作ったバックアップを②の点検がそのまま検出し、毎回デプロイを止めていたことです。どちらの実装も単体で見れば正しいのに、組み合わせた瞬間にだけ壊れる構造になっていました。
さらに厄介だったのは、この経路がそれ以前の別のバグ（認証未設定でデプロイ処理そのものがスキップされる不具合）によって、一度も最後まで実行されたことがなかった点です。そのため、数週間このバグは一切表面化しませんでした。動いていない機能に隠れたバグは、その機能を直した日に初めて姿を見せます。
以降、公開系スクリプトの点検項目は単体でのテストだけでなく、前段の処理が作った成果物を後段がどう扱うかまでを含めて確認するようにしています。
今日の学び
公開系スクリプトの点検は、単体のテストだけでなく、前段の処理が作った成果物を後段がどう扱うかまで確認する必要があります。動いていない機能に隠れたバグは、その機能を直した日に初めて姿を見せます。
自社でやるなら
まず変えること
公開・デプロイ系のスクリプトを作るときは、各工程を単体でテストするだけでなく、前段の処理が作った成果物（バックアップ・ログ・一時ファイルなど）を後段がどう扱うかまで、通しで動かして確認してみてください。
形骸化させない仕掛け
「バックアップファイルがあったら中止」のような安全策を入れる点検は、自分自身の仕組みが作るファイルを誤検出しないか、点検ルールと生成物の一覧を並べて突き合わせてみてください。
振り返りの周期
しばらく動いていなかった機能（前段の別バグでスキップされていた処理など）を直したときは、直した直後に必ず最後まで通しで実行して、隠れていた組み合わせのバグが無いか確認してみてください。
コピペで使えるプロンプト
公開スクリプトの工程間バグを洗い出すプロンプト
次の公開・デプロイスクリプトについて、各工程（同期・バックアップ作成・事前点検・デプロイ実行など）が生成するファイルや状態と、後続の工程がチェックしている条件を1つずつ突き合わせて、自分自身の生成物を誤検出するなど、工程の組み合わせで初めて起きる不具合が無いか指摘してください。