工業系企業では昔から、自社が作成したサービスやツールを他社のIT担当者も利用できることに気付いている。例えば、自動車メーカーのSaabは、ハードウェア企業とソフトウェア企業を自社から分離独立させている。同様に、General Electric（GE）も複数のテクノロジーグループを展開している。

　最近は企業の間で、自社独自のソフトウェアをスクラッチで構築して市場での差別化を図ろうとする動きが広がっている。こうした取り組みを進める企業は、収入の流れをさらに増やすため、自社開発のソフトウェアやその形式を商用またはオープンソースシステムとして他社にも提供している。

　その典型的な例がAmazon.comだ。同社のルーツはオンライン書店だが、同社の子会社が運営するクラウドサービス群「Amazon Web Services」（AWS）は、自社のサービスやアプリケーションを提供するだけでなく、数百万件にも及ぶ他社のアプリケーションもホストしている。同社は時間をかけて、ソフトウェアベンダーへとスムーズな転身を果たした。AWSはこうしたクラウド戦略の一環として、DellやHP、IBMなどに対抗するハードウェアも設計／構築している。

　ソフトウェアベンダーになろうと考える企業は少なくない。Netflixは、ビッグデータやワークロードオーケストレーションなどの分野でオープンソースソフトウェアの利用や提供の取り組みをGitHubに提示している。米国大手金融機関Capital OneはコンテナオーケストレーションツールベンダーCritical Stackを買収し、コンテナセキュリティの強化を目指し、そのソフトウェアを他社に販売するようになっている。

　従来のIT企業もまた変わりつつある。IBMはアプリケーション開発環境「Eclipse」事業を、Googleはコンテナオーケストレーションツール「Kubernetes」事業を、VMwareはPaaS（Platform as a Service）構築ツール「Cloud Foundry」事業をそれぞれスピンオフ（分離）している。

　出自はともかく、ソフトウェアの開発元企業は自社のソフトウェアを社内のデファクトスタンダードにする。これにより、開発と導入がさらに促される。IT担当者は、自社独自のニーズを満たすために、少なくとも大幅なカスタマイズを必要としないソフトウェアを利用できるようになる。しかも、それは実際の企業が開発して検証済みのソフトウェアだ。

　ITを専門としないさまざまな企業がサービスやアプリケーションを構築し共有している。ソフトウェアの経済は、こうした企業から恩恵を得ている。小規模企業にとっては、さまざまな種類のソフトウェアを入手しやすくなり、競争力のある製品ではイノベーションが促される。

求められる慎重さ

　残念ながら、このモデルには問題もある。これまでとは異なる“ソフトウェアベンダー”が堅実で自立したサポートを提供すれば問題ない。だが、そうでない場合は、こうしたベンダーのツールを利用するIT部門は難しい状況に陥る恐れがある。例えば、ソフトウェアの開発元企業が自社独自の要件を満たすために任意の時点でソフトウェアに変更を加える可能性がある。こうした変更は、他社にとって望ましくないか必要でない場合も当然ある。

　ソフトウェアの開発元企業がソフトウェアに大きな変更を加えたり、完全に廃止したりすることもある。Googleのインスタントメッセージングツール「Googleトーク」やSNS（ソーシャルネットワーキングサービス）の「Google+」などは分かりやすい例だ。このようなソフトウェアを利用しているIT担当者は、現時点では、自身でソフトウェアをサポートするか、別のシステムに移行するかを決めなければならない。

　特にオープンソースソフトウェアをベースにしたサービスには、デューデリジェンス（適正評価）が重要になる。利用に際してサポートをどこから受けるかだけでなく、そのサポートが終了する場合に新たにサポートをどこから受けるかを決めておく必要がある。ソフトウェアがサポート費用を負担するに値するサービスを提供していて、それを使い続けなければいけないのであれば、費用を負担すればよい。

　事業継続のため、ソフトウェアの供給ポイントは複数確保しておこう。開発元企業が小規模な場合は特にだ。そうすることで、ソフトウェアの開発元企業が倒産しても、IT部門のユーザーは別の機能に置き換えるまでサービスを利用し続けることができる。ソフトウェアの新たなエコノミーで心の安定を保つには、1つに全てを賭けるべきではない。