「完成してから出す」 をやめた夏

Feature Flag で小さく出す個人開発の設計

Deploy の上で、また指が止まっていた。

差分は通っている。
型もテストも、赤くない。

それでも頭の中では、同じ一文が鳴る。

「画面がまだ粗い」
「完成してから出そう」

個人開発の夏は、熱いのに進まないことがある。
原因は暑さだけじゃない。
完成を待つ癖が、リリースを先延ばしにする。

7 月、僕は Feature Flag を個人開発の運用に持ち込みました。
未完成を隠すためではない。
小さく出すための、夏のリリース設計として。

完成待ちがいちばん長いブロッカーになる

みなさんは、個人開発で「もう少し整えてからマージしよう」が、二週間・一か月と伸びた経験はありますか。

僕には、それが何度もありました。

夜間バッチへ逃がした話で、真昼の集中を守るためにメンテを夜へ移した。

置き場は整った。
なのに、機能の出し方は古いままだった。

新ダッシュボードの骨格はある。
API の型も先に載せられる。
本番の入口は、旧画面のまま。
理由はいつも同じです。

「完成してから見せたい」

完成の定義が曖昧だと、この一文は永遠に勝てる。
ボタンの余白、空状態の文言、モバイルの一行——
整える対象はいくらでも見つかる。

フリーランスの案件では、期日が境界になる。
個人開発では、境界を自分で描かないと、完成待ちが拠点になる。
海の日に拠点を引き直した話と同じ構造でした。

場所の輪郭がないと祝日が溶けるように、出し方の輪郭がないとリリースが溶ける。

7 月は走り出す月です。
走っているのにマージが止まる夏は、もったいない。

「完成してから出す ＝ 安全」 だと思っていた

かつての僕の個人開発リリースは、だいたいこうでした。

| 段階 | やり方 | 起きていたこと |
|:---|:---|:---|
| 実装 | 長い feature ブランチ | main から遠ざかる |
| 仕上げ | 「もう少し」が続く | 余白・文言・例外処理で無限延長 |
| マージ | 完成してから一括 | 差分が大きく、Deploy が怖い |
| 本番 | 全部いっぺんに見える | ロールバック想像が重い |

安全に見えた。
実際は、塊を大きくしていただけだったのです。

新しい UI を作るたびに、旧画面と新画面が頭のなかで並ぶ。
「どっちを本番にするか」が決まらないうちに、別のタスクが来る。
ブランチは生きたまま、夏のカレンダーだけが進む。

吃音のある僕は、口頭の説明より画面と文章で伝えることが多い。
だからこそ、粗い画面を見せたくない気持ちは強かった。
見せたくない気持ちと出せない状態は、似て非なるものです。
前者は配慮。
後者は進捗の停止。

七夕の技術の願い事で「触りたい／手放したい」を分けたときも、リストの下にいつも同じ項目があった。

願いは書いた。
仕組みは、まだなかった。

フラグは逃げ道じゃない——では、 夏にどう使うか

転機は、思想だけでは足りなかった、と気づいたことでした。

機能フラグは逃げ道じゃないで書いたとおり、かつての僕はフラグを未完成の倉庫だと思っていた。

本番は false。
手元は true。
Deploy は軽くなる。
消す日は書かない。

半年後、自分に聞けなくなる。

「このフラグ、いつ消すんだっけ？」

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

だから 7 月の実務では、問いをひっくり返しました。

逃げ道にしないためにフラグを使わない——ではない。
逃げ道にならない条件だけを満たして、個人開発のリリースに持ち込む。

夜間バッチが「いつ回すか」の設計だったように、
Feature Flag は「いつ・誰に・どこまで見せるか」の設計です。

デプロイが怖い夜の続きとしても読める。

怖さの正体が変更の塊なら、塊を分けて出す柵が要る。
フラグは鋸ではない。
出すあいだの安全柵にはなれる。

海の日連休のあとの夏に、僕が決めたのはこれでした。

【設計】 個人開発向け Feature Flag の最小構成

大企業の LaunchDarkly 運用を一人に持ち込まない。
僕が夏に固定した最小構成は、次のとおりです。

| 要素 | 個人開発での置き方 | やらないこと |
|:---|:---|:---|
| スイッチ本体 | 環境変数（例: `FEATURE_*`） | フラグ専用 SaaS を先に入れる |
| 判定場所 | 入口（ルート／ナビ／ページ）に近い一箇所 | 深い階層に `if` を散らす |
| 期限 | コメント一行＋週次リスト | 「いつか消す」 |
| 上限 | リポジトリあたり同時 3 つまで | 便利だから増やす |
| 確認 | 週 1 で ON/OFF と消す日を見る | 作りっぱなし |

ポイントは、全部をフラグにしないことです。
リファクタ、依存更新、型の整理——ユーザーに見えない変更は、フラグなしで小さく出す。
フラグは、見える面の出し分けに使う。

