インフラの現場でも使えるDRY・KISS・YAGNIについて
DRY原則、KISSの原則、YAGNIの法則
開発界隈では「DRY原則」「KISSの原則」「YAGNIの法則」という有名な3つの格言がありますが、インフラ界隈でこの言葉を使用している人はあまり見かけません。インフラ設計でも通じる点が多いともいますので、今回はインフラ系の現場でも使えるDRY原則、KISSの原則、YAGNIの法則について説明したいと思います。
DRY原則
DRY原則の説明
DRY原則＝Don’t repeat yourself＝繰り返しを避けろ！
Wikipediaでは下記のように説明されています。
Don’t repeat yourself (DRY) あるいはSingle Source of truth(英)[要出典]は、特にコンピューティングの領域で、重複を防ぐ考え方である。この哲学は、情報の重複は変更の困難さを増大し透明性を減少させ、不一致を生じる可能性につながるため、重複するべきでないことを強調する。
引用元：wikipedia 2021/4/17
https://ja.wikipedia.org/wiki/Don%27t_repeat_yourself
DRYは同じ機能を要する仕組みを複数個用意するということは、その分作業が増えてしまう上に混乱を生じさせるシステムとなってしまうので気を付けるべし、と言う内容です。
インフラの現場でも同じ機能や機材を複数個用意してしまうミスはあります。調達フェーズで気付けばまだ御の字ですが、実装フェーズで発覚すると最悪です。が、こういったケースは結構起こりえます。（笑）
機器が増えれば増えるほど開発フェーズのスピード感が失われ、その後の運用コストが無駄に増えてしまいます。とくにオンプレ系は一度構築した環境を撤去したり構成変更することは中々出来ません。最低でも数年は維持されます。その間、運用保守の担当者はこの負の遺産と付き合い続けることになります。
DRY原則から学べることは、『要求されている機能とコンポーネントの関係は必ず単一となり明確にすることが重要』ということだと思います。
エンタープライズ系のインフラはどうしてもウォーターフォールになってしまうので、最初の要件定義と調達フェーズを慎重に行うことが防止策だと思います。
KISSの原則
KISS原則の説明
KISSの原則=Keep it simple stupid=できるだけシンプルにしとけ！
Wikipediaでは下記のように説明されています。
KISS の原則 (英: KISS principle) とは、「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）という内容の、1960年代の米国海軍において言われた、経験的な原理・原則[1]の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。
引用元：wikipedia 2021/4/17
https://ja.wikipedia.org/wiki/KISSの原則
運用保守を経験しているエンジニアなら肌で感じるほどこの重要性を認識していると思います。複雑で大きなシステムを1つ作るより単純で小さいシステムを積み上げた方が改修やメンテナンスのし易さという点から優れており最終的なコストは低くなります。また、複雑化したシステムというのは俗人化しやすく担当エンジニアが現場から去ると完全にブラックボックス化してしまう懸念も挙げられます。
KISSの原則については「stupid」＝「愚か」というワードが入っています。時に優秀なエンジニアは個人の技術力で要求以上の機能追加や性能を引き出そうと設計を複雑化することがありますが、「stupid」はエンジニアへの戒めの念が込められていると言っていた人がいますが全くその通りだなぁと感じます。
KISSの原則から学べることは『高度な機能を複雑化してまで実装することに努力を向けるのではなく、単純な設計や構成にすることに最大限の努力を向ける』ことだと思います。
ただ、『単純な設計や構成に最大限の努力を向ける』と言うのは簡単ですがやり遂げるのは難しいことだと感じます。マズローのハンマーではありませんが、エンジニアは自身の知識だけで解決しようとするので…。（当方も昔はその傾向が強かったです…）
そういう時は自分より現場経験の長いエンジニアに助言を求めたり、過去の事例を調べてみることで回避できると思います。
YAGNIの法則
YAGNIの法則の説明
YAGNIの法則=You ain’t gonna need it=それはきっと必要にならない
Wikipediaでは下記のように説明されています。
“You ain’t gonna need it"[1]、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。
引用元：wikipedia 2021/4/17
https://ja.wikipedia.org/wiki/YAGNI
wikipediaにも記載されていますが「後で使うだろうと予測して作った機能は10%程度しか使わず、それに費やした時間の90%は無駄になる」と提唱する人がいます。数字の真偽はわかりませんが、YAGNIで伝えたいことは『必要な時になったら機能を追加しましょう。その方が最終的なコストはかからないんだから』ということです。裏を返せば『余計なことはするな』ともとれます。
YAGNIの法則から学べることは『わからない未来のために労力をかけない方がよい。きっと予測して作った機能は利益ではなく害悪へ変わってしまう』ということだと思います。
インフラの現場でも『念の為〇〇が起きるかもしれないから△△を用意した』と機能や物品を要件以上に準備し、結果使用しないケースは散見されます。
但し、組織にもよりますがオンプレ系で物品の購入をする際はYAGNIに当てはめるとまずい場合があります。主にエンタープライズ系のSIerは大手企業がお客様となり、お客様の資金で物品調達をすることになります。後になって想定外の物品を追加購入するとなるとお客様側の決済フローを再度まわす必要がありここのハードルが非常に高いことが多々あります。そのハードルを乗り越えるくらいなら最初に予測して購入する、という選択が重要になってきます。
まとめ
今回はDRY、KISS、YAGNIについてインフラの話しを交えつつ説明しました。
DRY原則＝Don’t repeat yourself＝繰り返しを避けろ！
KISSの原則=Keep it simple stupid=できるだけシンプルにしとけ！
YAGNIの法則=You ain’t gonna need it=それはきっと必要にならない
いずれも上記の過ちを起こすとそれを改修することが非常に難しく、その後の運用担当者やお客様はその負の遺産と付き合い続けることを強制されます。
そういったことが起きないようにDRY、KISS、YAGNIを意識して仕事を進めたいですね。