地方公共団体基幹業務システムはアプリケーション分離の夢を見るか？
本記事は総務省・デジタル庁が進める地方公共団体の基幹業務システムの統一・標準化（総務省では「自治体情報システムの標準化・共通化」と記載している）におけるシステムの実装方式の１つである共同利用方式：アプリケーション分離について記載します。
なお「地方公共団体の基幹業務システムの統一・標準化」「ガバメントクラウド」「共同利用方式」そのものの説明は割愛します。Google is your friend.
アプリケーション分離とは
デジタル庁は共同利用の実現方法として3つの分離モデル（アカウント分離/ネットワーク分離/アプリケーション分離）を示しています。AWSを例にすると以下のようになります。
アカウント分離：自治体ごとにAWSアカウントを別のものにし、それぞれに業務システムを構築する方式。監視、運用管理用のサーバーは共用アカウント上に構築する。
ネットワーク分離：1つのアカウント内の別VPCに自治体ごとの業務システムを構築する方式。ストレージ、監視、運用管理用のサーバーは共用のVPC内に構築する。
アプリケーション分離：1つのAWSアカウントに複数の自治体が共用で利用する業務システムを構築する方式。いわゆるマルチテナントのシステム。
「アカウント分離」「ネットワーク分離」は共同と言いながらも大部分が個別サーバーを構築するモデルとなっておりコスト効率が悪いと示されています。
コンピュートリソースや運用のコスト（工数）を考えるとアプリケーション分離にすべきでしょう。
ただし現状（2023年12月時点）ではアプリケーション分離を採用する見込みのベンダーがほぼ存在しません。この記事ではアプリケーション分離を阻む要素が何なのかをあげていきたいと思います。
アプリケーション分離を阻むものとは？
以下、4点があると思われます。
総務省のセキュリティポリシーガイドラインにおけるデータの消去要件
運用作業におけるリスクや影響範囲
自治体それぞれの非機能要件、カスタマイズ要望への対応
ベンダーにとって大きな投資判断となる
それでは1つずつ見ていきます。
1. 総務省のセキュリティポリシーガイドラインにおけるデータの消去要件
総務省が示しているセキュリティポリシーガイドラインに以下の記載があります。
『クラウドサービス上で機密性の高い情報（住民情報等）を保存する場合は、機密性を維持するために暗号化するとともに、その情報資産を破棄する際は、データ消去の方法の一つとして暗号化した鍵（暗号鍵）を削除するなどにより、その情報資産を復元困難な状態としなければならない。』
データ保護のためにデータの完全消去・完全廃棄の担保のため「重要なデータが復元できない状態で削除しなさい、普通のファイル削除ではなく暗号化キーを削除することなどで実現しなさい」ということが記載されています。
「クラウドにあるサーバー上のデータを完全に消去するにはどうすればいいのか？」は難しい問題です。マルチAZ/マルチリージョンにまたがり、エッジロケーションに配置されたデータのすべてを完全に消去することをサービス利用者が担保することは困難に思えます。
暗号化キーを削除する方法にしても、AWSをはじめ多くのクラウドサービスでは実現が難しく、アプリケーション分離を阻む最大の要因となっています。
アプリケーション分離の理想は1つのDBの中に複数の自治体のデータが保存されている状態です。共同でDBを利用しリソース効率を高くします。
ただし多くのDB製品における暗号化キーは通常1インスタンス（呼び方はDBサービスによって様々ですがここでは1つの独立したDB領域という意図で書いています）に1つです。
つまり1自治体、もしくは1つの機密情報の完全削除のために暗号化キーを廃棄してしまうとDBにあるすべてのデータが復号化できなくなってしまいます。
解決方法としては自治体単位でDBインスタンスを別にする方法がありますが、これではリソース効率は悪く、クラウド料金の大部分を占めるDBのコストは下がりません。
コスト効率が良いと言われる本当のアプリケーション分離を目指すなら総務省のセキュリティポリシーガイドラインの改定が必要となるでしょう。
2. 運用作業におけるリスクや影響範囲
次は仮にアプリケーション分離ができたとして実運用時のリスクを見ていきます。
私自身は地方公共団体基幹業務システムの運用作業を経験したことはないのであくまで聞き及んだ範囲での話となります。
（民間でのSaaS運用の経験はあるので理解はできます）
実運用ではデータの修正作業が頻繁に発生します。
「ｘｘ申請データが差し替えになった」「制度が変わってｘｘデータの一括変更が必要となった」のようにアプリケーションの機能ではカバーできないデータの書き換えが必要となります。
一般的には保守運用ベンダーのSEが対応します。
DBに接続し、SQLやDBツールを使って必要なデータを書き換えます。
この作業にリスクがあります。もちろん検証環境などで事前に間違いがないように努めるものの人間に絶対はありません。
手順書が間違っていた
検証環境と本番環境に違いがあり意図しない結果となった
検証環境だと思ったら本番環境だった
運用保守をやったことがあるSEであれば上記のミスは容易に想像できるでしょう。もちろん各ベンダーは仕組みやプロセスで極力ミスが起きないようにしています。
ではアプリケーション分離になった場合はどのようになるでしょうか。
端的に言って「影響範囲が大きくなる」となります。
既存の1DB=1自治体の構成であればミスがあっても影響があるのは1自治体だけですがアプリケーション分離になると複数の自治体に影響が及ぶ可能性があります。
ベンダーにとっては社員であるSEのミスですので言い訳ができません。
現状は1自治体に謝罪を行いますが、アプリケーション分離だと複数の自治体に謝罪することになります。信用問題にもなりますし各メディアにも出るでしょう。
多くのベンダーはこのリスクを避けたいと考えており、コスト効率の悪さ（インフラ費用の高さ）は自治体が負担するものになるので、多少高くても安全さを優先したい、という判断となります。リスクの判断としては合理的に思えます。
この問題はベンダー・自治体の両者でリスクや対応策、そこに掛かるコストを理解・許容した上でサービスを利用することが重要になります。
自治体職員のリソース不足（工数不足、スキル不足）の中では難しいところですが、ベンダー・自治体職員でしっかりとコミュニケーションをして解決すべき問題かと思います。
3. 自治体それぞれの非機能要件、カスタマイズ要望への対応
次に自治体独自の要件への対応についてです。
アプリケーション分離になると各種サーバーは共有のものとなります。もちろん業務ロジックやデータ項目などもなるべく共通の仕様となります。
そうなると個別要望への対応が難しくなります。現状は個別にサーバーが構築されているため個別カスタマイズを実現しやすい状況です。自治体は「我々のサーバー、我々のアプリケーション」と捉えているため要望を実現することは当たり前という認識です。
ベンダーは保守の複雑性が増すので個別カスタマイズはしたくないと思いつつ、カスタマイズ費や保守費が貰えるなら...、と対応しているケースが多いのが現状でしょう。
アプリケーション分離となると原則カスタマイズはできません。またバックアップやBCP/BCM対策も個別の要望を実現することは難しくなるでしょう。
自治体にとっては今まで当然のようにやっていた個別対応ができなくなり、ベンダーはそのことを各自治体に説得することが必要となってきます。
長い目でみるとコストが抑えらえる方式とはいえ、両者にとって痛みを伴うことになるので心理的な障壁がありそうです。
中長期的なメリットを自治体側の上位層がしっかり理解し原課に発信し続けることが重要となりそうです。
4. ベンダーにとって大きな投資判断となる
最後です。これはベンダーによって状況は異なると思いますが、そもそも大規模システムの設計変更、もしくは作り直しは大変なものとなります。
変更のための工数は多大なものになるためベンダーにとっては大きな投資となります。
基幹業務システムの市場規模は大きくなる見込みはなく、むしろ人口減少により縮退することが見込まれています。そんな中で大きな投資判断をすることは困難に思えます。
自治体基幹システム市場規模が減少しつつも、アプリケーション分離にすることで利益率の向上は可能かもしれません。また削減できた工数・人員を他の分野（窓口ＤＸなどよりフロント側）に再配置することで別事業で数字をあげられるかもしれません。
ベンダー各社にはビジネスモデルの変換を志向し、適切なビジネスとなるよう再考することが求められるのだと思います。
まとめ
アプリケーション分離を実現するための様々な障壁を見てきました。
困難さはあるものの、中長期的に効率よくシステムを運用していくにはアプリケーション分離方式は欠かせないものになるはずです。
今すぐは難しいかもしれないですが、皆の知恵と時間を使って実現に近づけていきましょう。
この記事が気に入ったらサポートをしてみませんか？