デジタル庁が公共SaaSのガバクラ縛りを諦めないと、ASP事業者のFinOpsを困難にし、地方自治体は高めの料金を払い続けることになるよ

公共システムの標準化とガバメントクラウド移行の次に、デジタル庁は公共SaaSの推進を行いたいようだ。ガバメントクラウドを利用するという条件がついた役所の基幹業務のアプリケーションサービス化。

SaaSという発想は新しいものではなく、大手システム開発（運用）会社の自治体クラウドサービスが既にある。ガバメントクラウド認定を受けたパブリッククラウドを利用を強制するところが新しい。しかし、FinOps（フィノップス）と言う観点で言うとよろしくない。

グローバルなサービスを展開するパブリッククラウド事業者AWS、Azure、GCP、OCIをハイパースケーラーと呼ぶ昨今なのだが、お値段が高めなので、初期はパブリッククラウドで構築し、規模が大きくなって安定したら（プライベートクラウドを含むパブリッククラウドの対義語としての）オンプレミスに回帰してコスト削減するのが、欧米の最近のベストプラクティスとなっている^*1。そして、このパブリッククラウドからの帰還^*2もFinOpsのひとつとして捉えられている。

パブリッククラウドの利用を推進する理由に、地方自治体のシステム運用要因の確保が困難になるという将来予測があった。少子高齢化でそのような事は十分起きうる。しかし、公共SaaSは多数の自治体に同一のアプリケーションを提供するサービスになるため、スケールメリットが出るのでインフラエンジニアの確保が困難になるかは分からない。ミドルウェアの設定や保守に専門知識はいるわけではあるが、ではパブリッククラウドの多種多様なサービスを理解してFinOpsを頑張るのも専門知識がいる。

デジタル庁のガバメントクラウドチームが推すモダン化技術を利用するために、コンテナ化技術によってプライベートクラウドを構築し^*3、オブジェクトストレージやメッセージキューを導入する^*4ことになったとしても、脱パブリッククラウドのハードルがそう高くなるわけではない^*5。2010年頃からこれらを実現するためのオープンソース製品が充実してきており、コモディティ化している。パブリッククラウドでは利用料金削減のためにアプリケーションの設計や運用が歪になっていることもあるわけだが^*6、プライベートクラウドではそれほど考えなくてよい利点もある。

もちろんSaaSであればASPが主体的にFinOpsを行うわけで、技術要素を心配する必要はない。場合によってはガバメントクラウドが使われると言うこともあるはずだ。しかし、ASPが主体的にコスト削減を機能要件を考えた上での結論であるべき。費用になる一方で収入に結びつかない機密性などは疎かにされがちなので、そこは基準を示す必要があるとは思うが、ガバメントクラウド縛りは適切ではない。

*1The Cost of Cloud, a Trillion Dollar Paradox | Andreessen Horowitz

*2オンプレミス回帰の英語表現Cloud Repatriationを訳すとこうなる。

*3関連記事：コンテナ化技術（Docker, Kubernetes）の時代

*4関連記事：オートスケール不要な地方自治体のシステムでも、オブジェクトストレージとコンテナ化技術は有用だよ，デジタル庁クラウドチームの推すメッセージキュー（バッチ処理のイベントドリブン化）が有用になる場面

*5コンテナオーケストレーションツールのKubernetes、オブジェクトストレージのApache Ozone、メッセージキューのApache Pulsarは十分に発展している。AWS LambdaとAWS Step Functionsを無闇に使っているアプリケーションは、プライベートクラウド移行あ困難であろうが。

*6オンプレからのデータ転送は圧縮してAWSに送り、AWS Lambdaで展開してインポートと言うような工夫、土日祝日はサービス停止で料金節約と言うようなケチケチ運用を指す。