この技術でできること
- 「念のため」の不要なUI追加をブロックし、画面をシンプルに保てる
- 将来の不確実な要件よりも「今ユーザーが抱えている課題」に集中できる
- エンジニアの開発工数を、本当に必要な機能（MVP）だけに向けることができる
例: 記事リストの画面をデザインする時、「将来的に記事が増えそうだから、最初から高度なフィルターとソート機能もUIに入れておこう」という判断を止め、「まずはシンプルなリストだけ出し、記事が50件を超えた時点で検索を追加する」という段階的な設計に切り替えることができる。
なぜ難しいか
誰もが「先回りして考えておくのが優秀な仕事だ」と思い込んでいるからです。
デザイナーは「後からUIを追加するとレイアウト崩れが怖いから、最初から枠組みを設計しておきたい」と考えます。エンジニアも「後からデータ構造を変えるのは大変だから、最初から拡張性を持たせておきたい」と考えます。しかし、その「先回り」の予測はたいてい外れ、誰も使わない機能のコードだけがシステムに残り、今後の開発スピードを遅くする「負債」に変わります。
デザイン時の判断ポイント（Before/After）
パターン: プロフィールの過剰な入力項目
Before（現実の悪い例）: 「ゆくゆくはユーザー同士のマッチング機能も入れるかもしれない」という理由で、初期リリースから「趣味」「職業」「SNSリンク」「自己紹介（500文字）」の入力画面をデザインして実装を依頼する。 → エンジニアはマッチング用のデータベース設計まで考慮し工数が膨れる。結果、ユーザーは登録が面倒になり離脱する。
After（現実的な整理）: 今のMVPで必要な「名前」と「アイコン」だけを入力要素とし、余計な項目は一切配置しない。
なぜ改善されるか（なぜ現実的か）: 「とりあえず作って使われない」という最大の無駄を省けるため。実データがない段階での将来予測は外れやすいものです。だからこそ、実際のユーザー行動でたしかめてから（必要になってから）作る方が精度が高く無駄がないからです。
代替手段: 後からUIを変更する前提で、画面レイアウトにあえて「スペース（ホワイトスペース）」を残しておくことで、レイアウト崩れの不安を解消する。
アンチパターンと衝突（デザイナー × エンジニア）
❌ 「今後デザインが変わるかもしれないから、何でもできるようにして」
デザイナーの視点: 後でボタンの色や配置がガラッと変わる可能性があるので、Propsでなんでも自由に変更できる「万能コンポーネント」を作っておいてほしい。（品質＝将来の変更に対する柔軟性） エンジニアの視点: 「なんでもできるコンポーネント」は条件分岐が複雑になりすぎ、バグの温床になる。今の要件で確実に動くものだけを作りたい。（品質＝現在の仕様の確実な動作）
なぜ衝突するか（品質の定義差）: デザイナーは「未知の変更コスト」を重く見積もり、エンジニアは「複雑化による現在のバグコスト」を重く見積もっているため。
どう合意するか:
- 「もしかしたら」の予測ではなく、「今決まっている要件」だけで設計する合意を取る。
- 将来変更が起きた場合は、「既存パーツの拡張」ではなく「新しい別パーツを作る」か「その時に作り直す」というルールを決める。
実践チェックリスト
最低ライン（Must）
[ ] 「念のため」「あった方が便利そうだから」という理由だけで配置したUIがない [ ] エンジニアに対して「将来こうなるかもしれないから対応しておいて」と過剰な拡張性を求めていない
理想ライン（Better）
[ ] デザインレビューで、不要に見える機能に対して「これは必要になってから追加しませんか（YAGNIの観点）」と提案できる [ ] 後から機能が追加される前提で、最初から「拡張可能な余白を持ったレイアウト」を組んでいる
関連技術
前提となる技術
- KISS原則 — 機能を足す前に、状態をシンプルに保つ思考
セットで使う技術
- コンポーネント設計 — 万能化を避ける境界設計
次に学ぶ技術
- DRY原則 — 機能は重複させないが、セットで無駄を防ぐ
まとめ
- この技術の本質: 将来の不確実な予測を捨て、現在確定している価値だけを実装する勇気
- UXへの影響: 不要な機能がないため、ユーザーが迷わず最速で目的を達成できる
- 実務での判断軸: 「明日リリースしなければならないとしたら、この要素は絶対に必要か？」
- 次に学ぶべき技術: DRY原則（削った後は、残った機能を重複させない）
KISSが「複雑さを削る」原則であるのに対し、YAGNIはそもそも「未来への不安で足さない」原則です。
目的別のおすすめ:
