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

前回につづいて、ソフトウェア開発に関連した標準指向や部品化についての話題です。

技術の二極化

今から１５年ほど前に「今後、ソフトウェアはプラットフォームやライブラリを作るハイエンドの技術者と、それらを使うだけを仕事にする技術者に二極化する」といわれていました。

OS、開発ツールやライブラリが充実したものに拡充されると、それを使って単純なアプリケーションを作成する技術者(?)と、そもそもの高度に専門化したライブラリを設計する技術者に分かれることになるというものでした。

その傾向は、ソフトウェアの標準と部品化の１回目に述べたようにライブラリはデバイスメーカーやOS、開発ツールメーカーに絞られてきている(オープンソースの場合には少し事情が異なりますが)点においては、二極化しているといえます。

実際には、ライブラリのセットが丸ごと入れ替えられたり、主要OSが変遷しているため、ライブラリの充実によって二極化したのではなく、ライブラリを組み合わせて使うだけではアドバンテージが無いため淘汰され、なんらかのアドバンテージを持っていて残っている技術者と初心者が担っているから二極化しているように思います。

新開発ツールと再生産

先ごろSunによってJavaのラピッド開発ツールが発表されましたが、おおよその技術者の感想は、期待より「今さら」とか「そこが問題ではない」といった否定的ともいえる反応が多いように思います（Javaな人達から５年遅いといわれも仕方がないような気もします）。

規模が大きくなったITシステムは、その開発プロジェクトが稼動できる所まで完遂できるかどうか、業務を効率化するための要件定義や運用後の仕様変更に耐えうるかなど、設計やアーキテクチャー、マネージメントなど、コード生産以外の問題の比重が大きくなっているため、相対的にコード生産の手法に関しての興味は低下していることにも起因しているかもしれません。

コード生産効率は良いに越したことはありませんし、品質への影響もありますが、便利な開発ツールが投入されて新規のプロジェクトでコード生産が効率化したとしても、次もまた繰り返されるため、当のプロジェクトの将来に渡る保守や再生産などには結びつきにくいと考えられます。

将来、別の互換のない便利な開発ツールに主流が移ったりOSが違う、開発言語も違う可能性があるため、コードについては「今はこれにする」という選択であって、何らかの期待を持って積極的に新しい開発ツールを選択するということが少なくなっていると思います。

開発ツールや言語まわりにしてそうですから、ソフトウェア部品に関しても「将来は捨てる」可能性が高いものを作るというに等しい行為です。

かつてはソフトウェアの再利用が錦旗のように言われましたが（今でも、この考え方が主流でしょう）、ソフトウェア・コードの部品化によるアドバンテージや対製作コストを考えると、開発プロジェクトの運営に不可避な作業を除いては、コードの再利用を重視した設計が、本当に重要であるかと考えることが多々あります（不可避な部分も沢山あるわけですが）。

書き直してもコストが見合う程度のものかもしれない……再利用に備えるよりも再生産の方が低コストであったり、開発手法が変化すれば変更を余儀なくされる再利用にコストをかけるリスクは、これまでの経過を考えると高いといえます。

数年前のコードが再利用にどれだけ耐性を持っているか、書き直した場合と変更保守ではどちらが得かと考えると……使い捨てるコードにコストをかけて、できるだけ長期間使い捨てにしないようにするか、再生産されることを前提として再生産のためにコストをかけるかということかもしれません。

ソフトウェアの標準と部品化の１回目に話題にしましたUMLを重視する考え方は、再生産型の考え方の１つだと思います。

UMLを扱うツールの互換問題が問題になると思いますし、そもそもUMLだけは安泰かということもありますが。