プログラミングの学び始めで、設計の良し悪しはわかりにくいものです。
そこで本稿では、初心者でもすぐ使えて効果が出やすい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つの合言葉
- 最小で動く形を5〜30分で作る(KISS)。
- 未来の機能はメモだけにして今は実装しない(YAGNI)。
- 同じようなコードが2回出たら印を付ける。
- 動作が落ち着いたら共通化する(DRY)。
- 変更後はすぐに実行して確かめる。
効果
学習と開発の両面で効く
| 効果 | 何が良くなるか | 初心者の実感できるサイン |
|---|---|---|
| 速度 | 手戻りが減り実装が早い | 毎回の作業が小さく終わる |
| 正しさ | バグの混入が減る | 原因を1画面で追える |
| 自信 | 変更に抵抗がなくなる | 「壊しそう」が減る |
| チーム | 読めるコードが増える | コードレビューが楽になる |
小さく作って確かめる回数が増えるほど、学びが加速します。
KISS原則
KISSとは
ひと言で
KISSは「Keep It Simple(シンプルに保つ)」の略として知られています。
今の自分が読んで理解できる最も簡単な形にするという意味です。
背景と狙い
複雑さは自然に増えるので、意識して減らす必要があります。
KISSは、短く、直感的で、説明がいらないコードを目指します。
初心者向け例
例1: 条件判定を素直に書く
簡単な偶数判定は、ビット演算より割り算の余りのほうが読みやすいです。
# KISSな書き方
def is_even(n):
return n % 2 == 0
# 難しく感じる書き方
def is_even(n):
return not (n & 1)
例2: ネストを浅くする
早めに返すと読みやすくなります。
# 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 |
| 引数・設定 | 最小限 | 使わない引数は入れない |
| 実行例 | すぐ試せる | サンプル値で動くか |
迷ったら読む指針
判断を軽くするコツ
- 5分ルール: 5分説明できない実装は複雑すぎます。単純化しましょう。
- 1機能1責務: 関数は1つの目的に絞ります。
- まず手で動かす: 小さなデータで実行して確かめます。
- 図よりコード: 長い説明より短いコードで示します。
「読んですぐわかる」ことに勝る最適化はありません。
YAGNI原則
YAGNIとは
ひと言で
YAGNIは「You Ain’t Gonna Need It(それ、今はいらない)」の意味です。
今使わない機能・設定・拡張点は作らないという約束です。
背景と狙い
未来はよく外れます。
いま必要な最小機能だけ作れば、遅れやムダを減らせます。
将来必要になったら、そのときの正しい形で足せば良いのです。
初心者向け例
例1: まずメモリで十分
最初のメモアプリは、データベースよりリストで十分です。
todos = []
def add(todo):
todos.append(todo)
def list_all():
for i, t in enumerate(todos, 1):
print(f"{i}. {t}")
最初からユーザ管理や永続化、同期機能を入れないことで、まず基本の使い勝手を確かめられます。
例2: 不要なパラメータを増やさない
# 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カ所に
重複したバリデーションを共通化します。
# 重複しているコード
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("名前が短い")
# 更新処理...
# 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へ近づける
- 重複を見つけて、意図を言葉にする。例: 「名前は3文字以上」。
- その意図を表す小さな関数を作る。
- 片方だけを新関数に置き換えて動作確認。
- もう片方も置き換えて再確認。
- 元の重複コードを削除し、名前をわかりやすく整える。
- 使い方の短い実行例を残す。
小さく置き換え、小さく確かめることで、失敗しにくくなります。
まとめ
KISS→YAGNI→DRYの順番で進めると、初心者でも安全に設計の良い習慣を身につけられます。
まずは読んでわかる形で最小に作り(KISS)、今いらないものは足さず(YAGNI)、同じ知識が2回出たら1カ所にまとめる(DRY)と覚えてください。
これだけで、コードは短く、直しやすく、壊れにくくなります。
今日の小さな成功を積み重ねれば、明日の大きな設計も自然と扱えるようになります。
