ガバメントクラウドのFinOpsについて真剣に考えてみる（後編その②）

　前編のFinOpsの概要、中編のデジタル庁のFinOpsガイドに続き、後編その①は一般的な共同利用方式においてガバメントクラウドでのFinOps実施は極めて難しいという説明をいたしました。中々にお先真っ暗の展開となってしまいましたが、最後にじゃあこれからどうしていけば良いのか。個人的見解を書いていきたいと思います。
　前後編の予定が４部構成になってしまいました、今度こそ完結です(;´Д｀)

７　デジタル庁におけるFinOpsの位置付け

　そもそもの話に立ち返って見ましょう。

　前編の冒頭で「自治体情報システムの標準化・ガバメントクラウド移行後の運用経費に係る総合的な対策について」に触れ、その中でFinOpsが登場したという話をいたしました。
　その中で説明されている対策内容を見てみると、「（1）見積精査等の当面の対策」と「（2）構造的な要因等に対する対策」の２つに大別されて説明されています。これらは暫定的対策と根本的対策と言い換えても良いと思います。

　注目すべきは、この中でFinOpsは前者、即ち暫定的対策に記載されているという事です。言い換えれば、デジタル庁はFinOpsでは根本的解決が出来ないと言っているようなものでしょう。

　ただし、FinOpsガイドは地方公共団体専用のものでは無く、冒頭に「本ガイドは国の行政機関のPMO、PJMO、地方公共団体の情報政策担当課長、情報システム担当職員、標準準拠システムの担当課の職員を主な読者と想定している。」とあります。
　また続けて「特に、ガバメントクラウド移行後にランニングコストが増加しており、削減方法を検討中の地方公共団体の職員においてはコスト削減のヒント集として参考とされたい。」と記載があります。

　要するに政府機関に向けては「これでFinOpsしっかりやれよ」と発信する一方で、地方公共団体に向けては「コスト削減ヒント集なので参考にせよ」と言っています。その程度の扱いです。デジタル庁も分かっているのです。
　ですので、デジタル庁は1741団体全部に向けてFinOpsをやれと言っているわけではなく、出来る団体が出来る範囲でやれば良いということだと思います。

８　公共SaaSは特効薬となるか？

　FinOpsじゃ根本的対策にはならない。じゃあどうすれば良いんだ？という疑問が当然出てくると思いますので、次はそちらについて見ていきましょう。
　「総合的な対策について」の「（2）構造的な要因等に対する対策」では６つの項目が挙げられていますが、その中で注目すべき項目が２つあります。

　まず「② 公共SaaSによる基盤・業務一体調達の実現に向けた環境整備」です。１段落目に以下の記述があります。

　公共SaaSの詳細についてはデジタル庁のGCASガイドを参照いただきたいところですが、ガバメントクラウド共同利用方式との大きな違いを挙げると以下の３点です。

（１）共同利用方式はIaaS/PaaSの共同利用である一方、公共SaaSは文字通りSaaSの提供
（２）共同利用方式は地方公共団体とデジタル庁が契約し、クラウド利用料を地方公共団体が支払う。公共SaaSはSaaS提供事業者とデジタル庁が契約し、クラウド利用料をSaaS事業者が支払う。
（３）共同利用方式は段階的なモダン化が認められるが、公共SaaSはモダン化が前提。ただし共同利用方式からの移行は経過措置あり。

　事業者がガバメントクラウド上にシステムを構築して複数の地方公共団体で利用するという点は共通していますが、契約周りの取り扱いが大きく違います。クラウド利用料はSaaS事業者が支払う一方、地方公共団体はSaaS事業者にSaaS利用料を支払います。要するに、FinOpsが事業者側に寄せられるのです。
　また共同利用方式からの移行については経過措置があり、モダン化等の公共SaaSの各種要件を満たさなくても当面は良く、現状のシステム構成のままで契約関係のみ整理を行い移行が可能です。

　これであれば事業者側が主体的にFinOpsを実施し、その恩恵を地方公共団体が享受できることになります。
　理想的な形に見えますが、この公共SaaSの最も大きな課題は、事業者側がクラウド利用料の変動リスクを負うことになり、移行するインセンティブが無い事です。あるいは、この変動リスクをSaaS利用料に上乗せして共同利用方式より高くなることです。

