「いつか使うかも」 を切って出した
YAGNI でスコープ半分にした個人開発
機能表を開いた夜、また同じ行が並んでいた。
「ダッシュボードのフィルタ（あとで）」
「設定画面のテーマ切替（いつか）」
「Cursor フル同梱（会員が喜ぶかも）」
どれも悪くない。
どれも、今のリリースを止める。
Feature Flag で「完成してから出す」はやめた。
見せ方の柵はできた。
なのに、作る量そのものはまだ膨らんでいた。
だから今日は、こう決める話を書きます。
「いつか使うかも」を切って出す。
スコープを半分にする——YAGNI の夏の実践記録です。
フラグがあってもリストは減らない
みなさんは、個人開発で「これは後で足せばいい」を、先に設計図へ書いてしまった経験はありますか。
僕には、それが 7 月の Vault 最小版と、手元の個人開発の両方でありました。
Feature Flag は、「作ったものをどう見せるか」の設計です。
入口を閉じたままマージできる。
粗い画面を本番に載せなくていい。
フラグは、まだ要らないものを作る言い訳にもなりうる。
「どうせ隠せるから、今のうちに入れておこう」
隠せる安心がスコープを太らせる。
完成待ちをやめたのに、作る待ちが増える——
形を変えたブロッカーでした。
7 月は走り出す月です。
増やさない二週間も、触らない一本も、空白週も置いた。
コードと機能表だけ、まだ「いつか」が居座っていたのです。
増やす声は、技術の言葉を借りると止まりにくい。
「拡張性のために」
「あとで困らないように」
「今のうちに型だけ」
真面目に聞こえるぶん、切るのが難しい。
正しそうな声ほど、先に札が要る——
触らない一本と同じ温度です。
「足りないかも」 と思って半分を先に足していた
かつての僕の個人開発スコープは、だいたいこうでした。
| 段階 | やり方 | 起きていたこと |
|:---|:---|:---|
| 構想 | 理想の完成形を書く | 必要機能と「あったらいい」が混ざる |
| 実装 | あったらいいを先に足す | 核心が後回しになる |
| リリース | 全部そろってから | 出る日が遠のく |
| 振り返り | 「まだ足りない」 | 次のリストがさらに増える |安全に見えた。
実際は、未来の自分の都合を、今日の自分に前借りしていただけだったのです。
Vault サンプルの設計書でも、同じ癖が出ました。
含める候補に、こう並んでいた。
📍 Cursor 層フル（skills / agents / hooks）
📍 サンプルノート 10 本
📍 .obsidian の推奨設定一式
📍 更新の自動化まわり
会員が喜ぶかも、という想像は正しいかもしれない。
でも v0.1 の成功条件は、もっと短かった。
zip を開いて骨格が見える。
テンプレが使える。
サンプルが数本あって、リンクが通る。
README だけで最初の 1 ノートまで辿れる。
成功条件の外にあるものは、今はいらない。
いらないのに載せると、README が迷子になり、配布日が延びる。
七夕の技術の願い事で「手放したい」ことを書いたときも、気づきは近かった。
リストが膨らむ原因は、増やしたものより手放し損ねたものにある。
機能表の「いつか」は、手放し損ねの別名でした。
Feature Flag の隣に切るルールを置いた
転機は、Feature Flag の記事の末尾に自分で書いた一文でした。
スコープを半分にする YAGNI は、作らない側の設計です。
Feature Flag は、作ったものをどう見せるか側の設計。
書いておきながら、前者をまだ運用していなかった。
もう一つの転機は、短い集中 3 日です。
Vault に一本絞ったとき、やったのは骨格・README・サンプル数ファイルだけ。
まるごと完成させることは禁止した。
あの 3 日は、すでに YAGNI の予行演習だった。
だから 7 月末、ルールを言語化した。
実験名:
スコープ半分で出す
対象:
Vault v0.1 と、個人開発の「いつか」機能表
禁止:
「あとで使えるから今入れる」
切る基準は、三問だけです。
1️⃣ 今の成功条件（v0.1／今週の一本）に必要か？
2️⃣ なくても出せるか？
3️⃣ 必要になったら、後から足せるか？
Yes / Yes / Yes なら、今は切る。
フラグで隠す対象にすらしない。
作らない。
吃音のある僕は、画面と文章で伝えることが多い。
だから足りない画面を恐れて、先に機能を足したくなる。
足りなさの正体は、しばしば説明不足であって、機能不足ではない。
README の一行と成功条件の短さが、先に要る。
誤解してほしくない点もあります。
YAGNI は、品質を捨てることではない。
テストを書かないことでも、雑に出すことでもない。
まだ来ていない要件を、今日のコードに入れないという話です。
今日必要な一本の品質は、落とさない。
明日の想像の品質を先に実装しない。
Feature Flag と YAGNI の役割分担
混乱しやすいので、姉妹記事として分けます。
| | Feature Flag（7/21） | 本記事（YAGNI） |
|:---|:---|:---|
| 問い | 作ったものをどう見せるか | まだ要らないものをどう切るか |
| 敵 | 完成待ちの長いブランチ | 「いつか使うかも」の肥大 |
| 手段 | 入口の柵・期限・上限 | 成功条件・半分カット・作らない |
| 失敗の翻訳 | 粗いから出せない | 足りないから足す |両方そろうと、夏の個人開発は前に出やすい。
片方だけだと、こうなる。
Flag だけ
👉️ 隠しながら作り続ける
YAGNI だけ
👉️ 切ったが、出し方の怖さは残る
僕の順番は、Flag で怖さを減らし、YAGNI で量を減らす、でした。
人によっては逆でもいい。
大事なのは、同じ道具で両方を済ませないことです。
