ビルド・デプロイ手順が失われたシステムを復元する5ステップ
改修の依頼が来て、コードの修正はなんとか終わった。さあ本番へ……と思ったところで手が止まる。 「これ、どうやって本番に出すんだっけ？」 前任者はFTPでファイルを上げていたのか、サーバーの上でビルドしていたのか。リポジトリを見てもREADMEは数行だけ、手順書はどこにもない——。そんな場面、ありませんか。
ここは、引き継いだシステムでとても迷いやすいところです。誰かが手を抜いたというより、「いつも同じ人がやっていたから、書く必要がなかった」だけ、ということがほとんどです。
この記事では、失われたビルド・デプロイ手順を、本番サーバーに残っている手がかりから逆算して復元する進め方を、一緒に順番に見ていきます。
結論：手順は「消えた」のではなく、本番サーバーの中に“結果”として残っています。①本番の今をまるごと保存する → ②本番に「何が・どこに・どんな形で」置かれているかを観察する → ③ビルドの入口（設定ファイル・スクリプト・履歴）を探す → ④検証環境で作り直して、本番と差分を比べる → ⑤手順書に書き、次のリリースで実際に使って直す。この5ステップで、少しずつ取り戻せます。
一度で完璧な手順書にしなくて大丈夫です。今日は①と②だけでも、十分に前へ進んでいます。
何が起きているか：手順はどこに消えたのか
ビルド・デプロイ手順が見つからないとき、たいていは次のどこかに「あった」はずのものです。
- 前任者の頭の中：毎回同じ人が作業していて、体が覚えていた。
- 前任者のパソコンの中：手元でビルドして、できたファイルだけをサーバーに上げていた。パソコンの返却と一緒に、ビルド環境も消えた。
- 止まったCIサーバーや退役した仕組みの中：昔は自動ビルドの仕組みがあったが、契約終了やサーバー整理で止まったまま。
- サーバーの片隅：ホームディレクトリに置かれたシェルスクリプトや、コマンドの履歴として、ひっそり残っている。
つまり、手がかりはゼロではありません。そして何より、本番サーバーには「手順を実行した結果」が今も動いています。ここが、復元のいちばんの出発点になります。
ビルド・デプロイ手順を復元する5ステップ
① 本番の「今」をまるごと保存する
最初にやるのは、調べることではなく守ることです。復元の途中で本番を壊してしまわないよう、今動いている状態をそのまま残します。
- 公開ディレクトリ（ドキュメントルート）を丸ごとアーカイブして、本番とは別の場所に保存する。
- 設定ファイル（Webサーバー・アプリの設定・環境変数を置いたファイル）もあわせて保存する。
- 保存した日時と、どのサーバーのどのパスから取ったかをメモしておく。
この保存物は、あとで④の「答え合わせ」に使う正解データになります。同時に、手順を復元できなかったときに今の状態へ戻すための命綱でもあります。バックアップの取り方に迷ったら、本番反映前のバックアップとチェックリストも参考にしてください。
② 本番に「何が・どこに・どんな形で」あるかを観察する
次に、保存した本番の中身を眺めて、どんな形で配置されているかを読み取ります。ここで、元の手順のかなりの部分が見えてきます。
- ソースのまま置かれているか、ビルド後の成果物か：たとえばJavaScriptが1行に詰め込まれた（圧縮された）ファイルなら、どこかでビルドしてから置いている、と分かります。
- 依存ライブラリの置き場所：
vendor/やnode_modules/が本番にあるなら、サーバー上でインストールしたか、手元から一緒に上げたかのどちらかです。 - ファイルの更新日時と所有者：最後のリリースで、どのファイルがいつ、どのユーザーで書き換わったか。まとめて同じ時刻なら一括で上げた、ばらばらなら1ファイルずつ上げていた、という推測ができます。
- シンボリックリンクやリリースごとのディレクトリ：
releases/日付/のようなディレクトリと、それを指すcurrentのようなリンクがあれば、ディレクトリを切り替える方式のデプロイだった可能性が高いです。
ここで分かったことは、推測のままでかまわないので、「〜らしい」と書き残しておきましょう。
③ ビルドの入口を探す
次は、ビルドやデプロイの“入口”になりそうなものを探します。リポジトリ・本番サーバー・前任者のアカウントのホームディレクトリを順に見ていきます。
- 依存とビルドの設定ファイル：
package.json（scriptsにbuildなどが書かれていることが多い）、composer.json、Makefile、pom.xml・build.gradle、Dockerfileなど。 - ロックファイル：
package-lock.jsonやcomposer.lockがあれば、当時入っていたライブラリのバージョンがそこに記録されています。復元ではとても心強い手がかりです。 - ランタイムのバージョン指定：
.nvmrc、.node-version、package.jsonのengines、composer.jsonのrequireに書かれたPHPのバージョンなど。 - CIの設定：
.github/workflows/、.gitlab-ci.yml、Jenkinsfileなどが残っていれば、手順そのものが書かれていることもあります。 - スクリプトと履歴：
deploy.shのような名前のファイル、cronの設定、シェルのコマンド履歴（~/.bash_historyなど）。rsyncやscp、git pullの行が見つかれば、どうやって置いていたかの答えにかなり近づきます。
ひとつ気をつけたいのが、コマンド履歴や古いスクリプトにはパスワードやAPIキーがそのまま書かれていることがある点です。見つけたものを手順書やチャットにそのまま貼らず、秘密の部分は伏せて扱いましょう（扱い方はパスワード・APIキーを平文で置かないための見直しにまとめています）。
④ 検証環境で作り直して、本番と差分を比べる
手がかりがそろったら、本番ではない場所で実際にビルドしてみます。ここがいちばん大事な「答え合わせ」のステップです。
- 検証環境（または手元）に、③で分かったバージョンのランタイムを用意する。
- 本番に出ているのと同じコミット（分からなければ、いちばん近そうなもの）を取り出す。
- ロックファイルどおりに依存をインストールする（Node.jsなら
npm ciのように、ロックファイルに合わせて入れるコマンドを使う）。 - 見つけたビルドコマンドを実行する。
- できあがったものと、①で保存した本番のファイルを比べる（
diff -rでディレクトリごと比べる、sha256sumでファイルごとのハッシュを並べる、など）。
圧縮されたファイルは、ビルドツールのバージョンが少し違うだけで中身がずれることがあり、完全一致しなくても失敗ではありません。見るべきは「ずれがどこに、どのくらいあるか」です。差分の読み方は本番だけで起きる不具合の差分調査の考え方がそのまま使えます。
そして、差分の中には大事な発見が混ざっていることがあります。リポジトリにはない、本番で直接書き換えられたファイルです。これを見落としたままデプロイすると、過去の修正を上書きして消してしまいます。見つけたら、まずリポジトリに取り込んでから先へ進みましょう。
⑤ 手順書に書き、次のリリースで使って直す
最後に、分かったことを手順書にします。最初はメモに近くて大丈夫です。
- 必要なもの（ランタイムのバージョン、必要なアカウント、作業する場所）
- ビルドのコマンドと、その順番
- 本番への置き方（どのサーバーの、どのパスへ、どの方法で）
- 置いたあとにやること（キャッシュのクリア、プロセスの再起動など）
- 戻し方（①で保存したものを使って戻す手順）
- 「まだ分からないこと」の一覧
そして、次のリリースでは、その手順書を見ながら作業し、詰まったところをその場で書き足します。手順書は、実際に一度使ってはじめて本物になります。書き方の型はリリース手順書（runbook）の作り方と最低限の項目で整理しています。
本番から逆算するという考え方
5つのステップをまとめると、やっていることはひとつです。本番という「答え」から、そこに至った「手順」を逆にたどること。
ゼロから正しい手順を考えようとすると、何が正解か分からず手が止まります。でも、本番には正解が実際に動いています。そこに近づけていけばいい、と考えると、ぐっと気持ちが楽になります。
具体例：PHPとJavaScriptの社内システムの場合
たとえば、PHPで作られ、画面の一部にJavaScriptを使っている社内システムを、ひとりで引き継いだ担当者がいるとします。
- ①保存：公開ディレクトリと設定ファイルをアーカイブして、別のサーバーへ保存した。
- ②観察：本番の
public/js/には1行に圧縮されたapp.jsだけがあり、元のソースはない。一方、vendor/は本番に置かれていた。 - ③入口探し：リポジトリに
package.jsonとpackage-lock.json、composer.lockがあった。前任者のホームディレクトリにはdeploy.shが残っていて、中身は「composer install→rsyncで本番へ転送」だった。ただし、JavaScriptのビルドはそこに含まれていない。package.jsonのscriptsにbuildがあり、手元でビルドしてから一緒に送っていたらしい、と推測できた。 - ④再現と差分：検証環境でロックファイルどおりに依存を入れてビルドし、本番と比べた。
app.jsは細かくずれたが、動作確認では問題なし。それとは別に、設定ファイルの1つだけが、リポジトリと中身が違っていた。調べると、前任者が本番で直接直した障害対応の修正だった。 - ⑤手順書：その修正をリポジトリに取り込み、「JSは手元で
npm run build→deploy.shを実行」と手順書に書いた。次の改修リリースで使いながら、キャッシュのクリアが抜けていたことに気づいて書き足した。
もし手順を推測のまま本番に出していたら、前任者の障害対応の修正を上書きして、昔の障害を呼び戻していたかもしれません。④の答え合わせが、その事故を静かに防いでくれたことになります。
影響：手順を取り戻すと、何が変わるか
- 改修のたびの「出すのが怖い」が減る：出し方が分かっているだけで、コードを直すことに集中できます。
- 戻し方が手に入る：手順が分かると、うまくいかなかったときの戻し方も書けるようになります（戻し方はリリースを戻す手順（ロールバック）も参考に）。
- 次の人に渡せる：あなたが休む日や、いつか引き継ぐ日に、同じ迷いを次の人にさせずに済みます。
反対に、手順が分からないまま毎回手探りで出していると、そのたびに神経をすり減らしてしまいます。復元は一度きりの手間で、その後のリリースをずっと軽くしてくれる作業です。
明日やること：本番の保存と、3行の観察メモ
明日できる、いちばん小さな一歩はこれです。
- 本番の公開ディレクトリと設定ファイルを、別の場所に保存する（保存日時とパスもメモ）。
- テキストファイルを1枚開き、名前を「デプロイ手順 復元メモ」にする。
- 本番を眺めて、次の3行だけ書く。
- ソースのままか、ビルド後の成果物か
- 依存ライブラリは本番に置かれているか
- 最後に更新されたファイルと日時
- リポジトリで
package.json・composer.json・Makefileなどの名前を検索し、見つかったものを1行ずつメモに足す。
30分もあれば終わります。手順が全部わからなくても大丈夫です。メモに残った「〜らしい」が、次に確かめることのリストになります。
ビルド・デプロイ手順 復元チェックリスト
復元を進めるとき・見直すときに当てる項目です。全部を最初からそろえる必要はありません。
まず外せない最低ラインはこの3つです。
- 【最低ライン】調べ始める前に、本番の公開ディレクトリと設定ファイルを別の場所へ保存したか
- 【最低ライン】復元したビルドを、本番ではなく検証環境（または手元）で試したか
- 【最低ライン】本番にあってリポジトリにない変更がないか、差分で確かめたか
次は、復元の精度を上げるための項目です。
- 本番の中身が、ソースのままかビルド後の成果物かを確認したか
- ロックファイルとランタイムのバージョン指定を探したか
- CIの設定・デプロイ用スクリプト・cron・コマンド履歴を確認したか
- 見つけたスクリプトや履歴のパスワード・APIキーを伏せて扱ったか
- ビルド後の作業（キャッシュクリア・再起動など）も手順に書いたか
- 戻し方を手順書に書いたか
- 次のリリースで手順書を使い、詰まった点を書き足したか
全部に○が付かなくても大丈夫です。最低ラインの3つがあるだけで、手探りのリリースから一歩抜け出せています。
よければ、こちらも
手順の復元は、引き継ぎやバージョン管理の整備とセットにすると、ぐっと進めやすくなります。
- リリース手順書（runbook）の作り方と最低限の項目：復元した手順を、使える形に整えるために。
- バージョン管理されていないコードをGitに載せる手順：本番にしかないコードを、まずリポジトリへ。
- 本番だけで起きる不具合の差分調査：④の差分の読み方に。
- レガシーシステムを引き継いだ初日にやること：引き継ぎ直後の全体の進め方として。
手順書がないシステムを、ここまで動かし続けてきたこと自体が、もう十分すごいことです。 手順は消えたのではなく、本番の中で静かにあなたを待っています。まずは本番を保存して、3行のメモを書くところから、始めてみましょう。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。