見出し画像

ガバメントクラウドのFinOpsについて真剣に考えてみる(中編)

 タイトルバナーはハロウィンには間に合わせたかったという希望の残滓です(´・ω・`)

 前編記事からの続きです。後編はガバメントクラウドで本当にFinOpsが可能なのかということを中心に書いていくとお知らせしましたところなのですが、折よく前編記事公開後にデジタル庁からFinOpsガイドが公開されました。
 FinOpsガイドはデジタル庁から今秋に出すと通知されていたもので、ガバメントクラウドにおけるFinOpsについて国がどのように考えているかを推察するための重要な文書であり、今回のテーマから外すことは出来ません。

 しかしながら、この内容を含めると長くなってしまうので、少し短めですが、いったん中編としてFinOpsガイドについて記載し、その後総括して後編につなげていきたいと思います。


4 継続的運用経費削減(FinOps)ガイド

 表記が「継続的運用経費削減(FinOps)」となっているところから既に不穏さを感じます。前編で述べた通り、FinOpsの本来の目的はビジネス価値の最大化であり、地方公共団体であれば住民サービスの向上にあたり、コスト削減のみが目的ではないからです。
 まあここは分かりやすさを重視したと理解して、何はともあれ中身を見ていきましょう。
 FinOpsガイドは以下の構成になっています。

はじめに
FinOpsの概要
ガバメントクラウドにおけるFinOpsのポイント
STEP1 コスト構造を把握する
STEP2 コスト削減計画を検討する
STEP3 コスト削減計画を実行する
STEP4 調達仕様書・契約に反映する

4-1 はじめに

 ポイントは2点あると思います。

 まず「改善に向けた更新を随時図っていく予定」ということで、今後も随時更新されていくこと。これは他のドキュメントと同じです。

 もう一つはモダン化ガイド5部作の1つであるということ、曰く「コスト最適化アプローチガイド」「継続的運用経費削減ガイド」「運用モダン化ガイド(仮称)」「インフラモダン化ガイド(仮称)」「アプリケーションモダン化ガイド(仮称)」だそうです。
 運用やインフラ/アプリのモダン化も本来はFinOpsの取り組みの一部に含まれると思うのですが、まあ全部放り込むと冗長になるので分けていると理解しましょう。

4-2 FinOpsの概要

 「FinOpsの概要と目的」の冒頭にFinOpsの定義があり、この説明は的確です。
 しかしその直後に運用保守作業費に言及があり、またまた不穏な方向に逸れていってしまっていると感じます。
 FinOpsの段階が進みと、クラウド利用料のみならず周辺の関連コストも含めての取り組みになりますので、方向性として決して間違っているわけでは無いのですが、必要なプロセスをすっ飛ばしてしまっている気がします。

 「想定する読者」は国と地方公共団体で事業者は含まれません。また会計・契約・財務の各部門が含まれないのも気になります。
 CCoEの編成が前提であればこれでも良いかもですが、それもFinOpsの段階が進んだ後の話です。

 「想定するシステム構成」は「R2(Rebuild)未満の段階にある利用システムを対象」とありモダン化したらFinOps終了のような誤った印象を与えかねない記載になっています。実際はモダン化達成の成否に関わらず、継続的に実施する必要があります。

4-3 ガバメントクラウドにおけるFinOpsのポイント

 「クラウド利用料は本番稼働がコスト削減のスタート地点」とあります。
 恐らく環境(アカウント)利用開始のことを本番稼働と言っているのかと思われますが、アプリケーションのカットオーバー後と受け取られかねない記述です。

 「コスト把握・削減計画の主体は利用職員」とあり、共同利用方式の場合は運用管理補助者との協業が必要とあります。これには異論ありません。

 「FinOpsの成果を調達仕様書・契約に反映する」は良く分かりません。運用保守作業費も含むとしているので、そのことでしょうか。

 「クラウド利用料」と「運用保守作業費」をスコープとするのは前述のとおりです。

 関係事業者の部分において、ネットワークアカウントの担い手である回線運用管理補助者が対象外になっているのは気になります。ASP領域と異なり、ネットワークアカウントは単独利用方式であるケースが多いため、本来はより効果的にFinOpsを実施できるはずです。

 「FinOpsの実施ステップ」がまた独特です。
 「コスト構造を把握」はCFMで言うところの可視化、「コスト削減計画を検討・実行」は最適化とすぐ想像がつきますが、最後が「調達仕様書・契約に反映」で計画・予測とかけ離れている印象です。
 まあ広い意味では計画・予測に含まれるのかもしれませんが、本来はそれ以外の重要な要素が多くあります。

 「FinOpsのサイクル」は非常に不可解です。「クラウド利用料」「運用保守作業費」いずれもSTEP4の仕様書契約への反映に至るまでに運用管理補助者に様々な作業を発注していますが、この作業は何に基づいて実施されるものなのでしょうか。
 普通に考えれば、仕様書を修正して契約変更を実施してから作業を行うべきものになります。そう考えるとステップの順番が不適切な気がします。

 「共同利用方式における検討のポイント」については、該当のSTEPのところで後述します。

4-4 STEP1 コスト構造を把握する

 まず「クラウド利用料の可視化」から見ていきます。

 「クラウド利用料の構造」「クラウド利用料の構造(モダン化後)」の記載内容については概ね異議はありません。ただ例示されているコスト構造や金額については事業者や自治体規模、利用方式によって異なりますので留意が必要です。

 「コスト可視化のためのツール」では「管理コンソール(CostExplorer)」「任意のコスト最適化ダッシュボード」「地方公共団体向けGCASコストダッシュボード」が示されています。
 CostExplorerは共同利用方式では利用不可能、任意のコスト最適化ダッシュボードは運用管理補助者が構築してくれるか、名古屋市や茅ヶ崎市のSrestのように専用サービスを利用せねばなりません。多くの自治体に取ってはGCASダッシュボードのみとなってしまうでしょう。

 以下GCASダッシュボードの利用方法の説明が延々と続きます。ネットワーク分離およびアプリケーション分離については「サービス別コスト」の利用が出来ないため、事業者から情報をもらわねばなりません。とはいえ、アカウント別の金額推移が利用できるだけでもメリットはあります。

 「共同利用方式におけるコスト把握のポイント」については正直これだけでは不十分です。各コストがどのような算出式となるか、とりわけ「カスタムスコア」が採用されている場合はそのスコアを求める計算過程が必須と思われます。

 「運用保守作業費の可視化」については、作業項目の可視化はメリットはあるものの、「提示した明細からコード化や自動化が可能である作業やその費用対効果を職員と協議、検討する。」はそもそも困難です。なぜならば、事業者はそれをやれるならば既にやっているからです。
 これが成立するためには職員が運用設計を実施したエンジニア以上のスキルと知見を有していなければなりません。職員がDOP-C02のプロフェッショナル資格を取得するか、さもなければAWSプロフェッショナルサービスといった、第三者の支援が必要でしょう。

4-5 STEP2 コスト削減計画を検討する

 ここは正直非常に厳しいです。

 冒頭から各CSPのレコメンデーションサービスの解説が続きますが、ほとんどの自治体職員は共同利用方式のためマネジメントコンソールにアクセスできません。

 そして、その出力結果だけ提供を受けても何が何だか分からず、次にどのようなアクションを起こせばよいか分からないでしょう。
 ほとんどの自治体職員はマネジメントコンソールにアクセスしたことがなく、クラウドプラティクショナー水準の知識もありません。そして共同利用方式の場合、構成図や設計書の提供はされないのが普通です。
 特定のリソースがレコメンデーション結果に上がっていたとしても、何も出来ないでしょう。まずそのリソースがAWSのどのようなサービスで、一般的な設計においてどのような役割を果たすか理解する必要があります。この時点で少なくともSAA相当の知見とスキルが必要です。
 更に適切なアクションを起こすためには構成図や設計書、それもリソースIDと紐づくような詳細設計書/パラメータシートが手元にあり、最低限それらのレビューを事業者から受けている必要があります。

 ネットワーク分離やアプリケーション分離の場合は更に困難です。そもそもレコメンデーション結果に出てきたものが自団体に関係するリソースかどうかも分かりません。
 そもそもコスト按分とどう紐づくのか。適切にタグ付けがされているか。適切な按分が実施されているか。各リソースのレコメンデーションに入るのはそれらの後になります。

 「運用保守作業費の削減計画」もかなり厳しいです。
 単価とか工数とかを精査して、事業者と交渉する。分かります。名古屋市でも事業者と交渉する時はそういうアプローチを取ることがあります。
 しかし、現実にはプロジェクトの人的作業はクラウドのようなオンデマンド課金ではありませんし、作業員のスキル水準も均質ではありません。
 究極的には作業要員のうち誰を何人充てるかという話だと自分は理解しています。めちゃくちゃ交渉して作業要員1人分を減らすことが出来るかもしれませんが、プロジェクトから外れたその要員が必要な時に戻ってきて作業してくれるわけでもありません。

4-6 STEP3 コスト削減計画を実行する

 繰り返しの記述となりますが、契約変更を実施し、仕様にコスト削減作業内容を加えてから各種作業を行うべきものとなりますので、STEPの順番が適切でない気がします。

4-7 STEP4 調達仕様書・契約に反映する

 これも繰り返しの記述になりますが、継続的改善にかかる各種作業も無料では無いわけです。
 とりわけ発注者が特段クラウドスキルを有しない一般的な職員である場合、事業者は内容の説明のために莫大なリソースを割くことになるでしょう。
 事実、名古屋市において俎上に上がった改善事項について、削減効果を作業工数が上回ったため、実施しなかったこともあります。
 共同利用方式においては調査や説明のコストが膨大になることが予想されるため、効果が出るケースは稀になるかもしれません。

5 継続的運用経費削減(FinOps)ガイドの総評

 色々気になる点がありましたが、総評すると以下のようになると思います。
(1)FinOpsと言いながらコスト最適の内容に偏重している。
(2)どちらかというと国や単独利用方式の地方公共団体向けであり、可視化や職員スキルから共同利用方式の地方公共団体においては実施が困難な内容が多い。
(3)運用管理補助者が各種作業を実施するコストが考慮されておらず、その作業を実施するために必要となる事前の仕様や契約の変更に関するプロセスが無い。
(4)上記作業のコストとFinOpsの予測成果を比較評価するプロセスが無い。
(5)継続的に実施する必要性の説明が少ない。

 かなり酷評する結果になってしまいましたが、まだこれは初版ですし、アップデート前提ですので、今後の改善を期待したいところです。

 後編では、じゃあ実際どうすれば良いのかという、改善点を出来るだけ書いていきたいと思います。今しばらくお待ちください(`・ω・´)ゞ