Prev / Next / /home/pochi/ChangeLog

ありがちな駄目な設計と構築事例[computer][ネタ]

2005-10-19

http://www.atmarkit.co.jp/farc/rensai/28it03/28it03.html

ドキュメントがまったくなく、ソースにコメントもなかった。
...
利用しているアプリケーションサーバがすでにEOLを迎えており、
...
単一マシン上での動作が大前提となっていたため、
...
バグの発生が起きても解析までに多大な労力を払う必要があった。
...
意味もなく途中でJavaとは違う言語のスクリプトを呼び出す
...
アーキテクチャにまるで一貫性がない。
...
パフォーマンスチューニングの設定もほとんどが誤りだった。


わはは。
こういうことは、なるべくなら話を聞くだけに留めたいけど、
実際に遭遇して経験すると財産になるのよね。

おかげさまで私も勉強させてもらっております。

筆者は、このシステムを構築した作り手への疑問と、
開発当時のプロジェクトに対して憤りを感じた。


怒りを爆発できれば良いんだけど、プロジェクトを進めた人は、
実は偉い人で、自分の経歴に傷を付けたくないので、成功!、
と言いはったりする場合もあるのよね ;-p。
その場合は、システム化により得られた成果を踏まえ、
より一層のシステム化による効率向上を目指し、
とか言う必要があったりする。
大人って大変なのよね。

参考)
素人CIOとの上手な付き合い方とは? --> [2005-09-07-3]

業務で使うシステムの場合には、技術的な問題に加えて、
人事的、組織的、リソース的な諸々の問題と戦う必要がある。
できれば、技術以外の部分は、ユーザ企業側のシステム部門で、
なんとかして欲しいものだけど、システム部門の育成って、
難しいのよねえ。
最低でも企業戦略にマッチングさせる部門に関しては、
自前でやんなきゃいけないけど、その作業って相当難しいし、
各方面との交渉、調整、推進って相当タフな仕事だからね。
その部分は、コンサルにアドバイスを貰うことはできるけど、
完全にアウトソースすることはできないところだし。

ちなみに、企業戦略と関係ない部分や、一般化できる部分、
つまり差別化しにくい部分については、
積極的なアウトソーシングを検討するほうが、
大抵の場合はコスト的に有利。
もし、ごちゃごちゃした日常業務に忙殺されて、
戦略に沿ったシステム提案ができない、という悩みを持つ、
情報システム部門の人がいれば、相談にのりますよん。
相談料は肉でいいよ。

Referrer (Inside): [2005-12-31-1]

permlink