共闘プラットフォームで真っ先に話題に出たのがSLAだ。ただ、一般的なそれとは様相が違う。あまり真剣に時間を割く必要もないだろうというのが私の見解だ。ただし、これを機に稼働率とコストの意識改革を自治体、ベンダーとにも求める。 A.1.5.1/可用性/継続性●メトリクス 稼働率 ●メトリクス（説明） 明示された利用条件の下で、情報システムが要求されたサービスを提供できる割合。 明示された利用条件とは、運用スケジュールや、目標復旧水準により定義された業務が稼働している条件を指す。 その稼働時間の中で、サービス中断が発生した時間により稼働率を求める。 一般的にサービス利用料と稼働率は比例関係にある。 ●標準選択レベル 3（99.5%） ●選択時の条件 ベンダーのサポート拠点から、車で2時間程度の場所にあることを想定。 １回当たり6時間程度停止する故障を年間２回まで許容する。 [+] コストと地理的

キホン編に引き続き、今回は自治体が主体的に決めるべきまとめておくべき要件をピックアップ。ベンダーがほぼ関与しない（できない）ので、各自治体の方々が抑えておく必要がある。要件の数としては多くなく、日頃からキチンと情報システムに関する要件をルール化されている自治体はまとめる程度でよいだろう。 E.1.1.1/セキュリティ/前提条件・制約条件●メトリクス 順守すべき規程、ルール、法令、ガイドライン等の有無 ●メトリクス説明 ユーザが順守すべき情報セキュリティに関する規程やルール、 法令、ガイドライン等が存在するかどうかを確認するための項目。 なお、順守すべき規程等が存在する場合は、 規定されている内容と矛盾が生じないよう対策を検討する。 （例） ・情報セキュリティに関する法令 ・地方公共団体における情報セキュリティポリシーに関するガイドライン（総務省） ・その他のガイドライン ・その他のルール

今回は、自治体システム標準化においてあまり話題に出ない「非機能要件の標準」を何回かに分けて執筆したい。 話題に出ないのは、おそらくあまり知られていない？のではないかと心配している。実は、「非機能要件の標準」は結構大事なのだ。ベンダーお任せの自治体も少なくないだろうが、これに関しての主役は自治体だ！ 標準仕様を満たさないと、標準準拠システムとして認めないと国は言っている。その中には、非機能要件の標準も含まれるのだ。 そして、この要件は非常にコストに影響する要件も多いのだ。 ボリュームのある内容なので、今回はキホン編。 ①非機能要件ってそもそも何だ？機能要件と非機能要件標準仕様！標準仕様！とみんなが騒いでいるのは、機能要件だ。 非機能要件を簡単に言うと、機能要件がどのように動くのかを定義しているものだ。 電卓を例に挙げると、「１+１＝」を入力したら「2」を出力と言うのが機能要件。大概、仕様に書

今回は、地方自治体の大多数を占めるであろう、共同利用方式かつマルチベンダ環境の難しさについて、説明したいと思います。 なお、特に注記が無い限り、ガバメントクラウドのCSPはAWSを想定して説明します。 １．標準準拠システムがSaaSのように使えないのは何故かデジタル庁は標準準拠システムをガバメントクラウド上に構築することについて、「SaaSのように複数ある中から自治体が好きに選んで使えるようになる」「これによりベンダロックインが無くなり、結果的に競争性が働いてコストも下がる」と説明してきました。 要するに、システム標準化により、基幹業務システムの調達が容易となり、自治体職員の負担が軽減され、職員減少による2040年問題を乗り切ることが出来るということです。 後ほど説明するように、現実にはSaaSにもロックイン要素はあります。標準化することによりそれが解消化されるかどうかの議論はさておき、デ

全国約1700の自治体は2025年度末までに主なシステムを標準仕様に準拠させ、その上で政府が運営する「ガバメントクラウド」に原則移行しなければならない。ところが今、この移行作業に暗雲が垂れこめている。標準仕様の改版が続いている上に、岸田文雄政権の経済政策に伴うシステム改修が追い打ちをかけているためだ。 自治体システム標準化・ガバメントクラウドへの移行に関わる自治体職員、ベンダーなどが困惑し続けている中、このまま進めてしまうとシステム障害などを含むトラブルの多発も懸念される。 最前線の現場の声を交えつつ、全国の自治体で今起きている事態やその背景、打開策などを探る。 第4回 「期限ありき」の政治主導はもう限界、岸田政権は行政デジタル化の目的問い直せ 「2030年くらいまで時間をかけないと無理ではないか」。2020年9月に発足した菅義偉政権（当時）が全自治体の情報システムを標準化する法案を検討し

２月５日、総務省は『自治体デジタル・トランスフォーメーション（ＤＸ）推進計画　第２・３版』を公表し、七つの重点取組事項を示しました。「自治体の情報システムの標準化・共通化」は〝筆頭〟項目ではなくなったものの、依然、重要なテーマであり、新年度を迎えて、その対応は一段と加速していくことと思われます。 ＊本内容は、２０２４年３月５日時点で公表されている情報に基づきます。 法制度改正が、移行の足かせに 昨年９月に改定された『地方公共団体情報システム標準化基本方針』において、〈移行の難易度が極めて高いと考えられるシステム〉は標準化期限後の移行を認める方針が示されました。 デジタル庁と総務省は、市区町村に「移行困難システムの把握に関する調査」を実施。その結果、市区町村の約１割で移行困難システムを抱えていることが判明しました。また、50団体・４８７システムが判定保留とされ、今後の精査でその多くが〝移行困