【夏の Feature Flag・役割】
・出す: 新画面／新フローの入口を閉じたままマージする
・守る: 本番ユーザー（または自分の本番利用）に粗い面を晒さない
・畳む: 安定したら分岐と旧面を消す
・しない: 未完成を永久に許す倉庫にする

公開したあとの保守フェーズで先に運用を書いたときの感覚に近い。
出す前に、畳み方まで含めて設計する。

【実践 ①】 命名 ・ 期限 ・ 置き場をセットで書く

スイッチを足すときは、コードより先に三行を書きます。

【フラグカード（最小）】
名前: FEATURE_NEW_DASHBOARD
出す範囲: 管理画面の新ダッシュボード入口のみ
消す日: 2026-08-04（または「安定 2 週後」）
消し方: 新 UI を常時表示 → 旧 UI 削除 → env 行削除

コード側は、入口に寄せます。

// 2026-08-04 まで。新ダッシュボード検証用。外したら旧画面を削除する
const useNewDashboard =
  process.env.FEATURE_NEW_DASHBOARD === "true";

export function DashboardEntry() {
  if (useNewDashboard) {
    return <NewDashboard />;
  }
  return <LegacyDashboard />;
}

命名ルールは雑でいいので、固定しました。

【命名】
・FEATURE_ で始める（設定値と混ぜない）
・対象が名詞で分かる（NEW_UI より NEW_DASHBOARD）
・否定形にしない（FEATURE_DISABLE_X は避ける）

環境の分け方は、個人開発ならこれで足ります。

| 環境 | 典型値 | 意図 |
|:---|:---|:---|
| ローカル | true | 新面を触る |
| Preview | true または一部のみ | 自分／限定確認 |
| 本番 | false → 検証後に true | 入口を段階的に開く |

大事なのは、本番をいきなり true にしない手順を文章に残すこと。
フラグがある安心感で確認を飛ばすと、柵が飾りの板になる。

【実践 ②】 何をフラグにし、 何をフラグにしないか

夏に実際に振り分けた基準です。

| 変更 | フラグ？ | 理由 |
|:---|:---|:---|
| 新ダッシュボード画面 | する | 粗い面を本番入口から隠せる |
| 新フローの一部 API | する場合あり | 画面とセットで出すとき |
| 型の強化・リファクタ | しない | 見えない変更は小さくマージ |
| 文言・余白の微調整 | しない | フラグのコストに見合わない |
| 実験的なナビ項目 | する | 迷ったら入口だけ閉じる |
| 「いつか使うかも」機能 | しない（作らない） | それは YAGNI 側の話 |

判断は、再び三問に戻ります。
コード哲学側で書いた問いを、夏の実務用に短くしています。

【フラグを足す前の三問】
1. 何を、どこまで小さく出すか（入口は一箇所か）
2. いつ、誰が、このフラグを外すか（日付があるか）
3. フラグが残ったまま、何が壊れるか（分岐のコスト）

答えがぼやけるなら、フラグは早い。
ブランチに留める。
まだ出さない。
それも立派な選択です。

答えがあるなら、名前と期限をセットで残す。
if の前に、消す日を書く。
それだけで、倉庫は柵に近づきます。

【棚卸し】 完成待ちから段階出しへ

見直しの結果を表に残しました。

| | 以前（完成待ち） | 今（フラグ付き） |
|:---|:---|:---|
| マージ | 全部できてから | 入口を閉じたまま先に載せる |
| 差分 | 大きくなる | 小さく分けられる |
| Deploy の指標 | 止まりやすい | 「入口は閉じてある」で一歩出せる |
| 本番の見え方 | 全部 or 何もなし | 旧面のまま／検証だけ新面 |
| 負債 | 長いブランチ | 短い期限つきフラグ（上限 3） |
| 週次 | 感覚で「あとで」 | フラグ一覧を 5 分見る |

Before / After を感覚ではなく一行で残すと、翌月の自分にも伝わります。

## Feature Flag（夏）
- いま開いているフラグ（最大 3）:
- それぞれの消す日:
- 今週オンにした／オフに戻した:
- 消したフラグと旧面の削除有無:

Obsidian の週次に、このブロックだけ足しても足ります。
続いたことのダッシュボードと同じで、減点しない。
開いている柵の数と、畳めた数だけを見る。

【失敗談】 フラグを増やしすぎて霧が戻った （汗）

最初の二週間で、二つ失敗しました。

【失敗 ①】 便利だから四つ目を足した

上限 3 を自分で破った。
ナビの実験、設定画面の実験、レポートの実験——
全部小さく出すために見えた。

実際は、入口が三つに増え、どれが本番の真実か分からなくなった。
コード哲学で書いた霧が、実務側にも戻ってきた。

対策は単純で、四つ目を足す前に一つ消すルールにしたこと。
増やすなら先に畳む。
増やさない週の精神と揃えます。

