DRYとKISS、どちらも重要だけど目的が違う
ソフトウェア開発における代表的な原則に DRY（Don’t Repeat Yourself） と KISS（Keep It Simple, Stupid） があります。
どちらも定番の原則として知られていますが、実際の現場では
-
DRYを優先するべきか？
-
KISSを優先するべきか？
-
両方同時に満たすにはどうすればいいのか？
と迷う場面が少なくありません。
この記事では、それぞれの意味、実際の使い分け、私の体験談、さらに応用編として「両立のコツ」まで分かりやすく解説します。
DRY原則とは？「重複をなくす」ための強力な指針
DRY原則（Don’t Repeat Yourself）は、「同じロジックや知識を複数箇所に書かない」という考え方です。
重複コードを排除し、仕様変更があっても1か所の修正で済むようにすることで、コードの保守性・拡張性を高めます。
詳しい説明は前回の記事で紹介しましたが、要点は次の2つです。
-
知識の重複はバグを生む
-
1か所で管理できる仕組みを作るべき
KISS原則とは？「シンプルさ」を最優先する思考法
KISS（Keep It Simple, Stupid）は、「とにかくシンプルに設計しろ」という原則です。
複雑な構造は作らず、できる限り分かりやすい形で処理を書こうという考えです。
特にKISSは、
-
過剰な抽象化を避ける
-
不必要なクラス化、パターン化を避ける
-
思考コストを減らす
といった効果があります。
簡単に言えば 「コードは読めば分かる程度がちょうどいい」 ということです。
DRYとKISSは矛盾する？いいえ、目的が違うだけです
一見、DRYとKISSは矛盾するように感じることがあります。
例えば、
-
DRYを徹底すると抽象化が進み、複雑な構造になる
-
KISSを優先するとコードが重複してDRYに反してしまう
という状況は現場でよく起こります。
でも本質的には、
-
DRYは“重複排除”が目的
-
KISSは“シンプルさの維持”が目的
と、役割が異なります。
つまり両者は衝突するものではなく、状況によって優先度を変えて共存させるべき原則なのです。
私が現場で経験した「DRY vs KISS の衝突」
以前、私はある大規模プロジェクトで共通処理をまとめる役を担当しました。
そこで「入力チェック処理」の共通化を試みたのですが、以下のような問題が起きました。
■ DRYを優先しすぎて複雑化した失敗例
私は「すべてのバリデーションは共通化するべき」と考えて、汎用的なチェックフレームワークを自作しました。
しかし、あまりに抽象化しすぎた結果、
-
コードを読むのに時間がかかる
-
少し特殊なケースに対応するときに学習コストが発生
-
他のメンバーが理解できず、結局“使われない共通処理”になった
という結果になりました。
DRYを追求しすぎてKISSを破ってしまった典型例です。
逆にKISSを優先してうまくいった例
同じチームの別メンバーは、「ページ固有の簡易チェックはローカルに書く」方針を採りました。
抽象化しすぎず、そのページだけに必要なロジックを素直に書いていたため、
-
理解コストが低い
-
修正が簡単
-
コードレビューがスムーズ
と、結果的にメンテナンス性が高くなりました。
ここではKISSのほうが正解だったのです。
DRYとKISS、どちらを優先すべきか？判断ポイント
以下の基準で考えると、どちらを適用すべきか悩みにくくなります。
【DRYを優先するべきケース】
-
同じ処理が複数画面・複数モジュールで使われる
-
仕様変更が頻繁に入る
-
バリデーションや料金計算など“ビジネスルール”が関与する
-
コード量が増えやすいロジックを共有したい
このような場面では、共通化しないと修正漏れが出て危険です。
【KISSを優先するべきケース】
-
その処理が1か所でしか使われない
-
定義を抽象化しすぎると理解が難しくなる
-
コンパクトに書いたほうが明らかに可読性が高い
-
初期段階で仕様が固まっていない
このようなケースでは共通化しないほうが最適です。
応用編：DRYとKISSを同時に満たすためのテクニック
両者を両立するためには、いくつかのコツがあります。
● 1. 共通化の「境界線」を決める
チームで「ここまでは共通化する」「ここからは個別実装」という基準を持つと、DRYとKISSのバランスが取りやすくなります。
● 2. 抽象化は「必要以上に行わない」
DRYを理由に抽象化を進めるとすぐ複雑になります。
「3回以上使われるまで共通化しない」といったルールも有効です。
● 3. 小さく共通化する
巨大な共通処理は理解が難しくなります。
小さくシンプルに共通化すると、DRYとKISSの両方を満たせます。
● 4. テストでサポートする
DRYを強めるほど抽象化が入りやすいので、テストでカバーしてKISS性を補うという方法があります。
まとめ：DRYとKISSを理解すれば、開発が劇的に楽になる
DRYとKISSはどちらが正しいという話ではなく、
-
重複をなくして保守性を高める（DRY）
-
複雑にしすぎず、シンプルに保つ（KISS）
という異なる役割を持った原則です。
両者のバランスを取れるようになると、
-
コードが読みやすくなる
-
バグが減る
-
仕様変更に強くなる
-
開発スピードが向上する
と、多くのメリットが得られます。
そして何より、開発がストレスフリーになります。
あなたもぜひ次のプロジェクトで「DRY vs KISS」を意識してみてください。
コードが見違えるほど整い、チーム開発の品質も大きく向上します。