　この解決策として、料金体系の段階的な移行が考えられます。

　公共SaaSにおいては「ガバクラ利用料をSaaS利用者に按分して請求することは想定しない」、即ち「クラウド利用料そのまま転嫁はNG」という一方で、出来高に応じたSaaS利用料を否定しているわけではありません。
　最初は利用する仮想サーバ１台につき幾らといった実績にかなり近い料金設定を設定し、その後SaaS事業者がFinOpsを進めてユニットエコノミクスにまで到達すれば、一般的なSaaS料金形態に切り替えるということも出来るでしょう。是非はともかく、MicrosoftもOracleも料金体系はコロコロ変えています。
　また、たとえ料金が現行と変わらなかったとしても、地方公共団体にとってはペイジー対応や納入期限等の会計事務関連でメリットがあります。
　
　もう１点特筆すべき点として「SaaS提供に親和性のあるネットワークの実現等」という記載があります。
　仮に基幹業務システムの環境が全て公共SaaSになったとしても、いわゆるネットワークアカウントの管理が依然として残ります。この部分についても解決を図るべきです。
　地方公共団体にとっては、LGWAN-ASPのように公共SaaSを利用できるのが理想です。

９　実際にコスト削減に効果があるもの

　次に同じく「② 公共SaaSによる基盤・業務一体調達の実現に向けた環境整備」の２段落目を見てみましょう。

　あまり知られていませんが、実はBPRはクラウド利用料抑制に効果的なのです。

　実際にBPRに効果をあげているのはつくば市です。
　デジタル庁の好事例共有会、東北IT物産展、ODEX大阪会場などで情報システム課の横田主任が説明していますが、つくば市は専用線の共有やコスト要因となる画像保存や事前データ処理などをオフロードすることでコスト削減を図っています。
　そしてそれ以外にも徹底的なBPRを進めていることがポイントです。

　BPRとクラウド利用料の相関についてピンと来ないかもしれません。
　政令市や中核市以上で良く見られるパターンですが、現行事務を踏襲しようとすると、パッケージ本体のカスタマイズは禁じられているため、外付けのアドオン機能を付随して解決を図ろうという事になります。
　つまり、パッケージ本体のDBをレプリケーションして当該機能を構築することになります。ご存じの方も多いと思いますが、パブリッククラウドにおいてDBサービスの利用料は非常に高価です。

　実は某市においても、COBOLベースのフルスクラッチシステムからパッケージ移行を実施したシステムが２つあり、一方はノンカスタマイズでサーバ機器リース料と比較したクラウド利用料が大幅に下落しましたが、もう一方のシステムはなるべく現行事務を踏襲しようとしたため、クラウド利用料が大幅に増加しました。
　後者では外付けRDSが無数に存在するため、原因は明らかです。

　BPRを進めればクラウド利用料が下がりますし、公共SaaSへの移行も容易になります。

　懸念点として、せっかく市区町村がBPRを推進しても、都道府県が従来通りの事務を要求し、外付け対応を迫られるケースが散見されるようです。

　デジタル庁は各団体の見積もり精査等の個別対応を実施する前に、まずこうした動きを調査して排除すべきでしょう。

10　今後のGCASダッシュボードとFinOpsガイドに期待する姿

　「（2）構造的な要因等に対する対策」でもう１つ注目すべきは「⑤ システム運用経費の見える化・分析による競争促進」です。

　これはかなり攻めた取り組みです。しかしながら筆者はデジタル庁の幹部とFinOpsについて意見交換した際に「結局事業者交代で競争が働かないと根本的解決にはならないのではないか」という趣旨のコメントをいただきました。ですのでデジタル庁は割と本気で取り組みのではないかと思います。

　「事業者の協力を得て」とありますが、これに対しては恐らく大多数の事業者が反発するでしょう。
　しかし、個人的にこれは事業者のためでもあると思います。

