💻 コーディング基礎講座【第三回】コードの設計原則を学ぼう！DRY・KISS・単一責任・SOLID原則

1. 👋 はじめに

前回は命名規則（キャメルケース・スネークケース・良い名前の条件）を学びました。

今回は コードの設計原則 を解説します！

「動くコード」と「良いコード」は別物です。
設計原則を知ることで、チームで長く使えるコードが書けるようになります。

この記事を読めば：

• ✅ DRY原則（繰り返しを避ける）がわかる
• ✅ KISS原則（シンプルに保つ）がわかる
• ✅ 単一責任の原則がわかる
• ✅ 関数の長さ・引数の数の目安がわかる

---

2. 🗺️ 設計原則の全体像

---

3. 🔁 DRY原則（Don't Repeat Yourself）

一言で言うと

「同じコードを繰り返して書かない」という原則です。
DRY ＝ Don't Repeat Yourself（自分自身を繰り返すな）

なぜ繰り返しが問題なのか

# Python
# ❌ DRY原則違反：同じ計算が3か所に書かれている
def print_order_summary_a(price: int, quantity: int) -> None:
    """注文Aのサマリーを表示する。"""
    tax = price * quantity * 0.10   # 消費税計算
    total = price * quantity + tax
    print(f"合計：{total}円")

def print_order_summary_b(price: int, quantity: int) -> None:
    """注文Bのサマリーを表示する。"""
    tax = price * quantity * 0.10   # 同じ消費税計算がまたある！
    total = price * quantity + tax
    print(f"合計：{total}円")

def print_order_summary_c(price: int, quantity: int) -> None:
    """注文Cのサマリーを表示する。"""
    tax = price * quantity * 0.10   # またまた同じ計算！
    total = price * quantity + tax
    print(f"合計：{total}円")

# 消費税率が10%→15%に変わったら3か所全部直す必要がある 😱

# Python
# ✅ DRY原則を守る：共通処理を1か所にまとめる
TAX_RATE = 0.10  # 定数化しておく

def calculate_total(price: int, quantity: int) -> int:
    """税込合計金額を計算する。

    Args:
        price: 単価
        quantity: 数量

    Returns:
        税込合計金額
    """
    subtotal = price * quantity
    tax = subtotal * TAX_RATE
    return subtotal + tax

def print_order_summary_a(price: int, quantity: int) -> None:
    """注文Aのサマリーを表示する。"""
    print(f"合計：{calculate_total(price, quantity)}円")

def print_order_summary_b(price: int, quantity: int) -> None:
    """注文Bのサマリーを表示する。"""
    print(f"合計：{calculate_total(price, quantity)}円")

# 税率が変わっても TAX_RATE の1か所だけ直せばOK！ 🎯

DRY原則の3つのメリット

メリット	説明
🔧 修正が1か所で済む	仕様変更のとき漏れなく対応できる
🐛 バグが減る	コピペするたびにバグも一緒にコピーしてしまうリスクがなくなる
📖 読みやすくなる	同じロジックに名前がついて意味が明確になる

DRY原則の注意点

⚠️ 「似ているコード」をすべて共通化すればいいわけではありません！

「今は似ているが将来変わりそう」なコードを無理に共通化すると、
変更するたびに複雑な条件分岐が増えてかえって読みにくくなります。

これを 「間違った抽象化（Wrong Abstraction）」 と呼びます。

「本質的に同じロジック」だけを共通化するのがDRYの正しい使い方です。

「コピペの重複」よりも「間違った共通化」の方が、後から修正するのが難しくなる。

「なんとなく似ているから共通化しよう」という判断は要注意です。
重複が気になっても、まず少し様子を見て本当に同じロジックか確認してから共通化しましょう。

---

4. 💎 KISS原則（Keep It Simple, Stupid）

一言で言うと

「シンプルに保て」という原則です。
KISS ＝ Keep It Simple, Stupid（シンプルにしろ、このバカ！）
※ Stupid は「シンプルにしないこと」に向けられた言葉です

複雑にしすぎた悪い例

# Python
# ❌ 複雑すぎる：1行で書こうとしすぎている
def get_active_adult_user_names(users: list) -> list:
    """アクティブな成人ユーザーの名前一覧を返す。"""
    return [u.name for u in users if u.is_active and u.age >= 18 and not u.is_deleted and u.email_verified]

※ 1行でスマートに書けているように見えますが、
「18歳以上・削除されていない・メール認証済み・アクティブ」という
複数の条件が1箇所に凝縮されているため、
パッと見て何をしているか理解しづらくなっています。
「短く書くこと＝シンプル」ではありません。
読む人にとってわかりやすいかどうかが「シンプル」の本質です。

