IT投資の質的変化(２)：ソフトウェアビジネス編

さて、「IT投資の質的変化(１)」で扱った「How IT spending is changing」。前回はハード寄りの話が多かったので、ソフト側の話も。
　
　
ためらいのあるソフト需要
　
ソフトの需要が一切無いかと言われるともちろんそんなことはない。買えるのであれば、良いものは買いたいという流れはある。ポイントはそこから実需に繋がりにくいことにある。

Although IT customers also want to improve their software, they are wary of big-bang packaged applications--purchases that are just now rolling off accrual budgets. This time around, CIOs are shunning expensive panaceas, especially large-scale customer relationship management (CRM) systems. Many tech executives lost face (or jobs) when the promised benefits didn't materialize, often because the technology demanded difficult-to-realize changes in processes and in employee behavior. Even worse than buying packaged applications, CIOs told us, was buying applications and then customizing them, for this strategy made it necessary to reinvest in customization with each subsequent upgrade.

まず、単純に大規模ソフトを組織全体に一気に導入するのは非常にリスクが高い。しばしば、引用箇所にもあるように組織が順応出来ずに効果が十分に発揮出来ないことがある。社内スタッフとして会計システムの導入に関わっている知人と最近やり取りしていて「むしろ、効率化どころか業務プロセスが増えている面もある」とあったが、まさに該当する。

理屈の上では、ソフトの機能を十分に生かし、新しい業務プロセスを描いてその通りにビジネスの仕組みを作り変え・・・と進むはずであるが世の中そう簡単には進まない。例えば、既存の外部システムの制約からどうしても特定の運用方法が採用出来ない、工場物流などのリアルアセットの都合から同じく条件が出てきてしまうなどは良く起こる話である。現場が怠惰だとか、変革を恐れるというケースももちろんあるが、それ以前に、本当に出来ないという話はごく普通に出てくる。

そうなると、勢い「カスタマイズしましょう」という話になるが、手を入れることは即、最後の行に書かれているバージョンアップを如何に行うのかという問題に突き当たる。更には実際にはアプリケーションの側もデータベースの設計が大きく変わったりと、カスタマイズ範囲を極小としていてさえ手を入れ無ければならないことがある。

よって、結局毎度毎度の大工事となりがちである。
　
　
柔軟性への要望とWebサービスの台頭
　
手直しのしやすい、部分改修のしやすい方法はないものか、リスクを一極集中させない方法はあるのかというビジネス側の要望は、ソフトのオブジェクトモデリング技法etcにバックアップを受けてモジュール別への導入の流れに繋がっている。同時に、企業内で統一的な管理の出来るメリットは享受したいということから、反対側で企業内ポータルやEAIのニーズを生み、柔軟性と機能分化への要望はWebサービスに引き継がれつつある。

Meanwhile, integration--a higher priority now than it was during the boom--is generating demand for enterprise application integration (EAI) technologies. Web services are gaining traction faster than anticipated, especially in small telecom and other companies at the forefront of IT innovation. Of the CIOs we interviewed, 8 percent said that Web services were their primary integration strategy.

仕様や技術要件が随時詰められているWebサービスであるが、主軸に据えて業務の見直しを行っている企業は全体の8％。数値の中身が見えないので単純な判断は出来ないものの、多いとはまだ言えない。中でも導入意欲が強いのが

Adoption is strongest among telecommunications and financial-services companies, whose technical complexity makes the software especially attractive.

テレコム、金融。業務の複雑性がキーになると本文中では触れられているが、もう一つ、基本商材がコモデティ化しているところとも言えないだろうか。オペレーション実行能力での差別化を進めるインセンティブが強いという理解の仕方である。
　
　
再び、”誰”
　
さて、ここまで来たところで、改めて問いたいことがある。仮にWebサービス的な実装方法が順調に普及し、サービスレベルまで分解された機能を組み合わせてシステムを組み上げるような仕組みになっていったとして、そのサービスを誰が提供するのか。

まず普通にあるのが、社内部門。アプリは外から買って構築を外部パートナーに依頼したとしても、資産としては自分達のものをするこれまでと基本変わらない方法。次に、ASPサービスがWebサービス化していくパターン。このパターンだとベンダーが提供する標準的なサービスをベースに組んでいくこととなる。eBay、Amazonなどが標準的に準備しているAPIもここに含んでしまって良い。最後に、大規模アウトソースのように、ユーザー企業とテクノロジーベンダーが一緒になって、ベンダー側に構築から運用までを任せきるパターン。IBMやEDSが代表事例となる。

それぞれ、
　・個別個別のサービスを提供する
　・サービスを取りまとめて、統一的なプロセスを設計管理する
　・そもそもどういうサービスが必要かを考える
の三つを誰が担うかが変わってくる。上に行けば行くほどベンダー側の仕事となり、下に行けば行くほどユーザー企業側の仕事となる。インフラを誰が提供するのか、というポイントもあるが、中間領域を誰がどのように分担するのかが当面の間模索の続く領域となる。個別管理を可能とし、柔軟性を高めたところで、最後何らかまとめないといけないことには変わりない。

新しい概念としてサービス・オリエンテッド・アーキテクチャ（SOA）というものしばらく前から提唱されているが、Webサービスの仕様もまだまだ詰められているのとどうようにSOAの概念自体も詰めがまだ足りない段階だと言える。

--
なお、エンタープライズソフト市場での収益構造の変化については以前「大型M&Aから読むエンタープライズ市場の変化」として、簡単ではあるがまとめたことがある。合わせて参照頂きたい。