KISSの原則

​

KISSの原則とは

KISSの原則は、システム、製品、ソリューションの作成において単純性をコアバリューとして提唱する設計哲学です。KISSは「Keep It Simple, Stupid」の頭字語です（「Keep It Simple and Stupid」や「Keep It Short and Simple」というバリエーションもあります）。その前提は驚くほど強力です。単純なソリューションは、理解し、実装し、保守し、デバッグするのが複雑なものより容易なのです。

「単純さは究極の洗練である。」— レオナルド・ダ・ヴィンチ

この原則は複数の分野での観察から生まれました。工学では、複雑なシステムほど故障点が多く、保守に手間がかかり、修正が困難です。ビジネスでは、複雑なプロセスはボトルネックを生み、関係者を混乱させ、変化に抵抗します。ソフトウェア開発では、過剰に設計されたコードは、チームを長年にわたって苦しめる技術的負債となります。KISSの原則はこれらの観察を実行可能なガイドラインに結晶化させています。複雑さが本当に必要でない限り、常に単純さを優先せよ、と。 よくある誤解は、KISSが「単純化せよ」や「原始的なソリューションを作れ」という意味だということです。実際には、単純さを達成するには、複雑さを作り出すよりも多くの努力が必要なことが多いのです。単純なソリューションは、完全で機能的、かつエレガントでなければなりません。実用的な目的に貢献しない不要な装飾を避けるだけです。

​

KISSの原則を3つの深さで理解する

• ビギナー: 問題を解決する際、機能を追加する前に「これが機能する最も単純な解決策は何か？」と自問してください。決して実現しないかもしれない将来のニーズを予測する誘惑を避けてください。
• プラクティショナー: 現在の要件に必要な最小限の複雑さでシステムを設計してください。賢いワンライナーより、明確で読みやすいコードを使ってください。実装したものだけでなく、なぜその決定を下したかを文書化してください。
• アドバンスド: 単純さは文脈依存であることを認識してください。専門家にとって単純なものが、初心者には不可能かもしれません。必要に応じて複雑な振る舞いに組み合わせられる単純なインターフェースを構築することで、単純さと拡張性のバランスを取ってください。

​

起源

KISSの原則の正確な起源はやや不明瞭で、複数の信頼できる情報源が異なるルーツを主張しています。最も広く引用されている起源は、1960年代の米国海軍航空に遡ります。航空機整備エンジニアが、航空機システムを単純で保守可能に保つようリマインダーとして「KISS」を使用したと言われています。このフレーズは整備マニュアルの文脈で登場し、ほとんどの航空機は単純明快な手順で運用可能に保てることを強調していました。 この原則は、ソフトウェアエンジニアリングの複雑さが増す中で奮闘した1970年代から1980年代にかけて、ソフトウェアエンジニアリングでより広く認識されるようになりました。エクストリームプログラミングとテスト駆動開発のパイオニアであるケント・ベックは、単純さを、ほぼすべてのソフトウェア設計決定に影響を与えるコアバリューとして認めています。同様に、伝説的なエンジニアであるエイダ・ラブレスは、計算機械における単純性を提唱したとしばしば引用されています（ただし、時には不正確に）。 この原則は、数多くの思想家によって裏付けられてきました。アルバート・アインシュタインは「すべてはできるだけ単純にすべきだ。ただし、単純にしすぎてはならない」と有名な言葉を残し、単純さは機能に奉仕しなければならないというニュアンスを捉えています。ソフトウェアでは、「一つのことをうまくやれ」というUnix哲学が、オペレーティングシステム設計全体にKISSを反映しています。この原則の持続力は、その普遍的な適用可能性に由来しています。単純さは、ほぼすべての人間の営みにおいて、コスト、エラー、認知負荷を削減するのです。

​

要点

​

応用場面

​

事例

2000年代初頭、Googleの検索インフラはKISSの原則を象徴的に体現していました。大規模な機能セットを持つ精巧なエンタープライズシステムを構築する代わりに、Googleの初期エンジニアは柔軟に組み合わせられる単純で信頼性の高いコンポーネントを構築しました。分散ファイルシステム（GFS）と並列処理フレームワーク（MapReduce）は、その単純さにおいてエレガントでした。一つのことをうまくやり、連鎖させて複雑な問題を解決したのです。この単純さにより、Googleのインフラは、はるかに複雑なシステムを構築した競合他社と比較して、比較的控えめなエンジニアリングのオーバーヘッドで、数百万件のクエリから数十億件のクエリへのスケールを可能にしました。教訓は明確です。単純で焦点を絞ったコンポーネントは、複雑で機能豊富なものよりよくスケールするということです。

​

境界と失敗モード

KISSの原則は強力ですが、重要な制限があります。第一に、過度の単純化は必要な機能を犠牲にする可能性があります。すべての複雑さが必要ないわけではありません。問題の中には本当に洗練されたソリューションを必要とするものもあります。鍵は、本質的な複雑さと偶発的な複雑さを区別することです。 第二に、ある対象にとっての単純さは、別の対象にとっての単純さとは限りません。専門家にとって単純なシステムは、初心者には理解不能かもしれません。KISSの原則は、システムの保守と使用を担当する人を考慮する必要があります。 第三に、単純すぎる単純さは脆弱性を生む可能性があります。時には抽象化のレイヤーを追加すること（即時の複雑さを増す）が、後により大きな複雑さを防ぐことがあります。この原則は、不要な複雑さを排除することを奨励すべきであり、必要な複雑さを避けることではありません。

​

よくある誤解

​

関連コンセプト

​

一言で言うと