閉じる

DRY KISS YAGNIの設計原則とは?わかりやすく解説

プログラミングの学び始めで、設計の良し悪しはわかりにくいものです。

そこで本稿では、初心者でもすぐ使えて効果が出やすい3つの原則であるKISS、YAGNI、DRYを順番にやさしく解説します。

「まず簡単に作る→余計な未来は足さない→同じことは1回にまとめる」という流れで、小さく確実に前進できるようになります。

DRY KISS YAGNIとは?プログラミング設計原則の基本

プログラミング初心者のゴール

何を目指すか

初心者のうちは、複雑な設計や高度なパターンよりも、動くものを最短で作り、小さく直しやすくすることをゴールにすると学びが早くなります。

コードは自分と未来の自分が読む文章だと捉え、短く、読みやすく、変更しやすく書くことが大切です。

学び方の姿勢

最初から完璧を目指さず、まずは動かす→気になったら直す→同じ直しが2回必要ならまとめるという姿勢が効果的です。

このリズムを支えてくれるのがKISS、YAGNI、DRYです。

3つの設計原則の役割

一覧で理解する

原則一言で主な役割破ったときの症状
KISS簡単に保つ読める・直せるコードにする複雑で理解に時間がかかる、バグが見つけにくい
YAGNI今いらないものは作らない過剰設計を防ぐ使われない機能に時間を使う、遅い
DRY知識を1カ所にまとめる変更しやすくするコピペが増え、直す場所を見落とす

3つは対立ではなく順番のある仲間です。

まずシンプルに作り(KISS)、不要を足さず(YAGNI)、重複が見えたらまとめる(DRY)の流れが扱いやすいです。

実践の順番

なぜこの順番か

  • KISSが土台です。最初から複雑にすると、そもそも動くところまでが遠くなります。
  • YAGNIがブレーキになります。未来の心配で今を止めないようにします。
  • DRYは最後の仕上げです。重複は2回見えてからまとめると、早すぎる抽象化を避けられます。

ミニ手順

5つの合言葉

  1. 最小で動く形を5〜30分で作る(KISS)。
  2. 未来の機能はメモだけにして今は実装しない(YAGNI)。
  3. 同じようなコードが2回出たら印を付ける
  4. 動作が落ち着いたら共通化する(DRY)。
  5. 変更後はすぐに実行して確かめる

効果

学習と開発の両面で効く

効果何が良くなるか初心者の実感できるサイン
速度手戻りが減り実装が早い毎回の作業が小さく終わる
正しさバグの混入が減る原因を1画面で追える
自信変更に抵抗がなくなる「壊しそう」が減る
チーム読めるコードが増えるコードレビューが楽になる

小さく作って確かめる回数が増えるほど、学びが加速します

KISS原則

KISSとは

ひと言で

KISSは「Keep It Simple(シンプルに保つ)」の略として知られています。

今の自分が読んで理解できる最も簡単な形にするという意味です。

背景と狙い

複雑さは自然に増えるので、意識して減らす必要があります。

KISSは、短く、直感的で、説明がいらないコードを目指します。

初心者向け例

例1: 条件判定を素直に書く

簡単な偶数判定は、ビット演算より割り算の余りのほうが読みやすいです。

Python
# KISSな書き方
def is_even(n):
    return n % 2 == 0

# 難しく感じる書き方
def is_even(n):
    return not (n & 1)

例2: ネストを浅くする

早めに返すと読みやすくなります。

Python
# KISSな書き方
def price(age):
    if age < 6:
        return 0
    if age < 13:
        return 500
    return 1000

# ネストが深い書き方
def price(age):
    if age >= 6:
        if age >= 13:
            return 1000
        else:
            return 500
    else:
        return 0

やりがちなNG

NG1: 先に難しい道具を入れる

最初から複雑なライブラリやデザインパターンを入れるのは避けます。

最小の標準機能で足りるならそれで十分です。

NG2: 1行に詰め込む

短さより読みやすさが優先です。

意味の異なる処理を1行にまとめると理解が遅くなります。

チェックリスト

自分で読み返すときの目安

確認項目目安OK/NGの例
1画面で全体が見えるか20〜30行以内100行超は分割を検討
名前で意図が伝わるか動詞+名詞calc → NG / calculate_total → OK
分岐の深さネスト2段以内3段以上は早期return
引数・設定最小限使わない引数は入れない
実行例すぐ試せるサンプル値で動くか

迷ったら読む指針

判断を軽くするコツ

  1. 5分ルール: 5分説明できない実装は複雑すぎます。単純化しましょう。
  2. 1機能1責務: 関数は1つの目的に絞ります。
  3. まず手で動かす: 小さなデータで実行して確かめます。
  4. 図よりコード: 長い説明より短いコードで示します。

「読んですぐわかる」ことに勝る最適化はありません

YAGNI原則

YAGNIとは

ひと言で

YAGNIは「You Ain’t Gonna Need It(それ、今はいらない)」の意味です。

今使わない機能・設定・拡張点は作らないという約束です。

背景と狙い

未来はよく外れます。

