無駄を省く その２

その１より

この考え方で流用できるのは、何もシステムだけでは無いと思います。

組織にしたって、動作にしたって無駄なものは無いにこした事はないですよね。

最初はシンプルなものでも、更新や修正を加えるうちに複雑になってしまうのは仕方ないのですが、あまりやりすぎてしまうと更新するだけで時間が大きくかかるものです。

そう言うのをさける為にドキュメントを多く残しはするのですが、途中からそのシステムを運用保守する人にとっては関連するドキュメントを最初から読み進める必要があり引き継ぎに時間を要してしまうケースも少なくありません。

状況によっては３ヶ月くらい勉強しないとまともに仕事に取り付けないという現場もありますので、複雑化しないというのは工数を抑えるという観点からも大切な事ですね。

最初はキレイにやる時間が無いのでまずは、目標を達成するためのシステムが出来上がります。

次に、そのシステムに対して不満点が多くなり、外部の人間が良いものにしようと色々な機能を取り込み始めます。

この時に、意味も無く複雑なモノが出来上がりやすいのですね。

プロトタイプは使う人を選ぶというか制作者の為のシステムである場合が多いので、まずは自分が使える事を前提に作られていきます。

量産機は色々な人が扱えないと不便なので、それが可能になるように色々な制限と機能を持たせます。
MicrosoftOfficeやWindowsなんかが代表格になりますでしょうか。

どちらも成功例ではありますが、バージョンが変わる毎にPCサポートなどをしている人は右往左往したのは良い想いで（？）ですね。

一つのバージョンアップにユーザにどんな影響があるのかそれを一つ一つしらみつぶしに対応するのはあまり現実的では無いと感じます。

大体が人手で何とかするという対応をしているので、何とかなっているのが現状ですが、企業などで扱うシステムはOfficeだけでは無いのでシステムの分だけ対応が必要になるのですね。

これらのシステムをシンプルに構成していれば変更点に対して問題の有る無しは、即答出来るケースだって出てきます。

こういった分かりやすく変化に強いものを作っていくというのがITエンジニアの本来の仕事ですね。

単純に入れるだけでなく、利用し続ける事を考えたものを提供していく場合に無駄を省いておくと問題を絞れるのではないかと思います。

今回はここまでです。

最後まで読んで頂いて有り難うございました。