KISS 原則

KISS 原則とは

KISS (Keep It Simple, Stupid) は、設計をできるだけシンプルに保つことを求める原則である。「ほとんどのシステムは、複雑にするよりシンプルに保った方がうまく動く」という考え方だ。設計目標としては 1960 年に米海軍で言及された記録が古く、頭字語そのものはロッキードのスカンクワークス (U-2 や SR-71 を生んだ部門) で主任技師を務めた Kelly Johnson が言い出したとされる。

出所として語られるのは、Johnson が設計チームに数点の工具だけを渡し、戦闘状況下で平均的な整備兵がそれだけで修理できる機体を設計せよと課した逸話である。つまり stupid は設計者を罵る語ではなく、自分以外の誰かが極限状況で扱えることを設計の目標に置く、という含意で読む。Johnson 自身はカンマを打たずに Keep it simple stupid と書いていた。

シンプルさの判断基準

シンプルさの判断基準を以下にまとめる。

観点	シンプル	複雑
読みやすさ	コードを読めば意図が分かる	コメントなしでは理解できない
変更容易性	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 vs DRY の違いを以下にまとめる。

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

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

AWS アーキテクチャでの KISS

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 原則の理解を深めるには関連書籍が参考になる。