事業者間調整の を読む! 調整の具体事例 2024/11/1(Fri) 1

About Me 2 Ｆ氏 2017年に某地方の地場ベンダに入社。業務SEやインフラSEを経て、 現在はガバクラ（OCI）担当マネージャーを兼務。 統合運用管理補助者として各ASPと目下 事業者間調整に奮闘中。。 ※私がOCI担当なこともあり資料が若干OCI視点強めになっている点ご容赦ください・・・ へーしゃについて（私の所属） 某県のいわゆる地場ベンダーです。AWS・OCIを取り扱います。 開発は行っておらず、複数社様のパッケージを担いで運用保守をしています。 自社データセンターで自治体クラウドを提供していますが、標準化対象業務はガバクラへの 移行を行うことになり、庁舎～ガバクラの統合運用管理補助を行うことに。

本LTの対象とする方 -事業者間調整ってリファレンス待てばうまくいくと思っていませんか? -連携要件だけ調整すればよいと思っていませんか? -そもそもどういった「調整」が潜んでいるか把握できていますか? -マルチクラウドでの調整ってなにをすればよいか分かりますか? 1つでも気になる項目がある方、ぜひ最後までお付き合いください! さっそくですが・・・ 3

CONTENTS 01. へーしゃの標準化・ガバクラ対応状況 02. 標準化・ガバクラでの課題と調整の必要性 03. 事業者間”調整”の具体事例 04. まとめ 4

へーしゃの標準化・ガバクラ対応状況 5 AWS NWアカウント OCI 運用管理補助者 （弊社） 保守エリア 自治体 クラウド ガバクラ接続 回線（NaaS） Ａ市 利用端末 FastConnect DC運用 ガバクラ接続回線 ASP・ガバクラ運用管理 NW運用管理 庁舎～DC回線 AWS APSアカウント Ｂ市 DirectConnect 弊社の役割 利用端末

へーしゃの標準化・ガバクラ対応状況 へーしゃが取り扱うパッケージ（一例） 6 ・・・ 健康管理（D社） 介護福祉（C社） 総合行政（B社） 総合行政（A社） ・・・ 自社クラウド 自社クラウド 自社クラウド 自社クラウド 現在 ・・・ 標準化後 稼働基盤（標準化前後） 自治体別導入状況 ・・・ C B A 自治体 ・・・ 10万 5万 1万未満 人口規模 ・・・ AWS OCI OCI 住基 ・・・ AWS OCI OCI 税 ・・・ AWS AWS AWS 福祉 ・・・ IBM IBM IBM ○○業務 自社・自治体内でマルチクラウド・マルチベンダ状態に

CONTENTS 01. へーしゃの標準化・ガバクラ対応状況 02. 標準化・ガバクラでの課題と調整の必要性 03. 事業者間”調整”の具体事例 04. まとめ 7

標準化・ガバクラでの課題と調整の必要性 8 出典:中島淳之介氏 標準化・ガバクラトレーニング資料より

事業者間“協議”から事業者間“調整”により調整役の主体が自治体へ 9 出典:第１回共通機能等課題検討会 出典:第２回共通機能等課題検討会 標準化・ガバクラでの課題と調整の必要性

連携要件の調整が例に挙げられているが、調整事項はそれだけではない 10 出典:第２回共通機能等課題検討会 標準化・ガバクラでの課題と調整の必要性 調整

マルチベンダ・マルチCSPのへーしゃが直面しているあらゆる調整事項 システム間 連携 NW関連 全体設計 ・連携要件 ・技術要件 ・運用設計 ・NWアカウント管理 ・CIDR調整 ・回線調達 ・コスト管理 ・非機能要件への適合 ・責任分界点の整理 And so on･･･ 11 標準化・ガバクラでの課題と調整の必要性

マルチベンダ・マルチCSPのへーしゃが直面しているあらゆる調整事項 システム間 連携 NW関連 全体設計 ・連携要件 ・技術要件 ・運用設計 ・NWアカウント管理 ・CIDR調整 ・回線調達 ・コスト管理 ・非機能要件への適合 ・責任分界点の整理 And so on･･･ 12 標準化・ガバクラでの課題と調整の必要性 なるほど、、 調整が必要なわけだ・・・

