モジュール定義の進化と技術者の立ち位置

物理レベルのモジュール定義から論理レベルのモジュール定義に技術は移行しています。たとえば、Catalysisのコンポーネント定義、UML 2.xのコンポーネント、最近ですとSCA（Service Component Architecture）があります。これらはCBD（Component-based Development）を推進するものです。こうした論理レベルのモジュール定義は、物理レベルのモジュール定義につきまとう、バージョン管理、配布、起動モデル、リソースのライフサイクル管理の制約や移植性の問題から独立した仕様化を可能とする上で重要な考え方です。

こうした仕様化に類似するのが、プロセス、スレッド、通信とポート、パッケージ、メッセージの論理レベルでの定義です。これらもメタモデル的にはすべてモジュール定義の一種と考えることができます。

この進化の過程は、COM（Component Object Model）やJava、CORBAでのパッケージやライブラリの管理の反省から起こりました。COMでは、ライブラリ形式のサーバ、代表的なのはActiveX controlですが、DLLというOS依存のライブラリ形式をパッケージとし、それをCOMコンポーネントと同一視したことによる多くの問題が引き起こされたのです。COMはインターフェースベースの定義でしたから、CoClassという実装のバージョン管理が弱かったこと、DLLを使うことで、OSの起動モデルが利用され、オブジェクト参照での解放がきれいに行われなかったこと、それに、一番の問題はDLLが実行時にファイルロックされ、実行時の更新ができかったことが問題になりました。のちにIISではシャドーコピーという方法でDLLのロックの問題を回避しました。しかし、この解決は本来はコンポーネントモデルが持つべき機能であったので、このような解決の方法は一時的、局所的だと言えます。

さて、こうしたコンポーネントモデルの進化、モジュール定義の抽象化は、物理レベルの実装機構の決定を遅延させる効果を持っています。さらなる抽象化の進歩は、物理レベルの仕様化や実装自体を省略することも可能かもしれません。この特徴は、概念レベルから論理レベルへのモデル変換の場合とは大きく異なっています。概念レベルから論理レベルへの変換では、要求と設計とのギャップが大きく、開発作業に多くの仮設と検証を含むので、モデル変換は例外を除いて困難と考えられるからです。この点での説明は将来のモデル変換のテーマで触れるつもりです。

それでは、こうした流れから、マイクロソフトはソフトウェア技術者に上流を指向することを推薦すると言えるでしょうか。確かに、昨今の傾向では、ソフトウェア技術者は、要求開発やプロジェクト管理、システム提案やソリューションコンサルティングなど上流工程、正確には、概念レベルを指向することがトレンドになっています。これは、こうした領域がモデル変換の自動化が困難な領域であることと関係があります。もっとも、日本のIT産業のビジネスモデルは、物理レベルは下請けの仕事、つまり、単価が安く、低コストが優先され、必ずしも生産性の高さが考慮されないことにも関係があります。

私は、ITシステムがどんな場合であってもビジネスの要求に基づかなければならない点で、概念レベルの経験や知識は持っておくべきだと思っています。しかし、だからといって、上流を単純に指向していいとは思っていません。一度、概念レベルを経験し、もう1度、分析、設計など論理レベル、あるいは、その実現技術の意思決定である、物理レベルに戻ってくるべきだと思います。そうでなければ、技術革新を起こすことも、十分に享受することもできないと思っています。技術者としての誇りや仕事の品質は、こうした技術を背景にしたものでなければならないでしょう。

マイクロソフトの出す技術テーマも、SOA、SaaS、BI、User Experienceなど、ビジネスとの結び付きを強めていて、一見すると、胡散臭いマーケティング用語、技術の裏付けのないキャッチな言葉ととらえられるかもしれません。それは、わたくしたちの責任でもあります。が、私は常にそれが実現可能かどうか、技術革新のポイントは何かを考えます。それなくして、自分の言葉で説明することはできません。