KISS原則（KISSの法則）とは？意味・由来とシンプルな設計の実践

KISS原則（Keep It Simple, Stupid）は、システムやコードを「必要以上に複雑にせず、できるだけ単純に保て」という設計指針です。KISSの法則とも呼ばれ、可読性・保守性を高めてバグを減らす目的で、プログラミングからUI設計まで広く使われています。

本記事では、KISS原則の意味と読み方、ロッキードの技術者が生んだ由来、実践するための具体的なコツ、そしてDRY・YAGNI・SOLIDとの違いと使い分けまでを整理します。混同されがちな「単純化しすぎる」失敗も具体的に扱います。

まとめ：KISS原則の要点

• 意味：「Keep It Simple, Stupid」＝目的を満たす最も単純な形を選び、余計な複雑さを持ち込まない。
• 由来：ロッキードの航空機技師ケリー・ジョンソンが第二次大戦中に用いた言葉。「現場の整備士が基本工具だけで直せる設計に」という意図で、設計者を侮辱する言葉ではない。
• 実践：ガード節でネストを浅くする／関数を一つの責務に絞る／循環的複雑度を目安（1関数10以下）に測る。
• 使い分け：KISS＝単純に、DRY＝重複を作らない、YAGNI＝今不要な機能を作らない、SOLID＝拡張性を保つ。相反する場面では優先順位を決める。
• 注意：単純化を過度に進めると拡張性や意図が失われる。KISSは「今の要件に対して最小」であって「機能を削る」ことではない。

KISS原則とは：意味と読み方

KISSは「Keep It Simple, Stupid」の頭文字で、「キス（の法則／原則）」と読みます。ソフトウェア開発では、同じ結果を出せるなら分岐やネスト、抽象化の層をできるだけ減らし、後から読む人が一読で理解できるコードを優先することを指します。

ここでの「単純」は「機能が少ない」ではなく「構造が理解しやすい」という意味です。要件を満たしたうえで、読み手が余計な文脈を追わずに全体を把握できる状態を狙います。逆に、高度なアルゴリズムや汎用的な抽象化それ自体は目的にならず、必要がなければ複雑さとして評価されます。

KISSの由来：ロッキードのケリー・ジョンソンと「現場で直せる設計」

KISSは、ロッキードの秘密開発部門「スカンクワークス」を率いた技師ケリー・ジョンソン（U-2やSR-71ブラックバードの設計者）が、第二次世界大戦中に用いた言葉とされています。有名な逸話では、ジョンソンは設計チームに基本的な工具一式を渡し、「戦地の平均的な整備士がこの工具だけで修理できるジェット機を設計せよ」と課しました。

つまり「Stupid（ばか）」は設計者や利用者を指すのではなく、「壊れ方」と「修理に使える手段の限られ方」の関係を指しています。最先端の機体でも、現場では限られた知識と道具で直せなければ意味がない——この発想がソフトウェアにそのまま移り、「あとで別の人が最小限の前提で保守できるコードに」という指針になりました。なお、ジョンソン本人はカンマなしの「Keep it simple stupid」と記したと伝えられ、「Keep it Short and Simple」など類似の言い回しも古くから使われています（KISS principle – Wikipedia）。

KISS原則を実践する設計の判断基準

KISSは心構えだけでは守れません。「単純さ」を判断できる具体的な基準に落とすことで、レビューや実装で再現できます。

ガード節（早期リターン）によるネスト削減

複雑さの多くは条件分岐のネストから生まれます。前提を満たさないケースを関数の冒頭で先に返す「ガード節」を使うと、主となる処理をネストの外に出せて、読み手が追う分岐が減ります。

// 変更前：正常系が3段ネストの奥にある
function getPrice(user) {
  if (user != null) {
    if (user.isMember) {
      return user.price * 0.9;
    } else {
      return user.price;
    }
  }
  return 0;
}

// 変更後：例外ケースを先に返し、本筋を平坦にする
function getPrice(user) {
  if (user == null) return 0;
  if (!user.isMember) return user.price;
  return user.price * 0.9;
}

行数はほぼ変わりませんが、後者は「会員なら1割引」という主目的が最後の1行に現れ、条件の抜け漏れも見つけやすくなります。KISSが狙うのはこの「読む労力の削減」です。

一関数一責務への分割

一つの関数に取得・計算・整形・保存を詰め込むほど、修正時に影響範囲が読めなくなります。「この関数は何をするか」を一文で言い切れない場合は責務が多すぎるサインで、分割の対象です。これはSOLIDの単一責任の原則（SRP）と重なり、KISSを実装レベルで支えます。名前も同様で、calculateTotalPrice() のように処理内容がそのまま読める命名にすれば、説明コメントを減らせます。

