ガバメントクラウドは共同利用方式でも安くはならない
何となくそんな気がしていましたが、最近確信するに至りました。
理由を端的にいうと、ガバメントクラウド利用基準等においては、共同利用方式のメリットの部分のみ記載して、デメリットの部分が記載されていないからです。言い換えれば、単独利用方式では発生しない隠れたコストがあるため、単独利用方式と比較して安くなることはないということです。
今回はその理由について説明していきます。また前提条件として、特に記載がない限りCSPはAWSを想定します。
１．顧客である自治体にアーキテクチャを承認してもらうための調整コストが発生する
「ガバクラの単独利用方式と共同利用方式って結局どうなの？」でも書きましたが、ガバメントクラウドの共同利用方式は、市町村としてのガバナンスを放棄し、ベンダに全権を委任する方式です。
痒い所に手が届く運用を望めない代わりに、自治体職員のマンパワーとコスト面で有利になる、そう言う説明をしてきました。
しかしこれは立場を変えてみると、ベンダが一切合切全てを決め、共同利用の参加自治体にそれを承認してもらう必要があるということです。
この「一切合切」の中には、セキュリティ対策やデータのバックアップ方式、大規模災害対策などが含まれます。いずれも自治体として譲れない重要な要素です。ベンダ提案にうまくマッチしていれば良いですが、そうでなければ「その方式は認められない、こうしてくれ」と各自治体から要求されることは自明です。
とはいえ自治体ごとに運用を変えてしまうと、画一的な運用によりコストダウンという共同利用方式のメリットが無くなってしまいます。
この調整だけでも非常に大変なことが容易に推測できます。
２．そもそも共同利用方式のコスト削減効果は限定的
ちょっとテクニカルな話になります。
共同利用方式は、アカウント分離型、ネットワーク分離型、アプリケーション分離型の３つの方式が示されています。前者ほど分離度と運用負荷が高くなり、コスト削減効果が低くなります。
アプリケーション分離型はアーキテクチャとして非常に難しいうえにリスクも高く、この方式を採用するベンダはほとんど無いという認識です。
ネットワーク分離型はいわゆる仮想ネットワーク（VPC）単位で団体環境を分離する方式ですが、１アカウントで運用しますので、CIDRに配慮しなくてはなりません。各自治体の庁内ネットワークのIP重複を避けつつ、参加団体同士でのIP重複も避けて設計を行う必要があるわけです。そしてVPCのCIDRは後から変更できません。（範囲の追加はできます）
最悪、双方向のPrivateLink、あるいは最近導入されたサービスであるVPC Latticeを用いるという方法があります。
何が言いたいかというと、ネットワーク接続に調整が不可欠で、かつ選択肢があるわけです。
この自治体はTransitGatewayでのクロスアカウント接続、この自治体はPrivateLinkというように、個別調整、個別運用が発生します。
これではとても、ベンダが一切合切を決めて画一的な運用とは言えません。
加えてネットワーク分離型は、単独利用方式のシングルアカウント運用と同じ短所を持ちます。即ちIAMの設計運用が複雑化し、リソースのクォータに配慮せねばなりません。端的に言えばCSPのベストプラクティスから外れるアーキテクチャです。
ですので消去法的に、アカウント分離型を採用するベンダが大多数でないかと思います。
アカウント分離型であれば、各自治体の庁内ネットワークはともかく、参加団体同士でのIP重複は配慮する必要はありません。
その代わり、共同利用方式のアカウント分離型は、単独利用方式のマルチアカウント運用と同じ短所を持ちます。
即ち、ControlTowerとOrganizationsが利用できないため、効率的なマルチアカウント運用を行う事が出来ません。そのため、事業者が普通にパブリッククラウドでサービスを提供するよりも運用負荷が高くなり、コスト増の要因となります。
つまり、共同利用方式は３つのパターンが示されていますが、そもそも現実的に選択しうるのはコスト削減効果が一番低いとされている方式です。
そしてその方式もCSPのマルチアカウントベストプラクティス非準拠の運用を強いられるため、コスト削減効果は更に低くなると予想されます。
３．ベンダ間で取り決める各種調整項目が多く、その調整コストと個別管理対応が発生する
最も大きな問題は、標準仕様において、ベンダ間調整として丸投げされており、明示されていない部分が多いことです。
例えばデータ連携です。
標準準拠システムのデータ連携の方式は、住登外宛名番号付番等の一部例外を除いて、原則オブジェクトストレージを用いるファイル連携に変更されました。要するに、AWSであればS3です。
とはいえ、バケット命名規則等の最低限のルールが示されているだけで、アーキテクチャが示されているわけではありません。
S3バケットに連携データが保存されると同時に相手方システムのSNSトピックにバケット通知を飛ばすのか、それとも相手方システムが新規連携データを捕捉するLambda関数を10分置きに起動させるのか。そうした細かい部分は各事業者間で決める必要があります。
そしてオブジェクトストレージを用いたファイル連携も原則であって、API連携も禁じられてはいません。難しい場合はファイルサーバを用いた連携方式も容認されています。
これらの方式のどれを選択し、どう仕様に落とし込むかは関係ベンダ間で調整せねばなりません。
そして共同利用方式ゆえに、発注者である自治体が間に入って調整してくれるということも考えづらいです。そもそも設計レベルの話なので、無理な場合が多いですし、共同利用方式なので調整してほしい設計内容が自治体の要求に合致しないことも考えられます。
これだけでも大変ですが、調整事項はこれに留まらず、各ベンダ環境間の接続をどこのベンダがやるか。その方式はどうするか。名前解決はどうするか。といった課題があります。
（なお環境間接続については「ガバクラの単独利用方式と共同利用方式って結局どうなの？」にて「共通的な部分」として言及しています。）
そして最も大きな課題として、マルチベンダの際の移行過渡期のデータ連携の問題があります。
一方のシステムが標準移行済の場合、そのシステムは当然ですが、標準仕様で連携します。一方で残された現行システムは現行レイアウトのままです。連携するためには誰かが変換をかけないといけません。
変換を担当することとなったベンダは貧乏くじです。
変換の仕組みの開発コストもさることながら、データの変換は必ずしも発注者の自治体が望む形になるわけではなく、説明して怒られなければなりません。当然押し付け合いが発生します。
これらの単件でも非常に重い課題を、受注する自治体について、それぞれ関係ベンダ間で全て決めて合意せねばなりません。そこに発注者である自治体は積極的に関与しない。
仮に顧客自治体が100あり、自治体の平均ベンダ数が３とし、調整項目をデータ連携、過渡期連携、環境間接続、名前解決の４つとすると、８００の調整事項が発生し、それぞれの調整結果を個別に仕様に落とし込み、管理せねばならないということです。
いや無理ゲーでしょ。それにめっちゃ個別管理発生するし、安くなるはずないじゃん(´・ω・｀)
４．運用フェイズにおいても共同利用方式は安くならない
「調整コストがかかるのは分かった。でもそれはイニシャルでしょ、ランニングコストは安くなるんじゃない？」と思われるかもしれませんが、残念ながら運用フェイズにおいても共同利用方式は安くなりません。むしろ、運用フェイズにおいては単独利用方式の方が安くなる可能性があります。
まず、上記でも少し言及しましたが、ベンダ間調整の結果できた個別運用の仕組みが無数にでき、画一的な運用によるコストダウンがそもそも実現できなくなるというのがあります。
そして、こちらの方が大きいのですが、共同利用方式の場合、ベンダはクラウド利用料の削減にかかるインセンティブがありません。
単独利用方式の場合、自治体がクラウド利用コストを可視化して改善をベンダに申し入れることが可能です。
出来るとは限りませんし、この調整や構成変更にかかるコストも恐らく生じますが、少なくとも自治体の努力により運用コストを下げる余地があります。
しかし共同利用方式の場合、ベンダが自腹を切ってアーキテクチャを変更してクラウド利用コストを下げるメリットはありません。
だから共同利用方式においては、以下の図は絵に描いた餅です。
この件に関するデジタル庁の非公式の見解は、「標準化がなされればベンダロックインが解消され、アーキテクチャの最適化やコストダウンに熱心でないベンダは淘汰される」というものです。
確かに理屈としてはそうなのかもしれませんが、実際にはベンダ間調整の結果としてその自治体向けに作りこんだ機能が無数にあります。新規ベンダであれば（アカウントが異なるため）そこの部分の再利用はできず、すべて作り直しです。ベンダ間調整も再度発生します。
自分は事実上そこがロックイン要素になると思います。
自治体側としては、標準化であれだけコストをかけたのに、更に新規ベンダにイニシャルを払うのかということもありますし、小規模ベンダは前述の調整面の困難さから総合的な経営判断で事業撤退する所が増えています。
実際にはコストダウンの努力ではなく、体力のない小規模地場ベンダから脱落していき、緩やかに大手の寡占状態となり、競争性を失っていって、そもそも乗り換え自体が困難になっていくと思います。
５．単独利用方式はどうなのか？
結論から先に言うと、単独利用方式であれば共同利用方式で発生する諸々の課題は解決でき、結果的にコストも安くなると思われます。
ただし単独利用方式を選択するには非常に高いハードルがあります。
単独利用方式はある意味、従来の自治体のフルスクラッチシステム開発の発注と変わりません。
自治体がクラウド運用や標準仕様で明言されていない一切合切の事項について決め、あるいは決めないまでも発注者としてベンダ間調整を仕切ります。
決まった結果に対して個別に対応する必要はありますが、少なくとも調整にかかる負荷は格段に低くなります。
ただしその分の調整コストは自治体に転嫁されます。しかしながら少なくともベンダが調整コストをドーンと積んでくることはないため、額面は安くなるはずです。
留意点として、自治体が仕切らないなら単独利用方式のメリットはなく、共同利用方式と同様な調整コスト等が発生します。
単独利用方式においては、自治体が一切合切を決める必要があり、必要なら調整に乗り出します。
マンパワーも必要ながら、クラウド運用の一切合切を決めて発注仕様に落とし込んだり、両事業者の言い分を聞いて適切に調整を行い判断するには、クラウドのアーキテクチャを語れる水準の職員が必要です。加えて現行システムにも精通していることが望ましい。
成功者バイアスに陥りがちですが、名古屋市のようにたまたまそういう職員が居れば良いのですが、現実的には難しく、クラウドに精通したコンサルティング事業者の助けが必要となるでしょう。
このコストも馬鹿にはなりません。
６．どうすればいいのか
そもそも、ガバメントクラウドの理念と標準化の共同利用方式の組み合わせが非常に相性が悪いというのがあります。
誤解を恐れずに言えばガバメントクラウドは政府機関のために用意されたものです。基本、政府機関のシステムは唯一無二のフルスクラッチシステムで、いわば単独利用方式です。アジャイル開発でモダン化を目指す理念の環境に、パッケージソフト中心で安定稼働重視の自治体基幹業務システムを載せて、コストダウンしましょというのが無理筋だったわけです。
これらの点については、つい最近本市がデジタル庁のヒアリングを受ける機会があり、（ここまで詳細ではありませんが）指摘させていただいたところですので、課題として把握はしていただいたと思います。
かと言って今それを指摘してもどうにもならないのも事実です。無かったことにはできません。
現実的な解決策としては、
〇 標準仕様書において、ベンダ間調整の余地が無い、あるいは少なくなるよう、より詳細に記述する。
〇 ベンダが自治体ローカルではなく、トップレベルで協議し、ベンダ間調整にかかる部分の業界共通ルールを作る。
ぐらいしか無いのではないでしょうか。
噂によると、つい最近、標準準拠システムのベンダによる協議会が立ち上がったと聞きます。
名前しか聞こえて来ず、何をやるかも全く知りませんが、もしそうした場でこれらの課題の解決が図られるのであれば、デジタル庁の理想に少しは近づくのではないかと思います。
他力本願ですが、ベンダ各位の努力に期待します。
うちは関係ないけどなー(´・ω・｀)
この記事が気に入ったらサポートをしてみませんか？