自治体システムの現状とベンダーロックインの回避方法【ベンダーロックイン②】
- category : GDX ナレッジ
#デジタルガバメント
- writer : GDX TIMES編集部
index
ベンダーロックインとは、情報システムをある特定のベンダーの製品や独自仕様の技術、サービスなどに依存した構成とすることで、他社への乗り換えが困難になることをいいます。本記事では、自治体システムの現状およびベンダーロックインを回避する方法について紹介します。
ベンダーロックインは、自治体システムのクラウド化が進まない原因のひとつ
ベンダーロックインとは、情報システムを特定のベンダーの技術や製品などに依存した構成とすることで、他社への乗り換えが困難な状況に陥ることです。現在、自治体の情報システムの構築やその管理においては、コスト削減や住民サービスの向上を図るために、クラウドコンピューティング技術を活用した情報システムの共同利用を進めようとしています。しかし、ベンダーロックインは、自治体システムのクラウド化を阻害する要因となっています。詳しくは、以下の記事をお読みください。
自治体システムのクラウド化を遅らせるベンダーへの依存体質【ベンダーロックイン①】
2022年の調査でわかった自治体の情報システムの現状
公正取引委員会は、行政のデジタル化の推進を喫緊の課題とする政府の取り組みを踏まえて、情報システムの調達において多様なベンダーが参入しやすい環境を整備するために、官公庁における実態の調査を実施しました。2021年6月から行った官公庁向けのアンケート調査、官公庁・ベンダーに対するヒアリング調査や、有識者による「情報システム調達に関する意見交換会」の内容を、2022年2月に「官公庁における情報システム調達に関する実態調査報告書」として発表しています。
「既存ベンダーと再度契約した」が98.9％
これまでに情報システムの保守、改修、更改などの際に、現在利用している情報システムを取り扱うベンダーと再度契約することになった事例の有無を質問したところ、98,9％の官公庁が「ある」と回答しました。既存ベンダーと再度契約することになった理由については、半数近く（48.3%）が「既存ベンダーしか既存システムの機能の詳細を把握することができなかったため」と回答しています。
なかには「既存システムは、これまでに何度も改修され、担当者がソースコードの変更履歴を理解できていないために、既存ベンダー以外に発注することができない状態」との回答もありました。このことからも、官公庁においては、情報システムに関する知見や人員体制が不足している可能性があることがうかがえます。
また、「既存システムの機能（技術）に係る権利が既存ベンダーに帰属していたため」との回答も24.3％と多く、情報システムの調達において、仕様書の作成や受注者との契約の際に、特定のベンダーに偏った仕様となっていたり、権利処理が適切になされていなかった可能性もあります。
システムを円滑に稼働させるためのAPI連携は52.2％
API連携を「全て」「ほとんど」「半数程度」「一部」行っている官公庁は、合わせて52.2％になります。これに加えて「API連携を行っていない」と回答した官公庁のうち126機関（全体の12.4％）が「他の方式で連携しているため」と回答しているので、この数値を足すと、約65％が何らかの方式で情報システム間の連携を行っているようです。
しかし、「全ての情報システムにおいてAPI連携を行っている」と回答した官公庁は、全体のわずか0.6％。これに「ほとんどの情報システムにおいて」「半数程度以上の情報システムにおいて」API連携を行っていると回答した官公庁を加えても、全体の19.5％にとどまっています。
仕様書を内部の職員のみで作成したのは67.6％
オープンソースのソフトウェアや汎用性の高い技術や製品を採用するオープンな仕様の設計を行うことは、多様なベンダーの新規参入を促し、ベンダーロックインを防止することにつながります。このため地方公共団体においては「地方公共団体情報システムの標準化に関する法律（2021年法律第40号）」によって、標準化の対象となる20の業務に関連する情報システムについては、各府省庁が作成する標準仕様書の基準に適合したものの利用が義務づけられています。
このような背景から、67.6％の官公庁が過去の同種案件の仕様書を参考にするなどして「内部の職員のみで作成した」と回答しています。ただし「オープンな仕様を定めるにあたっての仕様書の書き方や機能の設定方法について何が正しいのかわからず，担当者だけでオープンな仕様を定めることが難しいので，結果として仕様内容が単に前例踏襲になってしまっている」という声もあり、仕様書を内部で作成するための職員のリテラシーや、内部で作成した仕様書の精度にはまだまだ課題がありそうです。
「オープンソース化している情報システムがある」は4.7％
オープンソース化とは、情報システムに関するソースコードを公開することです。オープンソース化によって機能が公開されれば、そのシステムの更新時や関連する業務システムの調達において，さまざまなベンダーの新規参入を促すことになります。このような観点から、オープンソース化している情報システムの有無について質問したところ、「システムが提供する機能の全て又は一部をオープンソース化している情報システムがある」との回答は全体の4.7％に過ぎず、「機能をオープンソース化している情報システムは一切ない」との回答が大半（68.1％）でした。
オープンソース化の実例として、国土地理院の「地理院地図」がありますが、担当者へのヒアリングによると「ソースコードを公開することによって、その運用や改修のための調達の際に、既存ベンダー以外のベンダーも情報システムについて事前に把握することが可能なために、複数のベンダー間での競争が行われている」という声が聞かれました。このように、情報システムのオープンソース化によってその機能が公開されることで、ベンダーロックインを解消することができるため、国全体として情報システムのオープンソース化を推進することが期待されます。
ベンダーロックインを回避する方法
これまで見てきたようなベンダーロックインを回避するためには、どのような方法が有効でしょうか。
公的に定められた規格や一般的に利用されることが多いデータベースを採用する
そのためには、オープンソースを利用したクラウドツールやアプリを導入することが有効です。たとえば、APIの構築には、Auth2.0などISOで公的に定められた規格に準じて構築するとよいでしょう。データについては、一般的に利用されることの多いSQL DBやOracleなどのデータベースを採用し、アプリケーションも、Java（R）※やPythonなどシェアの高いプログラミング言語を採用します。
※Javaは、米国Sun Microsystems,Inc.の登録商標です。
複数の会社が参画するマルチベンダー形式で開発する
マルチベンダーとは、開発を依頼するベンダーを1社に限定することなく、複数のベンダーがチームを組んで開発を進めることです。システム構築後の運用にあたっては、チームのなかから対応力に優れたベンダーを選定することもでき、その時々の状況に応じて、チーム内のベンダーから依頼先を選定するなどの柔軟な対応が可能になります。
「ベンダーにおまかせ」状態にしない体制や企業・組織文化を整える
保有する情報システムそれぞれの特徴を把握し、ベンダー主導で構築するシステムと、発注者主導で構築するシステムとをしっかりと判別しておくことが大切です。
ベンダーが主導で構築しても支障がないシステムには、システムの構造がシンプルでシステム全体の把握が社内の担当者にも容易なものや、一部のシステム改修や機能拡張など。これに対して、発注者主導で構築するシステムとは、構築の範囲が広いものや構造が複雑なもの、今後、システムの拡張や改修、関連システムの構築が見込まれるようなシステムが当てはまるでしょう。
いずれにしても、システムについては、自社内でその全体像を把握し管理できるように努め、ベンダーへの丸投げ状態から脱却するという強い意志を経営陣主導で示しながら、自社のシステムについては社内で把握し管理するという企業文化を、着実に醸成していくことが大切です。
ドキュメントを最新化する
設計書などの情報システムに関するドキュメント類は、つねに最新の状態として管理し、第三者が見ても読みやすく理解しやすい状態としておきましょう。必要に応じて、ドキュメント類の最新化を、システムの保守運用を担当するベンダーに依頼しましょう。保守運用作業の範囲内でドキュメント類の整備を依頼することが可能です。
政府も、自治体システムの「クラウド化」「標準化」対策を強化
総務省は、地方公共団体のシステムに、ASP（Application Service Provider）やSaaS（Software as a Service）の利用を推奨しています。さらに、GIF（政府相互運用性フレームワーク）による標準化とカスタマイズの原則禁止の徹底によって、ベンダーロックインに陥ることをあらかじめ抑制しようとしています。
SaaSやGIFについては、以下の記事を合わせてお読みください。
公正取引委員会が行った「官公庁における情報システム調達に関する実態調査」でも、ベンダー間の適正な競争環境が整備されているとはいい難い状況にあることがわかります。今後は、自治体システムのクラウド化を進め、システムのブラックボックス化を防止するためにも、よりオープンなシステム環境が整備されることが望まれます。