循環的複雑度10による定量化

「単純かどうか」を感覚に頼らず測る指標が循環的複雑度（サイクロマティック複雑度）です。トーマス・マッケイブが1976年の論文「A Complexity Measure」で提唱したもので、コード内の独立した経路の数を表します。分岐が増えるほど値が上がり、テストすべき経路とバグの入りやすさの目安になります。

マッケイブは上限として10を挙げ（「絶対ではないが妥当な上限」）、NISTも1関数あたり10以下を推奨しています。一般に1〜10は良好、11〜20は要レビュー、20超はリファクタリング候補と扱われます。多くのリンターやIDEがこの値を計測できるため、レビュー前に閾値を超えた関数を機械的に洗い出せます。

KISS・DRY・YAGNI・SOLIDの違いと使い分け

KISSはしばしばDRY・YAGNI・SOLIDと並べて語られますが、狙う複雑さが異なります。まず全体像を整理します。

KISSとYAGNIは近い関係にあり、YAGNIが「今必要ない機能を作らない」ことでコード量を抑え、結果としてKISSの単純さに寄与します。読み方や具体例はYAGNI側で詳しく整理しているので、YAGNI（ヤグニ）原則の意味・読み方とメリット・デメリットを参照してください。

一方で、これらは常に同じ方向を向くわけではありません。DRYを徹底して共通化を進めると抽象化の層が増え、KISSの単純さと衝突することがあります。SOLIDの拡張性を優先した設計は、今必要のないインターフェースを増やしてYAGNIと緊張します。迷ったら、まず今の要件に対してKISSとYAGNIで最小の形を作り、重複が実害になった時点でDRYを、変更が頻発する箇所に限ってSOLIDを適用する——という順序が、過剰設計を避けつつ保守性を確保しやすい実務的な指針です。

シンプルにしすぎる罠：KISSが逆効果になる場面

KISSは万能ではなく、「単純さ」を取り違えると品質を落とします。次のような場面では、単純化をそのまま進めるべきではありません。

• 本質的な複雑さを削ってしまう：税計算や権限判定のように、仕様そのものが複雑な領域を無理に短く書くと、条件の抜けが起きます。ここで減らすべきは記述の複雑さであって、必要な分岐そのものではありません。
• 重複を「単純」と勘違いする：同じロジックを各所にコピーすると一見どの箇所も短くなりますが、仕様変更時に修正漏れが増えます。これはKISSではなくDRY違反で、単純さの偽装です。
• 変更が頻発する箇所で拡張性を捨てる：要件が動きやすい部分をベタ書きにすると、毎回の改修が大掛かりになります。KISSは「今の要件に対して最小」を意味し、既知の変更軸に対する備えまで削ることではありません。

判断基準はシンプルです。単純化した結果、読み手が理解を誤る／変更時に事故が起きやすくなるなら、それはKISSの適用ではなく手抜きです。KISSは「削る」ことではなく「目的に対して過不足のない形にする」ことだと捉えるのが実践のコツです。

よくある質問

KISS原則の読み方と由来は？

「キス（の法則／原則）」と読みます。ロッキードの技師ケリー・ジョンソンが第二次大戦中に用いた「Keep It Simple, Stupid」が語源で、戦地の整備士が基本工具だけで直せる設計を目指した逸話に由来します。

「Keep It Simple, Stupid」の Stupid はどういう意味ですか？

設計者や利用者が愚かだという意味ではありません。「壊れ方」と「修理に使える限られた手段」の関係を指し、誰でも最小限の前提で扱える単純さを保て、という戒めです。

KISS原則とYAGNI原則の違いは？

KISSは「構造を単純に保て」、YAGNIは「今必要ない機能を先回りして作るな」という指針です。作らないことでコードが単純になるため相性が良く、YAGNIはKISSを実現する手段の一つと位置づけられます。

KISS原則とSOLID原則は矛盾しませんか？

目的が異なります。KISSは単純さ、SOLIDは拡張性を重視します。SOLIDの単一責任の原則（SRP）はKISSと重なりますが、拡張性を優先して抽象化を増やす場面では衝突しうるため、変更が頻発する箇所に絞ってSOLIDを適用するのが現実的です。

コードが単純かどうかを客観的に判断できますか？

循環的複雑度（サイクロマティック複雑度）が目安になります。マッケイブとNISTは1関数あたり10以下を推奨しており、多くのリンターで計測できます。11以上はレビュー、20超はリファクタリングの候補です。

関連記事

• YAGNI（ヤグニ）原則とは？意味・読み方とメリット・デメリットを解説
• コード品質管理における自動化ツールの活用方法
• リファクタリングを行うべきタイミングとその判断基準