CONTENTS 01. へーしゃの標準化・ガバクラ対応状況 02. 標準化・ガバクラでの課題と調整の必要性 03. 事業者間”調整”の具体事例 04. まとめ 13

事業者間”調整”の具体事例 システム間連携の調整 ＮＷ関連 ガバクラ全体設計・調整 ご紹介する具体的事例は次の３つです。 14

システム間連携の調整 ＮＷ関連 ガバクラ全体設計・調整 15 事業者間”調整”の具体事例

調整すべき事項は連携要件だけではなく技術要件含めた幅広い調整が必要 16 -「履歴管理・最新フラグ」が事業者間調整 の例として自治体に説明されたが、調整事 項はそれだけだろうか 出典:第２回共通機能等課題検討会 I think... No..! ・・・ 今後発生するであろう事業者間調整の一例 事業者間”調整”の具体事例 ～システム間連携の調整～ あらゆる課題に対して関係者間の調整は発生する -リファレンスに基づいて調整した結果、発 生する新たな費用はどうするのか -連携元・先システムそれぞれで前提がある 中で柔軟な対応が可能だろうか -双方の事業者が譲れない場合はどうしたら よいのか 調整難易度:シングルベンダ＜マルチベンダ＜マルチクラウド

事業者間”調整”の具体事例 ～システム間連携の調整～ 技術要件の調整には仕様書が示すファイル連携の前提理解が重要 17 出典:共闘プラットフォームマガジン 【ガバメントクラウド】マルチクラウドにおけるファイル連携の課題点（OCI視点強め） 原則 原則とされる上記パターン①の場合の選択肢 カスタムアプリ が必要

事業者間”調整”の具体事例 ～システム間連携の調整～ 各システムで前提とする方式が決まっている 18 AWS OCI 共通機能（庁内データ連携）アカウント OCI Object Storage 業務システム イ 業務システム ロ 業務システム ハ カスタムアプリ 総合行政システムアカウント 福祉系システムアカウント ○○システムアカウント ガバクラ以外のCSP バケットが置かれるCSP 利用者側のCSP パターンA:CSPの認証認可を利用 パターンC:カスタムアプリを介した認証認可 File Storage データの保管場所 ファイルサーバを利用する場合はSFTP等にて接続 OBに対してSFTPを利用する案も? ※便宜上、各CSPの論理区分け単位 を「アカウント」と呼称します。 三者三様の前提を自治体が主体となって「事業者間調整」する。 その為には自治体のリーディングが必要。 パターンC -S3前提 ⇒カスタムアプリ対応が必要。 パターンA -プリンシパル認証等を利用して アクセス可能。 ガバクラ以外のCSP -ファイルサーバなどが有効?

事業者間”調整”の具体事例 ～システム間連携の調整～ 直接の利害関係に無いベンダ同士では建設的な話し合いになるとは限らない -前提とする実装を調整するということは、各自治体に個別最適することになる。 それは標準化の理念と真逆の対応では・・・? へーしゃは各社との対話を通じて最適解を模索中 19 自治体様や関係各社との対話・調整には全体最適の視点が必須! -どのような枠組みのなかでどういう制約がある? -取れる選択肢やメリット・デメリットなどは? -ステークホルダー間で共有し継続的なコミュニケーションが重要。 ⇒自治体様には建設的な意見交換ができるような場づくりを。

事業者間”調整”の具体事例 システム間連携の調整 ＮＷ関連 ガバクラ全体設計・調整 20

