「IT部門とビジネス部門は、お互いをもっと理解し合えば、より良いシステムが生まれる」というフレーズを良く耳にする。前回のブログでもアーキテクトがビジネスの要求を満たすことを強調しており、その為にビジネス知識に精通するに越した事はない。そして時々、人材育成において、現場の実習や、業務部門との人材交流が大切だと説かれている。しかし、ビジネス・システムを設計する“アーキテクト”は、ビジネスの現場(営業最前線や生産工場)での実体験を、豊富に積まなければ良いシステムを創れないのだろうか?
私は、現場経験を積む事は、あれば越したことはないものの、必ずしも業務に精通する為の必須要件であるとは思わない。例えば、同じ間接部門の“経理部門”の人材キャリアパスを見ると、必ずしも現場経験が必要ではない事が見てとれる。業務の現場経験がなくとも優秀な経理マンは大勢いる。そして彼らはビジネスの現場からも充分に尊重されている。それは、体系的に整理された“会計学”としての視点で物事を判断、分析できるスペシャリストだからである。会計学でいうところの複式簿記に相当するものが、ITの世界では各種のモデリングを始めとする設計手法である。ITアーキテクトは、これらの手法を用いて、現場ユーザより偏りのない中立で全体最適な、業務分析・設計が出来る立場にある(現場の臨場感は少なく、あくまでバーチャルであるが)。
業務コンシャスになるという事は,“ITシステムの設計段階でそれが実際の業務にどういったインパクトを与えるかを絶えず自問自答し続ける“ということである。間違ってはいけないのが、”設計したシステムが業務にどう影響するかをイメージする“のであって、”現状の業務を忠実に模写する“ことではない。そこにはデザイン(設計)という(ある種の型にはめる)要素が加わっている。このデザインがシステム化の付加価値の源泉であり、システムの良し悪しを大きく左右する。予め汎用的なデザインが組み込まれているものがパッケージシステムで、自分で組み立てるのがスクラッチということになる。
私はかねてから、「ユーザヒアリングのまんまシステムを作ってはならない」とプロジェクトメンバーに言い続けてきた。ヒアリングの通り模写したシステムはとても歪(いびつ)な型(デザイン)にならざるを得ない。やたらと複雑で例外だらけのしくみはカオスであり、システムの対局に位置するものである。
システムとは人間が創造する付加価値そのものであり、カオスな現実とは一線を画すものである。そして、そこにはアーキテクチャ(構造)が必要不可欠である。また、企業システムにおいて、その形は千差万別である。