アプリ開発におけるYAGNI：その本質、原則の要点、実践的なメリット

YAGNIとは？

YAGNI（You Aren't Gonna Need It）— エクストリームプログラミング（XP）の原則で、“それは必要ないだろう”という意味です。ルールはこうです：現在のユーザーストーリーで要求されていない機能は決して実装しないこと。今日必要でない機能は、“念のため”でも作ってはいけません。

この用語は、XP methodology（Kent Beckと共に）の共同執筆者の一人であるRon Jeffriesによって作られました。Jeffriesは述べています：“動作する最も単純なものを実装し、必要な時まで何も追加しないこと”。YAGNIは計画の禁止ではなく、時期尚早な実装の禁止です。

Standish Group CHAOS Report（2023）によると、平均的なソフトウェア製品の機能の64%はめったに使われないか、全く使われません。モバイルアプリに外挿すると — 書かれたコードの半分以上がユーザーに価値をもたらしません。YAGNIはこのリソースの無駄を防ぎます。

YAGNIを厳格なフィルターとして適用してください：すべての機能は「今、どの特定のユーザー問題を解決するのか？」という質問に答えなければなりません。答えがないなら — その機能は必要ありません。

YAGNIと怠惰や近道の違い

YAGNIは高品質なアーキテクチャの拒否ではありません。YAGNIは不要なコードを書くことを禁止しますが、正しいコードを書くことを禁止しません。現在の機能にクリーンな抽象化レイヤーが必要なら — それを作成してください。レイヤーが必要ないなら — 作成しないでください。重要な違い：YAGNIは機能に関するものであり、品質に関するものではありません。

開発者はしばしばYAGNIと意図的な技術的負債の蓄積を混同します（技術的負債は常に妥協であり、YAGNIは効率の原則です）。違いは、技術的負債は認識され文書化されるのに対し、YAGNI違反は単なる余分な作業であることです。

自問してみてください：「今この抽象化を作らなければ、必要になった時にリファクタリングにどれくらい時間がかかるか？」リファクタリングの時間が今書く時間より短ければ — 延期してください。

モバイルプロジェクトにYAGNIが重要な理由

モバイル開発は3つの理由でYAGNI違反に特に敏感です：APK/IPAサイズはインストール変換率に直接影響し、モバイルプロジェクトのコンパイル時間はコード量に比例して増加し、余分な機能ごとに障害点が増えます。YAGNIは怠惰についてではなく、集中についてです。

Google Play Console Data（2023）の調査では、APKサイズが10MB増えるごとにインストール確率が1.2%低下することが示されました。未使用のコードはリポジトリのゴミであるだけでなく — 直接的な金銭的損失です。余分なライブラリ（「後で追加するかもしれない」機能のため）はAPK肥大化の最も一般的な原因です。

Gradle Build Performance Report（2024）によると、Androidプロジェクトの追加モジュールごとに完全ビルド時間が3～7秒増加します。「念のため」5つのモジュールを追加すると — ビルド時間の増加はビルドごとに15～35秒になります。1年間で、5人の開発者チームはコンパイル待ちで最大200人時を失います。

CIでバイナリサイズを監視してください：警告限度を設定します（例：コミットあたり+500KB）。新しい機能なしでサイズが増えた場合 — それはコードレビューで議論すべきYAGNI違反です。

YAGNI vs ゴールドプレーティング：実践例

ゴールドプレーティング：時期尚早なアニメーション

ゴールドプレーティング — 製品を「改善」しようとして要件を超えた機能を追加すること。典型的な例：デザインがシンプルなフェードを指定しているにもかかわらず、開発者が画面間の複雑なトランジションアニメーションを追加する。アニメーションに2日かかり、ユーザーは気づかず、異なるデバイスでのバグが何年もプロジェクトを悩ませます。

UX Collective Annual Report（2023）によると、ユーザーの78%はアニメーションではなく、スピードと安定性でアプリを評価します。YAGNIが言うには：アニメーションが要件に指定されていないなら — 実装しないこと。デザイナーはUX問題を解決するために実際に必要になった時にアニメーションを追加します。

モックアップにあるものだけを実装してください。デザイナーがアニメーションを描かなかったなら — それは存在すべきではありません。モックアップからの逸脱はすべてYAGNI違反です。

20言語への時期尚早なローカライゼーション

スタートアップによくある間違い：「将来の国際市場進出のために」すぐに20以上の言語をサポートすること。YAGNIが推奨するのは：現在の市場の言語のみにローカライズすることです。新しい言語を追加するたびに、翻訳者の時間、文字列の切り捨てテスト、RTLレイアウトのデバッグが必要です。