事業者間”調整”の具体事例 ～ＮＷ関連～ NW関連のステークホルダーは多岐にわたり調整事項も多い 21 OCI ガバメントクラウド -X社共同利用方式、コンパートメント分離 自治体A AWS ガバメントクラウド -X社共同利用方式 -アカウント分離 AWS ガバメントクラウド -自治体A 単独利用方式 -アカウント分離 ベンダX NaaS 自治体B 自治体C AWS ガバメントクラウド -Y社共同利用方式 -NW分離 Compartment 共通 Compartment 自治体A Compartment 自治体B LGCS AWS ガバメントクラウド -自治体C 単独利用方式 -アカウント分離 自治体 接続回線 ガバメントクラウド NW管理 ASP 自治体C 自治体B 自治体A ベンダXのDC経由 LGCS ｶﾞﾊﾞｸﾗ接続回線 （利用無し） X社 共同利用方式 X社 共同利用方式 OCI NW管理 C 単独利用方式 （利用無し） A 単独利用方式 CSP-A NW管理 CSP:AWS Y社共同利用方式 （ﾈｯﾄﾜｰｸ分離） CSP:OCI X社共同利用方式 （ｺﾝﾊﾟｰﾄﾒﾝﾄ分離） CSP:OCI X社共同利用方式 （ｺﾝﾊﾟｰﾄﾒﾝﾄ分離） 業務ｱｶｳﾝﾄ① （利用なし） （利用なし） CSP:AWS X社共同利用方式 （ｱｶｳﾝﾄ分離） 業務ｱｶｳﾝﾄ② （利用なし） （利用なし） CSP:AWS Y社共同利用方式 （ﾈｯﾄﾜｰｸ分離） 業務ｱｶｳﾝﾄ③ OCI NW運用管理補助者 AWS NW運用管理補助者 庁内NW業者 J-LIS ベンダX 既存回線業者 ASP-X社 ASP-Y社 各登場人物の狭間タスク/責任分界点の調整、誰が行うの?? 左図のまとめ ガバクラ全体NW設計（CIDR重複対策など） -自自治体だけでなく関連自治体とのCIDR調整も必要 -自治体は各ステークホルダーの作業範囲/責任分界点 を把握しておく必要がある -そのためには構成・方式・技術実装など、自治体側 にもかなりのスキルが要求されることに。 ガバクラ運用管理補助者 ステークホルダーの例

事業者間”調整”の具体事例 ～ＮＷ関連～ NW運用管理補助者の担当範囲を確認しタスクに抜け漏れが無いか確認が大事 22 ガバクラNW管理のために -NWアカウント単独利用か共同利用か（メリデメ検討） -単独利用時はGCASユーザ管理、運用管理補助者と調整 -各ASPアカウントへの適切な権限管理と調整 -各ASPアカウントとの接続方式の調整（TGW、PrivateLink） -共通機能（データ連携等）は誰がどこに構築するのか調整 -ガバクラ全体（関連自治体含む）のCIDR調整 NW管理と密接に関係する調整事項が多岐にわたるが NW運用管理補助者はどこまでやってくれるのか NW運用管理補助者の担当範囲を把握することが重要 回線調達のために（すでに完了しているフェーズ） -帯域や可用性などの性能・非機能要件の評価 -コスト評価 -調達先検討（LGCS?独自調達?ASPに依頼?） -マルチCSP時の接続検討（GMCN使う?） 名前解決・証明書管理の調整 -DNS管理、レコード管理の主体は誰か -DNS持たないシステムの名前解決の調整 -庁舎側DNSの設定追加/変更 -証明書管理、許可する通信プロトコル OCI ガバメントクラウド -X社共同利用方式、コンパートメント分離 自治体A AWS ガバメントクラウド -X社共同利用方式 -アカウント分離 AWS ガバメントクラウド -自治体A 単独利用方式 -アカウント分離 ベンダX NaaS 自治体B 自治体C AWS ガバメントクラウド -Y社共同利用方式 -NW分離 Compartment 共通 Compartment 自治体A Compartment 自治体B LGCS AWS ガバメントクラウド -自治体C 単独利用方式 -アカウント分離 自治体 接続回線 ガバメントクラウド NW管理 ASP OCI NW運用管理補助者 AWS NW運用管理補助者 庁内NW業者 J-LIS ベンダX 既存回線業者 ASP-X社 ASP-Y社 ガバクラ全体NW設計（CIDR重複対策など） ガバクラ運用管理補助者 ステークホルダーの例

