YAGNIの法則

ちょっと私生活を綴った記事が多くなってきているので、
たまには真面目な記事を綴っていきます。

今日は「YAGNIの法則」というもの。

あまり聞き馴染みのない言葉かもしれないですが、
プロダクト開発（今回は特にソフトウェア開発も関係します！）において
重要な考え方になりますので、ぜひご一読ください！：）

YAGNIの法則とは・・・？

日本語で読むと「ヤグニのほうそく」なのですが、
英語の「You Aren’t Going to Need it.」の略称になります。

中学校の英語で習う「be going to~」の構文がありますが、
日本語に訳すと「それはきっと必要にならない」という意味。


プロダクト開発の開発範囲（スコープ）を絞っていく際に、
使われるため、少しでも機能をリッチにしようと、
「あれも、これも」となってしまいがちなケース、業務におけるあるあるかと思います。


特にソフトウェアはイレギュラーな手運用ありきで考えることをよしとしないので、
その分機能に加える＝開発工数が膨らんでしまう、という構造になってしまいます。。。

要約すると、「それはきっと必要にならない法則」
→必要性が強くない機能は要件から落としてプロダクト開発しましょう！ということです。

なぜこの法則が重要なのか？

このYAGNIの法則、調べるとソフトウェア開発で出てくる用語だそう。
でも残念ながらソフトウェア開発の要件を絞っていくのはビジネスサイドが多いかと推察します。

すなわち、
この法則「ソフトウェアの開発担当者よりも、要件決定をするビジネスサイドが知ってほしい」法則になるのです！


従来、「ソフトウェア開発」といえば、

• スクラッチ開発
• オンプレミス開発

という言葉に代表されるような、0ベースでカリカリ開発していく手法を取っていましたが、
最近では、

• パッケージ開発（PKG開発）
• クラウド開発

というような既存のソフトウェアをうまく組み合わせてソフトウェアを構築するように
トレンドが変化しているようです。


少し聞き馴染みのある言葉で言うと、

• Saas（Software as a service）
  • ソフトウェアとしてのサービス
    ＝既存ソフトウェアを製品化したもの
• API（Application Programming Interface）
  • ソフトウェアやプログラミングの連携を容易にするために設けられる、
    外部とやりとりするための窓口のようなもの

などの台頭で、パッケージ開発やクラウド開発の比重が高まっているのですね♪

ちなみに既存のSaasやAPI連携を利用しようとすると、
機能を増やすごとにオプション料金を発生させるケースがほとんどです！

なので、YAGNIの法則に話を戻すと、
「要件はミニマムにしましょう！」と言うのが基本スタンスになります。

まとめ

いかがでしたでしょうか。
今日は「YAGNIの法則」について綴ってみました。

少しまとめてみると、以下が本記事の要点ですね！

• 「YAGNIの法則」とは、
  「必要性が強くない機能は要件から落としてプロダクト開発しましょう！」と言う基本の考え方
• 元々はソフトウェア開発における専門用語だが、
  実はビジネス側で意識した方がメリットが大きい
• ソフトウェア開発の方法が変わってきており、
  最近の「パッケージ開発」を使う場合は、要件や機能を増やすとオプション料金が発生するケースがある。
  そのため、より強く「YAGNIの法則」を意識した方が良い！

マーケティングやプロダクト開発に関する記事を投稿しますので、
お楽しみに♪