こんにちは、マウンテンマンです。
ソフトウェア開発の世界には、ソフトウェア開発に関するさまざまな法則、経験則、原則や哲学が存在します。こんなものは当然、業界の関係者しか知りませんし、下手をすると業界でも知らない人は多い感覚です。
簡単に言えば、”あるある”ネタみたいなもので、聞くと、「確かに！」と共感できるものも多く存在します。
ソフトウェアを知らない人でも、聞くと、ソフトウェアの世界がどんなところなのか垣間見れて、結構面白いものですよ。
本記事では、そんなソフトウェアの世界に伝わる原則の１つ、YAGNIについて解説します。
YAGNIとは
YAGNIとは、”You ain’t gonna need it”という文の頭文字をとった言葉です。
“そんなもの必要ない”、という意味となります。
この言葉はつまり
ソフトウェアに対して、将来用の機能を追加しようとする時、天から聞こえてくる言葉
なのです。
本当に必要なものだけを作り、余計には作るべきではない、ということを説いています。
どういうこと？
プロダクトを開発していて、よくあるのが、ユーザーの意見を聞きすぎてしまうこと。
既に要件を整理して、機能も固めているはずなのに、
「こういう機能もあったらいいですね！まぁ本当、レアケースなんだけど！一応、実装しておいてくれない？」
こういうことを平気で言ってくるお客様もいるのです。ソフトウェア開発では、ある種、当たり前の光景です。
しかし、予算も人員も限られていますから、
「そんなの聞いていられない！」
というのが開発者の本音。
実際のところ、
こういった経緯で追加された機能が使われることはあまりない感覚です。
なぜ、こういう事が起きるのか？それにはいろいろな考察ができます。
- そもそも使用頻度が低いレアな機能として実装されるため、優先度も品質も低くなりがち。
- その機能が必要になった時、あらかじめ機能が用意されていればソフトウェア改造無しで、ユーザーニーズに対応できる、と思い込んでいる。それゆえ、実装されたことだけで満足しがち。
- 本当に必要な機能は、最初の要件定義で整理されている。ユーザー側で強い発言力を持つキーマンによる”鶴の一声”に迎合し、押し切られて機能追加しがち。
開発者としては、モノをたくさんつくると不具合も増えますし、その後の保守も大変です。
どうすればいいの？
結局のところ、ソフトウェア開発者は、YAGNI原則に従えばよいのでしょうか？
YAGNIの言葉を心の中で思い浮かべ、まず、
「本当にそれ必要？」
と考えてみるべきだと思います。使われない機能を作れば、その分、投資した費用を回収することも難しくなります。
必要かどうかを決めるポイントとして、次の３点について考えてみるとよいでしょう。
- 費用対効果について考える
- 既存機能で代替できないか検討する
- 作った後の保守費用について考える
ソフトウェア以外の場でも
YAGNIは、エクストリーム・プログラミング、というソフトウェア開発プロセスの中で提唱された原則とされています。
ただ、考え方としてソフトウェア以外のことにも通じるものがあると感じます。
言うなれば、以下のような感じでしょうか。
「必要なものは必要な時に必要な分だけあればよい。モノを持ちすぎることなかれ。」
有名なトヨタ生産方式で謳われるJust-in-time(必要なものを必要な時、必要なだけ作る)という考え方がありますが、本質は同じです。
まとめ
- YAGNIとは、”そんなの必要ないって”、と無駄な機能を作ってしまわないよう戒める先人たちの経験則(原則)
- 無駄なものを作っても、将来の負債となるだけ。作っても使われないことも経験的に多いので、できるだけ作らない方がよい。(シンプル is ベスト)
- どうしても必要とされるなら、要求元としっかり議論し、無駄とならないような機能として作るべき。(本当に必要なものは、初期の要件定義でピックアップされているはず)
昨今、アメリカのシリコンバレーなどでは当たり前のアジャイル開発手法が日本でも浸透し始めてきています。このYAGNIは、アジャイル的な開発経験の中で見出されてきた原則のように思います。
仕様追加などを受け入れるかどうかはプロジェクトマネージャーやSEの範疇かもしれませんが、最終的に苦労するのはプログラマーかな、と思います。
そのため、プログラマーこそ、このYAGNIを強く意識できたらいいんじゃないか、と思います。
自分が作ったものが無駄、とされたら悲しいですもんね。。(中には、どんなものでもオーダーされたら作る、というプロ意識を持つプログラマーもおりますが)
最後までお読みいただきまして、ありがとうございました！
コメント