◆部品化・構造化の落とし穴
システム構築にあたり、部品化・構造化は、生産性を向上させるための古くて、新しい考え方である。あらかじめ用意された部品を組合せて、システムを構築できれば、確かに早く、安くシステムを構築できるだろう。確かに、自動車などでは、こういった部品化により、安く、早く、良い物を作ることが実現されている。しかし、業務システムの場合は、いかがなものか。
特に、製造業における生産管理などは、会社毎に全て違うと言っても過言ではない。超多品種少量生産なのである。自動車会社でも、顧客にあらゆる部品の組合せを自由に選択させる方式を導入したところがあるが、やはり納入リードタイムが長くなっているそうだ。システムに要求される仕様にあった部品を探しているくらいなら、作ったほうが早いと言うこともありえる。
コンピュータの世界における部品とは、あくまで、人が、要求事項に沿うように、コンピュータの振舞いを図式化し、設計し、プログラミング言語で定義したものである。つまり、その部品は、作る人によって振舞いが微妙に異なるのである。例えば、実世界では、同じ「本」であっても、システムにおける「本」という部品は、書店の業務システムと、図書館の業務システムと、出版社の業務システムでは、それぞれに振舞いが異なる。
従って、要求仕様にピッタリ合う部品を探すことは、かなり困難である。そこで、現実問題として、どうするかというと、似たような部品を複製し、一部改修して目的の部品に仕上げるのである。また、全体の構造は、ある時点での要求事項を満足するために考案した、一時的な部品どうしの関係を定義したものである。古くは、階層型で関係を定義し、最近では、部品どうしの応答をネットワーク型で定義しているが、いずれも、静的な状態を定義したものである。
ところが、現実の世界は混沌としており、時間と共に変化する。開発中、あるいは運用中に、その変化に合わせて、部品なり構造なりを変化させていかなければならない。部品化しておけば、他の部品に影響を及ぼすことなく、これを実現できるというのが理想であるが、現実は、そう単純ではない。この場合に、部品の中味が明らかになっていれば問題ないが、ブラックＢＯＸになっているとやっかいである。あくまで、外から見た振舞いだけで、影響のあるなしを判断しなければならない。
開発当初は、部品の再利用により生産性が良くなったとしても、このような状況に陥ってしまうと、かえってコストアップにつながる。また、少しずつ振舞いの異なる、似たような部品が増えてしまい、管理が手薄になると混乱の極みである。中味がブラックＢＯＸである部品と、部品同士の複雑な関連、構造化により、業務変化のスピードにシステムの変更が追いつかなくなってしまっては本末転倒である。本来、部品化・構造化は、こういった問題を解決するために考え出させた手法である。その手法が、逆に自ら問題を引き起こすことになる。
最近では、多数の部品を提供しており、その組合せでシステムを構築するという業者も出てきているが、そのメリットは、顧客に還元されているのか疑問である。また、使われた部品は、あくまで提供した業者のものであり、中味はブラックＢＯＸである。ソースコードの提供もしている業者もあるが、その場合は、決して「お安く」はない。それに、その部品を使って、新しい部品を作ったり、組合せてシステムを構築するのは簡単ではない。そこで、また、コンサルティングが必要になったりする。
部品化して、中味が分からなくて良いのは、システムの中で、コンピュータとやりとりする内部の処理で、ほとんど変更が無いような箇所だけである。業務プロセスのように、環境変化に合わせて、処理内容（振舞い）を変更していかなければならないような場合は、中味が分からなければならない。システム構築において、部品を利用して、コストダウンを測る場合は、運用後の保守も考慮して、最小の投資になるか否かを判断しなければならない。
コメント