雑記：システムを例えるならば？

「システム」と言ってしまうと粒度が大き過ぎるかも知れません。　　「作る」（業務分析・システム分析の段階から含めて）側から見た場合の話として、「動作する成果物」である実行プログラム（こう表現すると、すっごい古臭いイメージを伴いますね．．．）を何に例えるでしょう？

個人的な価値観やイメージの話ではあるんですが、私が現役でプログラム書いている当初は「砂の山」（砂の作品）と表現してました。

仕様変更・仕様追加、そもそも要件自体の認識がオーナー側と食い違っている部分がある。　　途中から性能用件が変わった。　　新規ビジネスなので業務の流れ自体が途中で変った（いや、最初から固まってなどいない？！）。
内部構造の設計、アーキレベルでの見直し、論理層の切り方自体の見直し、切ないですねえ．．．．．。

システムはビジネスの為にあり、ビジネスにはタイミングが必要。　　手戻り作業に「ジックリと時間を掛けてもいいよ～～」なんてケースは、限りなくゼロに等しいです。　　極力短時間で、ベターな解を導き出さないといけません！
砂が崩れます．．．。
一生懸命に考えて、「美しい」とさえ言えそうなアーキテクチャにしたのに、あっちに穴掘り、こっちの壁を盛り上げ、どんどんイビツになっていきます。

システム寿命の短い想定のシステムでは、もう瞬間的な判断能力のみに依存します。　　恐らくはリファクタリングのフェーズなんて無いでしょうから、どんどん構造やソースは汚れる一方で、その内に寿命を迎えることになります。

困るのは、「短命」と想定していたシステムを「延命」する場合ですね。　　「短命」と割り切って汚れ放題だったりすると、これに手を入れるのは非常にコスト高になるし、担当者としても高ストレスになります。
なにより、そのシステムの構造に責任を持っていたはずの担当者にとっては非常に恥ずかしい、肩身の狭～い思いをすることになりますよね。

砂の楼閣じゃありませんが、油断をするとアッという間に崩れて変形して、混沌と無に帰してしまいます。　　よってたかって、沢山の人が触りますからね。　　少しでも混沌化を避けるために、オブジェクト指向、デザインパターン、フレームワークの階層化、相互依存性の抑止、開発ガイドライン、バージョン管理、色々な武器を使うわけです。
勿論、武器だけが存在していてもダメですね。　　なによりも使い手の意識と知識・技術が無いと。

[ どんな奴らがいるんだ？、あ？ ]

ランキング挑戦中！。クリック応援、お願いします！