ケース2 - パッケージ・アプリケーション・ベンダーの場合

ケース2 - パッケージ・アプリケーション・ベンダーの場合

パッケージ・アプリケーション・ベンダーのB社の場合も、ツールとシステムのライフサイクルのギャップ解消に悩みました。複数の企業にアプリケーションを販売しているB社の場合、特定のユーザー企業の状況だけに対応していればいいわけではなく、新しいOSバージョンが出ればそれにも対応しなければなりません。

これまではどうしていたかというと、実際にパッケージ・アプリケーションの開発に利用している特定バージョンのツールやフレームワークに関して、可能な限りこれを使い続ける方向で死守してきたのです。

もっとも、新しいOSが登場した際には、パッケージ・アプリケーションが新OS上で動作するようサポートする必要があります。このための措置として、既存バージョンのツールやフレームワークが新OS上でも動作することを検証し、問題があれば、その個所だけを修正して対応してきました。

既存バージョンのツールやフレームワークを使い続けるという方針によって、確かに最小の労力で新OSに対応することができました。しかし、この一方で、新しい機能やトレンドのユーザー・インタフェースなどを採り入れることができず、気が付くと「やや古いアーキテクチャで動いているアプリケーション」という印象になってしまったのです。

そこで、方針を改め、一足飛びに最新OSの機能をサポートした最新のツールやフレームワークを採用し、モダンなインタフェースも採り入れることにしました。ただ、この作業は、一気に大きなバージョン・アップとなったため、いくつもの変更が必要になったのでした。

今後は、このようなことのないように、もう少しパッケージ・アプリケーションのバージョン・アップの方法を改善していこうと考えました。そこで採用したのが、サブブランチを利用したバージョン・アップです。

リリース・プロジェクトと検証プロジェクトを分ける

用いたのは、それほど複雑な手法ではありません。プロジェクトを、ある時点で2つに分岐させ、検証用のみのプロジェクトを作るのです。こうしたサブブランチ・プロジェクトは、構成管理ツールなどを用いれば簡単に作成できます。

サブブランチ・プロジェクトの目的は、基本的にリビルド（修正したソースのコンパイルや最新のライブラリのリンクなどによってアプリケーションを構築し直すこと）です。リビルド以外の詳細なレビュー（確認/検証）のために使うと、思いっきり工数がかかってしまいますから、あえて切り捨てています。

ただし、新機能やプラットフォームの追加などを目的としたプロジェクトで、かつリリース候補のバージョンになると、リビルドではなく、本格的な検証のためにサブブランチ・プロジェクトを活用することになります。逆に、この時点では、基本的なビルドに関する変更状況は把握しているため、すぐに本作業（本格的な検証など）に入れるというわけです。

このユーザーの例は、開発ツールとして「C++ Builder」（DelphiのC++言語版に相当するRADツール）を使っていたので、（開発ツールであるC++ Builderの）バージョン間の差異はかなり低くなっていました。ロジック部分もC++の標準的なライブラリを使うように心がけていたため、バージョン間の影響はほとんどありませんでした。

一方、大掛かりなアーキテクチャ変更を伴うようなバージョン・アップを繰り返すフレームワークなどを使っていた場合、このようなアプローチは採れないかも知れません。ただし、こうしたケースでもサブブランチ・プロジェクトは有効です。少なくともサブブランチ・プロジェクトをビルドしようとした段階で、大きな変更に気が付きます。

ツールやフレームワークは便利なので、うまく利用したいものです。しかし、現在の便利さだけに目が向いていると、長期的な生産性/効率性が損なわれる恐れがあるのです。

では、こうしたバージョンの移行作業によって性能上の問題が発生するリスクはあるのでしょうか？