IT 技書の森

KISS 原則

Keep It Simple, Stupid - 設計をできるだけシンプルに保つことを求める原則

設計原則設計

KISS 原則とは

KISS (Keep It Simple, Stupid) は、設計をできるだけシンプルに保つことを求める原則である。米海軍の航空機エンジニア Kelly Johnson が 1960 年代に提唱した。「ほとんどのシステムは、複雑にするよりシンプルに保った方がうまく動く」という考え方だ。

シンプルさの判断基準

観点 シンプル 複雑
読みやすさ コードを読めば意図が分かる コメントなしでは理解できない
変更容易性 1 箇所の変更で済む 複数箇所の変更が連鎖する
デバッグ 問題の原因がすぐ特定できる 問題の再現すら困難
テスト テストケースが少なくて済む 組み合わせ爆発が起きる

違反の例

// ❌ 過度な抽象化: 1 つの処理に 5 層のクラス
class AbstractRepositoryFactory<T> {
  createRepository(): AbstractRepository<T> { /* ... */ }
}
class ConcreteUserRepositoryFactory extends AbstractRepositoryFactory<User> { /* ... */ }
// ... さらに 3 層

// ✅ KISS: 必要十分なシンプルさ
async function getUser(id: string): Promise<User> {
  return db.get({ TableName: 'users', Key: { id } });
}

// ❌ 過度に賢いコード
const result = data.reduce((acc, x) => ({...acc, [x.key]: [...(acc[x.key] || []), x]}), {});

// ✅ KISS: 読めば分かるコード
const result: Record<string, Item[]> = {};
for (const item of data) {
  if (!result[item.key]) result[item.key] = [];
  result[item.key].push(item);
}

KISS vs YAGNI vs DRY

原則 焦点 問いかけ
KISS 複雑さの排除 「もっとシンプルにできないか？」
YAGNI 不要な機能の排除 「今それは本当に必要か？」
DRY 重複の排除 「同じことを 2 回書いていないか？」

3 つは補完関係にあるが、DRY を過度に追求すると KISS に違反する。2 箇所の重複を共通化するために複雑な抽象化を導入するなら、重複を許容した方がシンプルだ。

AWS アーキテクチャでの KISS

❌ 複雑: API Gateway → Lambda → SQS → Lambda → SNS → Lambda → DynamoDB
✅ KISS: API Gateway → Lambda → DynamoDB

マイクロサービスやイベント駆動アーキテクチャは強力だが、要件が単純なら Lambda + DynamoDB の直接呼び出しで十分だ。将来の拡張性のために今の複雑さを増やすのは YAGNI 違反でもある。

シンプルさを保つ実践

  • 早期リターンでネストを浅く保つ
  • 1 つの関数は 1 つのことだけ行う
  • 抽象化は 3 回目の重複が出てから検討する (Rule of Three)
  • 「賢い」コードより「読める」コードを選ぶ

KISS 原則の理解を深めるには関連書籍が参考になる。

関連用語