手動デプロイをやめる｜CI/CD導入のメリットと小さく始める手順
「本番反映はFTPで手作業」「デプロイできるのは特定の1人だけ」——この体制は、いつか必ず事故を起こします。CI/CDとは、テスト・ビルド・デプロイといった作業をコードの変更をきっかけに自動実行する仕組みです。CI（継続的インテグレーション）が「変更のたびに自動でテスト・検証すること」、CD（継続的デリバリー/デプロイ）が「検証済みの変更を自動で配置できる状態にすること」を指します。本記事では、手動デプロイの何が危ないのか、そして大掛かりな体制変更なしに小さく始める手順を解説します。
手動デプロイの典型的な事故パターン
- ファイルの上書き漏れ・置き間違い — FTPで一部のファイルだけ転送し忘れる、別環境のファイルを上書きする。手作業では防ぎようがなく、しかも発覚が遅れがちです
- 本番でしか気づかないエラー — ローカルでは動いたコードが、依存パッケージやPHPバージョンの違いで本番だけ壊れる。テストの自動実行がないと、確認は「反映後に画面を見る」だけになります
- 「戻せない」問題 — 手作業デプロイは反映前の状態が残っていないことが多く、不具合時の切り戻しに時間がかかります
- 属人化 — 手順が特定の人の頭の中にしかなく、その人が不在だと緊急修正すら出せない。デプロイが怖いものになり、リリース頻度が下がっていきます
CI/CDを入れると何が変わるか
| 観点 | 手動デプロイ | CI/CD導入後 |
|---|---|---|
| 作業ミス | 転送漏れ・上書き事故が起きうる | 毎回同じ手順が自動実行され、手作業ミスが消える |
| 品質確認 | 反映後に目視確認 | 反映前にテストが自動実行され、失敗したら止まる |
| 切り戻し | 手作業で復旧、時間がかかる | 直前のバージョンを再デプロイするだけ |
| 属人性 | 特定の人しかできない | 手順がコード化され、誰が実行しても同じ |
| リリース頻度 | 怖いのでまとめて月1回など | 小さな変更を高頻度で出せる |
特に効くのは「失敗したら止まる」という性質です。人間の注意力ではなく仕組みで品質を担保するため、リリースのたびに緊張する状態から抜け出せます。
GitHub Actionsで小さく始める3段階
CI/CDツールには様々ありますが、コードをGitHubで管理しているなら、追加のサーバー不要で使えるGitHub Actionsが最初の選択肢になります。一気に全部を自動化する必要はなく、次の3段階で進めるのが現実的です。
- 第1段階：テストの自動実行（CI） — まずはpushやプルリクエストのたびにテストとLint（構文チェック）を自動実行するだけのワークフローを作ります。テストがまだ無いプロジェクトなら、「ビルドが通るか」「構文エラーがないか」の確認だけでも十分な第一歩です。デプロイには一切触らないので、既存の運用を壊すリスクがありません
- 第2段階：ビルドの自動化 — CSS/JSのビルドや依存パッケージのインストールなど、「デプロイ前にやっている手作業」をワークフローに移します。「ビルド成果物を作るところまで自動、配置は手動」という中間状態を挟むことで、安全に移行できます
- 第3段階：デプロイの自動化（CD） — mainブランチへのマージをきっかけに、サーバーへの配置まで自動化します。最初は本番ではなくステージング環境への自動デプロイから始め、本番は「手動でボタンを押したら実行される」承認付きにしておくと心理的な抵抗も小さくなります
各段階は数日〜数週間の粒度で進められます。第1段階だけでも「壊れた変更がマージされない」という効果が出るため、途中で止まっても投資が無駄になりません。
導入時につまずきやすいポイント
- 秘密情報のベタ書き — サーバーのパスワードやAPIキーをワークフローファイルに直接書いてはいけません。GitHub ActionsのSecrets機能に登録して参照します
- 本番と検証環境の差分 — CIでは通るのに本番で動かない場合、環境差が原因です。PHPやNode.jsのバージョンをワークフロー内で本番に合わせて固定します
- テストがないコードベース — 「テストを書いてからCI/CD」と考えると永遠に始まりません。順序は逆で、まず構文チェックだけのCIを敷き、以後の変更分からテストを足していくほうが現実的です
- 共有サーバーへのデプロイ — レンタルサーバーなどSSHが制限された環境では選択肢が限られますが、FTPSやrsyncでの自動転送に対応したActionを使えば自動化自体は可能です
導入効果はどう測るか
CI/CDの効果は感覚論になりがちですが、次の指標を導入前後で比べると投資判断がしやすくなります。
- デプロイ頻度 — 月1回のまとめリリースが週次・日次にできているか。頻度が上がるほど1回あたりの変更が小さくなり、不具合の切り分けも楽になります
- デプロイ作業にかかる時間 — 手順書を見ながら30分〜1時間かけていた作業が、マージ後の数分待ちに変わります。担当者の拘束時間として金額換算できます
- 本番障害からの復旧時間 — 切り戻しが「再デプロイ1回」になることで、障害対応の時間が大きく縮みます
小規模チームでも、デプロイ作業と本番トラブル対応に費やしていた時間を合算すると、月に数時間〜十数時間になっていることは珍しくありません。その時間が開発に戻ってくるのがCI/CDの実質的なリターンです。
まとめ｜「デプロイが怖くない状態」を最初のゴールに
CI/CD導入のゴールは高度な自動化そのものではなく、「誰でも・いつでも・安全にリリースできる状態」です。テストの自動実行という小さな一歩からで構いません。シャノンでは自社SaaSの開発・運用でCI/CDを日常的に回しており、受託開発やシステム保守でも同じ仕組みを組み込んでご提供しています。「手動デプロイをやめたいが何から手を付けるべきか分からない」という段階からでも、現状の開発フローに合わせた導入プランをご提案できますので、お気軽にご相談ください。