事業者間”調整”の具体事例 システム間連携の調整 ＮＷ関連 ガバクラ全体設計・調整 23

事業者間”調整”の具体事例 ～ガバクラ全体設計・調整～ 非機能要件の標準への適合確認 -可用性はASPが提供するシステム構成のみではない -回線周り、NW障害にも対応できるのか -自治体所在地の地理的要件も考慮が必要 ガバクラ全体の管理・調整は総合的な知識・技能が必要 24 インシデント発生時の対応フローの策定 -登場人物が多いので責任分界点を明確に -連絡経路・指揮系統などの定義が必要 ガバクラのランニングコスト最適化 -コストと可用性はトレードオフ、ASPがどこまで対応できるのか -非機能要件への適合を自治体がどう判断するか（補助金にも絡む） 単独利用方式と共同利用方式の検討と管理 -自治体でどこまでグリップするのか（したいのか）

CONTENTS 01. へーしゃの標準化・ガバクラ対応状況 02. 標準化・ガバクラでの懸念・課題 03. 事業者間”調整”の具体事例 04. まとめ 25

まとめ -リファレンスだけではうまくいかない -調整するのは連携要件だけではない -幅広い「調整」が潜んでいる -マルチクラウドの調整は関係者間の対話が重要 冒頭の問いに対するアンサー 26 幅広い分野の調整が必要になり、かつ多くの登場人物をコントロールし、それぞれの作業範囲に 抜け漏れがないか、各運用管理補助者の契約範囲が問題ないか、などを調整していく。 →現実的には各登場人物と協力し役割分担をして進めることが大切なのでは? 状況に応じた適切な調整を支援する役割が必要 本質的な運用管理補助者 （統合運用管理補助者） 統合運用管理補助者に求められるスキルは多岐にわたり調達は難しい 公共 標準化 ガバクラ AWS 業務知識 NW知識 × × × × × × ・・・ 事業者間調整の実体 OCI ×

まとめ 27 「こんなはずではなかった」を防ぐためにも 何のための事業者間調整か? ⇒「こんなはずではなかった」を防ぐために。 いままでベンダーがやってくれていたこと、よく言えば「よしなに」やっていたことも。 これからは -登場人物や制度枠組みが変更になり、各登場人物も全体像を掴めていない可能性も -事業者が示す契約範囲（役割分担）だけでは抜け漏れのタスクが発生することも ⇒自治体は、登場人物の役割を俯瞰し全体像を掴む必要がある。 それぞれの前提がある中で「調整」が必要に。 全体像の俯瞰 登場人物との コミュニケーション 全体最適の視点

まとめ 28 「こんなはずではなかった」を防ぐためにも 何のための事業者間調整か? ⇒「こんなはずではなかった」を防ぐために。 いままでベンダーがやってくれていたこと、よく言えば「よしなに」やっていたことも。 これからは -登場人物や制度枠組みが変更になり、各登場人物も全体像を掴めていない可能性も -事業者が示す契約範囲（役割分担）だけでは抜け漏れのタスクが発生することも ⇒自治体は、登場人物の役割を俯瞰し全体像を掴む必要がある。 それぞれの前提がある中で「調整」が必要に。 全体像の俯瞰 登場人物との コミュニケーション 全体最適の視点 行間を読んだ事業者間調整を していきましょう!

参考文献 -自治体情報システムの標準化・共通化に係る手順書4.0版 -各標準仕様書 -第１回共通機能等課題検討会 https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/d64b42c6-b563-49ec-80dc- 93693783a9bc/4ac0cd61/20240904_local-governments-common-features-issue_outline_01.pdf -第２回共通機能等課題検討会 https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/05577db2-dfdd-4d90-b2c1- 44d94639f44e/9d5e4d8b/20240904_local-governments-common-features-issue_outline_04.pdf -標準化・ガバクラトレーニング資料（VMWare 中島淳之介氏） -共闘プラットフォームマガジン 29

ご清聴ありがとうございました！ 30