Day18「統合運用業者が何を求められて何をしなければならないか」 @ ガバメントクラウドについて考えるAdvent Calendar 2022
この記事は、ガバメントクラウドについて考える Advent Calendar 2022のDay18「統合運用業者が何を求められて何をしなければならないか」となります。
※こちらの記事は基本的には公開情報を元にしていますが、個人的な妄想・意見も含まれておりますので、ご承知おきください。
このAdvent Calendarは、日々活動している中で課題として感じることなどをどこかで整理しなくてはいけないと思っていて、ちょうど良いタイミングだったので、全日自分が思うところを書くというスタイルにチャレンジして、どこまで続けられるかやってみたいと思います。
https://adventar.org/calendars/8293
以前、以下のツイートに多くのことをまとめてみたのですが、改めて整理していきます。
後々noteにはまとめるとして、ガバメントクラウドについて少しまとめて語っておこう。個人的妄想と推測が入り混じっているので、その前提でご覧ください。
— Junnosuke Nakajima | VMware | Public Sector (@jnakajima1982) October 11, 2022
統合運用業者とは？
ここでは統合運用業者と表現していますが、正式にはこれをガバメントクラウド運用管理補助者とされています。
運用管理補助者の定義は以下の通りとされています。
地方公共団体又は地方公共団体が指定するガバメントクラウドの運用管理を行う 事業者（以下「ガバメントクラウド運用管理補助者」という。）は、割り当てられ たクラウドサービス等を別途定める範囲内で自由に構成することができる。
この記載を見ていて思ったのですが、運用管理補助者でなく、ガバメントクラウド運用管理補助者なんですね。私の課題感として、運用管理補助者としての定義に20業務以外も含まれるのかというのがあったのですが、こちらを見ると対象範囲は20業務となりそうです。つまり、当初私が言っている統合運用業者というのは20業務＋20業務以外を運用する業者と定義したほうが良さそうなので、そう区別したいと思います。
20業務にとどまらないマイナンバー系システム全体を総合的に運用管理する業者は必要になると思いますし、今までは20業務と20業務以外の区別がなかったと思いますし、もしかしたらインフラ基盤運用業者とアプリ業者で分かれていたかもしれません。そのため、この業者間で上手く連携して対応していたのかもしれません。
ガバメントクラウドを利用するにあたって、この整理をしようとすると今のままだと以下の区分けが必要と思います。
20業務のアプリ業者
アプリケーション事業者はオールインワンパッケージ採用の場合は、1社となります。当然ですが、マルチベンダー構成の場合は、複数社となります。
20業務のアプリが載るガバメントクラウド運用業者
オールインワンパッケージ採用の場合、ガバメントクラウド運用業者はアプリ事業者と同一の可能性が高いと思います（ただ、今までの経緯から言っても基盤もアプリも両方見るというアプリ事業者がどれだけいるかというところかなと思います。インフラとアプリで別調達の場合も今までは多かった認識です）
マルチベンダー構成の場合は、おそらく共同利用方式ではなく、単独利用方式が選ばれることが多いと思いますので、アプリ業者とは別にガバメントクラウド運用業者(運用管理補助者)が1社選ばれることになると思います。
20業務以外のアプリ業者とインフラ運用業者
オールインワンパッケージ構成の場合、オンプレミス側でのアプリ業者は20業務以外も見ていると思うため、1社となるはずです。ただし、オンプレミス側のインフラ基盤をアプリ業者が見るかどうかが、もしかしたらガバメントクラウド側のそれとは異なる可能性があります。
マルチベンダー構成の場合も、アプリ業者とインフラ運用業者がほぼほぼ分かれることになるのではないかと思います。
統合運用業者の必要性
今までやっていなかったものをどうするかという議論にもなるのですが、20業務と20業務以外で環境が分かれてしまうことで、それぞれをそれぞれの範疇で運用するということになります。分かれてしまうおかげで統合で運用するかという判断が必要になってきてしまいました。これを別々に運用するのでよいということにすることも出来ますが、20業務と20業務以外で整合性の取れた設計は少なくとも必要となります。ネットワークなどはオンプレミスの延長でガバメントクラウドで設計されなければなりませんし、それに伴ってオンプレミス側とガバメントクラウド側での整合性を取らなくてはならないからです。つまり双方のスキルセットを持った人間が設計しなければならないということになります。もちろん、移行についても手法について設計・実施しなければなりません。
統合運用業者は誰がやるのか
では一体これらの作業を誰がやるのかということになるわけですが、基本的にはアプリ業者のサポートを得ながら、地場のSIerがこの役割を担うことになるのではないかと思います。繰り返し、ここまで述べてきていますが、これらのための人材確保（人材育成含む）が必要です。これは絶対数的な問題と基幹系の運用に足るレベルでできるのかという問題と、2025年度のそれも停止可能期間に集中する移行作業の際に同時に確保できるのかという問題が絡んでいくと思います。そうなると、人材の取り合いとなり、コスト的に見合うのかという問題になってきます。
これらは地場SIerの方々が、これから自治体からの依頼に応じて試算していくことで明らかになっていくと思いますが、今までに比べて設計・運用範囲がガバメントクラウドとオンプレミスの2箇所に広がり、移行作業まで担当することになるため、いくらクラウド側で委託範囲が増えるとはいえ、クラウド上での設計は必要なわけで、コスト面でメリットが出る余地があるようには思えていません。このような形にすることが運用コスト3割削減に寄与できるかというところはまだ私は確信が持てていないというところです。
執筆後記
このようにガバメントクラウドを考えるAdvent Calendar 2022では、以下の流れで進んでいくことになると思いますので、Day18以降もお待ちいただければと思います。
ガバメントクラウドの在り方
ガバメントクラウドの整備における課題感
ガバメントクラウドの利用における課題感
ガバメントクラウドの今後について考えてみる
Twitterなどで情報発信していますので、もしよろしければ覗いてみてください。