YAGNIの原則
YAGNIの法則はご存知ですか。
You Ain’t Gonna Need It. の略で、アジャイルとかでよく言われる「いらんもん作るな」の原則ですね。
「これいるやろー」で前もって作りこまれた機能は10%しか使われないし時間の無駄だよね（10%の根拠はあるんかな）、っていうあれです。
「まだ必要じゃない」って意訳する人もいますがこれは悪い意訳です。
YAGONIの原則
ではYAGONIの原則はご存知ですか？
これは「ここは明らかにあとで必要になるやつだから工数よこせ」の法則です。
ご存じないとおもいます。今僕が作ったからです。
ある程度の経験を積んだプログラマーならわかるとおもうんですが、「これは予め作りこんでおいたほうがいいな」っていう半ば直観めいた洞察、あるとおもいます。そういうことです。
スタータップ、それもWeb系だとプロトタイピングだからという名目のもとカウボーイ・ビバップな実装が美徳とされることが多いのではないでしょうか。Done is better than perfect、つまりDIBTPですね。
ベンチャーというのはつまり前人未到の地へ赴くことなのでさっと作って世にコンセプトを問わねばなりません。存在しない市場に向けた間違ったアイディアを完璧に実装するのは時間の無駄です。だからなるべく必要最低限、シンプルな状態で作り上げるのが常にベターなわけです。
というのは建前で、実際問題として明らかに作りこんでおくべき部分というものは存在しています。例をあげましょう。
例えばお金を扱うサービス。ここではセキュリティは絶対条件です。タコなものを作って世に問うと深刻な怒られや賠償が発生して高速で退場することになります。
またバズによって最初の集客を考えている場合も最低限のセキュリティは対策したほうがいいでしょう。タコ実装のままバズったサービスをオモチャにするのが好きな人たちが集まって脆弱性をあげつらってバズろうとするからです。そういう流行り方をすると普通の人たちは離れてしまいます。
僕が大好きな対戦ゲームであればサーバーやマッチングの安定性ですね。どんなにゲーム内容が良くても、ほかの人と対戦できない対戦ゲームはあっという間に人がいなくなります。そして一度離れた人間を呼び戻すのは、新規に参入してもらうよりも難しいのです。World war 3は完全にオワコン化してしまい、もはやレビューすらつきません。
上の例は大きなレイヤーでの話ですが、ミクロな実装レベルでも「ここは抽象化して柔軟に作りこんでおくべきだな」っていう勘が働くことはよくあるとおもいます。そしてそういう勘は90％以上正しいです*1。
そういうとき、主に作業量の見積もり部分でYAGNIを信奉するタイプの人と議論に発展することがあります。
相手はメジャーな法則を持ち出して盾にしてくるので「職人の勘」を論拠とするこちらは不利です。そういったときにYAGONIの原則を持ち出して戦ってください。お前を信じろ。でも勘が外れたらセプクだ。
YAGNIの適用領域
そもそもの話ですが、YAGNIを実装レベルの議論に持ち込むのが間違いです。
フロントエンド的なたとえ話をするならば、YAGNIを信じるあまりフレームワークを使わずにReactだけで作ろう*2！ みたいなことをすると、もはやだれにも管理不可能な怪物が出来上がります。辛くてもFluxで状態管理をしておけば、スケールさせたくなったときにReduxや未来のほかのいけてるフレームワーク、あるいはElmへの乗り換えも簡単です。
ざっくり断言しますと、YAGNIを気持ちよく適用できる領域はビジネスのコンセプト、あるいはペーパープロトタイピングの時点までです。
それより下のレイヤーで出来ることは「ベストを尽くす」、それだけです。どういうレベルで作りこんでいくかは、ビジネスの規模、メンバーの力量、そして納期で決まります。
YAGNIに出る幕はありません。
まとめ
YAGNIは基本的に結果論でものを言っているだけの原則なので適用できる場所は少ない。コンセプト設定の段階まで。
結局、メンバーの力量以上の速度や精度でサービス作るなんてできないわけで、そういうのを耳に心地いい小手先の言説でごまかすとパスワードが平文で保存されたりクレジットカードの情報が保存されて流出したりするんじゃないのかなとおもいました。
がんばれ。
