KISSの原則？
キスとSEやPGが何の関係が？
と、この原則を知らない人は思うかもしれません。
KISSの原則のKISSとはそれぞれの英単語の頭文字で、別にキスのことを言っているわけではありません。
プログラムを書くにあたってとても大切な考え方ですので、この原則は必ず頭に入れておいて欲しいものです。
KISSの原則とは何か？
まず、KISSの原則についてお話しします。
KISSとはKeep It Simple, Stupid.という言葉の頭文字を取ったもので、この言葉の日本語訳は「簡潔にしておけ、愚か者よ」などのように訳すことが出来ます。
これは文字通り、物事は簡潔で単純にしたままの方が分かりやすく、複雑にして分かりにくくしてはいけないことを指しています。
コードを書く際だけではなく、様々な業務に応用が利く原則であり、この原則を知り意識して実践していくことで、業務を簡素化してスムーズに進めることが出来るようになります。
また、業務をスムーズに行えないボトルネックとなる部分に関しても考えることが出来るため、SE、PGだけではなく、多くの職種や業務で重要な原則になります。
プログラムにおけるKISSの原則
プログラムにおけるKISSの原則はプログラムを単純で読みやすく保つことです。
そうすることでプログラムの保守性が上がり、誰が担当になってもプログラムを理解し修正が可能となります。
既存のプログラムの改修の場合、改修箇所に他では使われていない表現やルールを適用したり、コードの書き方を改修箇所だけ異なるといったことが起きないように、きちんと定められたコーディングルールを守ることを前提とし、処理を複雑にせず、出来るだけわかりやすく簡素に書くことが必要になるでしょう。
新規のプログラムの作成の場合、KISSの原則に則ったコーディングルールをきちんと定め、そのルールに従ったプログラムにするように、それぞれのプログラマーが意識することが必要です。
プログラマーの性として、新しく学んだことをプログラムに取り入れたくなるかもしれませんが、それよりも重要なのは保守性であり、可読性の高いプログラムに仕上げることを優先しなければなりません。
そのためには、どの機能に関しても統一した書き方が行われていて、同じような処理をしている個所を共通部品化するなど、コードを短く簡潔にすることで、プログラムの開発者が何らかの理由で抜けてしまった場合でも、新しく入ってきた開発者が問題なく読んで理解することが出来るようにしておく必要があります。
プログラムには開発者のエゴは必要はありません。
顧客の要件に従ったプログラムであり、読みやすく伝わりやすいプログラムを作り上げることこそがPGのなすべき仕事なのです。
プログラムは作品であると言えると思います。
統一性が取れてこそ価値が上がるもので、統一性が取れておらず読みにくいプログラムは価値の低いプログラムであると言えます。
開発全体におけるKISSの原則
KISSの原則を適用する場合は、プログラムだけではなく、設計書や仕様書にも適用させる必要があります。
例えば、プログラムを書く際に必要になる詳細設計書。
詳細設計書が読みにくく難解であるとしたら、PGが適切に読み取れずに、詳細設計書と異なる部分がプログラム上で出て来てしまうかもしれません。
しかし、それでは顧客の要望通りのプログラムとは言えず、コードレビュー時、納品時や受入試験で、顧客から「これはなぜこうしたのか」と指摘されることになります。
また、詳細設計書を書くのに必要な基本設計書、基本設計書を書くのに必要な要件定義書も同様に顧客の要望の中で必要なものを全て網羅しつつも、簡潔で読みやすいものでなくてはいけません。
基本設計書で書くことはかなり多く、詳細設計書に落とし込む際に何度も基本設計書に目を通し、作り上げていかなければなりません。
それにもかかわらず、基本設計書が複雑で読みにくかったり誤読を招く表現があったりした場合、それは詳細設計書を書く際のノイズにしかならず、詳細設計書に顧客が要望していないものを盛り込んでしまうミスも発生します。
ですので、基本設計書も単純かつ簡潔にまとめておくことが重要になります。
もちろん同じ原理で要件定義書を作成する場合も単純かつ簡潔でなければなりません。
まとめ
今回はKISSの原則についてお話ししました。
単純かつ簡潔に、これはSEやPGだけに限らずすべての仕事で必要な考え方になります。
ここではSEやPGを対象とした話にとどめていますが、KISSの原則はすべての仕事で重要になるとても大切な考え方なのです。
ですので、最低でもここのブログの対象の読者であるSEやPGの職に就いている方は、KISSの原則とはどのようなものかをしっかりと理解したうえで、設計書や仕様書をどう作るのか、プログラムをどう作るのかを考え、行動する必要があります。
設計書や仕様書、プログラムは簡潔かつ単純に
この考え方はしっかり覚えておきましょう。
今回の記事はここまでとなります。
また次の記事でお会いしましょう。
