06:48フォローするアプレッソ開発部の渡辺です。前回の記事では、SOAとは何かについて紹介をしました。今回はSOAがどうして必要になったのか、業務システム開発における歴史的経緯について紹介します。SOAでは業務で必要となるアプリケーションを直接作りません。このような方法を取る理由は解りにくいところもあると思います。回りくどくて二度手間ではないか、と思えるかもしれません(実際そのような側面もあります)。SOAあるいは、「つなぐ技術」による開発の考え方が登場した背景には、以下のような業務システム開発における歴史的苦闘があります。自社独自に業務システムを作る場合の問題まず、業務システムを直接に(つまり普通に)作ることを考えてみましょう。良いところ直接作るメリットは様々にあります。作り方として解りやすく自然です(この方法以外の方法があるの?と聞かれそうですらあります)。大きな長所として、一から作るために前提となる制限がなく、自分達の欲しいものを自由に作ることができる特徴もあります。良くないところ問題点もあります。開発期間がかかる傾向が挙げられます。どのような業務システムが必要か議論して決めた後、システムを開発して実際に動かすまでに、例えば三年がかかってしまい、完成した時点ですでに古くなっているようなことが起こりがちです。期間がかかるということは開発予算も大きくなりがちだということです。システムの全面刷新に予算も期間もかかるならば、と部分的改修や追加開発にとどめると、改修を行うほどシステムの中が汚くなってしまう傾向があります。その結果、改修を重ねるほどシステムに様々な問題が蓄積するようになります。不具合が出やすくなったり、改修作業が難しくなったり、使いにくくなったり、整合性の取れていない機能が出来てしまったりして、機能的に不十分なまま改良が困難になってしまったりします。なると、もはや新規開発を行った方がマシな状態になってしまいます。改修にとどめる場合も、開発作業にはある程度の期間を要することが多く、ビジネスニーズへの迅速な対応は難しい傾向があります。様々な理由で別々に作られたシステムが沢山出来てしまい、それらがうまく連携できなくなり、社内に多数のバラバラになったシステムが存在し、不便であるだけでなく全社最適な業務システムにできなくなってしまうことがあります。良い点:自分達の望み通りの業務システムが手に入る悪い点:予算がかかる、期間がかかる、機能の変更要求や追加要求に十分に対応できない、バラバラの多数のシステムになりがち完成品のソフトウェアを買ってくる場合の問題そこで新たな方法として登場したのが、自分達で開発を行う代わりに完成品のソフトウェアを買ってくる方法、すなわちパッケージソフトウェアの導入による業務システムの構築や更新でした。良いところまず、すでにある完成品を買ってくるため、完成までの期間がかからなくなります。パッケージソフトウェアは多くの会社が払ったお金で作られますから、結果的に安く済むようになります。パッケージソフトウェアは多数のシステムでバラバラになった社内システムを、全社で統合された一つのシステムにするためにも導入されました。パッケージソフトウェアには、自社では到底思いつかないような優れたビジネスのやり方が取り入れられていることがあり、パッケージソフトウェアを導入することで、そのような優れたビジネスのやり方で全社の業務を刷新することができる側面もありました。良くないところしかし、問題点も多くありました。自社向けに開発されていないので、導入してみると自社の業務にあわず、使い物にならない場合がありました。業務のやり方の独自性に自社の強みがあった場合、パッケージソフトウェアの導入によりその強みが失われてしまうこともありました。自社の事情だけで開発が進まないことから、自社にとって切実に必要な新機能がいつまでたっても用意されないようなことも起こります。そこで、個別事情に対応できない問題点に対応すべく、パッケージのカスタマイズやアドオン開発が行われるようになりましたが、今度はカスタマイズ部分が大きくなりすぎて結局予算と期間がかかるような場合や、カスタマイズ部分が原因でパッケージソフトウェア本体のアップデートに対応できなくなってしまい、システムが古いままになってしまうようなことも起こりました。バラバラになっていた社内システムをパッケージで統一した後、パッケージソフトウェア自体で賄えない機能が出てきたものの他のソフトウェアとうまく連携できなかったり、他社システムとの連携がうまく出来ないようなことが起こります。結果、融通の利かない巨大パッケージと、それとうまく連携できていないその他システム多数としてまたもバラバラに戻ってしまうようなことも起こります。良い点:すぐ用意できる、安くすむ、全社統一システムにできる、優れたビジネスのやり方で全社的改革ができる悪い点:自社業務にマッチせずに使えない場合がある、自社のプロセス面での強みがなくなることがある、自社の望んだとおりのシステムにならずに困ることがある、カスタマイズすると予算と期間がかかってしまうことがある、またバラバラに戻ることがあるこれら問題への解決策としのSOASOAは、このような独自開発やパッケージ導入における様々な問題を解決する考え方として注目されるようになりました。SOAは全ての面において優れた方法ではありません。部品(サービス)を作ってから部品同士を組み上げる方法は回りくどく面倒な方法でもあり、開発作業が難しくなってしまうこともあります。それは、ここまで見てきた様々な問題を無くすこととのトレードオフだと考えると、SOAの見え方が違ってくると思います。SOAの特徴である迅速性と柔軟性や再利用性は、自社開発システムやパッケージソフトウェアといった既存システムそのものの再利用に対しても効果的です。既存システムをサービス化してSOAに取り込んで利用してしまうことができます。自社開発のシステム上の優れた機能をサービスとして部品化すれば、旧システムを捨てることなく使い続けられますし、部品化した機能以外を切り落としてスリム化し、いわば旧システムの強みを洗練させた上で残すようなこともできます。システム開発をとりまく状況は、クラウドの利用が本格化しつつあることや、またモバイルやソーシャルやビッグデータへの対応が求められるようになるなど、さらに複雑化しつつあります。ビジネスに求められる速度もどんどん速くなっています。このような状況を踏まえると、変更の柔軟性や迅速性、そして多種多様なリソースを容易に利用できることは、今後より重要になるはずです。今後はSOAをはじめとする「つなぐ技術」が、より重要になるのではないでしょうか。次回の記事では、SOAのアーキテクチャであるレイヤ構造について簡単に説明し、SOAの導入が経営や業務部門にもたらす変化について説明します。コミュニティを開くコメントログインしてコメントを残してください。