# Python
# ✅ シンプルで読みやすい：条件を分けて意図を明確にする
def get_active_adult_user_names(users: list) -> list:
    """アクティブな成人ユーザーの名前一覧を返す。

    Args:
        users: ユーザーのリスト

    Returns:
        条件を満たすユーザーの名前リスト
    """
    result = []
    for user in users:
        is_adult = user.age >= 18
        is_available = user.is_active and not user.is_deleted
        is_verified = user.email_verified

        if is_adult and is_available and is_verified:
            result.append(user.name)
    return result

「賢く書く」より「読みやすく書く」を優先しましょう。
1年後の自分や新しいチームメンバーが読んで、
5秒で理解できるコードが良いコードです。

KISS原則のチェックリスト

チェック項目	判断基準
📖 コードを読んで3秒で理解できるか	できなければシンプルにする余地あり
🔍 条件式が複雑すぎないか	3つ以上の条件が重なっていたら分割を検討
🧩 1つの処理が多くのことをしていないか	「〜して、〜して、〜する」なら分割
🎭 技術的に面白いが読みにくくないか	「賢いコード」は保守の敵

---

5. 🎯 単一責任の原則（Single Responsibility Principle）

一言で言うと

「1つの関数・クラスは1つのことだけを担当する」という原則です。
英語では SRP（Single Responsibility Principle）と呼ばれ、
後述するSOLID原則の「S」にあたります。

責任が混在した悪い例

# Python
# ❌ 1つの関数が複数のことをしている
def process_user(user_id: int) -> None:
    """ユーザーを処理する。"""
    # ① DBからユーザー取得
    user = db.query(f"SELECT * FROM users WHERE id = {user_id}")

    # ② バリデーション
    if not user.email:
        raise ValueError("メールアドレスがありません")

    # ③ 名前をフォーマット
    formatted_name = user.name.upper()

    # ④ メール送信
    send_email(user.email, f"こんにちは {formatted_name} さん")

    # ⑤ ログ記録
    print(f"[LOG] ユーザー {user_id} に送信完了")

# この関数は「取得・検証・加工・送信・ログ」の5つの責任を持っている 😱

#Python
# ✅ 責任を分離した良い例
def get_user(user_id: int) -> User:
    """DBからユーザーを取得する。

    Args:
        user_id: ユーザーID

    Returns:
        ユーザーオブジェクト
    """
    return db.query(f"SELECT * FROM users WHERE id = {user_id}")

def validate_user(user: User) -> None:
    """ユーザーのバリデーションを行う。

    Args:
        user: 検証するユーザー

    Raises:
        ValueError: メールアドレスが未設定の場合
    """
    if not user.email:
        raise ValueError("メールアドレスがありません")

def format_user_name(name: str) -> str:
    """ユーザー名を大文字にフォーマットする。

    Args:
        name: フォーマットするユーザー名

    Returns:
        大文字にフォーマットされた名前
    """
    return name.upper()

def send_welcome_email(user: User, formatted_name: str) -> None:
    """ウェルカムメールを送信する。

    Args:
        user: 送信先のユーザー
        formatted_name: フォーマット済みの名前
    """
    send_email(user.email, f"こんにちは {formatted_name} さん")

def log_email_sent(user_id: int) -> None:
    """メール送信のログを記録する。

    Args:
        user_id: ログに記録するユーザーID
    """
    print(f"[LOG] ユーザー {user_id} に送信完了")

# 組み合わせて使う（各関数が1つのことだけを担当）
def process_user(user_id: int) -> None:
    """ユーザーへのウェルカムメール送信を行う。"""
    user = get_user(user_id)
    validate_user(user)
    formatted_name = format_user_name(user.name)
    send_welcome_email(user, formatted_name)
    log_email_sent(user_id)

💡 命名規則との連動性に注目！
責任が混在していた process_user（「処理する」という曖昧な動詞）が、
分割後は get_user・validate_user・send_welcome_email のように
第二回で学んだ「動詞＋名詞」の具体的な名前が自然とつけられています。

「関数に良い名前がつけられない」と感じたときは、
その関数が複数の責任を持っているサインかもしれません。
単一責任を意識すると、自然と良い命名ができるようになります🎯

単一責任のメリット

メリット	説明
🧪 テストしやすい	小さな関数は単体テストが書きやすい
🔧 修正しやすい	変更の影響範囲が小さくなる
♻️ 再利用しやすい	1つのことをする関数は別の場所でも使いやすい
📖 読みやすい	関数名を見るだけで何をするかわかる