　このnoteを読まれている読者の方であれば、共創PFのことはご存じだと思います。
　地方公共団体職員であれば誰でも利用できるクローズドコミュニティ。事業者が居ない場で、当然各事業者の諸々の事についても話題にあがります。

　例えば「○○社の××と△△社の□□で迷っていますが、実際に導入されている自治体の方、使用感を教えてください」と言った投稿はしばしばあります。当然コストの話も話題に出ます。
　それぐらいならまだ良いのですが、（個人名までは流石に出ないものの）営業やエンジニアの対応とかも当然チャンネルに書き込まれます。
　それを1500の自治体が一斉に目にするのです。

　それでなくとも、共創PF内で交流のある自治体職員間でダイレクトメールで「こっそり教えて」的な話は日常茶飯事です。
　以前と異なり、自治体に取って公共情報システムに関する口コミははるかに入手しやすくなっています。

　実際の利用者の口コミは判断材料として重要ではありますが、当然主観的なものです。そういった中には営業の態度が悪いエンジニアの対応が悪いといったものも含まれます。そうしたもので判断されるのは、事業者としては恐らく本意では無いでしょう。
　きちんとしたエビデンスに基づいて判断されるのが望ましいのではないかと思います。

　ここで重要な役割を果たすのがGCASダッシュボードです。
　
　先に述べた通り、ガバメントクラウドにおけるFinOpsは出来る団体が出来る範囲でやるということになると思います。
　ですので、個人的にGCASダッシュボードは、FinOps分析ツールとしてCostExplorerといったCSPのコスト管理ツールの車輪再発明をするよりは、ガバメントクラウドならではの情報を提供できるようにした方が有益だと思います。

　言い換えれば、各事業者が提供する情報システムのメタ的視点のメトリクスを閲覧できるようにし、システム選定の参考に出来るようにするのが望ましいと考えます。

　例えば、人口10万人規模の住民記録システムのコスト平均などが表示できるようになれば、各自治体にとって有用でしょう。
　更に踏み込んで、デジタル庁の一部職員の中には事業者ごとのコストも公開してしまえという意見もあります。いわば公共情報システムの「価格.com」をGCASダッシュボードでやってしまおうという事です。

　そこまで過激なことは行わないにせよ、口コミだけでなく何らかのオフィシャルなエビデンスに基づいてシステムを選定する方が、より健全な市場競争が育まれるのではないでしょうか。
　同様な観点から公共SaaSに移行したシステムやその料金体系をデジタル庁のウェブサイトやGCASダッシュボードで公開するのも良いと思います。先に述べた通り、自治体にとっては公共SaaSの方がメリットが大きく、選定理由の１つになるでしょう。

　もう１つ重要なファクターとして、地方自治法があります。
　現状、小規模自治体においてシステム調達の事務負担は極めて高いものです。デジタルマーケットプレイスが広まらないのも地方自治法の調達契約関連規定が壁になっているからです。
　筆者は地方自治法こそがロックイン要素になっていると考えます。システム関連に関しては少額随契の額を大幅に引き上げる等、法改正も併せて実施しないと事業者間競争が働かないでしょう。

　最後になりますが、GCASダッシュボードやFinOpsガイドに財務や会計部分の要素をもっと盛り込むべきと考えます。
　
　GCASダッシュボードは現行、請求支払の検査確認には利用できないとされていますが、デジタル庁は当然各団体ごとの請求額やその計算過程を把握しているため、そうした情報が参照できるようにするべきです。
　恐らく一般的な規模の自治体の場合は、FinOps目的よりこの請求支払の検査確認用途の方が望まれているでしょう。　
　
　同様にFinOpsガイドについても、読者を情報政策担当課長や情報システム担当職員のみならず、財政部門や会計部門の職員に対象を拡大し、クラウドエコノミクスに理解を求めるような内容に拡充するのが良いと思います。

　「ガバメントクラウドに構築された標準準拠システムの中から好きなものを選ぶことができ、レゴブロックのようにシステムを自由に入れ替えることができる」

　システム標準化プロジェクトの初期にデジタル庁幹部の方がそのように説明されました。
　現状そのようにはなっていませんが、そこへの道はまだ完全には閉ざされてはいないと考えます。