【コード哲学エッセイ】 機能フラグは逃げ道じゃない —— 小さく出すための怖さを減らす仕組み

デプロイの前にスイッチを一つ足す

七月の夜、エディタの右下に時計だけが進んでいる。
差分はそう大きくない。
テストも通っている。

それでも、指は Deploy の上で止まる。

「この画面、まだ粗い」
「設定がもう一段いる」
「ユーザーに見せるのは、来週でいい」

かつての僕なら、ここでブランチを抱えたまま寝た。
または、フラグを足して、本番では消しておくと言い訳した。

スイッチは簡単だ。
環境変数に false。
画面の入口に if。
デプロイボタンは、少しだけ軽くなる。

けれど、その軽さを何度も借りているうちに、僕は勘違いしていた。
フラグは、未完成を許す装置じゃない。
怖さを一段下げて、小さく出すための仕組みなのだと、あとから知る。

逃げ道だと思っていた頃

フリーランスになって数年、個人開発の画面を直すたびに同じパターンを繰り返した。

新しいダッシュボードを作る。
旧画面は残す。
FEATURE_NEW_UI を .env に書く。
本番は false、手元は true。

最初は賢く見えた。
「【コード哲学エッセイ】デプロイが怖い夜に。小さく壊して、小さく直す勇気の話」で書いたように、小さく出す勇気を借りられた。

問題は、借りっぱなしになったことだ。

「来週オンにする」と口にしながら、来週は別のタスクが来る。
旧 UI と新 UI が、コードのなかで並び続ける。
if の奥に、もう一つの if。
「【コード哲学エッセイ】長く続くプロジェクトでやらないことを決める」で書いた、ぼやけた顔が戻ってきた。

半年後、僕は自分に聞いた。
「このフラグ、いつ消すんだっけ？」

答えがないフラグは、逃げ道だ。
仕組みじゃない。

スイッチは隠すための布じゃない

いまの僕は、機能フラグをこう捉えています。

本番の光を、一段だけ落とす調光器だ。
部屋ごと閉鎖する鍵ではない。

小さく出すとは全部を見せないことじゃない。
変更の影響を見える範囲に限定することに近い。

バックエンドの型だけ先に載せる。
管理画面だけ先に試す。
特定の利用者だけ新フローに入れる。

そのときフラグは、誰に・いつ・どこまで見せるかの境界になる。
「【コード哲学エッセイ】設定値は隠す場所じゃなく境界だ」で書いた、環境ごとに変わる値の一種だ。
「【コード哲学エッセイ】公開 API は機能じゃなく約束の窓だ」の窓と同じで、全部晒さない選択をコードに残す。

逃げ道になるのは、境界が書かれていないときだ。
「とりあえずオフ」だけが残り、消す日が決まっていない。

怖さを減らすとは何か

デプロイの恐怖は、たいてい変更の塊から来る。
一度に、見え方も挙動も変わる。
ロールバックの想像が重くなる。

フラグは、塊を分ける鋸にはならない。
出すあいだの安全柵にはなれる。

本番では旧ルートのまま。
検証では新ルートを試す。
問題があれば、スイッチを戻す。
コードを巻き戻すより、呼吸が浅く済むことがある。

それは、未完成を永久に許すことじゃない。
短い期間だけ怖さを下げることだ。

僕が失敗したのは、期間を決めなかったこと。
いつかは、設計の言葉じゃない。
いつまでが、仕組みの言葉だ。

フラグを足す前に僕が置く三つの問い

スイッチを書く前に、僕は三つだけ問います。

何を、どこまで小さく出すか。
いつ、誰が、このフラグを外すか。
フラグが残ったまま、何が壊れるか。

答えがはっきりしないなら、フラグは早いのかもしれない。
ブランチに留める。
まだ出さない。
それも立派な選択だ。

答えがあるなら、名前と期限をセットで残す。
コメント一行でいい。

// 本番は false のまま。検証だけ true にして、差分を小さく載せる
const useNewDashboard =
  process.env.FEATURE_NEW_DASHBOARD === 'true';

if の前に、消す日を書く。
それだけで、逃げ道は仕組みに近づく。

出したあとに消す勇気

フラグの本当の仕事は、オンにすることじゃない。
オフに戻して、分岐を消すことで終わる。

新 UI が安定したら、旧 UI を捨てる。
フラグを削除する。
環境変数の行も、README の注意書きも一緒に消す。

ここで躊躇すると、また霧が戻る。
「念のため残しておこう」
「また使うかもしれない」

残したフラグは、未来の自分への負債になる。
「【コード哲学エッセイ】TODOコメントを借金のまま放置しない」と同じ温度だと、いまは思う。

小さく出す勇気のあとには、小さく畳む勇気が要る。
スイッチを外す日を、デプロイの予定に入れる。
それも、怖さを減らす設計の一部だ。

七月のエディタの前で

下半期に入り、出したい気持ちは強い。

「もっと載せたい」
「もっと直したい」

——七月の空気は、そう囁く。

そのとき、僕は昔の自分に声をかけます。

「これは逃げ道か。それとも、一段だけ怖さを下げる柵か」

後者なら、期限と名前をセットで足す。
前者に見えたら、まだブランチの中に留める。

機能フラグは、未完成の倉庫じゃない。
小さく出して、小さく直すための、一時的な手すりだ。

同じように、スイッチを増やして迷子になった誰かに届けばうれしいです。

ひとりごと

フラグを足すたびに賢く見えていた頃があった。
消す日を書かなかった自分へ、いまは少しだけ厳しくなれる。

七月の夜、Deploy の上で止まる指は、まだある。
それでも、手すりの向こうに、一歩だけ出せる日も増えてきた。

あわせて読みたい

▼ 小さく出す勇気の、もう一本の線として

恐怖の正体は変更の大きさ。
今回の手すりは、その続きとして読めます。

▼ フラグを置く場所としての設定・境界

機能フラグも、環境ごとに変わる境界の一種です。

▼ 外に見せる範囲を選ぶ話として

七月のコード哲学エッセイの流れ。
全部晒さない設計と響き合います。

次の一歩を一緒に決める作戦会議室へ

デプロイの怖さやフラグの付け方。
一人で抱えると、逃げ道と仕組みの境目がぼやけやすい。

作戦会議室では、現場で使える切り方を小さく分け合える場所にしたいです。
必要なときだけ、覗いてみてください。

参加する

Substack はじめました

ここまで読んでくださり、ありがとうございました。

X では短い言葉で、note では整理した文章で発信していますが、Substack では、もっと途中経過の思考や削りきらなかった葛藤、技術者として日々考えていることを書いています。

もし興味があれば、覗いてみてください。

会社員（元システムエンジニア）からフリーランスとなり、
15 年目に突入しました。

納期と障害対応に追われる毎日の中で、
「もっと自由に、もっと本質的にものづくりがしたい」
そう思ったのが独立のきっかけです。

現在は、技術と文章を軸に、
仕事がラクになる仕組みや続けられる働き方を発信しています。