ランニングコスト削減に向けた現状と問題提起
本記事では、総務省・デジタル庁が進める地方公共団体の基幹業務システムの統一・標準化（以下：標準化）及びガバメントクラウド（以下：ガバクラ）における、ランニングコストについて記載します。
2018年（平成30年）比で3割減の運用経費削減を目指すとされていますが、実現できる雲行きが怪しくなるどころか、増加するのではないかと懸念されています。
この点は、標準化・ガバクラ対応プロジェクトに関わるイチ関係者として思っていることを徒然と記していきます。「こうすればうまくいく！」というものではありませんし、批判をしているわけでもありません。その点は申し伝えておきます。
標準化やガバクラそのものについての詳細は割愛します。Google is your friend.
※本記事は、2023年12月28日時点の情報をもとに執筆しています。
はじめに
早速ですがランニングコスト問題に対する私の主張は以下の通りです。
ランニングコスト増の要因は
・（とりあえず）ガバクラ使おう！という流れ
・制度設計（スキーム）の問題点
が多くを占めていると感じます。
前者については、クラウドは正しく使う必要があるし、クラウドに向いているシステム、向いていないシステムもあることを理解しないといけません。流行っているから、カッコいいから、なにがなんでもクラウド使おうぜ〜だと失敗するということです。このことは、以下の本が大変参考になりました。
クラウドの性質と移行対象システムや業務の特性・性質を理解した上で、初めてクラウドジャーニーへ出発するかどうかを決めるということです。
後者については、現在の標準化・ガバクラ化の制度設計的に、ランニングコスト減がしづらかったり、ランニングコスト削減へのモチベーションが湧きづらかったりしている点です。
例えば標準化にあたっては、対象20業務のシステムを標準仕様に準拠させなければなりません。しかも2025年度までに切り替える必要があるため、実質的に開発期間は2023年度〜2024年度が目安となりますし、その間には税・介護・後期・子育てなど、法改正がてんこ盛りです。
2025年度までに2023年3月末時点の標準仕様書に適合させる必要がありますが、法改正等必要性がある改訂についてはそれも含めて対応することになっており、実質的に仕様凍結できない状態で開発をする必要があります。急ピッチで開発して、制度改正にも対応するには莫大なコストが発生します。そのコストはシステム利用料・保守料などに跳ね返ってきます。
ガバクラを使う自治体・ベンダの現状
ガバクラを利用するにあたり、自治体もベンダも、クラウド実務がない場合が大多数です。運用管理補助者の要件として各CSPのProfessional相当の認定資格者が要求されておりますが、実際は有資格者1人いればどうにかなるものではなく、技術者の採用・教育コストが発生します。
また運用ベンダ視点では、20業務はガバクラ、それ以外は既存環境を運用保守していくことになるため、運用作業量という観点で考えるとそれは増える可能性が高いです。これらのコストはシステム運用費用として跳ね返ってきます。
ではガバクラの利用料はどうでしょうか。ガバクラ利用料（CSPに対して毎月支払うクラウドの利用料）は、増加する可能性が高いと考えています（実際そのような声が現場から上がっており、デジタル庁もランニングコスト削減へ向けた取り組みを行うと説明しています。）。主な要因としては、モダン化できていないことやアプリケーション分離的（≒SaaS的）な活用ができていないことが挙げられますが、重要なのは、なぜそれができないのかを理解することだと思います。
これらの要因は自治体側でコントロールすることは難しく、開発ベンダに依存することになります。問題として次の2点があります。
１つ目は前述の通り開発ベンダは2025年度までに標準仕様へ準拠させるために多くのリソースを投下しており、モダン化対応するリソースがすでに枯渇している点です。
２つ目は、クラウド利用料は自治体が直接CSPに支払うスキームであるため、ベンダがガバクラ利用料を削減（モダン化させるなど）したところで、削減した分のお金は1円もベンダに入りません。つまりクラウド利用料削減に向けたモチベーションを生むインセンティブ設計が乏しいのです（支払いスキーム詳細については後述します）。
ここからは今までの流れをおさらいしてみましょう。
標準化・ガバクラ対応で目指す「３割減」とは
まずは標準化によってどのようなコストメリットを得られると言われているのか整理してみます。「地方公共団体情報システム標準化基本方針（令和5年9月）」には、次のように謳われています。
また、標準化対象事務に関する情報システムの運用経費等については、標準準拠システムへの移行完了後に、平成30年度（2018年度）比で少なくとも３割の削減を目指すこと
運用経費（ランニングコスト）を平成30年度比で3割削減することを目指すとされています。注意点は、「標準準拠システムへの移行完了で」削減を目指している点です（ガバクラへの移行完了ではない）。標準化＋ガバクラによって3割削減を目指すため、注意が必要です。
ちなみに意外と周知されていませんが、この3割減は「マクロで」達成するものとされており、個々の自治体で3割減というわけではないということです。（2023年2月14日 第4回東京都・区市町村CIOフォーラムにてデジタル庁担当者からの発言）
しかしこれを読んでいる皆様は、3割減は理想論であって現実的ではないと感じている方も多いのではないでしょうか。見積もりを作成したり確認したりと具体的な数字が身近になってきていることと思います。一方でランニングコストは現在よりも抑制できそうという自治体の声も聞きます。ランニングコストと一言で言ってもいくつかの要素がありますよね。そこで次は、ランニングコストの内訳について整理してみます。
＜ランニングコストの内訳を整理してみる＞
主なランニングコストの内訳は以下の通りです。
①ガバクラ利用料
②ガバクラ接続回線費用
③運用管理補助者費用
④アプリケーション（ソフトウェア・PKG等）利用料・保守費用
なおデジタル庁「ガバメントクラウド先行事業の中間報告 投資対効果検証の結果」などにはコストの内訳がもう少し細かく分類されていますが、ざっくり分けるとこのような感じになるかと思います。気になる方は上記資料もご参照ください。こちらの資料では、先行事業実績でいくつもの団体が、ガバクラ移行によりランニングコストの増加が確認されています。
①ガバメントクラウド利用料
AWS等のCSPに対して支払う利用料です。従来のインフラ利用料やデータセンター利用料などが相当します。ガバクラの契約スキームについてもおさらいします。デジタル庁が各CSPと一括契約し、各自治体に対してガバクラ個別領域を払い出します。ガバクラの契約主体はデジタル庁となり、支払いスキームは以下となります。
CSP↔︎デジタル庁↔︎自治体
※CSPはデジタル庁に対して請求、デジタル庁は各自治体に対して費用を計算して請求、自治体はデジタル庁に対して支払う。
ただし、共同利用方式における共同利用リソースに対する費用の按分方法等、実務上不完全なスキームであり、課題が残っている状態です。この共同利用リソースについてはCSP側では内訳を把握できないため、何らかの方法で按分する必要があるとされていますが、按分方法については現時点で国から提示はありません。仮にアプリケーション分離方式を採用してDBインスタンスを共同利用したとしても、そのコストをどうやって按分するのか（単純に等分？人口規模で按分？保存されているデータ量で按分？など）は示されていないのです。
なお、ガバクラはデジタル庁が一括契約するためrootアカウントをもつのはデジタル庁であり、各CSPが用意する無料枠は実質的に自治体は使えないという話も聞いています。（AWSの無料枠、OCIの通信料10TB/月無料など）
※ガバクラ利用料の支払いスキームについては記事執筆時点で確定していない（国からの公表がない）ため、「地方公共団体情報システムのガバメントクラウド利用に関する基準【1.0版】」に掲載されている契約モデルを参考にしています。今後変更される可能性があることをご了承ください。
②ガバクラ接続回線費用
自治体からガバクラへ接続するために新規に敷設する専用回線の利用料です。ネットワーク事業者に対して支払います。
ガバクラ接続回線については、当初国が「ガバクラ接続サービス」として一括調達・サービス展開するとしていましたが、現時点では各自治体が個別に調達するか、第5次LGWANを活用することになっています。第5次LGWANは、その稼働時期が明確に示されておらず2025年度の稼働までに利用開始になるのか不明瞭となっており、自治体は判断を迫られている状況です。個別調達となる場合は、ネットワーク事業者等から調達します。
利用形式については、自治体から直接ガバクラへ繋ぐ方式や、共同利用NaaSとして複数自治体で回線を共同利用する方式などが示されています（詳細は「ガバクラ推奨構成（自治体のみ公開）」を参照ください）。いずれの回線・形式を使うにせよ、今までになかったガバクラまでの回線を調達することになります。
③運用管理補助者費用
ガバクラ上で運用保守する作業費です。運用管理補助者（大体の場合はASPベンダが兼務）に対して支払います。
運用管理補助者はガバクラを利用する上で必要な役回りです。「ガバメントクラウド手続き概要（自治体のみ公開）」には、調達仕様に各CSPのProfessional相当の認定資格者が要求されています。
自治体行政システムの性質上新規参入が難しい領域であり、また短い移行期限内で低リスクな移行を実現するために、基本的には既存ASPベンダに標準化対応も依頼する場合がほとんどだと思いますが、既存ベンダにとっても不慣れなパブリッククラウド上で運用管理補助を行う必要があり、クラウド人材の育成・調達にコストがかかります。またマルチベンダ・マルチCSPとなる場合などにおいても、運用管理補助者の裁量にてそのすべてをコントロールする必要があり、従来のスキームでは存在しなかった部分のコストとなっています。
④アプリケーション（ソフトウェア・PKG等）利用料・保守費用
アプリケーション等の利用料・保守費用です。ASPベンダに対して支払います。従来のアプリケーション利用料・保守費用に相当しますが、前述の通り2025年度までに標準仕様書に準拠させる必要がある点、ガバクラ上で動作させるアーキテクト設計を行う必要がある点などより、開発費・人件費が高騰し、その分が価格に転嫁されている場合が多い印象です。
なぜランニングコストは高騰するのか
これら①〜④のランニングコストのうち、コスト削減の主体は誰か整理します。
①ガバクラ利用料
前提として、オンプレミスをそのままクラウドリフトした場合、一般的なCSP利用料の内訳は、コンピュート（仮想マシン）やDBサービスが6〜8割を占めると言われています。クラウドはIaaSとして使うのではなくPaaSやSaaSとして使うことでコストメリットを享受できるようになっていますので、クラウド移行する際は、どのようなアーキテクチャ（システム構成）にするかが非常に重要です。この点を踏まえガバクラがどのように使われているかですが、現状ほとんどの標準準拠システムはIaaSを載せているような構成と聞きます。国がモダン化を提唱する理由はここにありますし、私もガバクラ利用料を低減するにはモダン化は必須であると感じています。
一方でアーキテクチャについては、システム開発ベンダに依存する部分が多いのが事実です。開発元が示す動作保証＝推奨構成を大きく崩すことはリスクとなるため、運用ベンダ（実際に構築・運用するASPベンダ）の裁量でシステム構成を変更できる部分は限定的です。よって、開発元ベンダの設計がダイレクトにガバクラ利用料に反映されます。運用管理補助者は多くの場合開発ベンダではなく運用ベンダが行うことが多く、少なくとも共同利用方式において自治体側にガバクラ利用料を削減できるイニシアティブはほとんどありません。クラウドに適した構成でリフトしないとクラウド利用料は最適化されませんし、現在よりも高くなるということも普通にあり得るのです。
②ガバクラ接続回線費用
ガバクラにアクセスするために接続回線自体は必要になりますので新規敷設することになります。よって「どこと契約するか」「どう使うか」が重要です。LGWAN or 個別調達、単独契約 or ネットワーク共同利用 といった利用手段の検討も必要ですし、帯域はどの程度必要かといった自治体側の非機能要求も鑑みる必要があります。さらに非機能要件や総務省セキュリティポリシーガイドラインを満たすためにはインターネットを経由しない閉域網接続を用いることになり、それもコストが上がる要因です。
よって自治体の判断に依存しますが、いずれの選択をしても、コスト削減度合いは限定的と思われます。
民間企業の提供するネットワーク接続サービスに対して個別に値下げ交渉を行うことは現実的ではありませんし、私的には回線こそ国が一括調達すべきだったと感じるところです。LGWANがあるじゃないかと聞こえてきそうですが、こちらはどちらかというとガバクラ接続サービスの提供ができなくなった代替手段として湧いて出てきた印象であり、そもそもLGWANは2025年度稼働のために利用開始が間に合わない可能性が高いと言われています。（そもそも当初はガバクラ接続サービス自体無料で使えるという話ではなかっt？）
また依然として20業務以外は既存環境に残り続けるために、既存回線とガバクラ接続回線の二重投資になる面も問題と捉えています。さらにマルチクラウド（複数のCSPを利用）時におけるクラウド間通信費用についても問題があります。2023年6月に開催されたAPPLIC講演会の中で、デジタル庁淺岡参事官から「マルチクラウドとなった場合のクラウド間通信費は国が持つ」というアナウンスが有りましたが、現時点でその続報・詳細は提示されていません。また、他CSPへ折り返す通信と自治体に向かう通信をどのように区別するのかといった技術的な課題点も残っている状況です（各CSPは基本的には直接繋がっておらず、利用者側で回線を用意する必要があります）。
③運用管理補助者費用
運用管理補助者（多くの場合は既存ASPベンダが兼任することが多い）の裁量となります。運用管理補助者の責務は多岐にわたり、クラウド人材の育成等も必要になります。またガバクラの登場によって、今まで運用ベンダが得ていたインフラ利用料などはすべてガバクラ事業者（ほぼアメリカ）へ流れることとなります。お気持ち的には、運用管理補助者費用については下げる余地はあまりないのではと考えます。
④アプリケーション（ソフトウェア・PKG等）利用料・保守費用
ASPベンダ（運用ベンダ）の裁量となります。しかしシステム仕入先である開発ベンダの販売価格が開発費等の影響で高騰している場合もあり、従来の提供価格よりも値上がりしているケースもあると聞きます。よって、アプリケーション利用料・保守費用についても、下げる余地はあまりないのではと考えます。
このように、ランニングコストのうちコスト低減に向けてアプローチしやすい場所はそもそもあまりない可能性があります。しかしガバクラ利用料については、モダン化やアプリケーション分離的（≒SaaS的）な活用ができるようになれば改善すると言われています。（ガバメントクラウド先行事業の中間報告 投資対効果検証の結果など）
それは本当なのか、なぜそこまでわかっていて実現がされていないのか、考察してみます。
モダン化やアプリケーション分離的（≒SaaS的）活用は救世主か
アプリ分離の課題については、こちらで課題を整理していますので、ご参照いただければと思います。
一般的には、モダン化やアプリケーション分離的（SaaS的）な活用によってクラウド利用料は安くなると言われています。モダン化により、クラウドの俊敏性や柔軟性を活かし、動的に需要に対応していけるからです。AWSクラウドプラクティショナー（CLF）の勉強をしているとまず勉強するアレです。このようなポテンシャルをクラウドは持っています。
ではどんなシステムでもクラウドに持っていくことでそのようなメリットを享受できるのでしょうか。実のところ全てのシステム（業務）においてこの特性が活かせるかというと、必ずしもそうではありません。クラウドとシステムには相性があり、相性が良いシステムとそうでないシステムがあります。
モダンアーキテクチャによって、従量課金と需要に対して動的にスケールする俊敏性を手に入れることができますが、逆に言えば、例えば業務的な需要が均一もしくは需要そのものが低い場合などは、無理してクラウドを使わないほうが良いこともあります。また処理負荷やシステム利用する職員数も人口規模により様々であるため、その点も考慮しなければなりません。このような点から、そもそもすべての自治体基幹系システムをクラウドに乗せることは、コスト的な側面から適していない可能性があります。
標準準拠システムのモダン化が進まない理由は、ここまで述べてきたことが大部分だと思います。
・シンプルにリソース不足
・コスト削減（モダン化）のモチベーションが生まれにくいスキーム
・業務的にクラウドに適していないためモダン化させたところでコストメリットを得にくい
など。
また別の観点として、SaaSとして利用する場合に一般的なシステムと自治体基幹系システムの特異点について、いくつか見てみます。
フロント系か基幹系か
一般的なSaaSはフロント系システムであることが多い印象です。ユーザ数の増減やスパイクが動的であり、クラウドと相性がいいこともあるでしょうし、アジャイル開発に向いているというのもあると思います。対して標準化するのは基幹系（特に重要な20業務）であり、業務性質上いきなりクラウド移行するにはリスクが内在します。
扱う情報の機密レベル
個人情報や特定個人情報を扱う点が大きな特異点です。データベース共用化等実現に向けた法規制的ハードルも高く、リスクも大きいようです。データ主権などの課題も絡み、クラウド利用を前提とした法整備から始めていく必要がありそうです。
ユーザの接続経路
ユーザがシステムへアクセスする接続経路は、一般的なSaaSであればインターネット接続が主流ですが自治体基幹系システムは専用線による閉域網接続をする必要があります。閉域接続なので利用ユーザ間でIP重複がしないように調整する必要があります。
またネットワーク集約アカウントや場合によっては団体分の仮想クラウドネットワーク（AWSでいうVPC）が必要になりますが、CSPで定められているサービスクォータに抵触する可能性があり、多くの自治体を1つの環境へ誘導することが現実的に難しい側面もあります。（仮想ルータやVPCなどが上限に抵触する可能性あり）
ガバクラ利用料を削減する手段としてモダン化が掲げられていますが、このような理由によってモダン化が進まない現状が見えてきました。
標準化でガバクラ化は必須？必ずガバクラを使う必要があるのか？
ここまで見る限り、ガバクラを無理やり使うからランニングコストが高くなってしまっているのが現状と言わざるを得ません。そもそもガバクラにこだわる理由もあるのでしょうか。
ガバクラは、ガバクラ上に用意されたシステムを自治体が任意にチョイスして（スマホのアプリのように）共同利用できるようなプラットフォームではないですから、本質的なコストメリットが出にくい構造的問題があります。一方で大規模自治体など、ガバクラによってランニングコストが軽減できるという事例も見受けられます。大切なのは、ガバクラにこだわるのではなく、選択肢の一つとして活用していけるような枠組みが重要なのではないでしょうか。
自治体規模によってはスケールする必要もなく業務が回ることも有り得ますし、総務省自治体クラウドポータルサイト「クラウド導入状況（令和3年4月現在）」PDFによれば、2021年4月時点で実に1404もの自治体が、何らかのクラウド（自治体クラウドなど）を活用しており、すでにインフラコストが最適化されている可能性もあります。
建付け上ガバクラ利用は努力義務ですが、イニシャルに対する補助金要件としては「ガバクラへ接続でき、基本データリストをガバクラ上へ保存できること」がマストとなっており、実質的にはガバクラ利用を強く推奨されている状況です。少し脱線しますが、データ連携基盤としてガバクラを必須化する理由も不透明である以上、本当に必要なのか疑問を感じているところです。
コスト削減できそうな場所
このような背景からランニングコスト、とりわけガバクラ利用料が高くなっていますが、対処療法的なコスト削減を目指すなら、削れそうな場所はどこになるでしょうか。いくつか例を挙げてみます。
DR要件の実現手段の再検討
DRサイト（大阪リージョン）をどう使うかは自治体主導で交渉できる可能性があります。過剰な構成でないか、自治体業務を行う上で許容できる業務や停止時間はどれくらいか等、非機能要件の標準をどこまで要求するのか、一度ベンダと相談してみるのはありかもしれません。
IaaSシステムの稼働時間調整（24/365を止めるか）、検証環境の使い方
前述の通り、IaaSベースのシステムである場合は基本的にはサーバは24/365で稼働することが前提にあります。夜間や休日の稼働状況は確認してみてもよいでしょう。また検証環境の構成や稼働時間についても、調整する余地はあるように思えます
RIなどの活用
AWSでいうリザーブド・インスタンス（RI：期間コミットで通常利用より安価に利用する方法）の活用も有効でしょう。ただし国からはRI利用は時限措置と言われており、2026年度以降の利用可否等については不透明な状態です。しかしながら前述の通り、ガバクラ利用料のほとんどは開発元のシステム設計に依存しますので、その根本に関わるような調整は運用ベンダは積極的には行いたくない（できない）のも事実です。
まとめ ～本質的なランニングコスト削減に向けて～
本質的なランニングコスト削減に向けては、抜本的な制度設計の見直しや法・ガイドライン整備が必要なのではと考えます。また現場の解像度で議論をし、その過程を公表することも重要です。
R1（Replatform）を単純リフトではガバクラ利用料は下がりませんし、モダン化が進む枠組み設計も重要ですし、そもそもなぜガバクラを使うのか、その必要性を机上の空論ではなく実際の温度感で議論されることが必要なのではと思います。
全国の標準化・ガバクラ化に従事されているすべての関係者の皆様にとって明るい未来が訪れ、我が国の地方行政が抱える諸問題解決の一歩となることを祈っております。
ともに頑張りましょう(¯―¯٥)
この記事が気に入ったらサポートをしてみませんか？