なぜ設計改善は続かないのか
設計改善という言葉を聞くと、
多くの現場では、まず構造の話になります。
- クラスが大きすぎる
- 責務が分かれていない
- レイヤーが崩れている
確かに、どれも問題です。
ですが私は、いくつものモノリスや設計不良なコードを見てきて、
別の共通点に気づきました。
それは、
「判断が見えなくなっている」 ということです。
if 文は、判断の化石である
たとえば、こんなコードを見たことはないでしょうか。
if (user.isPremium && order.total >= 1000 && !order.isCampaign) {
applySpecialDiscount(order)
}
このコードが何をしているかは分かります。
ですが、なぜそうなのか は分かりません。
- なぜプレミアムユーザーなのか
- なぜ 1000 円以上なのか
- なぜキャンペーン中は除外されるのか
これらは本来、
仕様やビジネスルールとして説明されるべき「判断」です。
しかしコードの中では、
それらが ただの条件式 として埋もれています。
構造を直しても、設計が良くならない理由
多くの現場では、
このコードを次のように「改善」します。
if (canApplySpecialDiscount(user, order)) {
applySpecialDiscount(order)
}
読みやすくなりました。
ですが、設計はほとんど変わっていません。
判断は依然として、
- どこに属するのか分からない
- なぜそうなのか説明できない
- 別の場所で似た条件が増えていく
という状態のままです。
構造を整えても、
判断の置き場所が変わっていないからです。
設計とは「判断の置き場所を決めること」
私がこの数年でたどり着いた結論は、
とてもシンプルなものでした。
設計とは、
どの判断を、どこに置くかを決めること である。
たとえば先ほどの例なら、
「特別割引が許されるとはどういう状態か」という判断を、
明示的な存在として表現します。
class SpecialDiscountPolicy {
fun isEligible(user: User, order: Order): Boolean {
return user.isPremium &&
order.total >= MINIMUM_AMOUNT &&
!order.isCampaign
}
}
ここで重要なのは、
if 文が消えたことではありません。
判断に名前がつき、
置き場所が固定されたこと です。
判断が見えると、設計は動き始める
この形にすると、
現場で起きる変化があります。
- 変更理由を説明できる
- 仕様の議論がコードと一致する
- 「なぜここを直すのか」が共有できる
そして何より、
次に何を改善すればいいかが見える ようになります。
設計改善が止まらなくなるのです。
設計力とは、再現可能な判断の質
設計が得意な人は、
センスがあるわけでも、
特別な才能があるわけでもありません。
「どう判断したか」を説明でき、
それを別の場面でも再現できる だけです。
私はこれを、
設計力とは、再現可能な判断の質である
と定義しています。
構造の前に、判断を見る
もしあなたの現場で、
- リファクタリングが続かない
- 設計改善が属人化している
- 「で、結局どうすればいいの？」となる
そんな状態が起きているなら、
まず構造を見るのをやめて、
判断を見てみてください。
設計は、
そこから始まります。
おわりに
この記事では、
設計がうまくいかなくなる原因を
構造ではなく「判断」から捉え直す という視点を紹介しました。
- 判断がどこに置かれているのか
- なぜその判断が必要なのか
- その判断は説明できるのか
これらが見えなくなったとき、
設計は静かに崩れ始めます。
拙著 『判断から始めるソフトウェア設計』 (無料)では、
この記事で触れた考え方を出発点として、
- 判断を 見つける
- 判断を 切り出す
- 判断に 名前をつける
- 判断を 動かす
- 判断の 変化を追う
- 判断を 説明できるようにする
という流れを、
一つずつ詳しく説明しています。
もし今、
設計改善がうまく続かない、
何を直せばいいのか分からない、
そんな感覚があるなら。
それは技術力の問題ではなく、
判断の扱い方がまだ言語化されていないだけ
かもしれません。
この視点が、
あなたの設計を見直す一つの手がかりになれば幸いです。
Discussion