買い物に行く
スペースシャトル
「将来必要になるかもしれないから」と、最初からマイクロサービスを導入する。
ユーザー数は10人なのに、Kubernetesクラスターを構築する。
それは「コンビニに牛乳を買いに行くのに、スペースシャトルを作る」ようなものです。
目的（買い物）は達成できますが、コストと時間がかかりすぎます。
- 「Hello World」を表示するだけの層が5階層ある
- まだ誰も使っていない機能のために、拡張性を議論している
- ライブラリを使えば3行で終わる処理を、自作フレームワークで実装している
- 新メンバーがコードを理解するのに1ヶ月以上かかる
顧客はあなたの「美しいアーキテクチャ」にお金を払うのではありません。「動くソフトウェア」に払うのです。
01. YAGNI原則
「You Ain't Gonna Need It（それはきっと必要にならない）」。
将来の拡張性を予測してコードを複雑にしないでください。
その未来が来たときに、リファクタリングすればいいのです。
今必要なのは、今の要件を満たす最もシンプルなコード（KISS: Keep It Simple, Stupid）です。
美徳ではない。
負債である。
02. 枯れた技術の水平思考
最新でセクシーな技術スタック（Bleeding Edge）を使いたがる気持ちはわかります。
しかし、ビジネスの成功には「枯れた技術（Boring Technology）」のほうが貢献します。
バグが少なく、知見が豊富で、採用もしやすい。
イノベーションは「技術の選択」ではなく「技術の使い方（アイデア）」で起こしてください。
03. 抽象化の罠
「汎用的なBaseクラスを作れば、後で楽になる」。それは幻想です。
過度な抽象化は、コードの可読性を極端に下げます。
具体的な実装（Concrete）から始め、重複が3回現れたら初めて抽象化する（Rule of Three）。
この順序を守るだけで、コードは劇的にシンプルになります。