開発ツールの変遷と、現在の課題
もっと軽く。最近のトレンド
昔のソフトウエア開発は、1個の大きなシステムを全部1つのアーキテクチャで作り上げるような大型工事でした。一方、最近では、いろいろなシステムがつながって、お互いに利用することができるような状況にあります。すべてを完結させる必要はなく、小さいものを段階的に、場合によっては異なるアーキテクチャで作ることができます。
こうなってくると、ツールが想定するプロジェクトの定番パターンというものがなくなってきます。もし、このままツールがカバーする領域を広げていき、フレームワークのサポートや開発プロセスの統合などを推し進めていくと、とてつもなく多くの組み合わせをサポートしなければならなくなってしまいます。
開発ツールは、その方向に向かうのでしょうか。
答えは「ノー」だと思います。ベンダーにそんな体力はありませんし、結局理想的な組み合わせで使える人はごくわずかだからです。
また、多くのツール・ベンダーは、同時にプラットフォーム・ベンダーでもあります。自社のOSやデータベース、アプリケーション・サーバーなどに囲い込むようにベクトルが働いています。そうすると、理想的な組み合わせセットを提供するのが、ベンダーの方向性に合うことになるわけです。
一方、開発者は、こうした単一ベンダーによるロックインを嫌う傾向にあります。いろいろなシステムと連携したり、既存システムの改修や統合を行ったりしなければならない昨今、ベンダーが用意した特定の組み合わせだけというのは、受け入れがたいでしょう。
適材適所の使い分け
オープンソース系の言語やフレームワークが普及するのに伴って、プログラミング・ツールにエディタしか使わないというケースも増えています。そのためか、高機能な開発ツールを一度も触ったことがないという人もいます。
エディタだけでコンパクトに済ますことができるというのは便利ですが、煩雑なコーディング作業に時間をとられるというのは、プログラマが本来注力すべき創造的な仕事ではありません。
プログラミングを労働集約的な仕事と考えると、「タイピング量をどれだけ減らせるか」が、ツールの生産性を測るバロメータになってしまいます。そもそも「生産性なんて測れるのか」という疑問もあります。
ここで、見方を変えて「開発者がより創造的な仕事に従事できるようにする」という視点に立つと、ツールに求める機能と、その機能を判断するために何を尺度にすればよいかということが見えてきます。以下では、こうした機能を3つ紹介します。
- 定型的な作業を自動化し、複雑な作業を簡略化してくれる
フレームワークで使う定型的なコードを自動的に準備してくれるウィザード機能や、変数名の変更やメソッドの宣言方法などを安全に変更してくれるリファクタリング機能などが、時間短縮とコード品質の平準化といった点で役立ちます。 - 作ったものをすぐに見えるようにして、試行錯誤できるようにしてくれる
ある程度組みあがらないと確認できないようなユーザー・インタフェースやデータベース・アクセス機能などを、その場で確認したりテストしたりできるビジュアル・ツールなどが相当します。動きを簡単に確認できるので、早めに問題点に気づき、軌道修正できます。 - 手作業では見つからない問題点を検出したり、可視化したりしてくれる
メモリー・リーク検出ツールやSQLチューニング・ツール、静的コード解析ツールなどが相当します。プログラムの動作を追っているだけでは気づかない潜在的な問題点を、ツールの力を使って発見できます。
ツール導入のメリットというと、しばしば1番目の作業の自動化/効率化のことばかりが言われる傾向にあります。ところが、その後の部分も非常に重要です。「ツールを駆使する」という表現は、まさにこれらの機能を使いこなした場合に当てはまります。
「ツールがなければできなかった」、「ツールのおかげでこれだけの品質向上が可能になった」というようなケースは、まさにこれらの部分が関係します。つまり、ツールの導入効果に対しては、量的な改善（生産性）を求めるだけでなく、質的な改善（品質）を求めることが重要になります。そうすると、「エディタだけで十分」という議論にはならないと思います。
今回は、ツールの変遷を追いながら、現在の課題について考えてきました。開発者にとって理想的なのは、適材適所でツールを使いこなせることです。ただし、ツール導入にはそれなりにコストがかかりますから、導入のメリットについて、社内で正しい共通認識を持って検討してもらいたいですね。
次回は、稼働後のシステム更新などシステム開発プロジェクトのライフサイクルに着目し、開発ツールがどう関与するのかを解説します。