いま必要な最小機能だけ作れば、遅れやムダを減らせます。

将来必要になったら、そのときの正しい形で足せば良いのです。

初心者向け例

例1: まずメモリで十分

最初のメモアプリは、データベースよりリストで十分です。

Python
todos = []

def add(todo):
    todos.append(todo)

def list_all():
    for i, t in enumerate(todos, 1):
        print(f"{i}. {t}")

最初からユーザ管理や永続化、同期機能を入れないことで、まず基本の使い勝手を確かめられます。

例2: 不要なパラメータを増やさない

Python
# YAGNIな書き方
def greet(name):
    print(f"Hello, {name}!")

# 未来のために増やしすぎ
def greet(name, lang="en", uppercase=False, with_time=False):
    ...

今は英語と普通の表示で十分なら、余計な引数は持たせないほうが読みやすく、安全です。

やりがちなNG

NG1: 「いつか使うかも」を根拠に実装

使う人も時期も決まっていない拡張は足しません。

メモにしておき、必要が確定したら実装します。

NG2: 早すぎる最適化

速度やスケールの心配で複雑にするのは後回しにします。

まず正しく動くことが先です。

チェックリスト

今必要かどうかの確認

質問Yesなら作る/Noなら作らない補足
使う人が決まっているかYes誰がいつ使うか
今の仕様に必須かYesなくすと動かないか
30分以内に価値を見せられるかYes実演できる最小範囲か
代替の簡単な方法はあるかNoメモリ・手動で代替できれば今は不要
削ると困る人がいるかYes名前が挙がるなら優先

「後で足せる」は十分な理由になります

小さく作って学ぶ

ミニリリースの型

  • 最初は「手動でもいい」形で動かします。例: ファイルではなく画面に表示。
  • 次に「毎日使える」形に小さく改良します。例: 入力値の保存を追加。

フィードバックループ

作る→触る→直すを短い間隔で回します。

触った事実が本当の要求を教えてくれるため、外れにくくなります。

DRY原則

DRYとは

ひと言で

DRYは「Don’t Repeat Yourself(繰り返すな)」の意味です。

同じ知識を複数の場所に書かず、1カ所にまとめることで、変更漏れを防ぎます。

背景と狙い

コピペで増える重複は、後の修正点を増やします。

DRYは、意図やルールを1カ所に置くことで、直しやすさと信頼性を上げます。

初心者向け例

例: 入力チェックを1カ所に

重複したバリデーションを共通化します。

Python
# 重複しているコード
def save_user(name):
    if not name or len(name) < 3:
        raise ValueError("名前が短い")
    # 保存処理...

def update_user(user_id, name):
    if not name or len(name) < 3:
        raise ValueError("名前が短い")
    # 更新処理...
Python
# DRYにしたコード
def validate_name(name):
    if not name or len(name) < 3:
        raise ValueError("名前が短い")

def save_user(name):
    validate_name(name)
    # 保存処理...

def update_user(user_id, name):
    validate_name(name)
    # 更新処理...

ルールが1カ所になれば、要件変更も1回で済みます

やりがちなNG

NG1: 早すぎる共通化

1回しか使っていないのに抽象化すると、かえって読みにくくなります。

「2回目が見えたら共通化」を合図にします。

NG2: 継承で無理にまとめる

継承は強い結びつきを生むため、初心者は関数・小さなモジュールの共通化から始めると安全です。

チェックリスト

どの重複をまとめるかの判断

観点まとめる目安注意点
回数同じ意図が2回以上1回は様子見
似ている度合い名前違いだけで中身同じ似ているだけで異なる意図は分ける
変更の広がり直す場所が2カ所以上漏れのリスクが高い
テスト/実行例同じケースが複数共有のテストを作る
コピペ痕跡同じコメント/メッセージ出どころを1つに寄せる

置き換えの手順

安全にDRYへ近づける

  1. 重複を見つけて、意図を言葉にする。例: 「名前は3文字以上」。
  2. その意図を表す小さな関数を作る。
  3. 片方だけを新関数に置き換えて動作確認
  4. もう片方も置き換えて再確認
  5. 元の重複コードを削除し、名前をわかりやすく整える。
  6. 使い方の短い実行例を残す。

小さく置き換え、小さく確かめることで、失敗しにくくなります。

まとめ

KISS→YAGNI→DRYの順番で進めると、初心者でも安全に設計の良い習慣を身につけられます。

まずは読んでわかる形で最小に作り(KISS)、今いらないものは足さず(YAGNI)、同じ知識が2回出たら1カ所にまとめる(DRY)と覚えてください。

これだけで、コードは短く、直しやすく、壊れにくくなります。

今日の小さな成功を積み重ねれば、明日の大きな設計も自然と扱えるようになります。

この記事を書いた人
エーテリア編集部
エーテリア編集部

このサイトでは、プログラミングをこれから学びたい初心者の方に向けて記事を書いています。 基本的な用語や環境構築の手順から、実際に手を動かして学べるサンプルコードまで、わかりやすく整理することを心がけています。

クラウドSSLサイトシールは安心の証です。

URLをコピーしました!