19
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ガバメントクラウドAdvent Calendar 2024

Day 7

【前編】ガバメントクラウドの論点に対する対策を考えてみた

Last updated at Posted at 2024-12-06

本記事はガバメントクラウド Advent Calendar 2024の7日目の記事です。また、前編と後編の2つに分けています。

はじめに

NTTデータの西川です。
普段は公共部門の技術集約組織でクラウドの導入支援に従事しています。

先日、国立国会図書館からガバメントクラウドに関するレポートが公開されていたので読んでいました。

ガバメントクラウドの概要と主な課題、論点(刊行日:2024/10/20)
https://dl.ndl.go.jp/view/prepareDownload?itemId=info:ndljp/pid/13763465

今回は上記のレポートで触れられていた論点に関して可能な限り前向きに捉えて、少しでもいい方向に進めていくには何を考える必要があるのか、何をする必要があるのかを考えてみました。そもそも今対策を考える必要あるのか?というものについては、該当する論点について私の考えていることをまとめます。

もちろん短期視点での解決は難しい論点ばかりなので、本ブログの内容で即座に解決するようなものではないです。しかし、中長期的にいい方向に進むために必要なことを考えるきっかけとなれば幸いです。

公開情報の多くが地方公共団体向けの情報である都合上であるため、引用情報は地方公共団体向けのガバメントクラウドに関連する内容です。しかし、地方公共団体以外の一般的なガバメントクラウドを利用する際にも参考となる内容となっております。

本ブログで扱う論点

まずはじめに本ブログで扱う論点のインプットとするレポートの目次を示します。
image.png
図1 引用元:「ガバメントクラウドの概要と主な課題、論点」P31より抜粋

今回は「Ⅱ ガバメントクラウドをめぐる主な課題、論点」の内容を対象とし、扱う論点は以下の4つとします。

  1. ガバメントクラウドの利用による運用経費の削減効果
  2. ベンダーロックインや特定のクラウドサービスの寡占のおそれ
  3. 安全保障等の機微情報を取り扱う情報システムへの対応
  4. 米国 CLOUD 法への対応
    ※前編で1と2、後編で3と4を扱います。

以下の項目は本ブログで扱いません。ガバメントクラウドに興味がある方は一読してみてはいかがでしょうか。

  • Ⅰ 我が国におけるガバメントクラウドの概要
  • Ⅲ 諸外国における国の行政機関等のクラウド利用に係る取組

出典:ガバメントクラウドの概要と主な課題、論点
https://dl.ndl.go.jp/view/prepareDownload?itemId=info:ndljp/pid/13763465

本ブログのフォーマット

上記4つの論点について以下のフォーマットで整理していきます。

  • 論点n(a):論点
  • 論点n(b):対策立案
  • 論点n(c):参考資料

n = 論点番号

各論点に対する対策を考えてみた

今回示す対策はあくまでアイデア例の1つです。短期視点で銀の弾丸となりうるような類のものでもありません。

1. ガバメントクラウドの利用による運用経費の削減効果

背景

デジタル庁が主導となり政府情報システム、地方公共団体の情報システムの運用等経費及びシステム改修に係る経費の削減を目指しています。

論点1(a):論点

ガバメントクラウドへの移行による運用経費の削減効果が見られない事例が過半数を占めています。
デジタル庁は地方公共団体の基幹業務システムのガバメントクラウド移行に係る投資対効果を把握するため、一部の団体を対象に先行事業を実施しています。現行利用中のシステムを同規模で入替え・継続利用した場合の運用経費を試算し比較した結果を下記に示します。詳細はレポートをご覧ください。

image.png
図2 引用元:「ガバメントクラウドの概要と主な課題、論点」P42より抜粋

論点1(b):対策立案

前提

昨今、クラウド利用料の管理は一般的な課題として認識されています。これはガバメントクラウドに限った論点ではありません。クラウドに移行すればコストが安くなるような単純な話ではありません。初期フェーズでは国側で一定の費用面の補助を行う必要があると思います。
Flexera社のレポートによると、クラウドを利活用している組織が直面する最大の課題として2年連続でクラウド利用料の管理が1位となっています。2年連続2位であるセキュリティは、利用料が1位となるまで10年以上にわたり、組織課題の1位であったとのことです。もちろんセキュリティが今日現在も重要である点であることは変わりません。

