ソフトウェア開発は、リソースと時間の制約によって、バラバラに開発されることがほとんどです。もちろんシステムとシステムの連携がある場合には、連携する部分は共通のインターフェイスをもたなければいけませんが、システムの内部の機能を共有することはありません。つまり、同じ機能を複数のプロジェクトで開発しているということです。これは開発する時のコストも2倍になりますが、もっとやっかいなのが例えばトラブルで機能を変更する場合、偶然トラブルにならなかったプログラムが後で同じトラブルに見舞われることも考えられるのです。それも過去にトラブルの経験とその対処法がわかっていながらです。これは非常に効率が悪い。また、変化に迅速に対応するために新しいシステムが必要だという時に一から全て開発するのではなく、既に実績のある機能をそのまま使えたらどうでしょう。効率もいいですし、そもそも実績のある機能を使うわけですから信頼性も高いわけです。
つまり共通機能をくくりだして、いろいろなシステムで共有する事が出来れば、その機能を変更すれば全てのシステムで変更したことと同じ事になります。また、新しいシステムを作るときに既にある機能の固まりを使えば、無駄な開発は必要なくなりますよね？ 経営者から見れば、効率的な開発で納期も短くなりますし、手直しも楽なので新しいニーズに対応するシステムを開発させる時に時間と、コストの削減になります。変化への対応とコスト削減が一緒に実現出来るわけです。これは、経営者にとって魅力的な考え方ではないでしょうか？
簡単に言うとこれがSOA(Service Oriented Architecture)の考え方です。ソフトウェア資産を再利用出来る形で開発することと覚えてください。
つまり、この考え方からすると、再利用出来ないものは、いくらソフトウェアベンダがSOAと呼ぼうとも意味をなさないといえます。極端に言えば、あるシステムをSOAで開発しました。しかし次のプロジェクトは、そのシステムの存在をしらないのでまた新たなSOAで開発しましたとなれば、2重投資以上のコストがかかることになります。SOAでは、再利用しやすい機能にわけることによって、普通に開発する以上に手間がかかるのです。であれば、最初から従来通りの開発をした方が開発者も慣れているでしょうし、楽となってしまいます。
つまり、SOAは開発したあとの管理プロセスまで含めてきちんと整備しなければ、通常のシステム開発以上にコストがかかるという本末転倒の結果に陥る危険があるのです。SOAをうたうベンダーは多くいますが、実際には管理に関しても、管理ツールを提供する所までがベンダーの限界です。管理プロセスをデザインし、実行するという重要なところはベンダーが提供してくれない、ということを経営者が理解しなければなりません。
経営者であれば、「ならばソフトウェアだけではなく、開発に係わるもので共有できるものは全て同じように共有できれば効率的ではないか」とお気づきになるでしょう。例えば、開発のコアとなる人材、開発するツールや手順、展開時のテストや移行のノウハウが蓄積された手順書さらにはマネジメントの方法など、全てを資産化し、すべてのシステムで共有できればさらなる効率化が可能です。これはSOAをさらに広範囲に展開した考え方でSPL（Software Product Line）と呼ばれています。SPLはカーネギーメロン大学ソフトウェア研究所で開発されました。
さて、SOAやSPLというバズワードを知らなくても、今まで申し上げた通り、考え方は至極当たり前の事を言っているわけで、理解できるのではないでしょうか？ まずはIT部門が連発するバズワードに惑わされるのではなく、経営的視点で、"考え方"を中心に自分の企業でどこまで対応が可能かを考えてみるのはいかがでしょうか？「SOAとは？」を慣れないIT本で理解しようとするよりも本質的な考え方を中心にITへの適用を考えていく事が重要なのです。
Peace out,
Eric
筆者紹介
エリック松永（Eric Matsunaga）
Berklee College of Music、青山学院大学大学院国際政治経済学研究科（修士）卒業。19世紀の米国二大発明家Graham Bellを起源に持つ米国最大の通信会社AT＆Tにて、先進的なネットワークコンサルティングの領域を開拓。その後アクセンチュアにて、通信分野を柱に、エンターテインメントと通信を活用した新事業のコンサルティングをグローバルレベルで展開する。現在、通信業界を対象にした経営コンサルタントとして活躍中。
