見出し画像

「いつか使うかも」 を切って出した

YAGNI でスコープ半分にした個人開発

機能表を開いた夜、また同じ行が並んでいた。

「ダッシュボードのフィルタ(あとで)」
「設定画面のテーマ切替(いつか)」
「Cursor フル同梱(会員が喜ぶかも)」

どれも悪くない。
どれも、今のリリースを止める。

Feature Flag で「完成してから出す」はやめた。

見せ方の柵はできた。

なのに、作る量そのものはまだ膨らんでいた。

だから今日は、こう決める話を書きます。

「いつか使うかも」を切って出す。
スコープを半分にする——YAGNI の夏の実践記録です。


フラグがあってもリストは減らない

みなさんは、個人開発で「これは後で足せばいい」を、先に設計図へ書いてしまった経験はありますか。

僕には、それが 7 月の Vault 最小版と、手元の個人開発の両方でありました。

Feature Flag は、「作ったものをどう見せるか」の設計です。
入口を閉じたままマージできる。
粗い画面を本番に載せなくていい。

フラグは、まだ要らないものを作る言い訳にもなりうる。

「どうせ隠せるから、今のうちに入れておこう」

隠せる安心がスコープを太らせる。
完成待ちをやめたのに、作る待ちが増える——
形を変えたブロッカーでした。

7 月は走り出す月です。
増やさない二週間も、触らない一本も、空白週も置いた。
コードと機能表だけ、まだ「いつか」が居座っていたのです。

増やす声は、技術の言葉を借りると止まりにくい。

「拡張性のために」
「あとで困らないように」
「今のうちに型だけ」

真面目に聞こえるぶん、切るのが難しい。
正しそうな声ほど、先に札が要る——
触らない一本と同じ温度です。

「足りないかも」 と思って半分を先に足していた

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

👇️ Markdown 形式
| 段階 | やり方 | 起きていたこと |
|:---|:---|:---|
| 構想 | 理想の完成形を書く | 必要機能と「あったらいい」が混ざる |
| 実装 | あったらいいを先に足す | 核心が後回しになる |
| リリース | 全部そろってから | 出る日が遠のく |
| 振り返り | 「まだ足りない」 | 次のリストがさらに増える |

安全に見えた。
実際は、未来の自分の都合を、今日の自分に前借りしていただけだったのです。

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 の役割分担

混乱しやすいので、姉妹記事として分けます。

👇️ Markdown 形式
| | Feature Flag(7/21) | 本記事(YAGNI) |
|:---|:---|:---|
| 問い | 作ったものをどう見せるか | まだ要らないものをどう切るか |
| 敵 | 完成待ちの長いブランチ | 「いつか使うかも」の肥大 |
| 手段 | 入口の柵・期限・上限 | 成功条件・半分カット・作らない |
| 失敗の翻訳 | 粗いから出せない | 足りないから足す |

両方そろうと、夏の個人開発は前に出やすい。
片方だけだと、こうなる。

Flag だけ
👉️ 隠しながら作り続ける

YAGNI だけ
👉️ 切ったが、出し方の怖さは残る

僕の順番は、Flag で怖さを減らし、YAGNI で量を減らす、でした。
人によっては逆でもいい。
大事なのは、同じ道具で両方を済ませないことです。

【実践結果】 切ったもの/残したもの

Vault 最小版(約束 ②)

ここから先は

3,084字 / 3画像

メンバーシップ ¥ 500 /月

■メンバーシップ 15 年目フリーランス開発者のひとり戦略を支える作戦会議室です。\ 案件に追われる…

ベーシックプラン

¥500 / 月

最後まで読んでいただき、ありがとうございます。もしこの記事が「役に立った」「心に響いた」と感じたら、珈琲一杯分サポートいただけると嬉しいです。あなたの温かい応援を力に、また次の創作活動に励みます。