図4●変化と不変の分離の例
人間の役割の変化は多様である。人間モデルに安定性を持たせるため，役割を別のモデル要素として分離し変化に対応する。

アーキテクトが重要な役割を担う

　技術の進歩に合わせて適切にシステム資産を発展させるには，業務モデルとシステム表現を分離し，業務モデルから最適なシステム表現を選択可能にするアーキテクチャを構築しなければならない。そしてアーキテクチャ構築には，アーキテクトの存在が必須である。

　アーキテクトに課せられる役割は大きい。ソフトウェアの構造や振る舞いが特定の条件下でよい結果を生むという一種の経験則，分析パターンや設計パターンを知っている必要がある。これに基づいて，実装する上で発生する多くの技術的トレードオフや未知の問題を解決しなければならない。一方で，パターンにとらわれ過ぎず適切な設計の意思決定を行うことが求められる。設計と実装戦略において大域的な姿勢を持つことが重要である。以下にその例をいくつか挙げる。

　まず，間接参照の柔軟性とオーバーヘッドを適切に見極めなければならない。世の中には間接参照を使った拡張性の高い設計パターンやフレームワークが多く存在するが，いずれもその利点と引き換えに制限や副作用がある。例えば，XML文書の部分要素に処理プログラムを対応付けるフレームワーク，リレーショナル・データモデルにおける逆正規化やビューの設計，オブジェクト呼び出しテーブルのメモリー・レイアウト設計などである。間接参照による抽象化（レイヤー化），パターン，フレームワーク実装の利点と制限を理解することが大切だ。

　次に，プログラミング・モデルを適切に選択する必要がある。例えばシステムに拡張性を持たせようとすると，属性ベースかルールベースのどちらかを採用することになる。この二つは，システムのカスタマイズを許す個所にインラインで属性を記述するか，その個所をルールで表現するかで，戦略が異なる。XMLスキーマ言語や，.NET Frameworkでメタデータを定義するために使うカスタム属性が属性ベース。Schematronスキーマ言語，アスペクト指向言語のpointcut定義がルールベースの例である。

　属性ベースのプログラミングは，J2EE，.NETなど多くの開発/実行環境で採用されている。システムのうちカスタマイズ可能な機能（カスタム機能）が必要な個所に，機能を示す属性データを付与する。こうして，機能を実装するためのプログラム開発を省力化する。しかし，大規模プログラムでカスタム機能を利用する個所が増加する場合，あるいは，カスタム機能を必要とする個所や必要機能そのものの変更が予想される場合は，ソースコードに逐次属性を付与するとスケーラビリティの問題やコード変更などの保守の問題が生じる。

　一方のルールベースはソースコード外にカスタム機能が必要な個所を指定するルールを記述する。このため保守面で有利である。ただしルールに従ってカスタム機能の場所を検索し，機能を実行できる環境がなければならない。必然的にシステムが複雑化する傾向がある。いずれかのアーキテクチャ戦略を適切に選ぶことが肝要である。

適切なデータモデルや視点を用いる

　データモデルと表現の選択も重要である。データモデルとその表現方法には多くの種類がある。データ型とデータ値の対，リレーショナル・データモデルの項目とレコード，XMLの要素と属性，W3CのRDF（Resource Description Framework）のtripletデータ表現などである。概念モデルにおけるコンテナと収められるコンテンツのパターンに対して，適切なデータ表現とアクセス法を選択することが大切である。

　このところ話題になり始めたものとしては，分離した視点（Separation of Concerns）の導入がある。クラスやオブジェクトとは別の視点で問題領域を分離し，各サブシステムに適切なアーキテクチャを適用する。あるいは複数のパラダイムを使い分け，大規模システム開発のリスクを軽減する考え方と実践を行う。直交する（うまく分割され相互依存関係を持たない独立した）複数フィーチャやアスペクトをモデル要素として利用することが，分離した視点の例である。最近ではEA（Enterprise Architecture）における四つの視点（技術，アプリケーション，データ，業務）が知られている。

　変化と不変の分離という普遍的な課題も忘れてはならない。将来の業務や技術の変化に対して，変化する部分と変化しない部分を分離することが必要である。変化する部分に適切な柔軟性，拡張性を持たせるよう考慮しなければならない（図4[拡大表示]）。

アーキテクトが明るい未来を築く

　最後に，アーキテクトの姿勢に対する私の考えをまとめてみたい。

　まず，万能な技術はないことを認識せよ。抽象化には「抽象化のやぶれ」，モデル要素の導入にはモデルの意味の前提条件と限界のリスクが存在する。この観点では，オブジェクト指向技術も万能ではない。

　次に，技術に中立であれ。流行にとらわれず本質的な技術の意味と価値をとらえること。アプリケーション・サーバーの歴史はまだ10年以下である。陳腐化しない，ソフトウェア・サイエンスやソフトウェア工学の基礎を顧みることが重要である。

　そして，変化に対応せよ。技術の将来性，投資したシステムの保護を考慮し，変化する部分を予見して分離する。ただし，変化を予見することには深い洞察力が必要である。むしろ一歩進んで，自ら変化を作り出すビジョンを持つことに努めるべきであろう。

　最後に，モチベーションを維持せよ。新技術への絶え間ない挑戦には強い意志が必要で，留まることは許されない。自分で限界を設定してはいけない。

　Grady Booch氏は，ソフトウェアが複雑化する中で，その開発を困難にする9個の要因を挙げている。(1)物理法則，(2)ソフトウェア法則，(3)アルゴリズムにおける課題，(4)配布に関する課題，(5)設計上の課題，(6)組織の重要性，(7)経済的影響，(8)政治的影響，(9)想像力の限界，である。例えばアルゴリズムでは，圧縮，シミュレーション，知識表現の困難さを挙げている。配布に関しては分散コンピューティングが抱える8種類の誤謬，すなわちネットワークの信頼性，無遅延，無限の帯域幅，ネットワークの安全性，変更のないトポロジ，単一の管理者，転送コストがゼロ，一様なネットワーク，を指摘している。9個の困難さのうち(4)の配布までがコンピュータ・サイエンス分野の課題で，(5)の設計上の課題以下を方法論の領域としている。

　IT，特にソフトウェアは多くの困難さを持っており，複雑さの度合いを増している。今後，困難さに果敢に挑戦するアーキテクトが増え，明るい未来を築くことを期待している。