ところで、システム構築では、納期の遅れ、バグの多さ、使えない仕様など、多くの問題点が存在する。建築では、納期の遅れはあるかもしれないが、何もないのに建物が壊れることなど、ほとんどあり得ない。建築とシステム構築が似ているならば、この違いはどこから生まれているのだろうか。筆者は、システムアーキテクチャが未発達であるうえ、体系的な知識が不足しているからだと考えている。
そもそも建築には長い歴史がある。人類が初めて家を建てたのは数千年前のことだろう。一方で、システム構築の歴史は、最初のコンピュータといわれるENIAC(※)が作られたのが1946年、多くの企業でシステム構築が行われた期間と考えればここ30年、インターネットを利用する企業システムに限ればここ10年程度だ。
とすると、現在のシステム構築というのは、技術や体系化が未発達であった数世紀前の建築のような状況ではないだろうか。つまり、システム構築が理解しにくい理由は、最先端で複雑だからではなくて、未成熟で体系化が遅れているからだと考えた方がよいのだろう。
実際、18世紀のヨーロッパでは、石で造られたビルが崩壊する事故が発生していたそうである(20世紀になってもビルや橋の崩落はあるが、大きな──珍しいニュースとして扱われる)。
そんな時代の建築家に、現代のビルの仕様を渡せば、同じような結果に陥ることが予想されるだろう。ここから、現在のシステム構築が抱える問題点も明らかになる。
では、こうした現状を踏まえてシステムを構築するのはどうしたらよいだろうか。これは、数世紀前の建築家に建築を依頼するためにはどうしたらよいかという問いに答えることに似ている。いろいろな考え方があるだろうが、最も重要なのは、単純ではあるがコミュニケーションということになるだろう。
システムアーキテクチャに関する方法論や技術は、発達中であるがゆえに進歩が速く、またエンジニア(アーキテクト)の知識格差が大きいことから、どんなに信頼できるシステム構築者に依頼したとしても、最適なシステムアーキテクチャを選択するのは容易ではない。
また、企業情報システムでは規模や機能の変更が頻繁に行われるが、システムアーキテクチャはシステム規模に応じてドラスティックに変化しがちである(一軒家と10階建てのビルでは、工法がまったく異なる)。
このように、失敗する確率が高い状況では、発注者の価値観に合わせて、完成度に合意を形成しながら進めるしかない。
すなわち、施工主は自身の要求(システムの目的、機能、パフォーマンス、拡張性)をできる限りきちんと定めて建築家に伝え、建築家が作った設計が要求を満たすものであるかどうかを確認していく──つまり、施工主と建築家が、お互いの垣根を越えて、1枚の設計図に向かい協力し合うということだ。
建築も多くを学びながら発達してきた。システム構築も同じように、ここ数年で急激な発達を遂げている。近い将来、もっと良いシステムアーキテクチャが登場することは間違いない。しかし、建築工法がどんなに発達しても施工主と建築家の間のコミュニケーションが不可欠なように、システム構築においてもシステム発注者とエンジニアの間の協力は欠かせない。お互いの守備範囲を定め、漏れ・抜けのない協力体制構築がまず、最初の一歩だといえるだろう。
次回は、アプリケーション形式と開発手法について解説していこう。
Copyright © ITmedia, Inc. All Rights Reserved.