「KISSの原則」
はじめまして、企画設計グループの法貴です。
企画設計グループは、その名のとおり、システムの企画や設計(要件定義を含む)をしたり、プロジェクト全体のマネジメントをしたりするグループですが、今日は、私が要件定義や設計の工程で迷ったときに、いつも思い出すようにしている言葉を紹介します。
「KISSの原則」
「Keep it simple, stupid! 」で、略してKISSです。
意味は、「それをシンプルに保て！マヌケ野郎」。
Stupidとつくあたり、勢いがあって好きですが、レビューとか公式の場では説明しづらいのが難点。
システムやプログラムにおいて、複雑さは悪です。
それは、スパゲッティコードは避けよ、という意味の、ミクロなレベルでも当てはまるし、
システムのアーキテクチャ設計という、マクロな視点でも当てはまります。
ちなみに最初にこの言葉を使った人はstupidの前にカンマを付けずに、
「Keep it simple stupid」としていたそうです。
この場合、stupid は会話の相手に向けられているのではなく、itにかかります。
つまり、
「それをシンプルでマヌケに保て！」という意味です。
これも含蓄ある言葉だと思います。つまり、プログラムを賢く(=多機能)してはダメで、1プログラム=1責務という、シンプルな構成にしておけ、という意味だと思います。Unix(=Linuxの先祖)コマンドの精神ですね。
ところで、シンプルがいい、というのは、エンジニアならば、誰でも、直感的に分かりますよね？
それなのに、なぜ、巷には、
スパゲッティコードや、密接にサブシステム同士が絡み合う、複雑でモノリシックなシステムが溢れているのでしょうか。
単純に、エンジニアのスキル不足が原因のことが多いでしょう。
でも、時に、スキルの高いエンジニアであっても、
KISSの原則を守れないことがあるのです。
例えば、次に説明するYAGNIの原則を守れなかった結果、KISSの原則も守れなくなるケースもあると思います。
「YAGNIの原則」
「You ain’t gonna need it!」で略してYAGNI です。
意味は「そんな機能はいらん」です。
もう少し具体的にすると、
「その機能作っても、将来、使うことないから、作る意味ないよ。」
とか、
「運用で回避できるんだから、その機能はいらないよ。」
という感じです。
(若干、私の拡大解釈が入ってます)
将来必要かも、と思って機能を作り込んでも、実際には使われないことがよくあります。その機能を開発するためにかけたコストはドブに捨てたことになります。
また、あまり使われない例外的なユースケースのために、プログラムの条件分岐が複雑になったり、開発工数が倍になったりすることも、まま、あります。これが、YAGNIのせいでKISSの原則を守れなくなるケースです。
スキルの高いエンジニアほど、プログラムを汎用的に作りたいものです。しかし、その汎用性は本当に必要なのか、は見極めるべきです。もしかしたら、それはYAGNIの罠かも。。
KISSの原則を守れるならば、YAGNIな機能を実装しても大した害は無いですが、YAGNIな機能を実装したために、KISSの原則を守れなくなったら最悪です。
私は前職でSlerのエンジニアでしたが、その頃は、発注元がYAGNIな要件を指定してきても、立場上、それはYAGNIだと指摘するメリットがありませんでした。指摘したらその機能を開発する工数分の契約が削られるだけなので。
今は、自社サービスを開発する立場なので、YAGNIと気付いたら、その要件のシステム化を避けられないか、交渉するようにしています。
YAGNIをYAGNIと言えるのも、自社サービスのエンジニアの良いところかも知れません。
納得感のある要件定義・設計ができたとき、そのサービスを世に出して、その成長を見守ることは、とても楽しいですよ！
