はじめに KISSの原則とは

ケリー・ジョンソン氏によって提唱された原則です
一般的には "Keep it simple, stupid" （シンプルにしておけ！この間抜け） と解釈されますがジョンソン氏本人は"Keep it short and simple" （簡潔に単純にしておけ）という意味で使っていたようです。

どちらにせよ、この原則は物事はシンプルな方がいいということを訴えています。
さらに格調高い感じにいうと「オッカムの剃刀」というやつですね。

Simple is Best

まずはこちらをご覧いただきたい

阿部寛のホームページ

その古き良きインターネッツなデザインからネット上でよく話題に上がる阿部寛さんの公式ホームページです。
このシンプルさには美しさを覚えます。
そのレスポンスはなんと驚愕の406ms(ブラウザはVivaldiを使用)。

今風なWebサイトによくあるリッチなアニメーションなどは一切無いため、非常に質素な印象を受けますが、その一方で

ドラマ・映画などの出演情報
書籍・写真集の出版情報

といった、このホームページを訪れる人たちが求めているであろう情報へのアクセスは非常にわかりやすく動作も軽快であるため、ストレスを覚えることはまずありません。

これは個人的な感覚ですが、Webに限らずテクノロジーに関してエンドユーザーがストレスを感じるポイントは「遅い」か「わかりにくい」の二つで8割以上を占めていると思います。

システムはなぜ複雑化するのか

その機能本当に必要?

昨今のWeb界隈の技術の進歩はすさまじく、ほんの数年前と比べても実現可能なことは爆発的に増えてきていて、それに伴って開発時に要求されることも増えてきます。

ぶっちゃけだいたいのことは 技術的には 可能です。
しかし、技術者が言うところの「技術的に 可能」とそれ以外の人たちにとっての「実現可能」はたいていの場合大きな隔たりがあります。

クライアントからの要求仕様を盛り込んでいった結果、システムの色んな所が肥え太ってしまい、ユーザーから「重いんだけど(怒)」とクレームが来るのはWebに限らずシステム開発の悲しいあるあるですね。
ハードウェアの方も進歩しているので、スペックごり押しの力技で乗り切れるときもありますが、あまり健全なやり方ではないですね。

ですので、ある要求に対して技術的に 可能であることと、それをすべきかどうかは切り離して考える必要があります。
「そのアニメーションは必要なのか」といった問いかけが常に求められているのです。

補足：「可能」に対する認識

技術者の「技術的に 可能」とそれ以外の人たちにとっての「実現可能」は個人的な感覚ではこれくらい隔たっています。

ある機能の実装に関して

技術者「技術的に 可能」 => 「やろうと思えば不可能ではない」レベル、明言されてない要求(時間・コスト・レスポンスの速さなど)や他への影響はいったん無視して、言われた部分の実装が可能
それ以外の人たち「実現可能」 => 自分が望んでいる時間とコストで、他に影響が出ることなく完成する

なので、技術者からは相手が明言してないけど暗黙の前提として持っている諸々の要求を汲み取る努力が必要ですし、それ以外の人からは技術者が「技術的には」という枕詞を付けたら「現実的には不可能かもしれない」という警戒心を抱く必要があるでしょう。

「こんなこともあろうかと」症候群

システムが複雑化する要因は要求仕様の多さだけではありません。

よくあるパターンとしては、「いつか必要になるかもしれないから」とその時点では必要ない機能を実装してしまい、その結果システムが複雑化するパターンです。
宇宙戦艦ヤマトの真田さんみたいに「こんなこともあろうかと」と言って華麗に問題を解決するのは技術者の憧れですからね。
ハヤブサの小惑星イトカワ探索という技術者の「こんなこともあろうかと」が活きた実例があるだけに、前もって色々手を打っておきたいのは技術者の性であることは理解できます。

この症状のことを個人的に「こんなこともあろうかと」症候群と呼ぶつもりです。
サナダシンドロームという案もありましたが、真田さんをディスってるみたいなので私の中で却下しました。

stupidに込められた思い

冒頭に述べた通り、KISS原則の提唱者は"Keep it short and simple" といった意味で使っていたようですが、今では"Keep it simple, stupid"と解釈されるのが一般的です。
なぜstupidという煽るような一語が入ったのか、前述の複雑化の要因を踏まえてちょっと憶測してみようと思います。

仮説1 クライアントへの怒り

まず第一には色々な要求（時には無理難題）をぶつけてくるクライアントへの「バカ野郎!」という怒りでしょう。
様々な要求に応えた結果動作が重くなって、「じゃあこの機能はいらないや」と言われたら吠えたくなるのも無理ありません。

ですが、主に技術者が目にするような原則にクライアントへの怒りを盛り込んだところであまり意味がないのは確定的に明らかなので、たぶんこれは違うでしょう。

※KISSの原則自体はプログラミング以外でも使われることはあるみたいです。

仮説2 技術者への戒め

個人的にはこちらの方が本質的ではないかと思っています。

それは「こんなこともあろうかと」症候群にかかった技術者への「バカ野郎!お前は真田さんじゃないんだ!」という戒めです。
将来起こりうるあらゆる出来事に対して予め対策を立てるのはほぼ不可能ですし、結局無駄になる可能性を考えると必要になったタイミングで実装する方が建設的です。（容易に想定可能かつ、可能性が大きい事態に対しては予め対処した方がいい場合もあります）

それは「とりあえず動くもの作って後からリファクタリングすればいいや」という技術者への「バカ野郎!後から見たらわからなくなるぞ!」という戒めです。
最初に実装するときから極力シンプルなつくりにしておいた方が、後から改修したりするのも楽だったりします。

我々は自分で思っているほど賢くはないのです。

原点に立ち返る

さて、ここまで色々と論じましたが、ここでもう一度こちらをご覧いただきたい