ソフトウェアの標準と部品化 2

前回につづいて、ソフトウェア開発に関連した標準指向や部品化についての話題です。今回は、なぜ今さら、部品化と標準化を話題にしようと思ったのかを述べてみたいと思います。

ここ数年で、ソフトウェアの標準化や部品化に関わるムーブメントは、表層的には標準化の動きが大きく、また激しく変化しており、実装を伴う部品化はオープンソースのような形では現れることがあるものの、表面的には沈静しているといえます。

一つに、前回述べましたように、プラットフォームや開発言語などが変化しているため、実装レベルでのソフトウェア部品が即物的には意味をなさないことに起因しているかと思います。

また、それによって、デザインパターンやXP、UMLなどのようにコードの実装ではなく、設計レベルのもう一段抽象化された手法などがその役割を担うものとなり、実装上の共通化については、標準化(もしくはプロジェクトの共通のプラットフォーム)の過程に組込まれれるようにという形にシフトしてきているのだと認識しています。

前時代的なソフトウェア部品というのは、実装コード自身を指し、部品化することによる品質と開発効率の向上が「戦略」であるかの表現がなされていましたが、現在は、「戦術」として実装コードの共通化や部品化が行われるとしても、以前のようにメンテナンスと管理さえ怠らなければ、絶対的に有用なコードとなると考えて部品化されているわけではないと思います。

プラットフォームが変化したり、標準基盤や開発手法が変化すると、実装コードのライブラリ部品は必ずしも軽いメンテナンスで利用することが困難な部分が少なからず発生します。

実装部品化や共通化は、開発プロジェクトを遂行する戦術としては絶対的に有用であっても、中長期的にリーズナブルにメンテナンスする手法や将来のプロジェクトに有用であるとは限りません。

近年、開発手法や分析など実装以上のレベルでのドキュメント化や開発手法の標準化などを技術資産として「戦略」的な捕らえ方をしている説を目にすることがあります。

これも手法に過ぎないため、「戦術」であって開発上の「戦略」ではないと思いますが……

開発手法が変化すると、末端の実装コードの作成方法などは、劇的に変化します。

従って、ソフトウェアの部品化や開発手法の「戦術」も、将来性や中長期的にというのではなく、短期的にコストに見合う手法という観点を持つことが重要であると考えています。

PCのソフトであれば、MS-DOSの時代にはMS-DOS用のライブラリを、WindowsではWindows用のライブラリを、さらに32bitに、MFCにATL対応に、COMに…そして、Java、Perlでと忠実に作っていた人がいました。

そして.Netの仕事をするので、それらを即物的には利用できてはいない……

だから、UMLのモデリングやXMLドキュメントでといっても、基本的なプラットフォームや要件が違うので、程度問題であって、それを「戦略」的に捕らえれば同じことの繰り返しです。

ソフトウェアの部品化は、プラットフォーム・サイクルの短命化に伴って有効な期間が短くなってきていると思います。

今後の動向までは予見できませんが、実装コードやリソースを溜め込んで再利用する手法を守れば良いという状況ではないことは明白です。