本記事では2023年10月6日時点で私が感じているガバメントクラウドのコスト構造の課題について記載します。
今後、制度やスキームが改善され課題が解消することを願いつつ現時点はこのような課題があったことの記録として。 この記事が課題解決の一助になれば幸いです。
※本記事は個人的な見解であり、所属する団体・組織の見解ではありません。念のため。
この記事で扱う課題は「ガバメントクラウドのコスト」
本記事では「ガバメントクラウド 共同利用時のコスト」にフォーカスします。
標準仕様書のFit&Gap問題（実運用との乖離）、クラウドの運用管理補助者の担い手問題（自治体の情報システム部門の過負荷問題）、移行困難団体とそれに関連する補助金の額および期限、などなど多くの課題があると思いますが本記事ではガバメントクラウド共同利用におけるコスト問題を扱います。
ガバメントクラウドの契約スキーム
まずは前提条件としてガバメントクラウドの契約スキームをおさらいします。
この契約スキームのポイントは
- CSP（AWSやAzureなどを運営するクラウド事業者）→ デジタル庁 → 地方公共団体 という契約スキームになっている
- システム開発ベンダーはデジタル庁およびCSPとは直接契約ができない
- クラウド費用の支払いは地方公共団体→デジ庁→CSPとなっている
- つまりクラウド費用はシステム開発ベンダーのビジネススキームの外にある
という点にあります。
ガバメントクラウド「単独利用」「共同利用」
こちらもおさらいです。
デジタル庁は大きく「単独利用」と「共同利用」の2つの利用方法を提示しています。単独利用は民間企業と同じように1つの自治体がCSPのアカウントを専用につかう方法です。大きな規模の自治体は単独利用のほうがよいとされています。共同利用は複数の自治体で共同で管理する方法です。AWSでいうと１つのアカウントの中に複数の自治体のシステムを構築するようなイメージです。同一のシステム開発ベンダーのパッケージを利用している場合はベンダーにとって管理が容易になることからほとんどのベンダーは「共同利用」で進めたいと考えています。
共同利用における3つの方式
多くのシステム開発ベンダーが共同利用を推してるのですがその中に3つの方式があります。アカウント分離、ネットワーク分離、アプリケーション分離の3つです。AWSを例に概念を記載します。
- アカウント分離：自治体ごとにAWSアカウントを別のものにし、それぞれに業務システムを構築する方式。監視、運用管理用のサーバーは共用アカウント上に構築する。
- ネットワーク分離：1つのアカウント内の別VPCに自治体ごとの業務システムを構築する方式。ストレージ、監視、運用管理用のサーバーは共用のVPC内に構築する。
- アプリケーション分離：1つのAWSアカウントに複数の自治体が共用で利用する業務システムを構築する方式。いわゆるマルチテナントのシステム。
多くのシステム開発ベンダーは「アカウント分離」「ネットワーク分離」を採用する想定となると言われています。つまり「共同利用」と言いつつ実態は自治体ごとにサーバーとDBが構築されてしまう状態で2025年度末を迎えることになります。デジタル庁の言葉を借りれば「リソース効率の低い」方式です。もちろんコストは高くなります。
課題は「ランニングコスト」「コストガバナンス」の2つ
- ランニングコストの増加
- コストガバナンスの難しさ
上記２つの課題があると考えています。詳細を以下に記載していきます。
ランニングコストの増加
1つめはランニングコストの懸念です。
上述したようにほとんどのシステム開発ベンダーは「アカウント分離」または「ネットワーク分離」方式でシステムを構築します。
単純化すると以下の構造となります
- ガバメントクラウドに移行する2025年度末時点では、現状の構成（オンプレやデータセンターで自治体ごとに個別にサーバーとDB構築されている構成）とほぼ変わらない構成となることが想定される
- 2025年度末の期限もあり大きなアーキテクチャ変更を実施しないシステムが多い（モダン化、マネージドサービス利用は最小限）
- 当然オンプレに比べるとサーバーの単価は高い
- ネットワーク接続（専用線）の費用など純増する費用もある
- よってランニングコストは増えることが想定される
もちろん2026年度以降にモダン化などでコスト効率化は可能だと思います。ただ私個人の経験からモダン化によるコスト削減でそこまで大きな効果が期待できるのか...という懸念があります（あくまで個人の推測です）
この課題に対してはモダン化での最適化とは別に「アプリケーション分離」への変換を模索すべきだと考えています。
2026年度からがランニングコスト削減のスタート
クラウドは従量課金モデルですので実運用が始まってからが本番です。コンピュートリソースなどの利用状況とコストのモニタリングを行い実測値からコスト削減施策を継続的に行っていく必要があります。
コスト削減施策はもちろんシステム改修が伴います。その費用は誰が出すのかというのも論点の1つにすべきでしょう。
コストガバナンスの難しさ
2つめはコストガバナンスの問題です。
いくつかの論点がありますので整理します。
共同利用ならではの費用の透明性の低さ
クラウド費用は自治体がデジタル庁を通してCSPに支払うことになりますが、共同利用方式となると費用の透明性が危うくなります。そもそもストレージや監視用の共用サーバーなどは厳密に費用を複数の自治体の利用実績で分割することは困難です。
平常運用時には「費用は人口比率で案分」のような取り決めがあれば問題ないと思いますが、例えば以下のようなトラブル時には単純な費用の案分とはならないでしょう。
- どこかの自治体の利用が適切ではなく特定の処理でコンピュートリソースやストレージを使ってしまい費用が上がった
- 問い合わせ（または障害）調査のために、調査用のサーバーとDBを作って調査・検証したため費用が上がった
契約スキーム
上述の契約スキームに記載した通り「クラウド費用はシステム開発ベンダーのビジネススキームの外」です。つまりインフラコストの削減はシステム開発ベンダーにとってインセンティブは小さいものになります。
※もちろんインフラ費用が安いほうが選ばれやすくなるので関係ないわけではありませんがベンダーを入れ替えるほどのインパクトにはならないのでは、という想定です
コストの正当性（適切さ）を見るのは誰か
コストの正当を見るのは誰？という問いの答えはもちろん自治体になります。ここでも課題があります。
- クラウドインフラのコスト構造を理解する必要がある
- ベンダーごとのシステム構成はオープンにしてもらえるのか？という懸念
ガバメントクラウドの契約スキームの都合上、「見せたくないシステム開発ベンダー」「見る必要があるが見ることが難しい自治体職員」という構図になってしまいます。
コスト削減を主導するのは誰か
コスト削減が可能な箇所がある場合、システム改修を行う必要があります。
- そのシステム改修費用は誰が出すのか
- 共同利用の場合の意思決定の難しさ
このように「誰が主導してどのように意思決定するのか」が複雑で調整や意思決定に多大な労力がかることが懸念されます。
まとめ
ガバメントクラウド共同利用時のランニングコストの問題とコストガバナンスの問題について記載しました。
移行期限やその他の制約によるコスト効率の低いシステム構成となってしまう、現状の契約スキームではコストガバナンスを担う立場の不在という問題についてまとめました。
すぐにすべての問題が解消されることは困難かもしれませんが契約スキームの見直しは重要なことなのかなと感じています。
議論の広がり、深まりを願って
名古屋の高橋さんのnote、中島さんのPostに触発され、今の自分の考えを文章にしてみました。本記事で扱った課題はとても困難で大きなものです。もっとたくさんの人で議論を広げ、深めていきたいと思います。
現実を見ていくために、私目線で見えている課題と解決を模索している自治体さんの検討選択肢をまとめて行っている。 pic.twitter.com/f1TSEy1XSo
— 中島淳之介/ Junnosuke Nakajima @ VMware (@jnakajima1982) 2023年10月3日
また、2024年1月開催の「デッカイギ」でも議論の続きができると嬉しく思います。
最後に
この記事が同じような課題感を持ち、火中の栗をなんとかすべく奮闘している全国の仲間の課題解決の一助になれば幸いです。
