[アカデミック]
2026年06月01日
KISSの原則
前回は思考をシンプルに整理するための指針「オッカムのカミソリ」を紹介しました。
今回紹介する『KISSの原則』は、主に設計思想の一つになります。
モノづくりの設計では多用されますが、名前の面白さと、「オッカムのカミソリ」との類似点から、今回紹介したいと思います。
「KISS」とロマンチックな響きですが、その内容はシビアです。
『KISSの原則』は、「すべてを簡潔に」が根底にあります。
この歴史は古く、1960年代にアメリカ海軍の航空エンジニアだったケリー・ジョンソンによって提唱されとされています。
彼がチームのデザイナーたちに次のように述べたといわれています。
「私のような間抜け（Stupid）でも、戦場で手に入る単純な工具だけで修理できるような設計にしろ」
特殊工具が必要であったりなど、メンテナンス性が悪ければ、戦争での生存率に大きく影響が出ます。
軍に所属するエンジニアらしい発想だと思いました。
『KISSの原則』のKISSは、単語の頭文字からつけられています。
・Keep It Simple, Stupid.（シンプルにしておけ、この間抜け！）※最も一般的
・Keep It Short and Simple.（簡潔に、そしてシンプルに）
・Keep It Simple and Smart.（シンプルに、そしてスマートに）
といくつかバリエーションがあるようです。
ここで、モノづくり（ハードウェア設計とプログラミング）についての一例を挙げてみたいと思います。
１：ハードウェア設計
ハードウェアは、物理的な部品で構成されています。
部品には個々に耐久性があります。
ここで、顕著な例を挙げたいと思います。
すべての部品の不良品率が0.1%であったとします。
部品を10個使った製品と、100個、1000個使った製品の比較を行います。
| 部品個数 | 不良品率 |
| 10 | 約1.00% |
| 100 | 約9.52% |
| 1,000 | 約63.23% |
ですので、小さなモジュールを作成し、そのモジュール単位で部品数を減らす対応策があります。
大きな一体型の製品を作るのではなく、中・小規模のモジュールを使って製品を組み上げます。
不具合が確認できた時点で、モジュール単位のテストや部品交換で対応できるため。
最終的には、時間的コストを大幅に縮小させることができます。
２：プログラミング
ソフトウェアもハードウェア同様、ベンダー提供のライブラリを利用することで小さなモジュールと同じ効果が期待できます。
プログラミングを例として、１歩踏み込むと、面白い格言が思い起こされます。
「３日前の自分は他人」
格言の意味と教訓は、以下の通り。
「時間が経つと、その時の自分の考えはわからなくなる」
よって、ドキュメントやコメントをしっかり記録しておくことの重要性を説いています。
プログラミングでは、バージョンアップが頻繁に行われます。
その時、複雑で多機能なモジュール（関数等）より、シンプルなモジュールを作成した方が、メンテナンス性や拡張性が格段に良くなります。
プログラマの悪い癖「あと１つだけ（追加しよう）」。
その悪癖が開発にとってマイナスである証明にもなります。
今回は、設計思想につながる『KISSの原則』を紹介しました。
ハードウェアの教科書は、ソフトウェアに比べると圧倒的に不足しています。
当社では大学等の実験テキスト、新人教育向けのテキストなどの相談も承っております。
お困りの際は、お気軽にご相談ください。
