マルチベンダの全体管理における状況・課題提起・提案
今回は、地方自治体の大多数を占めるであろう、共同利用方式かつマルチベンダ環境の難しさについて、説明したいと思います。
なお、特に注記が無い限り、ガバメントクラウドのCSPはAWSを想定して説明します。
１．標準準拠システムがSaaSのように使えないのは何故か
デジタル庁は標準準拠システムをガバメントクラウド上に構築することについて、「SaaSのように複数ある中から自治体が好きに選んで使えるようになる」「これによりベンダロックインが無くなり、結果的に競争性が働いてコストも下がる」と説明してきました。
要するに、システム標準化により、基幹業務システムの調達が容易となり、自治体職員の負担が軽減され、職員減少による2040年問題を乗り切ることが出来るということです。
後ほど説明するように、現実にはSaaSにもロックイン要素はあります。標準化することによりそれが解消化されるかどうかの議論はさておき、デジタル庁としては「ファミコンのROMカセットを入れ替えるように簡単に標準準拠システムを変更できる」という文脈で説明しているように受け取られますし、実際それを期待した自治体職員も多いと思います。
しかしながら、将来的にはそうなることが理想だということは前置きしますが、実際の移行に向けた過程においては決してそうなっておらず、そして移行完了後もそうはならないと思われます。
このことは全国の自治体職員や関係ベンダが肌で感じておられるのではないでしょうか。どうしてそのような乖離が起きてしまうのでしょう。
２．連携の仕組みを個別に構築する必要がある
それは各業務の標準準拠システム同士が接続し、データ連携をする必要があり、それらの仕組みを個別に作りこむ必要があるからです。そのため、簡単に調達して簡単に変更するということは出来ません。
ここで、SaaS同士もデータ連携するという反論があるかも知れません。確かにそういうケースも多いですが、多くは手動連携です。Ａシステムからデータをエクスポートし、Ｂシステムにインポートするというものです。しかもデータの項目やレイアウトが完全に一致するとは限りません。項目合わせ程度のアシスト機能はあるかもしれませんが、基本はユーザーがオペレーションや編集を行う必要があります。
これが大変な場合、連携の仕組みをユーザー側で作りこみます。バッチを作成したり、LambdaなどのFaaSを活用したり、ETLを導入したりします。SaaSを変更したら当然作りこんだ部分は無駄になってしまいます。
これは標準準拠システムでも同じです。標準準拠システムは連携レイアウトの規格が標準仕様で決まっていますので、何の関連も無いSaaS同士を連携させるよりはマシですが、連携の仕組みを個別に作りこむ必要があることには変わりありません。そして、システムを変更した場合に「作りこんだ連携の仕組み」が再利用できず、無駄になってしまうのも同様です。
連携の規格が標準仕様で決まっているはずなのに、なぜ個別に作りこむ必要があり、再利用が出来ないのか、という理由については後ほど各章で詳しく説明いたします。
３．標準準拠システムの環境間の接続が必要になる
標準準拠システムとSaaSの大きな違いは環境です。
SaaSは基本インターネット上にあります。インターネットに接続し、DNSの仕組みで名前解決さえ出来れば、SaaSへの環境接続ということは気にしなくても構いません。
一方でガバメントクラウド上の標準準拠システムは自治体の庁内ネットワークから専用線で該当のCSPに接続し、閉域ネットワークを形成します。このため、各標準準拠システムの環境が閉域ネットワークの中で適切に接続され、庁内ネットワークとの通信を確保する必要があります。
この環境間接続はクラウドインフラ構築の作業となり、基幹業務システムのベンダに取っては門外漢で中々ハードルが高いことが予想されます。
しかも、AWSにおいては自分が把握しているだけでVPCピアリング、Transit Gateway、PrivateLink、VPC Latticeの４つの方法があります。当然、選択する方法によってベンダが行う作業も異なります。接続する運用管理環境側がTransit Gatewayを選べば、標準準拠システム側はアタッチメントとそのためのサブネットを構築する必要があります。PrivateLinkであればエンドポイントやネットワークロードバランサーが必要です。これらのどの方式を選択するべきなのかは標準仕様で示されていません。環境全体を把握し、最適な方法を選択する必要があります。
加えて環境間接続もただ繋げば良いというものではありません。自治体には三層分離のポリシーがありますから、マイナンバー系の環境とLGWAN系の環境は相互にアクセス出来ないように適切に制御する必要があります。この実装には庁内ネットワーク環境を踏まえた設計が必要です。主観ですが、かなり難易度が高い作業になります。
またマルチクラウドの場合はCSP間接続の仕組みも考慮する必要があります。デジタル庁は国側でCSP間通信に対応すると一度は明言しましたが、その後続報がありません。ここをスコープ外にして良いのか、それとも梯子を外された時のために考慮しておく必要があるのか。対応する場合、LGWANでどこまで対応してくれるのか。考えれば考えるほどリスク要因しかありません。
最も大きな課題は、この環境間接続を誰がどのようにやるか、ということが明確に示されていないことです。デジタル庁は「最初にリフトするシステムや、連携が一番多い住民記録システム、共通機能システムなどのベンダにやってもらえば良い」と言っていますが、慣れないクラウドインフラ構築作業で他ベンダとの仕様調整も発生し、対象自治体の全体ネットワークについても把握して設計する必要があるため、少なくとも自分たちの商品を標準規格に対応させつつ、片手間に出来る作業ではありません。どのベンダもやりたがらないでしょう。
そのため、ここの環境間接続を対応する運用管理補助者の引き受け手がおらず、移行を進めることが出来ないという事態が全国で起きています。
４．標準準拠システム間の連携の難しさ
環境間接続と同様のことがデータ連携にも当てはまります。標準仕様において連携の仕様は定められているといいつつも、実際には以下の３通りがあります。
（１）基本はオブジェクトストレージを用いたファイル連携
（２）API連携も禁止されてはいない
（３）難しい場合はファイルサーバを用いた連携も可能
もちろん、環境間接続と同様に、選択する方式によってベンダが行う作業も異なります。そして標準仕様で決められているのは概要のみであり、詳細な仕様や実装方法については各ベンダが検討せねばなりません。
例えば（１）のオブジェクトストレージの方法１つをとってみても、ファイルの置き場所であるバケットの命名規則等が決められているだけで、ファイルの保存、取得の仕組みについては触れられていません。そして厄介なことに、これらの仕組みは業務要件を考慮する必要があります。
どういうことかというと、例えば住民記録システムと国民健康保険システムの連携を考えた場合、窓口サービスの水準維持のため、住民の異動に関する情報を即時に連携する必要があるわけです。
役場の窓口で「今晩担当エンジニアがデータのインポートとエクスポートを行いますので、国民健康保険と医療証、介護保険の手続きは明日以降になります」という運用には中々できません。もしかすると小規模な町村だとこの水準の運用もあり得るのかもですが、標準準拠システムは政令市も２３区も中核市も使います。
即時の連携方法は、自分が思いつくだけでも２通りあります。
１つはファイル保存時（①）にバケット通知を連携先システムのSNSトピックに飛ばし（②）、それを受けて連携先システムがLambdaなどで保存されたファイルを取得しに行くというもの（③④）。
もう１つは連携先システムがEventBridge等を駆使して１分に1回等の短期間で周期的に巡回用Lambdaを起動させ（②）、新規に保存されたファイルが無いかチェックし（③）、新規ファイルが存在したらファイル取得用のLambdaを起動させ（④）、ファイルを取得する（⑤）というものです。後者はクラウド利用料が中々良いお値段になりそうな気がします。
一方で「即時で無くとも日次連携、翌日に反映できれば良いよ」というものもあるかも知れません。その場合は１日に１回捕捉しにいけば良いということになります。そして同じバケットの中に即時と日次が混在する場合、中々面倒な事になりそうです。
繰り返しになりますが、この即時か日次かといった選択は基本的には自治体の業務要件によって決まります。一方で共同利用方式はクラウドインフラに関して発注者の自治体に依らずベンダ間で調整して仕様を決めることが基本です。そうでないと「SaaSのように」とはなりません。自治体に取って適切な仕組みの実装がされるのか、甚だ疑問です。
このように、（１）のオブジェクトストレージの方式１つ取ってみても、調整して決めなければならない要素が多数ありますが、（２）のAPI連携と（３）のファイルサーバの各方式についても、同様に決めなければならないことが多くあり、ベンダ間で調整して仕様を詰めなければなりません。
詳細は割愛しますが、ベンダが異なる標準準拠システム間の連携が難しいことは分かっていただけたかと思います。
５．実装にはベンダ間のキャッチボールが必要である
ベンダ間で調整して方式を決定できたとしても、実装がまた大変です。
例えば４で述べたオブジェクトストレージを用いたファイル連携には、ファイルの提供元であるＡシステム、保存先のS3バケットを管理する共通システム、ファイルの利用先であるＢシステムの３システムが関与します。
厄介なのは、AWSの特性上、各ベンダが定められた仕様に基づき各々勝手に非同期で実装するというのが難しく、全体手順を考える必要がある点です。
例えば②のS3バケットから通知をBシステムのSNSトピックに飛ばす機能については、共通システム側でBシステムのSNSトピックのリソース名（ARN）の情報が必要です。また同様にBシステムでは共通システムのS3バケット通知の受け入れのため、S3バケットのリソース名が必要です。
このリソース名は該当リソース作成後にAWSが一意の番号を自動付番するため、事前に決めておくことが出来ません。
そのため、共通システムがS3バケットを作成後にBシステムにリソース名を通知し、BシステムにおいてSNSトピックのパーミッションに記述する必要があり、またBシステムがSNSトピックを作成後に共通システムにリソース名を通知し、共通システムにおいてバケット通知の通知先に記述する必要があります。
これは一例ですが、要するに設計のみならず実装フェイズにおいてもベンダ間できめ細かく調整しながら進めなければならないわけです。事前に工程を作業手順レベルまでブレイクダウンして、役割や確認ポイントを決める必要があり、それを怠れば実装作業の途中で頻繁に作業が停止してしまうことになってしまいかねません。
６．移行過渡期の対応を考える必要がある
マルチベンダの場合、現行システムから標準準拠システムへの移行タイミングを特に考慮する必要があります。
と言うのも、一時的に現行システムと標準化移行済みのシステムが併存する状態となり、その期間の移行過渡期のデータ連携方法を考慮する必要があるからです。
全ベンダが一斉同時に標準準拠システムへの切り替えを行う事が出来れば良いのですが、現実にはそうは行かないケースの方が多いと思いますし、仮にそうしたスケジュールで進めることが出来たとしても、一部のシステムのみ移行が失敗してロールバックするといった事態も考えられます。
標準仕様においては、この移行過渡期の対応にかかる方式については規定されておらず、リファレンス提供が行われる予定に留まります。なお2023年12月現在、このリファレンスはまだ提供されていないという認識です。
とは言え、そのリファレンスの内容自体はある程度想定はつきます。共通機能等技術要件検討会データ連携ワーキングチームにおける検討内容によれば、旧システムで変換をかける方法、新システムで変換をかける方法、統合DB等を活用して間に変換機能を設ける方法の３種類が例示されています。
例によって、どの方式を採用するかはベンダ間で調整して決めなければなりません。当たり前ですが、どのベンダも変換機能の実装を自分達ではなく相手方ベンダにやってもらいたいでしょうし、調整が難航することは想像に難くありません。
加えて、この移行過渡期対応の厄介な点は、移行時期の前後を考慮せねばならないことです。２つのシステム間の対応について、その移行順によって旧→新変換を行うのか、それとも新→旧変換を行うのかが変わります。要するに、何らかの事情でスケジュール遅延等が発生し、２つのシステムの移行順序が逆転してしまった場合に、当初予定していたのと全く違う対応事項を行わなければならないということです。極めて綿密なスケジュール管理とリスク管理が求められることになります。
７．全体バージョン管理を考える必要がある
実は、移行過渡期と同様な問題は、本番稼働後も発生します。
標準仕様書は、制度改正により内容が改定されることがありますが、問題はそれによりデータ要件・連携要件に大きな変更（メジャーバージョンアップ）が生じた場合です。この場合の標準仕様書間の整合性については「全体バージョン管理及び標準仕様書改定状況一覧の運用想定例」というドキュメントで整理されていますが、これらの仕様を元にした各標準準拠システムの実装時期の調整については何も触れられていません。
つまり、データ要件連携要件がメジャーバージョンアップした場合に、バージョンアップ対応済みのシステムと、未対応のシステムとが同時に存在し、連携データの不整合が発生する事態が起こりうるわけで、全てのシステムがバージョンアップ対応するまでこの問題は続きます。
言うなれば、移行過渡期の対応と同様の事を、データ要件連携要件がメジャーバージョンアップの都度、実施せねばならないわけです。
８．手詰まりの状況
今まで説明してきたように、標準仕様書のみで各ベンダがきちんと実装できるわけではなく、実際にはありとあらゆる部分において、複数ベンダ間で設計方式を調整し、連携しながら実装する必要があることが分かっていただけたと思います。
これは、関係ベンダが増えれば増えるほど、調整箇所が増え、指数関数的にプロジェクトの難易度が上がることを意味します。誰かが、全体の工程管理や課題管理を行わないと立ち行かなくなるでしょう。
しかし、この事実はベンダからは指摘しづらい状況です。万一指摘した場合、言い出しっぺの法則でその役務を押し付けられかねないからです。
発注者である自治体が自らこのことに気づき、全体工程管理や課題管理をコンサルティング事業者に委託し、あるいは自治体職員が自らその役目を買って出てくれれば良いのですが、そうでなければ手詰まり状態になりかねません。
9．どうすれば良いのか
結局この問題は、標準仕様書（とりわけデータ要件連携要件）に記述されている事項の粒度が荒く、ベンダがそこから具体的な設計を行う必要があることに起因します。それが単一ベンダで解決するものであれば競争領域と見なすことも出来ますが、まずいのは複数ベンダの関与する部分で事業者間調整としてしまっているところです。
標準仕様書の検討段階にて実装方式まで確定させるのは大変かも知れません。しかし、それを曖昧にして現場に丸投げすると、単純計算でその労力は1741×20＝3万5000倍に膨れ上がります。
一番良いのは、データ連携部分の基盤を国が作ってしまうことです。そうすれば「ファミコンROMカセットを抜き差しするように標準準拠システムを入れ替え出来る」というデジタル庁の目標により近くなります。現に、より複雑な仕組みの「マイナンバー情報提供ネットワークシステム」が出来ているのですから、出来ないはずはありません。
国が単一の基盤を作るのが諸般の事情で難しければ、東北・関東などのブロックに分けても構いませんし、都道府県単位でも構いません。
ともあれ、1741自治体の20業務それぞれで、情報連携の仕組みをベンダ間で調整して個別に作り上げるのはナンセンスです。標準システム本体の機能や帳票は標準化するのに、連携の仕組みは各自治体の業務の組み合わせごとにフルスクラッチでオンリーワンのものを作るのと同じ事です。これは疎結合とは言えません。当然、この独自に構築した連携アーキテクチャがロックイン要素となり、競争原理も働かなくなります。
何のために標準化しているか分からなくなりますね。
この記事が気に入ったらサポートをしてみませんか？