仕様書だけが降ってきた――「自治体システム標準化」で現場の混乱を招いた“完成図なき改革”（2/6 ページ）

「自治体システム標準化」と「ガバメントクラウド移行」を巡り、自治体の現場では人手不足、想定外のコスト増、移行遅延、責任の所在の不明確さ――といった深刻な混乱が広がっている。CIO補佐官として、現場で取り組みに関わってきた筆者が「マネジメントの視点」から事業について考える。

[川口弘行，ITmedia]

データ連携・管理のルールが欠落した仕様書

　さらに、現在も進行中であり、将来的にも完全な解決が見通せていない課題の一つに「システム間のデータ連携」があります。

　自治体の中には、いわゆるマルチベンダー方式を採用し、各業務システムをそれぞれ異なる事業者に委託し導入しているケースも少なくありません。このような場合、異なる事業者が提供するシステムの間でデータ連携を行わなければなりません。そして、そのためには、そのためのルールや標準を確立しておく必要があります。

　しかし、政府の方針は、データ連携のルールや標準を明確に定めず、自治体ごとに、システム間の連携ルールを事業者同士で調整させる（いわゆる「事業者間調整」）というものでした。

　一見すると調整による柔軟な対応のようにも聞こえますが、実際には各事業者とも人手も時間も限られており、互いに譲歩する余裕はありません。データ連携は過去の履歴にまで及ぶため、そもそものシステムの設計思想が異なれば、データの持ち方も変わり、連携のための歩み寄りはますます困難になります。

　お気付きでしょうか？　実は「標準仕様書」では、システムの中でデータをどのように管理するのかという基本的な内容が完全に欠落しているのです。4つ目のボタンの掛け違いは、この「データ管理、データ連携のルールや標準の策定を放棄した」点にあります。

　これほどまでに曖昧（あいまい）さが重なれば、ウォーターフォール型の手法には到底及ばない結果となることは容易に想像できます。

　では、アジャイル型を目指していたのか？　という点ですが、これも疑問です。

　一般的にアジャイル型の場合は、ゴール（この場合はWHYが実現できた状態）に最短距離で近付きつつ、その都度発生する課題に優先順位をつけて解決していくことを短期間で繰り返していきます。その際、ゴールに近付くための選択肢（HOW）は可能な限り多様であることが成功確率を高める秘訣となります。

　ところが実際には、筆者が考えていた試みは次々と潰されていきました。

　ここからは、筆者自身にまつわる「標準化」「ガバクラ」のサイドストーリーを記しておきます。

---

　まず1つ目のお話です。

　2019年11月に筆者は　AWS、VMware、通信事業者であるColtと共に東京都港区役所で実証実験を行い、「港区におけるハイブリッドクラウドの検証環境構築と性能評価レポート」という報告書を公開しました。

実証実験時の構成（「港区におけるハイブリッドクラウドの検証環境構築と性能評価レポート」より）

　これは、将来のガバメントクラウドの利用を見据え、クラウド上にサーバを設置しつつ、庁舎内にはストレージを配置するというハイブリッド構成でシステムを運用するものです。これにより、機微な情報を庁外へ持ち出すことなく、クラウドの利便性を享受できる仕組みを目指していました。

　実証実験の結果は良好だったため、筆者はこのハイブリッド構成を選択肢の一つとして検討していたのですが、後にガバメントクラウド上ではこの方式が使えなくなったということを知らされて、断念したことがあります。

　なぜこの選択肢が潰れてしまったのか、その理由は現在も分かりません。

　筆者が課題であると認識していたのは「機微情報の置き場所」だったのですが、今もなお、住民の機微な情報をクラウド上に配置することの是非についても、きちんとした議論がされていないように思います。