メインコンテンツまでスキップ

「正しい設計」という幻想

3ヶ月後の自分からの手紙​

あの時、クリーンアーキテクチャを採用しなければよかった。

たった3画面のCRUDアプリに、
UseCase、Repository、DTO、Mapper...

「なぜこの構造？」と聞かれても
「ベストプラクティスだから」としか答えられない。

変わる予定のないDBのために抽象化した。
誰も差し替えないインターフェースを作った。
書かれないテストのために依存を逆転させた。

目的のない構造は、ただの複雑さだった。
あの時、クリーンアーキテクチャを採用すればよかった。

最初は順調だった。
Controllerに全部書いて、サクサク進んだ。

でも1年後、3000行のControllerが5つ。
どこを変えると何が壊れるかわからない。
テストは書けない（書く気にならない）。

DBを変えたいけど、SQLがあちこちに散らばっている。
見積もりを出したら「3ヶ月」と言われた。

最初から分離しておけば...

どちらの手紙も本物​

両方のシナリオは実際に起きる。

┌─────────────────────────────────────────────┐
│ 設計の難しさ                                 │
├─────────────────────────────────────────────┤
│                                             │
│  過剰設計 → 開発が遅い、複雑すぎる          │
│  過少設計 → 変更が辛い、技術的負債          │
│                                             │
│  どちらも「あの時こうすれば」と思う          │
│                                             │
│  正解は最初からわからない                    │
│                                             │
└─────────────────────────────────────────────┘

「このプロジェクトは違う」​

よく聞く言葉がある。

「うちは小規模だから、シンプルでいい」
→ 2年後、誰もがそう思っていたプロジェクトが
  レガシーコードの山になっている

「うちは大規模だから、ちゃんとやらないと」
→ 使われない抽象化レイヤーを
  メンテナンスし続けている

規模だけで判断できない。

本当の問いかけ​

規模より重要な問い:

┌─────────────────────────────────────────────┐
│ 自分に聞いてみる                             │
├─────────────────────────────────────────────┤
│                                             │
│  Q: この部分、来年も同じ実装？               │
│  → Yes なら抽象化は過剰かも                  │
│                                             │
│  Q: この部分、来月には変わりそう？           │
│  → Yes なら抽象化の価値がある                │
│                                             │
│  Q: テストを書く予定ある？                   │
│  → No なら依存逆転の恩恵は半減               │
│                                             │
│  Q: 自分以外がこのコードを触る？             │
│  → Yes なら構造の明確さに価値がある          │
│                                             │
└─────────────────────────────────────────────┘

「後から変えればいい」の罠​

よくある楽観:
「最初はシンプルに作って、必要になったら分離すればいい」

現実:
├── 必要になった時には、コードが絡み合っている
├── 分離するには大規模なリファクタリングが必要
├── でも機能開発も止められない
└── 結局、技術的負債として積み上がる

「後から」は来ないことが多い

「最初からちゃんと」の罠​

よくある慎重さ:
「後で困らないように、最初から設計をしっかり」

現実:
├── 要件は最初からわかっていない
├── 使われない抽象化を作ってしまう
├── 「念のため」のコードが増える
└── 開発速度が落ちて、フィードバックが遅れる

「最初から完璧」は無理

じゃあどうすればいいのか​

┌─────────────────────────────────────────────┐
│ 現実的なアプローチ                           │
├─────────────────────────────────────────────┤
│                                             │
│  1. 「変わりそうな場所」を見極める           │
│     → そこだけ抽象化する                     │
│                                             │
│  2. 痛みを感じたら変える                     │
│     → 予防より治療                           │
│     → ただし「治療できる状態」を保つ         │
│                                             │
│  3. 判断を記録する                           │
│     → 「なぜこの構造にしたか」を残す         │
│     → 後で見直せるように                     │
│                                             │
└─────────────────────────────────────────────┘

最後に​

クリーンアーキテクチャは「正解」ではない。
フレームワーク直結も「間違い」ではない。

「この状況で、このチームで、このプロジェクトで」
何が適切かを考え続けるしかない。

銀の弾丸はない。
でも、選択肢を知っていることには価値がある。

間違えてもいい。
大事なのは、なぜその選択をしたか説明できること。