読み方 : ドライげんそく
DRY原則【Don't Repeat Yourself】
概要
DRY原則とは、ソフトウェア開発における設計指針の一つで、システムを構成するあらゆる情報や知識を複数の場所に重複して定義せず、一箇所で管理して他からはそこを参照する構造にすべきとする考え方。1999年に刊行された書籍『達人プログラマー』の中で提唱された。

システムやプログラムの中で同じ情報が複数箇所に分散していると、変更の際にすべてを修正しなければならず、一部への反映が漏れると不整合やバグの原因となる。情報を一箇所に集約することで、変更箇所を最小限に抑え、保守性と整合性を高められる。
この原則が対象とする「情報」は、プログラムコードに限らない。設定値や業務ルール、データベース設計、設計文書など、システムを構成するあらゆる知識が対象である。例えば、税率のような業務上のルールを複数のモジュールや設定ファイルに個別に記述すると、制度変更時に修正漏れが生じやすい。共通の定義として一元管理し、各機能からそこを参照する構成が望ましいとされる。
この原則はアンディ・ハント(Andy Hunt)氏とデイビッド・トーマス(David Thomas)氏の共著『The Pragmatic Programmer』(邦題:達人プログラマー)の中で示された。原著では「システムにおけるあらゆる知識は、単一の、明確な、権威ある場所に存在しなければならない」と定義されている。現代の主要なフレームワークや開発手法の多くに標準的な設計指針として取り入れられている。
実際の開発現場では、同一または類似の処理を関数やクラス、ライブラリとして共通化することをDRY原則の適用と呼ぶことも多い。ただし、厳密にはコードの重複排除は「OAOO原則」(Once and Only Once)と呼ばれる別の概念であり、DRY原則はより広くシステム全体の知識の一元管理を指す。また、文脈の異なる処理を無理に共通化すると依存関係が複雑になり、却って保守性を損なう場合もあるため、実際に重複が問題となった段階で共通化を行う考え方も広く採用されている。
(2026.6.11更新)