開発の標準化とフレームワークの普及：21世紀はじめのWeb技術史（2）

[原 幹（NTTデータ ビジネスコンサルティング ），＠IT]

　個人で、または趣味の範囲でコンピュータプログラムを書くことについては、その書き方やお作法に決まりはない。本人の好きな流儀でコードを書いてよいし、それに対するしばりや制約といったものは存在しない。

　しかし、企業向けアプリケーションのように複数の担当者が関わるコンピュータプログラムにおいてはそのようなやり方は通用せず、記述されたプログラムに対して何らかの方法で制約をかけてシステム全体の品質を一定水準以上に高める必要がある。

　今回は、ソフトウェア品質を高めるために進化を遂げてきたアプリケーション開発環境の最近の歴史を概観する。

2000年以降のIT技術動向

コード品質維持の限界

　Java言語はそれ以前の言語に比べてオブジェクト指向プログラミングの志向性を明確にしたプログラミング言語であり、開発効率や保守性が高いという特性を持っていた。一方でコードの品質維持は個々のプログラマの力量に委ねられているのが実情であった。もちろんプログラマの能力によってコードの品質は維持できるのだが、チーム開発はやはり人間の集団によるものであり、作成するコードのレベルを一定品質に維持することは各人の能力に依存する。これはJava言語が出現する以前から内在していた課題であり、人間系の品質管理ノウハウが依然として必要な領域でもあった。

Strutsの出現とアプリケーション開発フレームワークの普及

　このような状況の中、アプリケーション開発を標準化・効率化するための全体的な枠組み（フレームワーク）が出現する。Struts（ストラッツと発音）と呼ばれるそれは、Jakarta Projectによって策定されたJava言語でのアプリケーション開発におけるソフトウェアフレームワークである。

　ここでいうソフトウェアフレームワークとは、アプリケーションに共通して実装される処理（入出力処理やエラー処理など）を標準化して、個別に実装するべき範囲を最小限にするべく工夫がなされたソフトウェアの枠組みを称する。すなわちプログラマはどのシステムでも共通して実装する機能を個別にコーディングすることもなく、記述したいコードに集中できるようにする枠組みを意味する。

　Strutsの大きな特徴は、MVCモデルの本格的な実装だ。MVCとは「Model-View-Controller」の略称であり、

• Model-ビジネスロジックおよびデータベースアクセスを制御（JavaBeansにて行う）
• View-画面表示および入出力制御（JSP/HTMLにて行う）
• Controller-ModelとViewの処理を切り分け画面遷移やマッピングを制御（サーブレットに行う）

の3つの役割を明確に切り分けることで、例えば、画面とデータベース制御の開発担当を分離するなどモジュール単位での開発を可能にしたこと、読みやすく洗練されたコード記述を可能にすることなどにより、アプリケーション開発の生産性を向上させることに大きく貢献し、またカスタムタグによるコード保守性の向上の恩恵も享受できるようになった。Javaプログラミングの心得があれば、チーム開発でも生産性の違いがシステム品質にばらつきをもたらすリスクを低減することを可能にしたのである。

　それ以前の構造化プログラミングの時代でもソフトウェア品質の標準化手法は存在したが、Java言語におけるソフトウェアフレームワーク（特にStruts）の画期的な点はツールやアーキテクチャそのものに品質向上や標準化のノウハウが組み込まれており、プログラマが意識しなくても一定品質のコードを記述できる「仕組み」を提供したことにある。

　このようなソフトウェアフレームワークのもたらすメリット（開発生産性の向上・チーム作業の効率化・保守性の向上）はソフトウェア業界では好意的に受け入れられ、一気に普及期に入る。大手システムインテグレータなどはフレームワークベースの開発環境を独自に提供するようになった。