コロナ禍の「デジタル敗戦」を教訓に、政府が推し進める大規模プロジェクト。 全国の自治体を巻き込んで進められてきたが、1割の自治体が目標期限の2025年度末までに間に合わない見込みということが明らかになった。 自治体の現場で何が起きているのか、取材した。（経済部記者 當眞大気） 「自治体のシステムの標準化で移行困難システムの調査、ヒアリングの結果がまとまりました」 河野デジタル大臣は、3月5日の記者会見でこう口火を切った。 全国の自治体を対象に「システムの標準化」と呼ばれる作業を、政府が目標として掲げる2025年度末までに完了できるか、調査した結果を明らかにしたのだ。 間に合わない見込みだと分かったのは171の自治体。対象の全国1788の自治体のおよそ1割にあたる数字だ。 大阪府や埼玉県といった6つの府県のほか、横浜市や名古屋市など20すべての政令指定都市、新宿区や渋谷区といった東京の10の

「移行に対応する能力がない地場ベンダーが撤退する一方、全国一斉の作業に国の制度変更への対応も重なり、大手であっても人手が足りない。既存顧客を引き受けるだけで精いっぱいだ」 全国1788自治体の3.5万近くに上る既存システムを、2025年度までに一斉に作り替える――。「令和のシステム大移動」とでも呼ぶべき、政府主導の巨大プロジェクトが国民生活の裏側で始まっている。 これまで自治体が個別に構築してきた住民記録や戸籍情報などに関する20の基幹業務システムを、政府が示した共通の仕様書（基準）に合う形で作り直す「システム標準化」を行い、政府が整備する「ガバメントクラウド」上で稼働させる。自治体のシステム運用の効率化を図る狙いで、政府はすでに7000億円規模の予算を投入して事業を推進している。 しかし、その作業は当初の想定以上に難航している情勢だ。政府は昨秋、移行が極めて難しい一部自治体については20

自治体職員は年度末の異動が恒例行事となっており、大抵の場合、ローテーション人事で過去の実績などを考慮せずにランダムに振り分けられるのが通例となっていますが、今年はどうなるのか。。。？

庄司昌彦 / Masahiko SHOJI @mshouji 標準化対象である自治体システムの「運用経費3割削減」が #デッカイギ では何度も話題になりました。基本方針に何と書いてあるかをしっかり確認しておく必要を感じたのでシェアします。 「地方公共団体情報システム標準化基本方針」令和５年（2023 年）９月 pic.twitter.com/00D0PhxmEE

デッカイギの実行委員会の方から依頼を受けて、1/6（土）13:00-15:30開催予定の「標準化困りごと相談会」にて「調達」コーナーのファシリテーターを行う事になりました。 どのような場になるか今から楽しみですが、その予習として、システム標準化関係の調達について、どのようなものがあるか、事前におさらいしておこうと思います。 解説には以下のアーキテクチャ図を用います。左側が自治体庁舎で右側がガバメントクラウド（例としてAWS）です。 システム標準化にかかる調達 １．ガバメントクラウド利用権付与・運用管理委託契約ガバメントクラウド利用権付与・運用管理委託契約の範囲　ガバメントクラウド利用基準に示されている、ガバメントクラウドの利用にかかる自治体とデジタル庁との契約です。基本的には自治体ごと、CSPごとに締結を行い、システム単位やベンダ単位で締結を行う必要はありません。共同利用方式についても同様

本記事は総務省・デジタル庁が進める地方公共団体の基幹業務システムの統一・標準化（総務省では「自治体情報システムの標準化・共通化」と記載している）におけるシステムの実装方式の１つである共同利用方式：アプリケーション分離について記載します。 なお「地方公共団体の基幹業務システムの統一・標準化」「ガバメントクラウド」「共同利用方式」そのものの説明は割愛します。Google is your friend. アプリケーション分離とはデジタル庁は共同利用の実現方法として3つの分離モデル（アカウント分離/ネットワーク分離/アプリケーション分離）を示しています。AWSを例にすると以下のようになります。 アカウント分離：自治体ごとにAWSアカウントを別のものにし、それぞれに業務システムを構築する方式。監視、運用管理用のサーバーは共用アカウント上に構築する。 ネットワーク分離：1つのアカウント内の別VPCに自

本記事では、総務省・デジタル庁が進める地方公共団体の基幹業務システムの統一・標準化（以下：標準化）及びガバメントクラウド（以下：ガバクラ）における、ランニングコストについて記載します。 2018年（平成30年）比で3割減の運用経費削減を目指すとされていますが、実現できる雲行きが怪しくなるどころか、増加するのではないかと懸念されています。 この点は、標準化・ガバクラ対応プロジェクトに関わるイチ関係者として思っていることを徒然と記していきます。「こうすればうまくいく！」というものではありませんし、批判をしているわけでもありません。その点は申し伝えておきます。 標準化やガバクラそのものについての詳細は割愛します。Google is your friend. ※本記事は、2023年12月28日時点の情報をもとに執筆しています。 はじめに早速ですがランニングコスト問題に対する私の主張は以下の通りです

政府が自治体システムの仕様統一を決め、来年デジタル化のための新法提出を目指すと報じられました。自治体システムの標準化はかねて総務省で検討が進められてきて、直近もデジタルガバメント閣僚会議の下に設置された「マイナンバー制度及び国と地方のデジタル基盤抜本改善 WG」で議題に挙がり、わたしも議論に参加しています。 技術屋の視点でみると、法律で定められた似たような住民事務を、どうして1740もある自治体がバラバラにシステム構築しているのか、不思議に思われるかも知れません。ひとつのシステムで賄った方が効率的ではないかという意見も大きいのではないでしょうか。 確かにバラバラにシステム構築されているために特別定額給付金などの新しい制度ができた際まとめてシステム改修できずに、大量の手作業が発生して給付に時間を要してしまったことは記憶に新しいところです。もし日本全体で単一の住民システムが動いていて、そのシス