金曜日の夜、FTPクライアントの前で
あれは、私がまだ駆け出しのWebエンジニアだった頃の話です。
金曜日の夜23時。世間は週末の開放感に浸っている時間帯に、私は薄暗いオフィスで一人、モニターの光に照らされていました。
クライアントのWebサイトの更新作業。
手元には、Excelで作られた「リリース手順書_v12.xlsx」。
画面には、FTPクライアントソフト。
左側がローカルの開発環境、右側が本番サーバー。
「このファイルを、右側にドラッグ＆ドロップする」
たったそれだけの作業です。でも、私の指先は小刻みに震えていました。
もし、間違って設定ファイル（config.php）を上書きしてしまったら？
もし、アップロード中に回線が切れてファイルが破損したら？
もし、手順書の「v12」が最新じゃなくて、誰かが勝手に書き換えた「v13」が存在していたら？
エンターキーを押す瞬間、祈るような気持ちでした。
「頼む、動いてくれ。エラー画面にならないでくれ」
無事に更新が終わった後も、不安は消えません。家に帰ってもスマホでサイトを確認し続ける週末。
「インフラエンジニアって、寿命を削って給料をもらっているのか？」
本気でそう思っていました。
そんな私を、この「運任せのリリース地獄」から救い出してくれたのが、CI/CDという概念であり、技術でした。
自動化。
人間がやるからミスをする。人間がやるから怖い。
機械にやらせれば、ミスもしないし、文句も言わないし、何より速い。
CI/CDを導入してからの私は、金曜日の夜に震えることはなくなりました。
コードをGitHubにプッシュして、あとはコーヒーを淹れて待つだけ。
「デプロイ完了」の通知がSlackに届くのを、優雅に眺めるだけです。
今回は、かつて手動デプロイの恐怖に怯えていた私が、どうやってCI/CDを学び、現場に導入し、そして「DevOps」という文化を定着させてきたのか。その全貌を、泥臭い失敗談とともに共有します。
教科書的な定義の解説ではありません。あなたが「楽をする」ための、そしてエンジニアとして「信頼を勝ち取る」ための、実践的なガイドブックです。
そもそもCI/CDって何？「自動化」の正体
「CI/CD」という言葉、求人票や技術記事でよく見かけますよね。
Continuous Integration（継続的インテグレーション）と、Continuous Delivery（継続的デリバリー）または Deployment（継続的デプロイメント）。
略語の意味なんてどうでもいいんです。重要なのは「何をしてくれるのか」です。
ざっくり言うと、「コードを書いてから、ユーザーに届くまでの『面倒くさい作業』を全部自動でやってくれる仕組み」のことです。
CI（継続的インテグレーション）：最強の虫取り網
プログラミングをしていると、バグ（虫）は必ず発生します。
「セミコロンを忘れた」「変数名を間違えた」「既存の機能を壊してしまった」
これらを、人間が目視でチェックするのは不可能です。
CIは、コードを保存（プッシュ）した瞬間に、自動的に走る「検問」です。
仮想のロボットが立ち上がり、あなたのコードを読み込み、文法チェック（Lint）を行い、テストコード（Unit Test）を実行してくれます。
もしバグがあれば、「ここ間違ってるよ！」と瞬時に教えてくれる。
チーム全員がこの検問を通すルールにすれば、バグだらけのコードが結合（インテグレーション）されることを防げます。
これが「継続的インテグレーション」です。常に綺麗な状態を保ち続ける、ということです。
CD（継続的デリバリー/デプロイ）：無人の宅配便
CIの検問を通過した「綺麗なコード」。これを本番サーバーに置く作業がデプロイです。
かつての私のように、FTPで手動アップロードするのは「手渡し」です。
CDは、これを「ドローン配送」にするようなものです。
検問（CI）をパスしたら、そのまま自動的に本番サーバーへファイルを転送し、サーバーを再起動し、データベースの更新までやってくれる。
ボタン一つ、あるいはプッシュするだけで、数分後には新機能がユーザーの手元に届く。
これが「継続的デリバリー/デプロイ」です。
DevOpsとの関係：道具と文化
よく「CI/CD」とセットで語られる「DevOps（デブオプス）」。
これはツールの名前ではなく、「文化」の名前です。
昔の現場では、
開発チーム（Dev）は「新機能をガンガン出したい！」と言い、
運用チーム（Ops）は「サーバー落としたくないから変更したくない！」と言う。
仲が悪かったんです。対立していたんです。
でも、CI/CDという「共通の自動化ツール」を使うことで、
開発者は安心してコードを出せるし、運用者は安定してサーバーを守れる。
「ツールを通じて仲良く協力しようぜ」というのがDevOpsの本質です。
CI/CDは、DevOpsを実現するための最強の武器なのです。
なぜ今、CI/CDスキルが求められるのか
「手動でもなんとかなってるし、覚えるの面倒くさいな」
そう思うかもしれません。私もそうでした。環境構築とかYAMLファイル書くのとか、地味で大変ですからね。
でも、副業やフリーランスとして単価を上げたいなら、CI/CDは「必須教養」になりつつあります。
「信頼」をお金に変える
クライアントにとって、一番怖いのは「バグでサイトが止まること」と「デグレ（修正したら別の場所が壊れること）」です。
「手動で頑張ってチェックします！」というエンジニアと、
「テストとデプロイを自動化しているので、人為的ミスは起きません」というエンジニア。
どちらに高い報酬を払いたいか、明白ですよね。
自動化スキルは、そのまま信頼性と単価に直結します。
開発スピードが3倍になる
手動デプロイに30分かかっていたとします。週に2回リリースしたら1時間。月に4時間。
CI/CDを組めば、この時間がゼロになります。
浮いた時間で新しい機能を開発したり、別の案件を受けたりできる。
「時間の切り売り」から脱却するために、自動化は最強の投資なんです。
心理的安全性の確保
これが一番大きいです。
「金曜日の夜にデプロイしたくない」という恐怖から解放されます。
テストが通っているという保証があるから、自信を持ってリリースボタンを押せる。
この精神的な余裕は、エンジニアとして長く働き続けるために不可欠な要素です。
【実践編】GitHub ActionsでCI/CDを構築してみよう
理屈はこれくらいにして、実際に手を動かしてみましょう。
CI/CDツールにはJenkins、CircleCI、GitLab CIなど色々ありますが、今から覚えるならGitHub Actions一択です。
なぜなら、世界中のエンジニアが使っているGitHubに標準搭載されていて、追加料金なし（一定枠まで）で使えるからです。
ステップ1：やりたいことを整理する
いきなりコードを書く前に、「何を自動化したいか」を箇条書きにします。
今回は、典型的なWebアプリ（Node.jsなど）を想定して、以下のフローを作ってみましょう。
- GitHubにコードを
pushする。 - 自動的に仮想環境（Ubuntu）が立ち上がる。
- 必要なライブラリ（
npm install）を入れる。 - テスト（
npm test）を実行する。 - テストが通ったら、完了通知を出す。
（※デプロイまでは設定が複雑になるので、まずは「CI（テスト自動化）」までをゴールにします）
ステップ2：ワークフローファイルの作成
GitHub Actionsの設定は、リポジトリの中に .github/workflows というフォルダを作り、その中にYAMLファイル（例：ci.yml）を置くことで認識されます。
プロジェクトのルートディレクトリで：
mkdir -p .github/workflows
touch .github/workflows/ci.ymlステップ3：YAMLファイルを書く
「YAML（ヤムル）？ インデントがずれると動かないやつでしょ？」
その通りです。でも、恐れる必要はありません。基本の型は決まっています。
以下を ci.yml にコピペしてみてください。
name: Node.js CI
# いつ実行するか？（トリガー）
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
# 何をするか？（ジョブ）
jobs:
build:
# どのOSで動かすか？
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [18.x, 20.x]
# 複数のバージョンで並列テストできる！
steps:
# 1. リポジトリのコードを持ってくる
- uses: actions/checkout@v3
# 2. Node.jsをセットアップする
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
# 3. 依存関係をインストール
- run: npm ci
# 4. ビルド（あれば）
- run: npm run build --if-present
# 5. テスト実行
- run: npm test
ステップ4：GitHubにプッシュして確認
これを保存して、GitHubにプッシュしてみてください。
リポジトリのページを開き、「Actions」タブをクリックします。
すると…
あなたの書いたYAMLに従って、GitHubのサーバー上で仮想マシンが立ち上がり、コマンドが実行されている様子がリアルタイムで見えます。
緑色のチェックマーク「✓」がつきましたか？
おめでとうございます！ これがあなたの「最初のCI」です。
もし赤色の「❌」が出たら？
おめでとうございます！ あなたは今、バグのあるコードが混入するのを未然に防いだのです。ログを見て、何が原因か（テストが落ちたのか、YAMLの書き方が悪いのか）を探りましょう。この試行錯誤こそが、インフラエンジニアへの第一歩です。
現場で必ずぶつかる「CI/CDの壁」と乗り越え方
基本は簡単ですが、実際の現場導入では様々な壁にぶつかります。
私が踏み抜いてきた地雷と、その回避策をシェアします。
壁1：テストコードがない問題
「CIを導入したいけど、そもそもテストコードが一行もないんです」
これ、あるあるランキング1位です。
テストがないのにCIを入れても、ただビルドができるかどうかのチェックにしかなりません。
解決策：
「Lint（静的解析）」から始めましょう。
ESLintやPrettierなどのツールを使って、「コードの書き方が汚くないか」「明らかな文法ミスがないか」をチェックするだけなら、テストコードを書く必要はありません。
これだけでも、「セミコロン忘れで動かない」といった低レベルなミスを排除できます。ハードルを下げて導入し、徐々に「重要な機能だけテストを書く」文化を作っていくのがコツです。
壁2：CIが遅すぎてイライラする問題
最初は数秒で終わっていたCIも、プロジェクトが大きくなると数分、数十分とかかるようになります。
「ちょっと修正しただけなのに、テスト待ちで20分も待たされる！」
こうなると、開発者はCIを無視し始めます。本末転倒です。
解決策：
- キャッシュを使う:
npm installなどを毎回ゼロからやると時間がかかります。actions/cacheなどを使い、変更がないライブラリは使い回す設定を入れます。 - 並列実行: 前述のYAMLにあった
matrixを使ったり、テストファイルを分割して複数のマシンで同時に実行させたりします。課金枠を消費しますが、エンジニアの待ち時間（人件費）よりは安いです。
壁3：秘伝のタレ化したサーバーへのデプロイ
CIまではできたけど、CD（自動デプロイ）が難しい。
なぜなら、本番サーバーが長年手動で継ぎ足し運用されてきた「秘伝のタレ」状態だからです。
SSHで入って、あのコマンドを叩いて、権限を変えて…という複雑な手順を、自動化スクリプトに落とし込めない。
解決策：
無理に既存サーバーにCDしようとせず、「コンテナ化（Docker）」を検討してください。
環境をDockerイメージとして固めてしまえば、それをAWS ECSやGoogle Cloud Runなどのコンテナ基盤に「ポンと置く」だけでデプロイが完了します。
CI/CDとDockerは、切っても切れない親友のような関係です。
副業案件での「CI/CD導入」提案の切り出し方
あなたが副業で参画したプロジェクトに、まだCI/CDがなかったとします。
ここで「CI/CD入れましょうよ！便利ですよ！」と直球で言っても、クライアントは「それでお金かかるの？」「納期遅れない？」と渋い顔をするでしょう。
経営者には、技術用語ではなく「メリット」で話す必要があります。
刺さる提案フレーズ：
- 「リリースのたびに発生している手作業（30分）をゼロにできます。月に換算すると○時間のコスト削減になります」
- 「人為的なミスによるサイトダウンのリスクを、仕組みで90%減らせます」
- 「今後、他のエンジニアさんが入った時も、この仕組みがあれば即戦力として動いてもらえます（引き継ぎコスト削減）」
私はこのトークで、何度も「CI/CD構築案件」を追加受注してきました。
単なるコーディングだけでなく、「開発環境の改善」まで提案できるエンジニアは、クライアントにとって手放したくないパートナーになります。
FAQ：よくある質問
Q. CI/CDを入れると、逆に開発が遅くなりませんか？
A. 導入初期は設定やテスト記述で工数がかかりますが、中長期的には必ずプラスになります。バグ調査や手動デプロイの手間がなくなる時間を計算してみてください。借金を返済するのと同じで、早めに導入するほど利子が浮きます。
Q. 個人開発でも必要ですか？
A. 必須ではありませんが、強く推奨します。
半年後に自分のコードを見た時、どうやってデプロイするのか忘れているものです。CI/CDの設定ファイル（YAML）は、最強の「手順書」代わりになります。自分の記憶力を信用してはいけません。
Q. Jenkinsじゃダメなんですか？
A. ダメではありませんが、初心者にはおすすめしません。
Jenkinsは自前でサーバーを立てて管理する必要があり、「Jenkinsおじさん」と呼ばれる専任の管理者がいないと運用が回らなくなりがちです。GitHub Actionsなどのマネージドサービス（SaaS）を使うのが現代の主流です。
自動化は「サボり」ではなく「創造」への切符だ
ここまで、CI/CDとDevOpsについて、その仕組みから実践、現場での立ち回りまで解説してきました。
昔の職人気質なエンジニアの中には、「楽をすること」を悪だと捉える人もいました。
「苦労して手動でコマンドを叩くのがプロだ」と。
でも、私は声を大にして言いたい。
エンジニアの仕事は、苦労することではありません。価値を生み出すことです。
ルーチンワークを自動化し、機械に任せられることは任せる。
そうして生まれた「余白」の時間で、もっと使いやすいUIを考えたり、新しい機能を設計したり、あるいは家族との時間を大切にしたりする。
それこそが、テクノロジーを使う人間のあるべき姿ではないでしょうか。
CI/CDを導入したあの日、金曜日の夜にオフィスを出て、同僚と飲みに行ったビールの味は格別でした。
「あ、今頃GitHub Actionsがデプロイしてくれてるな」
そう思いながら飲むビールには、自由の味がしました。
あなたにも、その味を知ってほしい。
YAMLファイルとの格闘は、最初は少し大変かもしれません。エラーで真っ赤な画面に心が折れそうになるかもしれません。
でも、その先には「震えない指」と「クリエイティブな時間」が待っています。
さあ、エディタを開いて、.github/workflows フォルダを作りましょう。
あなたのエンジニアライフを、あなたの手で「自動化」するのです。
その通知が届くたび、あなたは自分が作った「仕組み」に感謝することになるはずです。
Happy Automating!
