it

YAGNI原則の適用方法は?実装のタイミングと判断基準も!(機能開発:要件定義:設計思想:開発効率:無駄な機能の削除など)

当サイトでは記事内に広告を含みます

YAGNI原則の概念を理解しても、実際の開発現場でどのように適用すればよいか悩む方は多いでしょう。

「今必要か否か」の判断は状況によって異なり、経験と適切な基準なしには判断が難しい場面も少なくありません。

本記事ではYAGNI原則の具体的な適用方法・実装タイミングの判断基準・現場での実践方法について詳しく解説していきます。

YAGNI原則の適用方法:判断の基本フレームワークの結論

それではまず、YAGNI原則を適用する際の基本的な考え方と判断フレームワークについて解説していきます。

YAGNI原則を適用する際の最も基本的な問いは、「この機能は現在の要件・仕様・ユーザーストーリーに明示されているか」という確認です。

明示されている場合は実装すべきであり、「あると便利かもしれない」「将来必要になりそう」という曖昧な理由だけでは実装を見送るのがYAGNI原則の正しい適用です。

YAGNI適用の判断フロー

確認事項 判断
現在の要件・仕様に含まれているか 含まれる → 実装する
今すぐユーザーに価値を提供するか する → 実装する
「将来必要かも」という理由だけか そのとおり → 実装しない
後から追加するコストが極めて高いか 高い → 例外的に検討

要件定義フェーズでのYAGNI適用

要件定義の段階でYAGNI原則を意識することが、過剰設計を防ぐ最初のステップです。

ステークホルダーとの議論で「将来的にこんな機能も欲しい」という要望が出た場合、それが今のリリースに必要かどうかを明確に問い直す姿勢が重要です。

バックログに記録しておいて将来のスプリントで検討するというアジャイルのアプローチが、YAGNI原則と非常に相性よく機能します。

コードレビューでのYAGNI確認

コードレビューの場面でもYAGNI原則は有効に機能します。

レビュー時に「このコードは現在の要件に必要か?」「この抽象化は今必要か?」という観点でチェックすることで、過剰実装を早期に発見できます。

チーム全体でYAGNI原則を共有し、レビュー文化として定着させることがコードベース全体のシンプルさを維持する上で非常に効果的です。

実装のタイミングの具体的な判断基準

続いては、実装すべきタイミングを判断するための具体的な基準を確認していきます。

3回ルールとの組み合わせ

YAGNIと組み合わせて活用できる考え方として「3回ルール」があります。

同じパターンのコードが3回以上繰り返された時点で初めて抽象化・共通化を検討するというアプローチで、早すぎる抽象化を避けながら必要な共通化を適切なタイミングで行う指針となります。

1〜2回の重複でいきなり汎用化するのではなく、繰り返しが確認された段階で初めて対応するというのがYAGNI原則とも一致する考え方です。

後付けコストの見積もり

YAGNI原則を適用する際に考慮すべきもうひとつの視点が、後から機能を追加する際のコストです。

後付けコストが低い機能は今実装しなくてよく、後付けコストが非常に高い機能(データベーススキーマの根本変更など)は例外的に先行検討が合理的な場合もあります。

後付けコストの見積もりを判断基準に加えることで、より現実的なYAGNI原則の適用が可能になります。

スプリントゴールとの整合性チェック

アジャイル開発ではスプリントゴールを基準にYAGNI原則を適用するのが効果的です。

そのスプリントのゴール達成に直接貢献しない機能の実装は見送り、バックログに積んでおいて優先度を再評価するというサイクルを繰り返すことで、開発リソースを常に最も価値の高い機能に集中させることができます。

YAGNI原則適用の実践例

続いては、YAGNI原則の適用に関する具体的な実践例を確認していきます。

API設計でのYAGNI適用例

REST APIを設計する際、「将来的にフィルタリング機能が必要になるかもしれない」と考えて複雑なクエリパラメータを先行実装するケースはYAGNIに反します。

現在の要件で必要なエンドポイントのみを実装し、フィルタリング機能が実際に要求された段階で追加するアプローチが正しい適用例です。

データベース設計でのYAGNI適用例

「将来このテーブルに列が増えるかもしれない」と考えて多数のNULL許容列を先行追加するのはYAGNI違反です。

現在必要な列のみを定義し、実際に列が必要になった段階でALTER TABLEで追加するアプローチが推奨されます。

場面 YAGNI違反の例 正しい適用
API設計 不要なエンドポイントの先行実装 必要なエンドポイントのみ実装
DB設計 不要列の先行追加 現在必要な列のみ定義
UI設計 使われない設定画面の実装 必要な画面のみ実装
設計パターン 不要な抽象レイヤーの追加 シンプルな直接実装

まとめ

本記事では、YAGNI原則の適用方法・実装タイミングの判断基準・具体的な実践例について解説しました。

YAGNI原則の適用において最も重要なのは「現在の要件に含まれているか」という一貫した問いかけであり、アジャイルのスプリントゴール・コードレビュー・3回ルールと組み合わせることで効果的に機能します。

YAGNI原則を開発チームの文化として定着させることで、シンプルで保守しやすいコードベースを長期にわたって維持できます。

判断に迷ったときは「今本当に必要か?」という問いに立ち返ることが最善のガイドとなるでしょう。