強力なロックインを生み出す「客独自の仕様」

 確かに、ITベンダーが独自仕様のシステムをつくるわけだから、独自仕様とはITベンダー独自の仕様だと考えるのが普通だ。で、ITベンダー独自の仕様といえば、API(アプリケーション・プログラミング・インターフェース)などシステム間連携の仕組みを独自仕様にしているケースが考えられる。さらに、ITベンダーが自ら開発した独自仕様のフレームワークを使って、業務アプリケーションを構築したケースもあるだろう。

 システム間連携の仕組みを独自仕様にして、データ形式も独自のものにしておけば、他のITベンダーは新システムを構築する際に、その独自仕様のシステムとの連携で大きな困難に直面する。開発に必要な工数が読めないし、プロジェクトが炎上するリスクも高くなるため、入札を断念することになる。既存のシステムを構築し保守運用を請け負っているITベンダーにとっては、自分の「シマ」に他のITベンダーが侵入してくるのを防げるわけだ。

 独自仕様のフレームワークを使って業務アプリを構築するほうは、システム刷新の際に他のITベンダーにリプレースされる可能性を激減させる効果がある。フレームワークの著作権などは、パッケージソフトウエアやクラウドと同様に、開発したITベンダーが保持する。自分たちの知的財産なのだから、そりゃ当たり前だ。行政機関などの客側が著作権を持てるのは、その上で開発した、あるいはカスタマイズした業務アプリの部分だけである。

 つまり他のITベンダーが落札した場合、そのITベンダーはゼロベースでシステムを再構築しなければならない。現行のシステムを構築し保守運用してきたITベンダーは、フレームワークに関する情報を開示する義務もないから、システム刷新プロジェクトの炎上リスクは高い。なので、既存のITベンダーによるベンダーロックインが機能し、あえて人様のシマを荒らそうという酔狂なITベンダーは現れなくなる。

 そんな訳なので、ベンダーロックインを生む独自仕様として、このITベンダー独自の仕様に公取委などの関心が集まるのは当然だ。デジタル庁が地方自治体のシステムのクラウド移行に向けて標準化を進めるのも、こうした問題意識があるからだろう。もちろんパッケージソフトウエアやクラウドを活用する場合も、それらのプロダクトの独自仕様によってベンダーロックインが発生する可能性があるから、ベンダー独自の仕様に目を光らせることでベンダーロックインを防ごうというのは、理にかなっているように思える。

 ただねぇ。ITベンダー独自の仕様よりも強力なベンダーロックインを生み出す独自仕様がある。それが客独自の仕様だ。世間の人は何のことか分からないと思うが、IT業界の関係者、特にこの極言暴論の熱心な読者なら、既にピンときていると思う。そう、利用部門のくだらない要求も含めて事細かな要件を、これでもかと言わんばかりに反映した仕様のことだ。

 この客独自の仕様は、その客をシマにしているITベンダー以外にはうかがいしれない。しかも客独自の仕様は、システムの保守運用の期間中に「成長」するという性質も持つ。何のことかと言うと、「ここを修正してくれ」「こんな機能が欲しい」といった利用部門からの要求に対応し、ITベンダーがシステムを改修しているうちに、どんどんシステムが複雑化することを指す。次のシステム刷新の際、客の要求が「現行通り」の場合、成長し肥大化した客独自の仕様は、もはや他のITベンダーには手に負えないものとなるわけだ。

次ページ むしろロックインされたがる行政機関の愚