ガバメントクラウドのFinOpsについて真剣に考えてみる（後編その①）
前編はFinOpsの概要、中編はデジタル庁のFinOpsガイドについて見ていきました。
後編はガバメントクラウドで本当にFinOpsが可能なのか。実際どうすれば良いのかということを書いていきたいと思います。
そして長いので結局後編を２回に分けることになりました。まだまだ続きます(;´Д｀)
６ ガバメントクラウドでFinOpsを阻むもの
そもそもクラウドFinOpsはモダン化と同じで、クラウド利用を突き詰めていけば自然と段階が進みものと認識しています。
モダン化を阻む壁は時間でした。2025年度までの移行というピン留めがされた状態ではモダンアーキテクチャへの変更のための時間が確保出来なかったわけです。
一方で、FinOpsを阻むものは主にガバメントクラウドの共同利用方式のスキームにあるという認識です。
具体的に１つずつ見ていきましょう。
６－１ FinとOpsの分離
共同利用方式においては、ガバメントクラウドを提供するデジタル庁と利用する地方公共団体との契約となり、主体は地方公共団体であるものの、共同利用を取りまとめる事業者、即ち運用管理補助者の介在が必須となります。
地方公共団体はクラウド利用料はデジタル庁に支払う一方で、クラウド運用は専ら運用管理補助者が実施し、その作業委託費を運用管理補助者に支払います。職員はクラウドの管理コンソールにアクセスできません。
何が言いたいかというと、共同利用方式においては財務（Fin）と運用（Ops）が分離されているのです。これは財務と運用を一体的に行うFinOpsにおいて致命的です。通常のクラウド利用のFinOps活動に比べ、はるかに各種コストがかかるのです。
まず運用を担当する運用管理補助者はクラウド利用料を負担しません。自分の懐が痛みませんので、構成においては安定稼働を優先し、マージンを多くとる傾向があります。即ちクラウドコストを下げる営みは、運用管理補助者にとってはメリットが全くないのです。
一方で財務を担う地方公共団体は運用を実施できません。運用を他者に任せていますので、クラウドコストを下げるために運用管理補助者に説明して作業を依頼する必要があります。当然無料でやってくれるとは限りません。そして前述のとおり運用管理補助者にとっては安定稼働のマージンを削る作業に他なりませんので、ネゴシエーションが必要になります。
そもそも共同利用方式においては、運用の画一化によりコストを下げるという建付けでした。例えば人口規模別で構成をパターン化してIaCで管理するというような手法が考えられます。
ここで特定の自治体だけFinOps活動により構成を変えると、その前提が崩れてしまいます。そうした面からも共同利用方式とFinOpsは相性最悪です。
６－２ 可視化の壁
FinOpsは手始めに可視化から開始しますが、ここにも難があります。
可視化のためにはコスト状況を参照できるダッシュボードが必須です。通常、これらはわざわざ別に用意しなくてもクラウドサービス側で用意されています。
AWSであればCostExplorer、OCIにはCost Analysisやコスト管理ウィジェットがあります。
しかし前述のとおり、地方公共団体職員は管理コンソールにアクセスできませんので、利用できるのは別に用意した「任意のコスト最適化ダッシュボード」か「地方公共団体向けGCASコストダッシュボード」のいずれかです。（中編参照）
「任意のコスト最適化ダッシュボード」は運用管理補助者が自作するか、サードパーティ製品を導入せねばなりません。後者の代表は名古屋市や茅ヶ崎市が導入したSrestですが、他にもZabbixやDataDogなど幾らでもあります。いずれにせよ、運用管理補助者が対応してくれなければ利用することはできません。
となると、最後の頼みの綱はGCASダッシュボードですが、こちらは分析機能がまだまだ不足している印象です。
粒度は月次のみであり、日次の推移は確認できません。
ドリルダウンはサービスごとのみで使用タイプまでの掘り下げは出来ません。しかもサービスごとの内訳が確認できるのは単独利用方式と共同利用方式のアカウント分離のみで、ネットワーク分離やアプリケーション分離は請求額しか分かりません。
最もネットワーク分離とアプリケーション分離はそれ以前の問題があるのですが、そちらは後で詳しく説明します。
つまり、可視化と言ってもほとんどの地方公共団体は請求額の月別推移しか分からないか、「どのサービスから着手するか」ぐらいの切り分けしかできないというわけです。
といっても、その程度がどれぐらい良いのか悪いのか分からないと思いますので、FinOpsを推進している名古屋市のやり方と比較しましょう。
ご存じのとおり名古屋市は全面単独利用方式ですので、管理コンソールからCostExplorerが利用でき、GCASダッシュボードよりはるかに詳細な分析が可能です。
なお、その前段階でSrestで全体傾向を把握するプロセスがありますが、ここでは割愛します。
例えばGCASダッシュボードではEC2というサービス単位の総金額しか分かりません。オンラインサーバ、バッチサーバ、運用管理サーバ、EUCサーバ等、様々なEC2インスタンスがあると思いますが、それらの総合計しか分からないのです。
一方、名古屋市においてはその中の各インスタンス単位のコストが確認できます。更に言えば、そのサーバがどのリージョンのどのAZにあるか、どのVPCに所属しているかも分かります。
インスタンスの中の更に詳細な金額も分かります。例えばEC2インスタンス本体のオンデマンド課金の他、EBSの料金、インスタンスにかかるデータ転送の料金、インスタンスのバックアップを取得する料金などが把握できます。
またコスト分析の粒度も月次のみならず日次で表示可能ですので、コスト変動をイベント的に調査することが可能です。
例えばGCASダッシュボードではEC2の料金が先月と比べて1000ドル値上がりしたということしか分かりませんが、名古屋市であればSEの誰々が検証作業のために仮想サーバを1台追加したため13日から値上がりしているというところまで分かります。具体的なやり方は割愛しますが、興味があれば以下のLT資料をご確認ください。
普通にAWSを利用する場合に比べ、可視化にかなりハンディキャップがあることがご理解いただけたでしょうか？
６－３ スキルと委託契約の壁
可視化の次に来るのは最適化ですが、ここでも壁があります。
思い起こしていただきたいのですが、前編で「適切に実施するためにはそれなりのクラウド知識が必要になります。」と書きました。言い換えればほとんどの自治体では適切に実施できないということです。これは中編でも言及した通りです。
無理に進めようとすると、一から十まで運用管理補助者に説明を求めることになり、莫大なコミュニケーションコストがかかります。
希望があるとすれば、ここをデジタル庁の見積もり精査支援で対応することですが、実際にそのような体制を取ってもらえるかは不明です。
あるいは、共創PFキャンプのようなワークショップでカバーするような手法もあるかもですが、最適化のキモは前編で説明した通り、ただコストを減らせば良いというものでは無く、可用性などの非機能要件は必要な水準を確保する必要があるということです。
現在デジタル庁のガバクラチームが実施しているコスト最適化ワークショップは非常に実践的でとても良い内容だと思います。
ただし、そのワークショップでは多くの判断材料が与えられていますし、実際の運用管理補助者との折衝については扱いません。
多くの最適化の試みはマージンを削ることであり、前述のとおり運用管理補助者側の立場からすれば何のメリットもありません。
運用管理補助者から「やっても良いですけど、その結果生じた不具合については一切責任を負いません」と言われ、それでも押し切れる自治体はどれぐらいいるでしょうか？
妥協案として考えられるのは、最適化にかかる構成変更の検証を実施し、問題が無ければ構成変更を行うというものです。当然有償になるでしょう。
それに限らず、共同利用方式においては最適化関連で職員が出来ることは極めて少なく、最初から最後まで運用管理補助者の手を借りねばなりません。この過程で多くの費用が生ずることが考えられます。
要するに、十分なリソースがあるか、あるいは事業者と強固な信頼関係を築くことが出来ているところしか、最適化アクションは実施できないのではないかと思います。
６－４ 按分ルールの壁
可視化の壁のところで「ネットワーク分離とアプリケーション分離はそれ以前の問題」と書きましたが、その話をしようと思います。
クラウド利用料の課金はアカウント単位です。
アカウント分離であれば、そのアカウント全体の課金額がアカウント所有団体のコストとなりますのでとてもシンプルなのですが、ネットワーク分離とアプリケーション分離は同一アカウントを複数団体でシェアしますので、団体ごとの課金額を把握できるようにせねばなりません。
ネットワーク分離はVPC単位となりますので、各VPCのリソースにもれなくタグをつけねばなりません。アプリケーション分離はリクエスト回数等、課金タイプの実績に応じた額を把握できるようにせねばなりません。
しかし、実際の請求額は必ずしも実績に応じた額とはなっていません。
請求額をどのように按分するかは運用管理補助者が任意に決定します。ですので、例えば人口比率や独自係数など、実績に関係なく固定比率にされる可能性があります。場合によっては団体数均等割のケースもあります。
この時点でもうFinOpsはやる意味がありません。
例えば自団体の按分率が実績に関係なく５％固定とされた場合、コスト最適化の活動で100万円削減したとしても、自団体には5万円しか還元されないのです。やるだけ無駄です。
そして、運用管理補助者が実績に応じた按分率を採用してくれたとしても、果たしてそれが正しいのかと言う疑問があります。
実例として、EC2インスタンスやS3などは実績値ですが、VPCのTGWアタッチメントやエンドポイントにはタグがついておらず、実際の実績費用より過大に請求されていたというケースがありました。
これはデジタル庁がネットワーク分離やアプリケーション分離における按分ルールのガイドラインを定めなかったことに起因します。構成最適化の前に、適正な按分ルールを求める方が先決でしょう。これはデジタル庁のFinOpsガイドには記載されていない事項です。
そもそもの話ですが、個人的に言えばネットワーク分離やアプリケーション分離は「なし」です。
システム標準化においてはアカウント分離よりネットワーク分離やアプリケーション分離が推奨されていますが、これはFinOps観点からすれば大間違いです。
「必要なリソースを必要な分だけ」のクラウド運用の原則を曲げ、分離把握可能な複数団体のコストをわざわざ混ぜてから再按分するというもので、FinOpsの可視化やコストの透明性を大きく毀損するものです。
アプリケーション分離においてモダンアーキテクチャを採用し、かつ事業者がFinOpsを突き詰めてユニットエコノミクスを追求し、SaaS的運用をするのであれば問題ありませんが、それはガバメントクラウド共同利用方式ではなく、公共SaaSとして実施すべき内容です。IaaSでやる内容ではありません。
そしてネットワーク分離は何一つメリットがありません。そもそもネットワーク構成や各種クォーターの問題から、１アカウント全部で全団体を運用するのは不可能です。運用的に楽になったりコスト的に有利になる要素もありません。ただただ混ぜているだけです。
ですので、ガバメントクラウドでのFinOpsはマイナスからのスタートです。
本来個別に把握可能なコストが混ぜてぐちゃぐちゃにされていて、それを分離するところから始まり、可視化手段も制限され、最適化実施の際の職員スキルもおぼつかない。
正直お先真っ暗です。
６－５ 合意無き共同利用
ついでですので、共同利用方式の悪い点を更に書いていきます。
従来の共同利用については、利用団体が運用や費用負担などの各種条件を詳細に取り決め合意をするというプロセスがありました。これらは各団体の担当者レベルで決めることができるようなものではなく、背後には各団体の議会があり、非常にタフな調整となりますので、しばしば都道府県が間に入って調整することもありました。
しかし、ガバクラ共同利用にはこのプロセスが一切ありません。共同利用の各団体は、たまたま同じ事業者に発注していたというだけで、運用や費用負担に関する取り決めや合意は一切ありません。それどころか、他にどの団体が利用しているかということすら分かりません。
従来の共同利用で時間をかけて諸々調整していた運用や費用負担などの事項は、運用管理補助者に全権が委ねられています。全利用団体が運用管理補助者に白紙委任状を提出しているようなものです。
考えてみれば凄い仕組みですね(￣▽￣;)
このように共同利用方式においては運用管理補助者が絶対的な権力を有しています。標準化の建付けで言えば「このゆびとまれ」方式で嫌なら事業者を変えれば良いという事ですが、現状地方公共団体に選択肢が無いのは周知の事実です。
そして前述のとおり、国が定めた按分ルールもないため、本来関係全団体がタフな調整を経て決定すべき費用負担は運用管理補助者が勝手に決めています。当の運用管理補助者もこんなことやりたくないと思っているかもしれません。
そしてこの方式には大きな穴があります。
多くの場合、地方公共団体は真面目なFinOps活動でクラウド利用料そのものを下げるより、政治的な工作活動で運用管理補助者の按分率を変えさせる方が容易なのです。
例えばですが、ある利用団体が運用管理補助者に支払う委託料を100万円値上げする代わりに按分率を下げてクラウド利用料を平均200万円下げるような交渉を持ちかけたらどうでしょうか？
運用管理補助者はノーリスクで100万円増益になります。交渉を持ちかけた利用団体も100万円コスト削減になります。差額の200万円は他の利用団体が按分して知らない間に負担することになります。
これは共同利用の関係者に合意のプロセスが無く、お互いが単なる顧客同士であって認知できず、運用管理補助者が絶対的な権力を持ち、デジタル庁がルールを定めず無法地帯だからこそ成立する状況です。
非常に邪悪な試みですが、別にこれは禁止されているわけでもルール違反でもありません。というよりルールがありません。やったもの勝ちです。
昨今のふるさと納税絡みのあれこれを見れば、こうした活動も当然に今後水面下で行われると考えるのが妥当です。
６－６ 蛇足
（※ 2025/11/10 6:30 一部改稿）
ここから先は松屋でJK達が話していた内容なので話半分で。
システム標準化におけるガバメントクラウド共同利用方式は「コストを混ぜて再按分すれば３割減」という不可解な理論からスタートしています。そしてこの共同利用方式の仕組みの構築にはガバクラチームが関与していないらしいのです。
言われてみれば、システム標準化基本方針や初期のガバメントクラウド利用基準には「とにかく共同利用が良いんだ」という記載しか無く、肝心の政府基本方針に見られるモダン化を始めとしたクラウドスマート関連の記載は一切ありません。
そしていざガバメントクラウドを利用しようとする段になり、突然モダン化しろという話が出てきました。明らかに不自然ですよね。
スキーム構築の初期段階でガバクラチームが検討の中に入っていれば、また違った形になったかも知れませんが、それはもう望むべくもありません。
これから考えるべきことは、今からどうやって軌道修正していくか。
それを今から書こうと思うのでですが、FinOpsの課題部分が膨らんで余りに長くなってしまったので、ここでひとまず切ります。
続きは、次回の後編その②で書きたいと思います。今度こそ完結です(￣▽￣;)