Deloitte Digital Globalization Survey（2022）によると、モバイルアプリの60%は最初の市場から出ることはありません。それがあなたのケースなら — 多言語サポートに費やしたリソースは無駄になります。YAGNIアプローチ：英語（ベース）+ ターゲット市場の言語。その他は — 実際に地域に進出する際に。

優先順位付けにYAGNIを使用してください：機能が今後2四半期のロードマップにないなら — 開始しないでください。ロードマップは文書化され、プロダクトマネージャーによって承認される必要があります。

AndroidとiOSでYAGNIを適用する方法

AndroidでのYAGNI：不要なライブラリを追加しない

Androidプロジェクトはライブラリインフレーションに悩まされています。開発者はビジネスロジックの最初の行を書く前から、Retrofit、OkHttp、Gson、Room、Dagger Hilt、Navigation Component、DataStoreを追加します。YAGNIが推奨するのは：予防的にではなく、実際の必要性に応じてライブラリを追加することです。

// YAGNI違反：ライブラリの予防的組み込み
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// そしてアプリは今は単に"Hello World"を表示するだけ

ライブラリは独自の複雑さを持つ依存関係です。それぞれにバージョン更新、破壊的変更時の移行が必要であり、APKサイズを増加させます。追加するライブラリは、そのライブラリが解決する具体的なタスクが発生した時に。OkHttp（最小限のHTTPクライアント）から始め、RESTクライアントが必要になったらRetrofitを追加し、というように進めてください。

iOSでのYAGNI：SwiftUIを強制しない

SwiftUIは強力なフレームワークですが、その採用は実際のニーズによって駆動されるべきです。プロジェクトがiOS 14+で開始され、カスタムUIコンポーネントの要件が最小限なら — SwiftUIは良い選択です。プロジェクトがiOS 13をサポートする必要があるか、複雑なカスタムジェスチャーを必要とするなら — UIKitが正しいソリューションです。YAGNIは「流行りだから」という理由でのSwiftUIへの移行に反対します。

// YAGNI：SwiftUIに実際の利点がない限りUIKitを使用
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "プロフィール"
    }
}

// SwiftUIが必要なら — UIHostingControllerを介して統合
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Point-Free: 「SwiftUI vs UIKit Decision Guide」（2024）の分析は推奨します：明確なビジネス上の理由（例：デザイナー向けのLive Previewの必要性）なしに、既存のUIKit画面をSwiftUIに移行しないこと。動作しているコードを書き直すことは直接的なYAGNI違反です。SwiftUI — 新しい画面用、UIKit — 既存の画面用。

YAGNIに従う際の典型的な間違い

悪いアーキテクチャの言い訳としてのYAGNI

最も危険な間違いは、悪いアーキテクチャの言い訳としてYAGNIを使うことです。「リポジトリレイヤーは作らない。YAGNIだから — ViewModelに直接クエリを書こう」。これはYAGNIではなく、技術的負債を蓄積しているのです。YAGNIは不要な機能を禁止しますが、アーキテクチャの整合性を禁止するわけではありません。

アーキテクチャは保守性への投資です。3画面以上を書いているなら — 基本的なアーキテクチャレイヤー（MVVM、リポジトリ）はすでに正当化されます。1画面なら — よりシンプルなアプローチを取ることができます。鍵：現在の機能に必要なアーキテクチャの最小限を決定し、それ以上追加しないこと。

判断を「アーキテクチャ上の」ものと「機能的な」ものに分けてください。アーキテクチャ上の判断（レイヤー、ナビゲーション、DI）はYAGNIの対象外です — これらは保守性に必要です。機能的な判断（機能、スクリーンショット、アニメーション）は対象です。

APIを扱う際のYAGNIの盲目的な適用

もう一つの極端 — 将来のAPI契約を無視すること。開発者がバックエンドから5つのフィールドを持つJSONを受け取り、「残りはYAGNIによれば必要ない」として3つだけをパースする。問題：フィールドが追加されると、レスポンスが変更された場合にバックエンドがパースを壊す可能性があります。解決策は、すべてのレスポンスフィールドをマッピングすることです。たとえ今すべてを使わなくても。

Meta API Design Guidelines（2023）によると、クライアントはサーバーが返すすべてのフィールドをパースし、未使用のものを無視するが、構造全体を破棄してはいけません。YAGNIはここでは別のことを指します：「バックエンドが返すかもしれない」といって、まだ仕様にないフィールドの処理を追加しないこと。

レスポンス構造全体をパースしてください（サーバーが現在返すすべてのフィールド）。現在のAPI仕様にないフィールドの処理は追加しないでください。これはYAGNIと変更への回復力のバランスです。