アーキテクチャーという単語はICTシステムの現場ではさまざまな意味で使われる。「ソフトウエアによる処理方式」あるいは「OS/ミドルウエアのスタック」や「ハードウエアの構造」、「ハードウエアの製造プロセスの世代」といった意味で使われる場合が多い。

　筆者はシステムの品質を左右する3要素は、システム基盤とアプリケーションの処理方式、そしてアプリケーション構造であると考えている。構造の悪いシステムはバグが減らないからだ。以下、ITアーキテクトとして品質の高いシステムを構築する心得をアプリケーションと非機能要件、ライフサイクルを通じた管理の三つの観点で論じていく。

アプリケーションの構造化には洞察力が必要

　ITアーキテクトがアプリケーション開発で求められることは二つある。企業活動全体の中でシステムが将来どう使われるかやシステムの位置付けが将来どう変わるかを洞察することと、その洞察をアプリケーションの構造、つまりアプリケーションのアーキテクチャーに反映することだ。

　この背景には、いくらアプリケーションの設計開発手法を標準化しても、人によって設計の結果が異なるという事実がある。手法には、構造化（POA）やデータ指向（DOA）、オブジェクト指向（OOA）などがあり、歴史を変遷してさまざま使われてきた。ただ、どれも結局はユースケースに基づくアプリケーションソフトと構造化されたデータを成果物として作り出す。結果的に、「いつ、誰が」に着目してユースケースを洗い出したり、伝票や画面からデータ項目を洗い出したりする過程で、主従関係がよく逆転する。

　例えば、サプライチェーンに着目して機能を整理していくと商品が主で購買者が従になるが、顧客管理に着目すると購買者が主で商品が従になる。よくあるケースが、システムの構築当初は事業部ごとのシステムだったため、各事業部で扱う商品ごとに顧客に請求書を出していたものの、顧客サービスの向上を目的に「顧客単位にまとめて請求書を出す」という新たな要求を加えたところ、改修が広範囲に渡ってしまった、といったものだろう。

　取引データ一つとってみても業務視点の変化がキー項目の違いに出てくる。受注システムは顧客、生産システムは商品、物流システムは地域といったように変わるのだ。