ツールを生かした開発の実際

アプリケーションのライフサイクルを考える

前回、アプリケーションを時間軸で見たときの問題点として、ツールがサポートしているフレームワークやデータベース・プラットフォームが、バージョン・アップとともにアプリケーションの想定と合致しなくなる例を挙げました。このような事例は、アプリケーションを作り捨てられない多くのケースで、開発後数年たってから発生します。

特に最近は、なんでも新しい技術で作り直すわけにはいかない予算事情もあって、「なんとかうまく手間をかけずに新システムに移行できないものか」と苦慮している例が増加しています。ツール・ベンダーの立場でも、こうした相談を受ける機会が明らかに増えている気がします。

こうした状況を受けて今回は、「ツールをどのように生かせばいいのか」に着目して解説します。とはいえ、あまり具体的な例を挙げると差し障りがありますので、よくあるケースから仮想例を組み立てて紹介します。

ケース1 - 自社の情報系システムの場合

最初に紹介するのは、自社システムを開発したケースです。

A社では、情報系のシステムに、「Delphi」（Pascalベースの言語を用いたRADツール）を使ったクライアント・サーバー型のアプリケーションを開発して運用していました。10年ほど前に、時流に乗ってJava化するといって、あまり明確な機能スペックを定義せずに移行プロジェクトを進めました。その結果、従来のシステムほどの操作性、パフォーマンスを出せず、とりあえず従来システムはそのまま使い続けるという結論になってしまいました。

その後、新しい業務システムなどは、サーバー・サイドのJava技術などを使って、完全に新規で作成し成功してきましたが、クライアント・サーバー型の従来システムだけはそのまま残り続けました。残り続けた最大の理由は、キーボード中心の入力形態です。ファンクション・キーを使った入力や、矢印キーによるフィールドの移動です。「マウスを使わずに素早くたくさんの情報を入力しなければならない」という要求に合致する、代替のインタフェースがなかったのです。

A社では、最終的に、無理なアーキテクチャ変更は行わず、従来のクライアント・インタフェースはそのまま温存することにしました。ユーザーにとっては、バックエンド側のシステムがどうなっているのかは関係ないので、このバックエンド側（舞台裏）だけを調整することにしたのです。

具体的には、Delphiのクライアント画面に貼り付いたロジック（ちょっと比喩的な表現ですが、画面を構成するプログラムにロジックが混在していると考えてください）を、ペリペリと引き離して、別のモジュールに移動します（現在は、こうした作業をサポートするリファクタリング機能やUMLモデリング機能がDelphiの開発環境に付属しています）。そして、モジュールを、クライアント側で使用するものと、リモート・サーバーに配置するものに分別します。

リモート・サーバーを置くことで、クライアントは軽量化でき、メンテナンスも容易になります。ただし、ネットワーク通信を伴うので、どのデータを引っ張ってくるかといったことを、精査しなければなりません。最終的に、クライアントは、どのようなデータベース・アクセスをしているとかデータの更新処理の詳細がどうだとかいったことは一切関知せず、ただ、ブラック・ボックス化された更新メソッドを呼び出すだけでよくなりました。

その結果、クライアント側もサーバー側も、アップデートが比較的自由になりました。同時に、専用のクライアント・ソフトと並行して、Webクライアントもリリースしました。これにより、マシンのアップデートにも柔軟に対応できるようになりました。Webクライアントは、専用クライアントと比べて操作性は劣りますが、専用クライアントと同等の機能を備え、データの入力・参照が可能です。

自社システムの場合、使用するクライアントの環境はある程度制御できるかもしれません。しかし、常に最新環境への対応が求められるパッケージ・アプリケーション・ベンダーや、ユーザーの環境に左右される受託開発のケースなどでは、継続的に新しい環境に対応する体制が必要になります。

現状の開発資産を新しい環境に合わせていくには、ツール側のアップデートも考えなければなりません。既存の開発資産、最新環境への適合、ツールのバージョン。どのように、これらのバランスをとればよいのでしょうか？