YAGNI原則とは?開発者必見、効率的な開発のコツ

ざっくりと

  • 必要ないものは作らない
  • 開発効率を高める
  • ユーザーにとって使いやすい

YAGNI原則とは、必要ないものは作らないという考え方です。

概要説明

YAGNI原則とは「必要ないものは作らない」という考え方である。なぜならば、無駄な機能を作ると開発時間が増え、コストもかかるから。

例えば、未来のためにと考えて作った機能が使われない場合。そして、ユーザーにとっても使いやすい製品ができる。「必要ないものは作らない」は、「必要になってから作れ」という考えになる。

つまり、必要な機能だけに集中することで、質の高い製品ができる。だから、開発効率とユーザー満足度が高まる。

職業職種

  • ソフトウェア開発者
    ソフトウェア開発者は、YAGNI原則をよく使用する。なぜなら、効率的な開発が求められるから。例えば、締め切りに間に合わせるため。
  • プロジェクトマネージャー
    プロジェクトマネージャーは、YAGNI原則を採用することが多い。なぜなら、プロジェクトのコストと時間を管理する必要があるから。例えば、予算オーバーを防ぐため。
  • UI/UXデザイナー
    UI/UXデザイナーは、YAGNI原則を考慮することがある。なぜなら、ユーザーにとって使いやすいデザインが必要だから。例えば、使われないボタンやメニューを省くため。

YAGNI原則は、名前の由来は”You Aren’t Gonna Need It”で、これは英語で「それは必要ない」という意味です。YAGNIは、ヤグニと読みます。

代表例

  • Agile Alliance
    Agile Allianceは、YAGNI原則で有名である。なぜなら、アジャイル開発の推進団体として、YAGNI原則を広めているから。例えば、教育プログラムやカンファレンスでの紹介。
  • 37signals(現Basecamp)
    37signals(現Basecamp)は、YAGNI原則で名高い存在である。なぜなら、シンプルなソフトウェア設計と効率的な開発を重視しているから。例えば、製品「Basecamp」では必要最低限の機能しか提供しない。
  • Kent Beck
    Kent Beckは、YAGNI原則で世間に知られている。なぜなら、Extreme Programming(XP)の創始者として、YAGNI原則を広めたから。例えば、多くの著書や講演での紹介。

手順例

以下は、YAGNI原則を実践する手順です。
  1. プロジェクトの目的を明確にする
    目的を明確にすることで、何が必要で何が不必要かがわかる。なぜなら、目的に合わない機能は不必要だから。例えば、目的に合わせたフィーチャーリストの作成。
  2. 必要な機能だけをリストアップする
    必要な機能だけをリストアップする。なぜなら、それがYAGNI原則の核心だから。例えば、ユーザーストーリーやタスクの整理。
  3. 開発を始める前にチームで確認する
    開発を始める前に、チームで必要な機能について確認する。なぜなら、みんなが理解していることでムダがなくなるから。例えば、スプリントプランニングでの確認。
  4. 開発中も定期的に見直しを行う
    開発中も定期的に必要な機能を見直す。なぜなら、プロジェクトの進行によって必要な機能が変わる可能性があるから。例えば、レビューミーティングでの確認。
  5. リリース後もフィードバックを収集する
    リリース後もユーザーからのフィードバックを収集する。なぜなら、実際に使ってみて初めてわかることもあるから。例えば、ユーザーサーベイやデータ分析。

類似語

  • KISS(Keep It Simple, Stupid)
    KISSは、YAGNI原則の類似語である。なぜなら、両方ともシンプルな設計や開発を目指すから。例えば、不必要な複雑さを避ける。
  • DRY(Don’t Repeat Yourself)
    DRYは、YAGNI原則の類似語である。なぜなら、効率的なコードを書くことが共通しているから。例えば、同じコードを何度も書かないようにする。
  • MoSCoW法
    MoSCoW法は、YAGNI原則の類似語である。なぜなら、どの機能が必要でどれが不必要かを分類する手法だから。例えば、Must-have, Should-have, Could-have, Won’t-haveで機能を分類。

反対語

  • Gold Plating
    Gold Platingは、YAGNI原則の反対語である。なぜなら、不必要な機能や装飾を追加することを推奨するから。例えば、ユーザーが求めていない豪華なUIを作る。
  • Feature Creep
    Feature Creepは、YAGNI原則の反対語である。なぜなら、プロジェクトが進行するうちにどんどん新しい機能が追加されるから。例えば、開発中に急に新しい機能を追加する。
  • Overengineering
    Overengineeringは、YAGNI原則の反対語である。なぜなら、単純な問題に対して複雑な解決策を用いるから。例えば、シンプルなウェブサイトに複雑なデータベースを組み込む。

会話例

  • プロジェクトミーティングでの会話
    「この新機能、追加しようか?」
    「いや、YAGNI原則に従って、必要ないものは追加しない方がいいよ。」
  • コードレビューでの会話
    「このコード、将来的に使うかもしれないから残しておくね。」
    「それはYAGNI原則に反するから、今必要ないなら消しておこう。」
  • プロダクト企画での会話
    「ユーザーが使いやすいように、この機能もつけよう!」
    「確かに便利かもしれないけど、YAGNI原則に基づいて、今は必要ない機能は後回しにしよう。」

注意点

YAGNI原則を使用する時の注意点は、過度なシンプルさである。なぜならば、あまりにもシンプルすぎると、後で機能を追加するコストが高くなる可能性があるからだ。

例えば、将来的に必要になる基本的な機能まで削ってしまうこと。そして、その結果、後で大きな修正が必要になる。だから、バランスが大事。

YAGNI原則とKISS(Keep It Simple, Stupid)は、間違えやすいので注意しましょう。

YAGNI原則は、今必要ないものは作らないという考えです。

一方、KISSは、全体的にシンプルな設計やコードを目指すという考えです。

記事を書いてる人

ガラケー時代からWEB開発やってる自宅SE です。

「○○を知りたい!!」「○○が分からない!!」などありましたら、Twitterでもブログでもコメントいただければ、ご期待に添えるように頑張ります!

ネット事件簿チャンネルを運営しているので、YouTubeもぜひ覗いてみてください!!

雨おやじのSNSを覗く!!
IT用語辞典
雨おやじのSNSを覗く!!
ITkagyo

コメント