---

6. 📏 関数の設計：長さ・引数の数の目安

関数の長さ

目安	判断基準
✅ 20行以内	1画面で全体が見える・理想的
⚠️ 20〜50行	長いがまだ許容範囲・分割を検討
❌ 50行以上	ほぼ確実に複数の責任を持っている・分割すべき

💡 「スクロールしないと全体が見えない関数は危険サイン」
1画面に収まる長さを意識しましょう。

引数の数

引数の数	評価	対処法
0〜2個	✅ 理想的	そのまま
3個	⚠️ 要注意	問題はないが設計を見直す余地あり
4個以上	❌ 多すぎ	オブジェクト・辞書にまとめることを検討

# Python
# ❌ 引数が多すぎる
def create_user(
    name: str,
    email: str,
    age: int,
    address: str,
    phone: str,
    role: str
) -> User: ...

# ✅ オブジェクトにまとめる（Python）
from dataclasses import dataclass

@dataclass
class CreateUserInput:
    """ユーザー作成に必要な入力データ。"""
    name: str
    email: str
    age: int
    address: str
    phone: str
    role: str

def create_user(input: CreateUserInput) -> User:
    """ユーザーを作成する。

    Args:
        input: ユーザー作成に必要な入力データ

    Returns:
        作成されたユーザー
    """
    ...

// ✅ オブジェクトにまとめる（TypeScript）
interface CreateUserInput {
  name: string;
  email: string;
  age: number;
  address: string;
  phone: string;
  role: string;
}

function createUser(input: CreateUserInput): User {
  // input.name・input.email… と使える
  ...
}

// 呼び出し側も読みやすい！
createUser({
  name: "Alice",
  email: "[e-mail]",
  age: 25,
  address: "東京都渋谷区",
  phone: "090-1234-5678",
  role: "admin",
});

💡 引数をオブジェクトにまとめるメリット：

• 呼び出し側で「何の値か」がキー名でわかる
• 引数の順番を間違えるバグがなくなる
• 後から新しいプロパティを追加しやすい

---

7. 📚 コラム：SOLID原則とは？

SOLID原則 とは、オブジェクト指向設計における5つの重要な指針をまとめたものです。
今回学んだ内容は、その入り口になっています。

頭文字	原則名	一言で言うと
S	単一責任の原則（SRP）	1つのクラス・関数は1つのことだけ担当する
O	オープンクローズドの原則（OCP）	拡張には開いて・修正には閉じている設計にする
L	リスコフ置換原則（LSP）	派生クラスは基底クラスと置き換えても動くようにする
I	インターフェース分離の原則（ISP）	使わないメソッドへの依存を強制しない
D	依存関係逆転の原則（DIP）	具体的な実装ではなく抽象に依存する

📖 SOLID原則をさらに深く学びたい方へ：
このシリーズの「AIが書いたコードをレビューするスキルを考えよう【第三回】設計・アーキテクチャの視点」でも
SRP（単一責任）とOCP（オープンクローズド）を実際のコード例とともに解説しています。

👉 [AIコードレビューシリーズ第三回]

---

8. 🎯 まとめ

原則	一言で言うと	守るとどうなる
🔁 DRY	同じコードを繰り返さない	修正が1か所で済む・バグが減る
💎 KISS	シンプルに保つ	読みやすい・保守しやすい
🎯 単一責任	1つのことだけを担当する	テストしやすい・再利用しやすい
📏 関数の長さ	20行以内を目安に	1画面で全体が把握できる
📏 引数の数	3個以内を目安に	呼び出しやすい・テストしやすい

「良いコードとは、未来の自分や仲間にとって読みやすいコードです。」
DRY・KISS・単一責任の3つを意識するだけで、
コードの品質は大きく変わります💪

次回は コメント・ドキュメント を解説します！
良いコメント・悪いコメントの違い・マジックナンバーの排除・
「なぜを書く」というプロのコメント術を学びます🌟

💬 質問や感想があれば、コメント欄でお気軽にどうぞ!
👍 役に立ったら、いいね&ストックをお願いします!
🎓 ここまで読んでくださって、本当にありがとうございました!

---

🔗 シリーズ記事

• 【第一回】コードの基本構造
• 【第二回】命名規則
• 【第三回】コードの設計原則（この記事）
• 【第四回】コメント・ドキュメント（近日公開）
• 【第五回】エラーハンドリング（近日公開）
• 【第六回】テスト・ファイル構造・バージョン管理（近日公開）