【失敗 ②】 消す日を来週とだけ書いた

来週は、来週になると別の来週になる。
日付のない期限は、期限じゃない。

対策として、カレンダーか週次ノートに YYYY-MM-DD を書くことにした。
曖昧語は禁止。
「安定したら」も禁止に近い。
安定の定義を一文で書けないなら、まだフラグを足さない。

もう一つ、環境差分の事故もありました。
Preview は true、本番もいつの間にか true——
確認を飛ばした自分のせいです。
デプロイ前の 30 秒チェックに一行足しました。

【Deploy 前・30 秒】
・本番の FEATURE_* は意図どおりか
・入口は閉じているか／開くなら誰向けか
・消す日はまだ有効か

【実践用】 今夜からできる最小の Feature Flag チェックリスト

同じ設計を小さく始める形に落とします。

【個人開発 Feature Flag・最小】
1. 「完成待ち」で止まっている変更を一つ書く
2. 見える入口か？ → Yes ならフラグ候補
3. 三問（範囲／消す日／残ると壊れるもの）に答える
4. FEATURE_ 名＋コメントに消す日を書く
5. 入口一箇所だけ分岐する（深い if を増やさない）
6. リポジトリの同時フラグは 3 まで
7. 週 1 で一覧を見て、期限切れは畳む（旧面削除まで）

道具は最小。
環境変数と入口の分岐と、週次の五分。
LaunchDarkly は、一人で上限を守れなくなってからでいい。

来週のテーマに近い話も、先に一言だけ。
スコープを半分にする YAGNI は、「作らない」側の設計です。
Feature Flag は、「作ったものを、どう見せるか」側の設計。
両方そろうと、夏の個人開発は前に出やすくなります。

| | 以前 | 今 |
|:---|:---|:---|
| 心理 | 粗いから出せない | 粗い面は入口で閉じられる |
| ブランチ | 長命化しやすい | main に寄せやすい |
| 本番 | 全部見せるか、何も出さないか | 段階出し |
| 週次 | 「あとで整える」 | フラグの生死を見る |
| 感情 | Deploy で止まる | 柵の向こうに一歩出せる |

完成を待たない夏は、 雑に出す夏じゃない

カーテンを閉じた真昼に、静かに実装する。
夜はバッチに任せる。
祝日は、拠点の輪郭で区切る。

7 月の設計は、どれも強度を分ける話でした。
Feature Flag も同じです。

完成を待たないことは、雑に晒すことではない。
未完成の光を入口で調光することです。

部屋ごと閉鎖する鍵ではない。
一段だけ落とす調光器。
オンにしたら終わりでもない。
オフに戻して、分岐を消して、初めて仕事が終わる。

もし今、Deploy の上で「完成してから」と止まっているなら。
その完成は、本当に今日必要な完成か。
それとも、出し方の輪郭がないだけか——
一度だけ問い直してみませんか。

小さく出す夏は、完成の定義を下げる夏じゃない。
出す単位を小さくする夏です。

夜間へ逃がした静けさの上で、柵を一本足す。
その先で、指は少しだけ Deploy を押しやすくなる——
僕には、それがはっきり見えました。

ひとりごと

完成待ちのブランチを閉じたとき、少しだけ勝ちを感じました。

勝った相手は、品質じゃない。
「もっと整えてから」と聞こえる、終わりのない声です。

粗いものは、入口の向こうに置く。
main には、畳める形で載せる。
消す日を書く。
上限を守る。

夏の技術学習は、新しいフレームワークより、先にこの出し方かもしれないと思いました。

同じように、完成待ちで夏が止まっている人のヒントになれば嬉しいです。

あわせて読みたい

▼ 思想側の一本として（逃げ道にしない話）

今回の実務設計の前提です。
期限と名前がないフラグは、仕組みじゃない、という話。

▼ 出す前に、日中の静けさを守る線として

小さく出す設計も、真昼の集中があってこそ続く——その前段です。

▼ 怖さの正体が「塊」であるとき

フラグは鋸ではない。
出すあいだの安全柵、という感覚の原点です。

▼ 触りたい／手放したいを分けた夏の入口

「出し方を卒業する」が願い事だったところから、今日の仕組みへ繋がります。

▼ 出したあとの運用を先に書く話

出す・畳む・残さない。
保守の温度感が近い記事です。

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

完成待ちで止まるリリース。
フラグを足すべきか、まだブランチに留めるべきか。
一人だと、倉庫と柵の境目がぼやけやすいです。

作戦会議室では、個人開発の出し方——命名、上限、消す日、週次の見方——を、現場の粒度で分け合える場所にしたいと思っています。
Feature Flag の続きや、来週の YAGNI（スコープ半分）とセットで整えたいとき、必要なタイミングで覗いてみてください。

参加する

Substack はじめました

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

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

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

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

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

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