image.png
図3 引用元:Cloud computing trends: Flexera 2024 State of the Cloud Report

対策案

FinOpsという概念が近年注目を集めており、個人的には論点1の対策として有効であると考えています。
画像1.png
図4 引用元:Gartner、「日本におけるクラウド・プラットフォームのハイプ・サイクル:2024年」を発表

FinOpsとは

クラウド利用時における運用のフレームワーク、組織文化を醸成するためのプラクティスです。目的はクラウドのビジネス価値を最大化、データに基づくタイムリーな意思決定を可能にし、エンジニアリング、財務、ビジネスチーム間のコラボレーションを通じて財務上の説明責任を果たすことです。一過性の営みではありません。
※ FinOps Foundationの定義を私の解釈を含めて日本語訳したものです。

参考:What is FinOps?

FinOps Foundationとは
ベストプラクティス、教育、標準を通じて、FinOpsの分野を推進することに専念するLinux Foundationのプログラムで、Cloud Native Computing Foundationなどの組織と連携しています。FinOps Foundationは2019年設立。2024年11月にFinOps FoundationのJapan Chapterが設立されました。
参考:FinOps FoundationのJapan Chapter設立のお知らせ

FinOps Framework

FinOpsを始めるための役立つツールとしてFinOps Frameworkがあります。FinOps FrameworkはFinOpsの実践を確立し、それを成功させるための運用モデルを提供するフレームワークです。FinOpsを実現するためのプラクティスや設計原則を整理したものです。
image.png
図5 引用元:Japanese Framework Translation

注意点

各組織におけるフェーズや成熟度によってアプローチは多岐に渡ります。唯一無二の絶対解があるわけではなく、必要なタイミングで必要なプラクティスを導入することが重要となります。ガバメントクラウド利用組織において、これからコスト最適化を検討される組織や検討中の組織が増加することが予想されます。その際は是非FinOpsのナレッジの利活用をご検討ください。

余談

先日FinOps FoundationのJapan Chapterが設立されたので、今後ナレッジが公開情報として多く広がることが期待されます。先日開催されたCloudNative Days Winter 2024においても、いくつか事例が紹介されています。

image.png

図6 引用元:Woven by ToyotaのFinOpsの取り組み@CloudNative Days Winter 2024

論点1(c):参考資料

2. ベンダーロックインや特定のクラウドサービスの寡占のおそれ

背景

ガバメントクラウドは複数のクラウドサービス事業者のクラウドサービスによって構成され、国の行政機関や地方公共団体はその中からクラウドサービスを選択することが可能となっています。2024/12時点ではガバメントクラウドとして以下の5つのクラウドサービスが採用されています。

  • Amazon Web Services(AWS)
  • Google Cloud
  • Microsoft Azure
  • Oracle Cloud Infrastructure(OCI)
  • さくらのクラウド(条件付き採用)

論点2(a):論点

「特定のクラウドベンダーへのロックインの状態(クラウドロックイン)になるおそれがあるのではないか。」という意見が存在しています。参考情報として「ガバメントクラウド」「一般的なクラウド市場」におけるシェアに関する情報を以下に示します。

  1. ガバメントクラウドにおけるシェア(2024/10):AWSが90%以上を占めている。
    ガバメントクラウドに採択されたクラウドサービス.jpg
    図7 引用元:運用コスト増にAWS寡占、ガバメントクラウド推進法案の陰で「こんなはずでは…」

  2. 一般的なクラウド市場のシェア(2024 2Q):AWS32%、Microsoft Azure23%、Google Cloud12%
    Cloud Provider Market Share Trend.jpg
    図8 引用元:Cloud Market Growth Stays Strong in Q2 While Amazon, Google and Oracle Nudge Higher

論点2(b):対策立案

中長期的には対策は必要であるが、直近で多くの方が対策をするフェーズではないと感じているので対策は割愛します。

公共部門の多くの組織にとって論点2を検討するには時期尚早では?

そもそも論として、現段階で本論点を議論するようなフェーズなのでしょうか?
多くの公共部門の組織はこれからガバメントクラウドをはじめとするクラウドを利用し始めるフェーズです。クラウド人材の育成、組織体制の整備や文化の醸成などの施策を始める/改善を進めるフェーズである認識です。
image.png
図9 引用元:【2024年度版】クラウドまわりの政府動向をまとめてみた

