開発ツールの変遷と、現在の課題

開発ツールから透けて見えるもの

ソフトウエア開発において、ツールは欠かすことができません。しかし、ツールに求められる要件は、時代とともに変わってきています。開発者にとっては必要に迫られて使うものに過ぎませんが、開発ツールに長らく携わってきた筆者からすると、ツールを通して現在のソフトウエア開発の課題が透けて見えます。

ツールの開発には相当な時間がかかるうえ、一度使い始めたツールは手に馴染（なじ）んでくるため、1つのツールにとどまる時間が長くなります。そうすると、そのとき抱えている開発上の課題とツールが提供する機能が合致しないということが起こります。実は、このギャップが、現在開発者が抱える課題であったり、これからのツールの方向性を考えるヒントだったりするのです。

この連載では、開発の現場が抱える課題をあぶり出し、ツールがどのようにこれらの問題に対応しようとしているのかを解説していこうと思います。開発に携わる人にとっては、ツールとの付き合い方や、これからのツールに求められることなどが理解できるのではないかと思います。

初めに、ちょっとだけ過去20～30年ぐらいの開発ツールの歴史を振り返ってみましょう。私自身が初めてプログラミングを経験したのは20年以上も前のことで、今とは状況もずいぶん違いました。プログラムは結局指示した通りにしか動かないのですが、現在ではその原因が自分のコードに限らないケースが多くなっているのですね。

開発ツール小史

現在普通に目にする開発ツールは、1980年代のIDE（統合開発環境）の発明によってスタートしたといっていいでしょう。IDEは、従来ばらばらだったエディタ、コンパイラ、デバッガを1つにまとめたもので、コードを書いてすぐに実行、テストできるというのが革新的でした。これで、一連の開発の流れがすっきりして、今では当たり前の「試行錯誤」を繰り返す開発ができるようになりました。

その後、Windowsの登場とともに、開発環境自身もGUI化します。マルチウィンドウによって多くの情報を一度に扱うことができるようになりましたが、同時に、GUIアプリケーション開発のためにコードが複雑化してしまいました。Windowsのアプリケーションは、基本的にイベント・ドリブンの処理を記述しなければならないので、これに合致するオブジェクト指向型の開発が、従来型の開発スタイルに慣れた多くのプログラマにとって難しく感じられたのかも知れません。

これに対し、マウス操作でユーザー・インタフェースを設計できる「Visual Basic」が普及します。さらに同じ簡単なアプローチでありながら、C++などと同じような高機能を兼ね備えた「Delphi」も登場します。これらのツールは、RAD（Rapid Application Development）ツールと呼ばれ、90年代後半は、RADツールによるクライアント・サーバー（C/S）型のアプリケーション開発が全盛でした。

やがて、Javaの普及とWeb開発の広がりが同時期に起こります。Java開発ツールも、当初はRADツールの形態を採っていましたが、サーバー・サイドの需要が拡大することでツールのあり方が変わっていきました。さまざまなフレームワーク（特定用途の機能コンポーネント群）の台頭によってソフトウエア部品を「組み合わせて使う」スタイルが広がり、標準のIDEプラットフォームとして「Eclipse」が登場します。

Eclipseは、構成こそ1980年代に登場したIDEと同じですが、さまざまなプラグインによって機能を追加・統合できる点が異なります。これにより、ある意味、「統合」による「IDEの究極の形」が完成したと言ってもいいでしょう。

しかし、ここには大きな落とし穴がありました。