システム標準化にかかる調達について
デッカイギの実行委員会の方から依頼を受けて、1/6（土）13:00-15:30開催予定の「標準化困りごと相談会」にて「調達」コーナーのファシリテーターを行う事になりました。
どのような場になるか今から楽しみですが、その予習として、システム標準化関係の調達について、どのようなものがあるか、事前におさらいしておこうと思います。
解説には以下のアーキテクチャ図を用います。左側が自治体庁舎で右側がガバメントクラウド（例としてAWS）です。
１．ガバメントクラウド利用権付与・運用管理委託契約
ガバメントクラウド利用基準に示されている、ガバメントクラウドの利用にかかる自治体とデジタル庁との契約です。基本的には自治体ごと、CSPごとに締結を行い、システム単位やベンダ単位で締結を行う必要はありません。共同利用方式についても同様です。
形式上委託契約ですが、委託者がデジタル庁であり、受託者が自治体です。そして受託者から委託者にクラウド利用料を支払うという不思議な契約になっています。
手続き自体はウェブ画面で利用規約への同意ボタンを押すだけであり、自治体内部での事前調整や意思決定さえ済んでいれば、時間はほとんどかかりません。ただ現状クラウド利用料が発生しないため、発生するようになった場合の支出負担行為をどう整理するか、内部で事前調整しておいた方が良さげです。
一方で別途利用申請が必要であり、こちらはより詳細で複雑な手続きとなりますが、本筋から外れますので割愛します。
また細かい話で、払い出されたアカウントに用いるMFAハードデバイスも必要になりますが、こちらも少額ですので割愛します。
名古屋市の場合は、デジタル改革推進課が代表で本契約の締結を行っています。
２．アプリケーション等提供・保守契約
ガバメントクラウド利用基準に示されている、標準準拠システム（共通システム含む）の提供にかかる自治体と事業者との契約です。
とはいえ、実態としては標準準拠システムのパッケージソフトだけではなく、その周辺のクラウド環境の構築も含めた契約になるはずです。
例えばＡ社開発のパッケージソフトを運用ベンダのＢ社経由で調達する際、ほとんどの場合はＡ社とＢ社両方と個別に契約するわけではなく、Ｂ社のみと契約することになるはずです。ですので基本は後述（3-1）する運用管理補助者がASP事業者を兼ねる契約を締結することになると思われます。
３．ガバメントクラウド運用管理補助委託契約
ガバメントクラウド利用基準に示されている、クラウドインフラの運用管理にかかる自治体と事業者との契約です。
標準準拠システムに関係なく、とにかく委託内容にガバメントクラウドの運用管理要素が入っており、管理コンソールからガバメントクラウドを操作することがあれば、全部この契約に該当しますので、実態としては様々なものがあり得ます。
代表的なものは「標準準拠システム等の運用環境の提供」や「各標準準拠システム環境とのネットワーク接続」ですが、例えば「クラウド運用最適化やモダン化にかかるコンサルティング業務」なども事業者が管理コンソールから運用状況を確認する必要があれば、この契約に該当すると思われます。
気づかれたかもしれませんが、この契約の範囲は１のガバメントクラウド利用権付与・運用管理委託契約と同じです。
デジタル庁から見ると、本契約はガバメントクラウド利用権付与・運用管理委託契約の再委託契約となるため、利用申請時にこの契約に関する事項の記載が必要になります。
３-1．ガバメントクラウド運用管理補助委託契約（標準準拠システム等の運用環境の提供）
クラウドインフラ運用管理のうち、標準準拠システム等の運用環境の提供にかかる自治体と事業者との契約です。（過去の筆者のnoteでは広義の運用管理補助者という名称を用いていました。）
実態としては、アプリケーション等提供・保守契約の事業者がそのクラウド運用環境の構築も行う場合がほとんどであるため、アプリケーション等提供・保守契約と併せた一本の契約になるはずです。一応、分けて契約することは可能ですが、メリットはほぼありません。
機能要件の大半がアプリケーション等提供・保守、非機能要件の大半が運用管理補助委託になりますが、そうしたことを意識せず、とにかく自治体に必要な作業を包括的に仕様に書けば良いと思われます。
名古屋市の場合は、業務を所管する事業担当課がこの発注・契約を行っています。
３-２．ガバメントクラウド運用管理補助委託契約（各標準準拠システム環境とのネットワーク接続）
クラウドインフラ運用管理のうち、庁内と各標準準拠システム環境とを接続するクラウドネットワークインフラの提供にかかる自治体と事業者との契約です。（過去の筆者のnoteでは狭義の運用管理補助者という名称を用いていました。）
標準準拠システムをSaaSのように利用とはいいつつ、実際は特定個人情報保護の観点から閉域網経由の利用が必須であり、その回線をベンダごとシステムごとに用意するのは現実的ではありません。
そのため、１組だけ回線を引いて各システム環境へのアクセスを確保し、交通整理を行う必要があります。
従来に無い役務であり、この部分をどこの事業者に任せるのか。また、単独の契約とするのか他の契約と併せるのかといったことが課題になると思います。
純粋に環境間接続ネットワークインフラの構築のみ役務であれば、自治体の情報システムや20業務の予備知識は不要であり、新規の事業者の参入が可能です。ただし自治体側で仕様を書くのが難しいですし、親和性が高いということで共通機能システムの内容（例えばデータ連携のためのS3の整備）も含むのであれば、少なからず業務の知識が必要となり、新規事業者には敷居が高くなります。
現実的には既存事業者のどこかに併せて依頼する形になると思われます。
名古屋市の場合は、この部分を単独で切り出し、ネットワークインフラ構築のみならずガバナンス適用やクラウド上システムの継続的改善といった役務を追加して、一般競争入札（総合評価落札方式）に付しています。
４．ガバメントクラウド接続回線関連契約
ガバメントクラウド利用基準に示されているガバメントクラウド接続サービスに相当する、ガバメントクラウドへの接続回線の確保にかかる自治体と事業者との契約です。
ガバメントクラウド接続サービスの提供はもう終わってしまったので、今後は令和６年度後半導入と言われているLGWAN回線経由での接続か、独自に回線を調達せねばなりません。ベンダ経由でベンダDCからの回線を利用するという方法もあります。
実はこの調達が個人的には最も厄介な調達ではないかと思います。というのも単に線を引けば良いというものでは無く、庁内ネットワークの状況や冗長化等の非機能要件も考慮して調達する必要があるからです。
詳細は次の４－１で述べます。
４-１．ネットワークの全体設計、デザインに関する委託契約
デジタル庁からの事務連絡で示された「ネットワーク構築運用補助委託契約」が相当すると思われます。
庁内ネットワークとガバメントクラウド上のネットワークとは閉域網でつながっており、同一のネットワークアドレス空間ですので、庁内のネットワークのことも踏まえてガバメントクラウド上のネットワークを設計する必要があります。
例えばですが、当然皆さんの自治体では三層分離を実施されていると思います。しかし、デジタル庁のガバメントクラウド推奨構成を見ると、ネットワークは接続回線レベルでは分離されておらず、クラウド上のネットワークでルーティングでアクセス制御を行う仕組みです。
デジタル庁のドキュメントでは庁内側に深く言及されていないのですが、要するにクラウド接続回線につなぐ前に、自治体において三層ネットワークを混ぜる仕組みを予め構築しなければならないということです。
三層分離時に各自治体においてどのような対応を行ったかは定かではないのですが、場合によってはIP重複の問題もあるかもしれません。物理的に回線が分離されており、別ネットワーク空間であればIP重複していても支障が無いからです。その場合、IPを変換する仕組みを構築するか、推奨構成に従わず分離したまま別々の回線としてガバメントクラウドに接続する必要があります。あるいは思い切ってマイナンバー利用事務系のみ対応し、LGWAN接続系はガバメントクラウドに接続せず、必要になってから追加対応するという選択肢もあるかもしれません。
一方クラウド側に目を向けると、それぞれの標準準拠システムに過不足無いIPアドレス範囲を割り当てなければなりません。また、庁内で三層を混ぜてガバメントクラウドに回線を出している場合は、誤ったネットワークセグメントにアクセスされることが無いよう、適切なルーティング設定やそのルールを決める必要があります。
こうした自治体の、庁内からクラウドまでのネットワークの全体設計やデザインを一気通貫で行う必要があり、これを職員が行う事が出来なければ、事業者に委託する必要があります。
名古屋市の場合は、この部分を委託せず、職員のみで実施しました。その結果、ガバメントクラウド接続サービスは利用せず、デジタル庁推奨構成とは異なる方式を採用することになりました。
４-２．ガバメントクラウド接続回線の提供にかかる契約
接続回線本体の契約です。選択肢として大きく次期LGWANか独自調達かの二択になるかと思います。
次期LGWANについては、提供時期の問題と、詳細仕様が明確でない中でネットワークの全体設計を行わなければならないという課題があります。また帯域や冗長化について自治体の望む水準が確保できない可能性があります。
独自調達にはこうしたデメリットはなく、好きな構成を選べますが、純粋に一から仕様を書き下ろす必要がありますので大変です。国のガバメントクラウド接続サービスの調達仕様は参考にはなりますが、自治体のネットワーク状況によりそのまま採用できない場合もあります。
標準準拠システムベンダのDCからガバメントクラウドに接続し、他の契約と併せて一本でやるという方法もあるかも知れません。この場合、ベンダDCへの回線は、当然該当の標準準拠システムの属するネットワークセグメントのものになると思いますので、三層の別のネットワークセグメントをどうするかは別途考えなければなりません。
詳細は割愛しますが、マルチクラウド（マルチCSP）となる場合は更に複雑になります。
名古屋市の場合は、本市要件を満たすための独自の仕様で一般競争入札を行い、調達を行いました。
４-３．庁内ネットワークの変更にかかる契約
ガバメントクラウドへの接続回線を設置するためには、当然庁内ネットワーク機器に回線を接続する必要があり、その設定変更が必要です。また接続回線を独自仕様にせず、国に推奨する仕様に従うのであれば、前述した通り事前に庁内側で三層を混ぜる必要があります。これは次期LGWANの場合も同様だと思われ、LGWAN接続系にマイナンバー利用事務系を引き込む形で混ぜてからLGWAN回線に接続する必要があると思われます。
こうした庁内ネットワークの変更作業を職員が行うので無ければ、事業者に委託する必要があります。当然、４－１で述べたネットワークの全体設計を考慮する必要があります。
名古屋市の場合は、前述のガバメントクラウド接続回線の提供にかかる契約に含める形で、調達を行いました。
５.PMO運営支援にかかる契約
システム標準化全体の進捗管理や課題管理の支援にかかる、自治体とコンサルティング事業者との契約です。特にマルチベンダの場合、進捗や課題の管理の難易度が上がりますので、必要度が高くなります。
名古屋市の場合、他の案件と併せて、一般競争入札（総合評価落札方式）で調達を行っています。
以上、考えられる調達を書き連ねてみました。
調達に関する課題についても書こうと思いましたが、こればかりは自治体によって悩みどころが違うと思いますので、実際現地で直接お尋ねしようと思います。
では、羽田でお会いしましょう。
この記事が気に入ったらサポートをしてみませんか？