ガバメントクラウドの調達公示への考察 - 後編 -
0/4 に以下の URL に「デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供－令和 3 年度地方公共団体による先行事業及びデジタル庁 WEB サイト構築業務－」が公示されました。
こちらについて、元々の記事が非常に長いため、以下の記事を2分割したものの後編がこちらとなります。
前編をまだお読みでない方はこちらを御覧ください。
ガバメントクラウドの契約・コスト
続いて、ガバメントクラウドの契約やコストについても、考えれば考えるほど検討項目は多いと思います。それらを深堀りしていきます。今回のガバメントクラウドがクラウドサービスの「単価契約」であることと、「従量課金」であることに関連してくる。これらは、以下の関係書類の中の「クラウドサービス基本契約書」の内容に見てとれます。
1. 保守契約の所在と予算確保
上記のように単価契約をする場合は、考えにくいことではあるが、そのクラウドと契約をするアプリ事業者・自治体がゼロのケースが見込まれる。その場合でも、利用者がクラウドサービスを契約した際に付随するような通常の保守契約は提供されるはず。ただし、国のシステムに於いて、高いサポートレベルを求められた場合に、個別にクラウドサービス事業者もしくは関連する事業者と、より高い保守レベルの契約を行うことになることが想定され、契約がゼロだったとしても定常的な予算がかかることが想定される。ちなみに、関連する事業者とは契約が結べない調達になっている。これは応募要領の「公募対象」に以下の記述があるためである。
なお、本公募においては、複数の事業者による共同提案は認めない。
2. 従量課金の予算計上
クラウドサービスはシステムの特性にも依るが、従量料金制を利用するケースのほうがコストメリットがあることも考えられる。その場合に、どのように予算計上をするのかが課題となる。国の予算の仕組み上、天井を決めた上でそこから分配する方式になることも想定されるが、それでは今までの予算計上と変わらず、「使わなかったときに支払わない」ことによるコストメリットが得られなくなってしまう。
また、天井を決める際に問題になるのは、各システムが利用できるリミットを設定できるため、そのような機能を利用することになり、システムの停止もしくは警告の方法によってユーザーを制御することになると思います。ただし、それによる停止が許容されるとも思えないため、警告を発出するといった方法となるのではないかと思います。しかしながら、通常稼働時の見込み金額は設定しておくが、イレギュラーな事態になった場合の考慮が追加で必要となる。
障害発生といったイレギュラーな事象が起きた場合、警告を出してからユーザーに届き、システム改修やそもそも回避ができるものなのかを検討して対処するまでに相当の時間を要することからも、1 段階の警告＝予算の天井にすることはあり得なく、複数段階の立て付けにすることが望ましいと思います。しかしながら、どのような期間、どのようなサービスを利用しているかによって、段階の定義が非常に難しい。また、今までのやり方では回避できない場合は、やはりガバメントクラウドの運用者であるデジタル庁に予算のバッファが必要になることが想定される。
加えて、マルチパッケージ構成＝マルチクラウド状態になった場合に、クラウドをまたいだ天井をどのように制御するかについては検討の余地があると思われる。クラウドごとでの警告の仕組みは形成できるものの、クラウドをまたいだユーザーがトータルで保持している予算をどのように消化できるかはさらなる検討ポイントになります。これが対処されなければ、クラウド A では予算が逼迫しているが、クラウド B では余裕があるという状態の際に、柔軟な運用ができません。そして、地方自治体全体に対してどれだけの共用バッファを見ておくかの見積もりは、現状の可視化の時点から難易度が高いのではないかと思います。
対策としては、 AWS でいうリザーブドインスタンス（前払い式）の料金体系を選択することになるが、それではやはりクラウドネイティブのメリットを得られにくい。また、リザーブドインスタンス型の料金体系を選んだとしても、障害対応における一時的なリソース増強などの必要性のための予算の必要性を考える必要がある。また、ネットワークのダウンストリームの従量課金は逃れるすべがなく（Oracle Cloud Infrastructure の専用線パターンを除く）、監視についてもどれくらいのメトリックをどれくらいの頻度で監視するかであるとか、バックアップの頻度をどのようにするかなど標準化で定義されていないような運用項目については自由度が出てきてしまう。大容量のデータをなるべく頻繁に流さないようにしてくださいといったようなガイドを出すのでしょうか？更にバックアップなどは、差分容量など事前に読みづらいものも存在するため、事前に料金計算が難しくなるのと、どの程度予算を確保しておくかに大きく影響するため、難しさを増長させることになると思います。
このようなクラウドに沿った予算体制の確立・整備と、クラウドネイティブアーキテクチャの組み合わせによって初めてコスト効果が最大化される。しかし、それが全体もしくは一部でしか実現できない場合は、バッファを設けておくか、定額となる箇所をできるだけ増やしてバッファを少なくすることが必要となるはずです。
調達仕様書の中にも以下の記載があり、月次実績レポートを提出することは定められているように見受けられるものの、予算計上とバッファ・複数クラウド利用時の考慮については、難しい検討が必要となると考えています。
８ 実績レポートの提出 （1）クラウドサービスを提供する事業者は、毎月の利用量及び利用料金の確定後、前月分の利用実績を提出するものとする。 （2）実績レポートの内容及び提出時期は、個別契約において定めるものとする。
3. ソフトウェアライセンスのコストの可視化
IaaSを利用したサービス提供をおこなう場合、OS上に導入するソフトウェアライセンスは、各アプリ業者により調達されることになる。今までのライセンスに比べ、クラウド上でのライセンスはそもそも課金対象が異なるケースが多く、持ち込みに制限がある場合もある。本来は、このあたりまで含めたインフラとしての費用が全体的に安くなったかどうかを検証していかなければならないが、ガバメントクラウド側からはそれらの費用が一切見えなくなってしまうため、効果測定が難しくなる。PaaS/SaaSのソリューションを利用すればガバメントクラウド費用として計上できるが、そうでない場合はどれくらい費用がかかっているかわからなくなるため、コスト効果を出すためにはそこまで踏み込んだ調査が必要になる点がネックとなる。
ベンダーロックインを改めて考える
ガバメントクラウドにより、ベンダーロックインを回避し、システム間の柔軟な移行を促進するといったような声がよく聞こえてきます。そもそもベンダーロックインからの解放とは何なのでしょうか？
今回のクラウド要件（別紙 1 基本事項及びマネージドサービスの技術要件詳細）を見て強く感じたのは、国産クラウドベンダーの排除です。国産クラウドの多くは IaaS がメインで、今回の要件に書かれているような PaaS/SaaS 機能は提供していません。さらには、複数の事業者で合同で提案することが許されていない先述の記載があります。つまり、IaaS ベンダー・アプリ事業者がこれらの PaaS/SaaS に相当する機能を、IaaSクラウド上にソフトウェアを使って共同で実現することも今回は許されていません。そのため、IaaSベンダー自らがそのようなソフトウェアを購入・契約締結し、自社サービスとして立て付けることができれば対応可能でしょうが、この期間においてそれを実現するのは不可能でしょう。つまり、Native Cloud と言われるような外資系クラウドベンダーをターゲットにした調達仕様書になっているわけです。そこから推測されるのは、国産クラウドベンダーを利用することが、ベンダーロックインになるため、ガバメントクラウドの対象から外すような書き方にしているということです。その仮説に基づけば、国産クラウドベンダーの何がベンダーロックインと思われているのでしょうか？
大前提として、今回はガバメントクラウドと同時並行でシステム標準化が走っています。その標準化により、業務とデータが標準化され、どのアプリケーションにデータを移行しても利用可能である…はずです。これらの前提において、何がベンダーロックインなのかを考えていきます。
独自ミドルウェア
例えば、ガバメントクラウドの要件のデータベースの項目(別紙 1 基本事項及びマネージドサービスの技術要件詳細)を見てみましょう。SQL Server や Oracle Database といった基幹系におけるデファクトとなっているデータベースソフトウェアの記述がなく、MySQL/PostgreSQL が明示されています。こういった箇所から、独自のミドルウェアがベンダーロックインと思われている可能性を考えてみます。先の標準化がされた状態で、これはベンダーロックインになり得るのでしょうか。
今まで、Oracle Database を使っていたとして、標準化されたデータになっている状態だったとしても、Oracle Database を使っているシステムから抜け出せないようなことになり得るのでしょうか？もしそうであれば、全くシステム標準化の意味を成していないはずです。別にどんなアプリケーションの作りをしていたとしても、データが標準化されていればデータベースソフトウェアに関係なく、移行できるはずです。これが妨げられるようであれば、標準化自体がうまく行っていない可能性があります。
今まではデータの型が標準化されていなかったので、他のアプリ事業者のアプリケーションに移行しづらかった（変換が必要なため）わけで、ミドルウェアのせいではないはずです。もちろん、特定のミドルウェアが高いから、などの理由があるのかもしれませんが、それはそのアプリ事業者が全体を考えた上で、それを利用することに価値を見出しているから利用しているわけです。どちらかと言えば、もし特定の高価なミドルウェアがあったとして、それを利用しているとアプリの値段が高くなってしまい（もしくは他のミドルウェアを使ったほうが安くなる）、今回の標準化によってアプリ事業者を変更することのハードルが低くなったことにより、競争の観点からそういったミドルウェアを選ばなくなる方が健全だと私は考えています。※しかしながら、高度な要件をクリアするためにこのようなミドルウェアが使われることは開発者の観点から選択の自由として尊重されるべきだとも思います。
そういったアプリケーションアーキテクチャにまで介入するのではなく、本来あるべき姿・競争を生み出すような動きのほうが正しいアプローチだと思います。
これはクラウドネイティブアーキテクチャの話も同様のことが言えると思っています。インフラに関する人材が揃っておらず（人材を揃えなくてよく）、どれだけ利用者が増えるかわからないようなサービスに対して、クラウドネイティブアーキテクチャは非常に有効です。OS などの定常的に動いて定量的な金額がかかるものよりも、本当に利用した時間だけ課金されていく仕組みが適しています。
しかしながら、これは独自ミドルウェアと同様に、どんなアーキテクチャやミドルウェアを使ったとしても、それによってどのような結果がもたらされたとしても、それはアプリ事業者としての責任なのです。誰かがそのアーキテクチャの在り方を強制させるべきではないと思います。もちろん、そういったものが利用できるクラウドサービスがあることは歓迎すべきことですが、そういったクラウドサービスを利用したとしても、先の独自ミドルウェアは IaaS を利用すれば利用できないわけではないので意味のないことだと思います。
分散性・自律性
また、国・行政のシステムについては、民間企業のサービスに比べて、分散性・自立性が求められると思っています。今までの地方自治体のシステムの多くは個別に立てられていて、1 つの自治体システムの障害は他の自治体のシステムには影響を及ぼさないことがほとんどでした（JIP-BASE などの共同利用のケースは除く）。しかしながら、今のままのガバメントクラウドは、片手もしくは両手で数えられる程度のデータセンターに集約されることになってしまうため、障害への全体波及度合いを鑑みたクラウドの選択肢の提供がされるべきです。また、クラウドサービス事業者の加入・撤退に左右されることがあってはいけないクラウドであるべきだと思います。そして、今回の対象となりえるクラウドが横並びで並行してシェアを分け合っている現状から考えると、それぞれのクラウドにはユースケースや強みがあり、それぞれの人がそれぞれの価値観で利用しているはずです。そのため、各自治体からも、既存システムが稼働しているクラウドや既存契約の観点から、自分たちのシステムが構築されるべきクラウドの選択をしたくなるはずです。
アプリケーション開発体制（17 業務及びそれ以外も含めて）
それに対して、アプリ事業者が応えていくのは、今まで以上に負荷の高いことだと思っています。各クラウドごとに特徴のあるクラウドネイティブ機能(PaaS/SaaS)があり、特定のクラウドのそれらに準じて作った場合には、自治体からの他のクラウド上での構築要望に応えられなくなる（機会損失の可能性）、もしくは複数のクラウド仕様に伴ったアプリケーション開発を複数並行しなければならなくなります。アプリ事業者としては 17 業務の構築されるクラウドの選択肢に対応していくことに加え、17 業務以外のアプリケーションは引き続きオンプレミスやプライベートクラウドにも当面は残っているわけで、複数の開発体制を組むか、どれかに統一していく必要があるわけです（ガバメントクラウド自体も義務ではないこともあり、多くの状況に考慮したアプリケーションを開発する必要がある）。標準仕様に従う負荷もある中で、2025 年度までに全自治体が標準仕様に準拠できるように、各クラウド仕様にも準拠するというのは大変な負荷だと考えています。これはアプリケーションを開発するための人材育成・確保・維持が今まで以上に負荷になることであり、コスト的にもアプリケーション利用費用に返ってきてしまうのではないかと考えます。
現在からのデータ移行課題
そのような状況下において、先のデータ標準化についても考えなければならないことがあります。データ標準化されるにしても、既存のデータはそれとは違う形で保存されて運用されているわけです。つまり、その既存のデータから標準化されたデータ形式に移行する作業が必ず発生するわけです。それは既存のデータを設計しているアプリ事業者にしか移行ツールを作ることがほぼできないと思います。この部分のほうがよっぽどベンダーロックインなわけで、これがあるからこそベンダーを変えるというのが難しかったのだと思っています。標準化されるためのハードルとして、補助金等で乗り越えていくのであろうとは思いますが、ここで既存アプリ事業者としては、自分たちが選ばれるようなコントロールを入れてくるのは至極真っ当な動きかと思います。
今回の調達
今回の調達方法を見ると、結局ベンダーロックインからの真の脱却というのは難しいのだろうと感じられる箇所があります。そもそも、ある程度必要な機能に絞れば、そこにはそれが選ばれるのは当然という技術は存在します。それはベンダーロックインではないと定義したとしても、調達期間と調達仕様からは、今までのベンダーロックインを忌み嫌いながらも、違ったタイプのベンダーロックインでしかないほうに舵を切ろうとしているように見えています（それが今までよりマシだからというように見えます。）
これだけの大事な選択を求められる調達にも関わらず、必要機能がどういった理由で必須になっているのかなどが公開されていないだけでなく、調達期間が非常に短く見えます。もちろん事前に調達が可能かなどの観点で各クラウド事業者と会話をしていくことは必要だと思いますが、それ以外の事業者にチャンスを与えられないような取り組みに見えてしまいます。また、クラウド要件については国産ベンダーを排除するようなものに見えるだけでなく、機能要件の中には利用されるシチュエーションが見えない機能が必須要件となっているようにも見えます。それらが必須だとしても、サービスとして提供されていなければならない理由が私にはどうしてもわからないのです（ソフトウェアで実現されたとしても良いのではないか）。
また、クラウド事業者に対しても恣意的な記述の多さが目立つように感じます。本当にこれらの要件が求められるのかが明確でないまま、調達するというのは、今までベンダーロックインと揶揄していたものとは別のものを作り出しているだけで、本質的には全く変わっていないのではないかと思えてしまいます。
明確な技術仕様で言えば、以下の点が明確に特定クラウド事業者を縛っていると感じます。
日本国内のデータセンターで当該クラウドサービスを自らが３年以上運営していること
ちなみに調べてみたところ、以下の通りで、Oracle だけ外れることになります。（果たして3年というのはどこから来ているのでしょうか？）
- AWS : 2011/03/02
- Azure : 2014/02/26
- Google : 2016/11/08
- Oracle : 2019/05
オンプレミスにもクラウドサービス、API、ツールを提供しアプリケーションの実行、管理、セキュア化が行えるサービスが提供されていること。
特にオンプレミスでも同様の環境を用意できることと言うのは、AWS Outposts/Azure Stack といったものに限定され、Google や Oracle では実現できないのではないかと思っています。※ちょうど執筆時点でGoogleは発表されました。
このような恣意的な記述は、各クラウド事業者の当事者でないとなかなか気づけないポイントであるのではないかと思いますので、他にも同様のものがある可能性が否定できません。つまり、マルチクラウドと言えども非常に選択肢を絞った調達になっているのだと感じています。そのため、こういった調達においても、本質的なところを見た調達をできるようにならなければいけないのだと思います。
ガバメントクラウドの調達に見る今後の課題まとめ
いろいろ書き連ねてまいりましたが、これらの見解は最初にも述べたとおり、以下に基づいております。そのため、至らない点などあれば、適宜ご指摘頂き、本文章をブラッシュアップしていければと考えております。
ガバメントクラウドに求められる機能といった公開されている情報から、私個人の見解を述べていきたいと思います。そのため、内部的に検討が進んでいること等があり、それらが公開されていないということであれば、そこまでは考慮しておりませんし、考慮できないため、その前提で考察を述べていこうと思っております。また、毎度のことながら、どこかを悪く言ったり、自分たちが有利になろうという意図ではありませんので、予めご了承ください。
私は、先行事業の中で検討する価値があるはずの上記のような点が事前に整理され、それらを中心に先行事業が行われるのであれば良いと思っております。しかしながら、それらが一般の目から見えていないことは非常に不安です。そのため、この進め方で本当に当初の目的が実現されるのかが見えていないため、懐疑的になってしまう内容になった箇所もあるかと思います。政府共通プラットフォームのように終息するような流れにならないように、選択肢を提示しながらどう運用していくかまで落とし込めれば、素晴らしい取り組みになると思っていますので、その検討の一助になれば幸いです。