エンバカデロの今に至る開発ツール部門分離の真実 その3

今、ALM（アプリケーションライフサイクル管理）で、開発環境を含む製品を継続して提供している企業は？と問われて思い浮かぶのは、IBMやマイクロソフトだ。IBMは、Rational Softwareの買収によって獲得した製品が重要な役割を担っているし、マイクロソフトは、Visual Studio自身が、ALMをサポートするようになっている。この両者に共通するのは、ALMのフル機能を自前で揃えていることだ。

おそらくボーランドが目指したかったのは同じところだったと思うのだが、何が違ったのだろうか。

当時、ボーランドは、JBuilderによって主要なJ2EEアプリケーションサーバーをサポートし、IBM、Oracle、BEA、日立など、主要なベンダーのJava開発標準環境となっていた。ただ、一方でEclipseが台頭してくるなど、開発フェーズだけではツール単体での差別化が難しいと感じていて、テスト／パフォーマンス部分にOptimizeIt、設計部分にTogether、構成管理にStarTeam、要求管理にCaribarRMといった製品を、買収という方法で揃えていた。

これらは、それぞれ別の製品ではあるけれども、拡張性の高いJBuilderのIDEのおかげで、ひとつのツールから全部アクセスできるようになった。JBuilderを開発者のデスクトップと見立てて、ここからすべてにアクセスできるようにした、というわけだ。

当時、「開発者の一日」のようなプレゼンを見た記憶がある。

このシナリオは、Javaという特定の開発言語／プラットフォーム限定ではあるが、ある瞬間点だけならうまく機能する。Javaには、さまざまなテクノロジースタックがあり、JDKのバージョン、フレームワークのバージョン、アプリケーションサーバーのバージョンなどなど、いろいろな技術の集合体であるがために、どうしてもそのときどきの要求に合わせて、それなりにうまくいく組み合わせを作って、それで開発をやるという傾向になりがちだ。

JBuilderの場合、その組み合わせを自分で定義して、プロジェクトごとにスイッチできるという発明（JDK Switching）により、いろいろな開発に簡単に適合できた。個人的には、この機能こそ、複雑なテクノロジースタックを抱えるJava開発で、JBuilderが最もウケた理由のような気がしている。

ところが、ボーランドが打ち出した構想はこうだ。

アナリスト、アーキテクト、デベロッパー、テスター向けに最適化されたツール環境を提供する。共通のソフトウェア開発の基盤を用いることで、ビジネスの要求に合致した最適なソフトウェア供給のしくみを用意できる。

SDO（Software Delivery Optimization）というコンセプトから打ち出された製品計画は、ALMに必要なすべての機能を使用者ごとに最適化されたかたちで提供しようという考えだった。ただ、ここには、技術的な飛躍がひとつある。ソフトウェア開発では、設計と実装のはざま、つまり論理設計と物理設計の調整が難しく、実際にちゃんと動くものを作るための現場の作業が、どうしても論理上の設計との乖離を生む。

特定のプラットフォームだけにロックインしていると、ツールがこれを吸収するように用意できるのだが、ロックインをさせないという選択をすると、なかなかツール側で調整するのは難しくなる。

そのため、全体最適化は、ロックインを前提としないと中途半端に終わることが多く、ユーザーの利便性を考えたら局部最適化のほうが実用的だ。ベンダーロックインを回避し、IT資産の自由を担保したいという開発チームにとっては、局部最適化を適宜組み合わせたほうがよいわけだ。

先に挙げたIBMやマイクロソフトのALMは、自社のプラットフォームに対して最適化しているため全体最適化ができる。これはどちらがよいという話ではなく、それぞれ目指すところが違うはずなのだが、当時ボーランドが進めた戦略は、SDO実現のためにツール全体でひとつのプラットフォームにロックインさせてしまう結果になった。

その後、このロックインを解放し、ALMに局部最適化された製品を出して行ったのは賢明だったと思う。ただ、当時の経験から、経営陣が、開発の実装部分については、技術的に複雑なため、切り離して考えようという結論に至ったのだとも推測できる。

結果的に、切り離された開発ツール部門は、より開発の現場に密着できるようになるわけだが、そのことは、Borland Developer Conference 2006の中でも鮮明に打ち出されていったのである。