ガバメントクラウドの調達公示への考察
10/4 に以下の URL に「デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供－令和 3 年度地方公共団体による先行事業及びデジタル庁 WEB サイト構築業務－」が公示されました。
まず、最初にこれだけの規模感・数のテナントを管理するであろうマルチクラウドは日本のどこでも運用されていない（と思われる）ため、考慮点を網羅することは難しいですが、ガバメントクラウドの運用に備えて先んじて検討して、先行事業の検証内容に生かしていくことが継続的に必要だと考えます。ここではガバメントクラウドに求められる機能といった公開されている情報から、私個人の見解を述べていきたいと思います。そのため、内部的に検討が進んでいること等があり、それらが公開されていないということであれば、そこまでは考慮しておりませんし、考慮できないため、その前提で考察を述べていこうと思っております。また、毎度のことながら、どこかを悪く言ったり、自分たちが有利になろうという意図ではありませんので、予めご了承ください。
マルチクラウド運用
ガバメントクラウドは、公募公告における目的の項の以下文言からマルチクラウドになることが想定されます。つまり、性質の異なるクラウドサービスを複数運用していくことが大前提にある取り組みであることが想像されます。この複数クラウドの運用については、先にも述べましたが、この規模での運用を先んじで実施している先駆者が見当たらないため、参考となる情報が少ない中で非常に難しい運用定義になると考えています。
本公告はクラウドサービスの適正かつ確実な提供を確保するため、公募参加者に対し、その確実なサービスの提供を証明する書類等の提出を求めるものであり、デジタル庁が当該提出された書類等の審査においてクラウドサービスの提供が可能と判断した者すべてと契約の締結を行うものである。
責任分界点
まず、クラウドサービスの利用という観点でも、クラウドサービス事業者との責任分界点は常に課題になりがちです。さらにそこに複数クラウドを考慮した運用を立て付けなければならない点において、難易度が上がっていきます。
今回は地方自治体のシステム標準化におけるプラットフォームとしてのガバメントクラウドの検討であることを前提に課題を整理していきたいと思います。1700以上の自治体が様々なクラウドタイプ（IaaS/PaaS/SaaS）を組み合わせて利用して、それらが複数クラウド上で運用されていくことは、管理者にとっては並大抵のことではないはずです。そういった点も踏まえて、以下の点について、整理していくこととします。
1. どんなシステム構成パターンがあり得るか
2. 誰が責任を追うのか
3. どこまで責任を追うのか
まず、いくつかのシステム構成パターンにおいて、今のままでは責任分界点が曖昧になる可能性があります。例えば、マルチパッケージベンダー構成による 17 業務システムの調達が行われた場合を想定します。1 つのクラウド上で実現されたとしても、権限分掌の観点などから、各アプリケーション事業者間で同じテナントを利用するのではなく、別々のテナントを利用することになると思われます。同じテナント上に複数のアプリケーション事業者を混在させることは設計・運用管理の観点でかなり複雑になるはず。そもそも、同一テナント内での権限分掌設計・設定を誰がやるかもどんなベストプラクティスになるかも、誰が主体となって、どんなリソースの提供の仕方をするか次第になるからです（後述でも別途この問題について触れようと思います）。そのため、アプリケーション事業者ごとに提供するテナント内は自由に構成させたほうが画一的な権限分掌が見込めるのではないかと思います。
どちらのケースにせよ、クラウド内でのテナント間をつなぐネットワーク（例えば、AWS でいう Transit Gateway）は、誰が責任を持つかの議論が必要となります。この部分を、複数のアプリケーション事業者のうちの 1 つが担当するにしても、他のアプリケーション事業者からの変更や障害対応等の要求に相応の SLA で応えて対処をしなければならなくなります。このままでは、迅速性や責任分界点の観点で望ましいやり方とは思えません。また、ガバメントクラウドと庁舎間のネットワークについても、この課題は波及していきます。このように担当するアプリケーション事業者が増えれば増えるほど、責任分界点が非常に難しくなっていきます。
直近で公表された以下の「クラウドサービス提供における情報セキュリティ対策ガイドライン（第 3 版）」にもクラウドサービス利用における責任についての記載がある（P.22 以降）。
責任共有モデルにおけるクラウドサービス事業者とクラウドサービス利用者の責任範囲・内容は一律に決まるものではなく、クラウドサービスの内容やクラウドサービス利用条件・環境ごとに、両者で責任範囲と内容について合意し、契約で明⽰することが重要である。また、双方の責任範囲において、クラウドサービス利用者がセキュリティ上のリスクを判断できるように、クラウドサービス事業者はクラウドサービス利用者に対して、クラウドサービスの内容やクラウドサービス利用条件・環境等について適切に情報提供をする必要がある。
また、IaaS/PaaS/SaaS のどれを利用しているかによっても責任範囲は変わり、それらの組み合わせになった場合は複雑化します。以下では、クラウド利用数とアプリケーション事業者数によるシステム構成ケースを整理し、どのように課題が顕在化しやすいか考えていきます。
1. シングルクラウド・シングルベンダー
このケースにおいては、シングルベンダーが庁舎とのネットワークも担当すれば問題は起きにくいと思われる。
2. シングルクラウド・マルチベンダー
先の例の通り、テナント間の接続とクラウドと庁舎の接続で、責任分界点が曖昧になる。
3. マルチクラウド・マルチベンダー
更に複雑化する。テナント間の接続の問題がクラウドごとに発生し、クラウドと庁舎の接続も複数になるため、責任分界点の定義が非常に難しい。
以上のように、責任分界点が複雑化する恐れが大いにあるため、どのようにこの課題をクリアするかを考える必要があります。テナント間及びクラウド間の接続を、デジタル庁が介在するということであれば統一的な運用が可能になるが、府省のシステムに加え 1700 以上の自治体のシステムを単一の運用チームでホストするのは難易度が高いと思われます（特に、ガバメントクラウドの対象クラウドごとに技術チームが必要となり、24 時間体制の構築が必要になるため）。では、これを自治体側が制御できるかというとかなり難しいと考えます。つまり、このような全体の責任を持ち、システムとして成立することを補助する業者が介在しないとこの問題は解決しないのではないかと考えています。特にシングルクラウド・シングルベンダーであれば、そのアプリ事業者が全てを担当することも考えられるが、アプリ事業者がそこまでやりたくない、もしくはそこまで自社システム以外に精通していないというケースもあるはずです。
統合運用業者の必要性
このように、クラウド間ネットワーク、クラウド内相互接続および全体としての正常性に責任を持つ業者を別途調達しないと、インフラだけ提供する国との役割分担で漏れるところが多くなります。それを補う役割を期待する位置づけのものを調達する必要があると思われます。デジタル庁は、ガバメントクラウドを提供したから、その上にあるものは全て自治体側でやってねということになると、アプリ業者からすると今までに比べて、インフラの中の見えるものが変わってくると思われるため、責任を取れる範囲が限定化されてしまい、契約上、自治体職員に全体の正常性の確認が押し付けられてしまう可能性があるのではないかと考えています。これらは本来の自治体職員が考える範囲を減らすという目的にも反するところになってしまうので、何らかのガイドが必要なのではないかと思います。
リソース妥当性・リソース引き渡し先の検討
今から述べる 2 点は、全体の運用にも関わる部分になります。ガバメントクラウドが誰に対して提供されるものなのかが重要です。こちらもいくつかの検討パターンが存在します。
1. 自治体＝クラウド管理者
自治体に 1 つの基盤（アカウント）として提供して、そこを各アプリ事業者が利用するケース
2.アプリ業者＝テナント管理者
アプリ事業者に、担当する自治体単位で必要になる基盤を引き渡し、アプリ事業者はその上にアプリケーションを構築し、自治体に引き渡すケース
3.アプリ業者＝業者用クラウドリソース管理者(IaaS)
アプリ事業者に担当する自治体数分のトータルリソースを提供して、アプリ事業者が自治体ごとのシステム区切りを作って運用するケース
4.アプリ業者＝業者用クラウドリソース管理者(SaaS)
アプリ事業者がアプリケーション層で SaaS 化してマルチテナント化している場合は、アプリ事業者にガバメントクラウドのリソースを必要に応じて渡さなければならないケース
このようにいくつかのケースが存在します。3,4 に関しては、アプリケーションの作りについて、アプリ事業者に口をだすことは難しいため、両パターンに備えなければならないと思われます。また、2 番目については、自治体単位でどれだけ使っているかを測るには、複数のアプリ事業者の利用料を足し合わせないと見えなくなってしまうことになります（利用するクラウドが複数だった場合にはどうなるであろうか）。
また、ガバメントクラウドの利用促進の目的であるコスト削減を実現するためには、ガバメントクラウド全体の最適化は常に行われるべきです。しかしながら、上記のいずれのケースにおいても、引き渡すべき必要なリソースの妥当性を判断することは非常に難しいです。アプリ事業者から求められる想定リソースが妥当なのかを事前に判断することは更に難しい。また、アプリ事業者からすればインフラ部分についてはコスト負担しないため、安全に舵を切ったサイジングになりがちで大きめに見積もることになると思われます。ただ、先述の通り、これが過大なのかを事前に判断する術がありません。自治体規模によってテンプレート的なものは存在するが、利用頻度などによって異なってくるためです。
使わなければ料金がかからないようにする、もしくは使わない・使っていないリソースは縮小するなどといった手段が考えられるが、後述の予算計上の箇所が重要となってくる。また、使わない・使っていないリソースは縮小するといった方策については、どのタイミングの情報をもって、どれくらい削減できるか、それを誰がどのような判断基準で判断するか、そしてそのレビューの機会をどれくらいの頻度で持つかを定義しなければならない。さらに言えば、これを 1700 以上の自治体のシステムそれぞれに対して、最適化を年に 1 回実施したとしても、365 日のうち 1 日に 5 件程度回さなければならない計算となり、実質自動化しなければ難しい。マルチベンダー・マルチクラウド構成になった場合には、計算ロジックがさらに複雑になることが想定される。
セキュリティの状況変化に応じた動的追従
リソースと同様に 1700 以上の自治体のセキュリティ状況を常に見ておくことは難しいと考えると、デジタル庁が管轄するのではなく、各地方自治体に管理分掌をしなければならなくなります。ガバメントクラウドとしてのインフラ基盤としてのセキュリティはISMAPによる認証があるにしても、そのインフラをどのように利用しているかに対してセキュリティホールは生まれるため、インフラを提供したからセキュリティは各自でという運用ではガバメントクラウドの目的であるセキュリティ向上は見込みにくい。OS・アプリケーション領域及びクラウドの設定にまつわるセキュリティにも引き続き考慮が必要です。そして、クラウド上の構成や設定は常に変わっていきます。半年や定期的なレビューといったやり方では、現代の脅威に遅れを取ってしまう可能性が高い。そのため、ガバメントクラウド利用によってセキュリティ向上を目的とするのであれば、各地方自治体にセキュリティの内容について一任するのではなく、全体のセキュリティホールをデジタル庁が常に見ておく運用が望ましいと考えます。つまり、ガバメントクラウド全体におけるセキュリティに関する変更イベントが発生するごとに自動的にレビューされ、必要に応じてアラートが上がるというような仕組みが必要になのではないかと思います。
こちらも総務省が提示している「クラウドサービス提供における情報セキュリティ対策ガイドライン（第 3 版）」に参考となる記載があります。
Ⅱ．４．３．情報セキュリティポリシーの遵守、点検及び監査
Ⅱ．４．３．１．【基本】 レビュー
> 各情報資産の管理責任者は、自らの責任範囲における全ての情報セキュリティ対策が、情報セキュリティポリシーに則り正しく確実に実施されるように、定期的に及び脅威の変化や設定・構成変更等の状況変化に応じてレビュー及び⾒直しを行うこと。また、組織の情報セキュリティのための方針群及び標準に関し、システムや提供するクラウドサービスが、定めに従って技術的に遵守されていることをレビューすること。
アカウント提供単位と制限・権限管理
先述の権限分掌の運用も検討する必要があります。先程のユースケースごとにどのような権限を自治体 or アプリ業者に引き渡すかを定義しておく必要があります。また、管理権限も多くの項目があり、例えば、サービス利用範囲の制限をするか否か、利用金額の制限をするか否かなども検討項目になるべきです。事前にヒアリングしたサービスだけを許可するのか、予算さえ許せばその他のサービスを利用できる権限を渡すのかも定義する必要があります。
後にも述べる予定ですが、予算を超えた場合にシステム停止してそれ以上の予算を超過させないという手段もあるが、自治体のシステムに於いてはシステム停止に繋がる恐れがあるので、そういった手段は取りづらいと考えます。加えて、予算を段階的に見せてアラートを上げる方法もあるが、段階をどのように定義するのか、障害期間や障害対応方法にもよるが、代替手段による一時しのぎなどの利用料は当初の想定よりも増減することが想定されるため、どう定義するのかをよく検討する必要があります（こちらは詳細について後ほど述べます）。
自治体とのネットワークアドレス設計
先行事業の時点では、クラウドと自治体の接続は専用線が想定されています。これに対していくつかのポイントを述べていきます。
1. 専用線は地域によって導入できるタイムラインが大きく異なります。つまり、すぐに引けるエリアもあれば、下手をすると数ヶ月以上かかる地域もあるため、クラウドの迅速性に比べて回線が追従できないケースが出てくることが想定されます。そのため、LGWAN やガバメントネットワークといった自治体が引き込んでいるネットワークもしくは VPN 等のインターネット網を利用したセキュアなネットワーク構成が望ましいと考える（このあたりは地方自治体の三層分離モデルも関連してきますが、それに関してはまた別途）。
2. 専用線を前提とした場合、マルチパッケージが別々のクラウドで構成されている場合、自治体からは各クラウドに専用線を引く必要があり、クラウド間連携は全て庁舎をまたぐ構成になる。そのため、Equinix のようなクラウドハブ的なソリューションや SDWAN のような仕組みを考える必要がある。もちろんそのような場合においては、クラウド間で適用できるセキュリティ項目・レベルが異なるため、どのように構成するかは各事業者の判断に委ねられるところとなってしまう。クラウドサービス間のネットワークを統合的にセキュリティを掛けるような NOC やセキュリティクラウドサービスの検討が必要となってくる。
3. 最後が、ネットワークアドレス体系についてです。
これもどのように全体設計がされているかに依ります。既存の自治体側ネットワークアドレス体系とクラウド側のIP アドレス体系の間には、整合性が取れていなければいけません。これがマルチパッケージ構成になった場合、パッケージ間のネットワークアドレス体系にも整合性が必要となり、アプリ事業者間の調整が必要になります。ほとんどのクラウドサービスでは、既存で利用していたネットワーク体系をそのまま持って行けるところは少なく、IP アドレス調整が困難になることが想像されます。これらを防ぐために、NAT 構成などを利用することが考えられるが、結局 NAT 構成の外側の IP アドレスと庁内の間には整合性が必要になる。さらに、これは専用線であった場合の話なので、自治体内で整合性が付けばよいが、LGWAN 等の広域専用ネットワークを組んだ場合には、自治体間・アプリ事業者間でのネットワーク整合性を取らなければならない。
自治体においてはセキュリティクラウドなどで既に経験済みの内容になるかと思われるが、それも都道府県内での話となり、今回はそれをも更に超えた枠組みになっていくため、全体の整合性を管理するような運用者・組織を準備することが良いと思われる。ただし、アプリ事業者が SaaS モデルで構成していた場合には更に困難を極めることになるだろう。
マルチクラウド運用の課題まとめ
このように、ガバメントクラウドをマルチクラウドとして運用する場合には、述べてきたような課題が考えられる。このようなことに対する考慮はガバメントクラウドの調達内にも見当たらないのと、先行事業での検証項目として明示もされていないため、このあたりがどうなるのかについては、引き続き注視が必要であると考えています。
1. 責任分界点
2. リソース妥当性・リソース引き渡し先の検討
3. セキュリティの状況変化に応じた動的追従
4. アカウント提供単位と制限・権限管理
5. 自治体とのネットワークアドレス設計
ガバメントクラウドの契約・コスト
続いて、ガバメントクラウドの契約やコストについても、考えれば考えるほど検討項目は多いと思います。それらを深堀りしていきます。今回のガバメントクラウドがクラウドサービスの「単価契約」であることと、「従量課金」であることに関連してくる。これらは、以下の関係書類の中の「クラウドサービス基本契約書」の内容に見てとれます。
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は発表されました。
このような恣意的な記述は、各クラウド事業者の当事者でないとなかなか気づけないポイントであるのではないかと思いますので、他にも同様のものがある可能性が否定できません。つまり、マルチクラウドと言えども非常に選択肢を絞った調達になっているのだと感じています。そのため、こういった調達においても、本質的なところを見た調達をできるようにならなければいけないのだと思います。
ガバメントクラウドの調達に見る今後の課題まとめ
いろいろ書き連ねてまいりましたが、これらの見解は最初にも述べたとおり、以下に基づいております。そのため、至らない点などあれば、適宜ご指摘頂き、本文章をブラッシュアップしていければと考えております。
ガバメントクラウドに求められる機能といった公開されている情報から、私個人の見解を述べていきたいと思います。そのため、内部的に検討が進んでいること等があり、それらが公開されていないということであれば、そこまでは考慮しておりませんし、考慮できないため、その前提で考察を述べていこうと思っております。また、毎度のことながら、どこかを悪く言ったり、自分たちが有利になろうという意図ではありませんので、予めご了承ください。
私は、先行事業の中で検討する価値があるはずの上記のような点が事前に整理され、それらを中心に先行事業が行われるのであれば良いと思っております。しかしながら、それらが一般の目から見えていないことは非常に不安です。そのため、この進め方で本当に当初の目的が実現されるのかが見えていないため、懐疑的になってしまう内容になった箇所もあるかと思います。政府共通プラットフォームのように終息するような流れにならないように、選択肢を提示しながらどう運用していくかまで落とし込めれば、素晴らしい取り組みになると思っていますので、その検討の一助になれば幸いです。