もちろん中長期的に対策を検討する組織やWGなどは必要かと思いますが、現段階で他の論点と並んでいることに違和感を覚えました。

参考: Multi-Cloud Innovation and Advancement Act of 2023
米国連邦機関がクラウド技術を採用する際の近代化と効率化することを目的とした法律であり、マルチクラウド技術を推進するものです。2024年4月に上院で承認されました。日本は米国に対してクラウド利用の状況が約10年程差があるため、日本では2030年頃でしょうか。詳細は割愛します。
S.2871 - Multi-Cloud Innovation and Advancement Act of 2023

ガバメントクラウドにおけるシェアの偏りについて

前提として私は業務でAWS、Azure、Google Cloudに携わっている人間です。

ガバメントクラウドにおいてAWSのシェアが著しく高いことを指摘する意見が存在しています。私の意見は以下の理由で、現状AWSのシェアが一定高くなっているのは納得感があります。

  • 公共分野における先行事例の数が圧倒的に多いこと。
  • AWSエンジニアの数が圧倒的に多いこと。
  • ユーザコミュニティや技術ブログなどをはじめとするナレッジが圧倒的に多いこと。

私は日本の現状として、公共部門のクラウド利用のシェアの奪い合いではなく、公共部門のクラウド利用の拡大を進めているフェーズであると理解しています。一般的なクラウド市場を見てもYoY(Year-on-Year)の成長率は2024年Q3時点でも約20%となっていること、昨今の日本におけるクラウドまわりの動向(図9)などが根拠です。

image.png
図10 引用元:Cloud Market Growth Surge Continues in Q3 – Growth Rate Increases for the Fourth Consecutive Quarter

また、日本をはじめとする多くの先進国において労働人口の減少は紛れもない事実としてあります。人口動態が変わる中、公共部門のシステムを維持・改善するには必要な偏りではないでしょうか。初期フェーズでマルチクラウドとして複数のクラウドサービスを並行して利用することは、難しい面が多数生じる可能性があることは容易に想像がつきます。これらは様々な主義・主張がある観点だと認識しているため、唯一無二の答えだとは思っておりません。

と記しつつ、中長期的な視点で考える必要な論点ではあるため、以下に検討事項や参考となる考え方を記します。

検討事項:クラウドのサービスモデルの選定(サービスモデル=IaaS, PaaS, SaaS)

ロックインを意識してクラウドサービスのモデルを選定する際には「A:移行性や運用の自由度」と「B:先端性やアジリティ」のトレードオフを検討するとよいです。0か1かといったような議論ではなく、グラデーションがあるものであることを認識することが重要となります。必ずしもPaaSなどのマネージドサービスを用いてクラウドネイティブな構成とするのが正義であるわけでもないし、IaaSだからロックイン要素がゼロとなるわけではないです。

  • IaaS:ミドルウェア以上は利用者側でコントロール可能であるため、比較的ロックイン要素は少ない。(ゼロなわけではない。)
  • PaaS:AとBのバランスが取れているパターンが多い。各CSPごと、各サービスごとに特徴が大きく出る領域である。
  • SaaS:導入や運用コストが低いが、ロックイン要素は多い。

考え方:Switching Cost

Switching Costはベンダーやツールやサービスなどを乗り換えようとする際に乗り換えにかかるコストを指します。Switching Costの内訳としては、時間、柔軟性、機能性や費用などが対象となりえます。

image.png
図11 引用元:開発におけるロックインのリスク評価と考え方

今回は考え方の紹介のみで詳細は割愛しますが、ロックインの議論をする場合に現実的な可能性や確率を検討できているか?ということを振り返るきっかけとなれば幸いです。

image.png
図12 引用元:開発におけるロックインのリスク評価と考え方

Switching Costの詳細については下記をご覧ください。
引用元:Don't get locked up into avoiding lock-in

余談

既にガバメントクラウドとしてクラウドベンダを変更している事例が紹介されているものも存在しています。この辺のSwitching Costも事例として公開されたら拝見してみたいです。
image.png
図13 引用元:ガバメントクラウドにおけるデータ・生成AI活用の未来と宇和島市における先行事業とその後の姿 ~CSPの変更~

論点2(c):参考資料

前編は以上となります。後編につづきます。

19
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
19
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?