【コード哲学エッセイ】 デプロイが怖い夜に。 小さく壊して、 小さく直す勇気の話

金曜日の夕方、指が震える

金曜日の 17 時。
モニターには「Deploy」のボタンが表示されています。
あとはこれをクリックするだけ。
それなのに、マウスを握る手にじっとりと汗が滲みます。

「もし、サイトが落ちたら？」
「もし、ユーザーのデータが消えたら？」

一週間かけて積み上げた変更の塊。
そのすべてを、このワンクリックで世界に放つ。
それはまるで、爆弾の導火線に火をつけるような恐怖でした。

かつての僕にとって、デプロイは「祈り」でした。
どうか何も起きませんように。
どうか無事に週末を迎えられますように。

でも、祈りはしばしば裏切られます。
深夜の電話、飛び交うアラート、冷え切ったピザ。
そんな夜を過ごすたびに、僕はこう思いました。
「もっと完璧に確認してからリリースすればよかった」と。

「完璧」 が恐怖を育てる

恐怖の正体は、実は「変更の大きさ」にあります。

不安だから、まとめて確認しようとする。
不安だから、一度に全部リリースしてしまおうとする。
そうやって変更を溜め込めば溜め込むほど、その塊は巨大なモンスターへと成長します。

いざリリースして問題が起きたとき、どこが原因なのか特定するのに何時間もかかる。
影響範囲が広すぎて、ロールバックするのも怖い。

皮肉なことに、「完璧にしてから出そう」という慎重さが、かえって致命的なリスクを生み出していたのです。
僕は、自分で自分の首を絞めていました。

小さく壊せば、かすり傷で済む

転機は、ある先輩エンジニアの言葉でした。

ハッとしました。
システム開発において、バグや障害をゼロにすることは不可能です。
だったら、起きたときの被害を最小限にすればいい。

「小さく壊して、小さく直す」

100 行の変更を一回リリースするより、10 行の変更を十回リリースする。
もし 10 行の変更でバグが出ても、原因はすぐに見つかります。
修正も簡単だし、影響範囲も限定的です。

それは、一度に完璧な城を築こうとするのではなく、レンガを一つずつ積んでいくような感覚でした。

デプロイを 「日常」 に変える

それから僕は、開発のスタイルを変えました。
機能が完成していなくても、動く部分だけこまめにリリースする。
裏側（ユーザーに見えない部分）の変更だけでも先にデプロイしておく。

最初は怖かったです。
「こんな中途半端な状態で出していいのか」と。
でも、回数を重ねるごとに、デプロイボタンへの恐怖が薄れていきました。

リリースは「祈るような儀式」から、呼吸をするような「日常の動作」へと変わっていったのです。

傷つくことを恐れない勇気

もし今、あなたがデプロイを怖いと感じているなら。
それはあなたが慎重で、責任感が強い証拠です。
でも、その責任感の方向を少しだけ変えてみませんか？

「絶対に失敗しないこと」を目指すのではなく、「失敗してもすぐに立ち直れる状態」を作ることへ。

小さく壊す勇気を持ってください。
かすり傷なら、すぐに治ります。
そしてその傷は、システムとあなた自身を、より強く、たくましく育ててくれるはずだから。

さあ、恐れずにボタンを押しましょう。
もちろん、金曜日の夕方じゃなくて、月曜日の朝にね。

あわせて読みたい

▼ 障害対応が怖くなくなる視点の転換

エラーログは批判の手紙ではありません。
システムがあなたに助けを求めているメッセージです。

バグへの恐怖心を、好奇心と愛着に変えるためのエッセイ。

▼ デプロイの恐怖を技術で支えるために

テストコードを書くのは面倒ですか？
でもそれは、未来のあなたが安心して眠るための「祈り」なのです。

テストがくれる本当の価値について。

▼ 具体的なデプロイフローを知りたいときに

精神論だけでなく、実際にどうすれば安全にデプロイできるのか。

CI/CD や自動化の具体的なテクニックを解説した実践編。

ひとりごと

「小さくリリースする」って、口で言うのは簡単ですが、実践するのは勇気がいりますよね。
でも、一度そのリズムを掴むと、もう巨大なリリースには戻れなくなります。

ちなみに僕は、金曜日のデプロイは（どんなに小さくても）極力避ける派です。
週末は美味しいビールを飲みたいですからね（笑）