　特にStrutsによってもたらされるメリットは開発効率を高めることに寄与したが、独自仕様のソフトウェアフレームワークが乱立することで優位性は長くは続かず、各社横並びの様相になっていく側面もあった。さらに、開発環境そのものにソフトウェアフレームワークが組み込まれる流れが起きつつあった。

IDE（統合開発環境）の台頭とEclipseの浸透

　Jbuilder、VisualCafe、VisualAgeなど初期のJava開発ツール群には、ソフトウェアフレームワークの発想が盛り込まれておらず、またツール間の機能差異もあってアプリケーションの共通化が十分に図られていたとは言いがたかった。

　このような状況の中、共通プラットフォームを確立するという目的の下に開発されたIDE（統合開発環境）が「Eclipse」（エクリプス）である。EclipseはIBMが1998年に開発を始め、2001年にオープンソース化したことで爆発的に普及したIDEである。

　Eclipseの主な特徴は以下のとおりである。

• CVS連携：バージョン管理システムCVSと連携したソースコードの履歴管理
• JUnit連携：ユニットテストのためのテストコード自動生成
• Ant連携：ビルドシステムAntとの連携
• コード編集支援：クラス名・メソッド名・変数名の補完、メソッドスケルトンの自動生成など

　Eclipseは標準機能に対してさまざまなプラグイン（追加機能）を組み込むことで、開発作業を効率的に進められるようになる。主なプラグインには以下のようなものがある。

• Tomcatプラグイン：アプリケーションサーバTomcatとの連携
• UMLプラグイン：UMLダイヤグラムからのJavaコードの自動生成やリバースエンジニアリング
• STP：SOA開発を支援する

　Eclipseは軽快な動作も相まって開発者コミュニティの間で爆発的に普及した。IDEにソフトウェアフレームワークの機能が組み込まれたことで、ツールによる生産性向上は端境期を迎えたのである。

ソフトウェア品質向上・標準化につながる次の進化は？

　企業向けシステムは大規模化・複雑化・高機能化の一途をたどっている。さらには技術の進歩は日進月歩を通り越して“秒進分歩”の勢いで進んでおり、追随するのも容易ではない。このような激しい変化の中、ソフトウェア品質を保つための方法論はどのような進化段階を迎えるのだろうか？

　1つ考えられるのは、IDEのようなツール群にソフトウェア開発方法論と呼ばれる概念を取り込めるだけ取り込んでしまい、開発者が意識しなくてもそのレールに乗って開発を進めることで自動的に一定品質の成果物（この場合はソフトウェアコード）が作られるようになる、というストーリーだ。あたかも工場のラインで機械的に作業を進めるがごとくである。ただし、筆者はこの考え方には否定的だ。ソフトウェアプログラミングは知識集約型の作業であり、投入時間に比例して機械的に生産できる性質のものではない。現在の開発環境がそうであるように、ツールによるソフトウェア品質の維持・標準化はあくまで支援にとどまるレベルだろう。

　ではどのような進化を迎えるか、あるいは迎えるべきなのか？ アプリケーションの複雑度や規模に応じて適用するフレームワークや開発手法を選別する、モジュール間インターフェイスの記述をある程度自動化して人手が介在するのを極力少なくする、などの方向性が考えられよう。将来予測は非常に難しい。確かなことは、21世紀に入ってからは企業向けシステム開発の困難さやリスクは飛躍的に上がっており、人間の判断力に頼ってソフトウェア品質をコントロールするのは限界があるということだ。人間系のノウハウに頼ったとしても、技術の進歩によってそれは容易に陳腐化する。

　一方でITの社会インフラとしての機能は日増しに重要性を増す一方である。技術要素の進化に依存せず、高品質のソフトウェアを提供できる仕組みが早期に普及・定着化することを期待したい。

「21世紀はじめのWeb技術史」バックナンバー

• 最小限の手間でシステム間連携を実現する〜疎結合アーキテクチャの登場
• 開発の標準化とフレームワークの普及
• 集中と分散を繰り返すクライアント環境の歴史