オピニオン
水道事業の広域連携とシステム共同利用
後編: 広域連携後のシステム形態と検討の進め方
2025年01月16日 桑原雅裕
前編では水道事業が置かれている現状を踏まえた広域連携の必要性について考察し、広域連携では既存システムの再構築の検討が必要となることを述べた。
後編となる本稿では、システムを共同利用するためにはどのような形態があるかをインフラ面・機能面から整理し、水道事業の共同利用システムとして考えられる形態を考察する。あわせて実際に共同利用システムの導入の進め方についても考察する。
1.自治体システムの形態
<①インフラ面(サーバー設置・データ管理の場所)>
サーバー設置・データ管理の場所として、主に自庁設置型とデータセンター活用型が考えられる。従来の自治体システムは、Part1でも述べたとおり、自庁舎内にサーバーを設置しデータを管理する自庁設置型が主流であったが、近年はデータセンターを活用する手法が増加している。
両者を比較すると、耐災害性、情報セキュリティ対策の面からデータセンター活用型が望ましいと考えられる。耐災害性としては、データセンター自体が堅牢な建物であることに加え、庁舎とは別拠点でデータ保管をすることで、仮に庁舎が被災したとしてもデータが利用可能となり、災害直後からシステムを活用した迅速な復旧・復興が可能となる。また、情報セキュリティ対策の面では、自庁舎としての設備や情報セキュリティ担当職員の対応では限界がある点を、データセンターの活用により、データ管理に特化した施設・体制にて建物・敷地内の監視やウイルス対策等を行うこととなるため、よりセキュアな環境と言える。
<②システム機能面(機能選択・調整の手段)>
システムの機能面(どのような機能を備えるか)については、スクラッチ開発とパッケージシステムの利用が考えられる。スクラッチ開発とは、自治体が望む機能・運用に合わせて一から「オリジナルシステム」を開発・構築するものである。
パッケージシステムの利用とは、システムを提供する各事業者(以降、ベンダー)が、業務に必要な機能を予め想定し提供される製品(例えば料金システムであれば、受付、開閉栓、検針、調定、滞納整理等の基本的な機能を備えている)を利用しシステムを構築するものである。パッケージシステムは基本的な機能を備えているが、細かな事務の流れは自治体により異なるため、システムをカスタマイズして利用することが多いが、近年ではパッケージシステムが備えている機能に合わせて、自治体側が業務を見直し、カスタマイズを極力行わない「ノンカスタマイズ」の考え方も浸透している。
スクラッチ開発、パッケージシステムの利用について比較すると、一般的には費用面から、パッケージシステムを利用したシステム構築が望ましいと考えられる。スクラッチ開発で一から開発するよりも、パッケージシステムとして備わっている機能にカスタマイズをする方が費用は抑えられる。さらに上記のようにカスタマイズを行わないよう調整を行うことで、個別対応を行う部分が少なくなり、導入に係る時間も大幅に削減することが可能となり、結果的に費用削減につながる。
2.水道事業での共同利用システムとして考えられるシステム形態
インフラ面、機能面をそれぞれ踏まえて共同システムの形態を考えると、耐災害性・情報セキュリティ面の理由から、データセンターを活用した上で、費用面からパッケージシステムへのカスタマイズもしくはノンカスタマイズにて機能を備える形が望ましい。具体的には、①データセンターに利用自治体が共同でサーバーを設置し管理運用を行うパターン、②自治体はインフラやシステムを保有しない形で、ベンダーが提供するシステム(いわゆる「ベンダークラウド」)を共同で利用するパターン、③水道情報活用システムを活用するパターン、が想定される。
水道情報活用システムとは、経済産業省・国土交通省が中心となり水道データの標準仕様を策定しているクラウド型システムの仕組みであり、標準仕様に基づき統一されたデータを、同じく標準仕様に基づき定義づけられる「水道標準プラットフォーム」を介して、ベンダーが提供する業務システム(アプリケーション)を利用するものである。水道情報活用システムの仕組みの中ではデータ規格等が統一された状態となるため、他システムとの連携や移行が容易となる。
例えば、次の「水道情報活用システムの利用イメージ」ではA・B水道事業者が水道標準プラットフォーム介して、運転監視・施設台帳、需要予測システムを共同利用することを示している。デバイス等については、システムの仕様にあわせて導入されていることが多く、従来はシステムを更新する場合にデバイスもあわせて取り換える必要があった。しかし水道情報活用システムの仕組みでは、データ規格やデータ連携仕様が統一されているため、それに準拠したデバイスを導入していれば、システム更新のタイミングで必ずしもデバイスを更新しなくてもよいこととなる。

前述の共同利用システムの3つのパターンにはそれぞれにメリット・デメリットがある。①データセンターでの共同利用では機能・運用面での柔軟性が高いが、自庁設置の場合と同様に自治体側でハードウェア保守を実施する必要があり、職員負担は依然として生じる。②ベンダークラウドではインフラ面も含めてシステムはベンダー側で管理されるが、特定のベンダーに依存しベンダーロックイン(※1)となる可能性が高くなる。また、③水道情報活用システムではデータ規格等が統一されるため、水道情報活用システムに準拠しているシステム間での連携が容易となりデータ移行の負担が軽減されるものの、現時点では水道情報活用システムに準拠していないパッケージシステムも多く、また水道標準プラットフォームを提供するベンダーと、アプリケーションを提供する事業は原則として異なるため、その双方との調整が必要となることが課題である。

また、広域連携に伴うシステム統合では、後から加入する自治体が存在する可能性や、加入時は既存システムを利用し、システム更改のタイミングで広域団体の共同システムに合流する形も考えられる。そのような場合に備えて、利用団体数の増減によるデータ量増減等に柔軟に対応できるかという点も重要である。その場合、クラウド型のシステムのように従量制サービスとして柔軟にデータ量の増減に対応できることが有効であると考えられる。
3.「自治体クラウド」を参考としたシステム共同利用の進め方の検討
システムの共同利用に当たっては、どのようなシステムを構築するか(インフラ面・機能面)に加え、稼働後の運用についても関連自治体間で十分に検討することが必要となる。そのような事項に対する検討の手順については、複数の自治体でのシステム共同利用を前提とした「自治体クラウド」にて「自治体クラウドの現状分析とその導入に当たっての手順とポイント」(総務省自治行政局地域情報政策室 平成28年8月5日)に整理されており、大きな検討過程は次のとおりである。

検討の流れとして特に重要となるのが、Ⅰ事前検討、Ⅱ計画立案の部分である。
Ⅰ事前検討の時点では推進体制が整う前の段階であるので、都道府県が呼びかけて参加意向のある自治体が集まる形や、一部事務組合や規模の大きな自治体を核として協議会等を設置し、検討を進めることが考えられる。Ⅱ計画立案では、後続するⅢ仕様検討・システム選定以降も団体間での協議が必要となるため、円滑に調整を進めるため自治体を超えた推進体制を構築し、具体的に導入計画を策定することが大切となる。
実際に上記流れに沿って進める中で、検討の内容について自治体クラウドと水道事業でのシステム共同利用とでは異なることも想定されるため、以下の2点に留意が必要である。
1点目として、自治体クラウドでは「コスト削減」が議論の中心となったが、水道事業の場合には、水道事業を維持しサービスを提供するための広域連携・システム共同化であることが前提であるため、単にコストだけでなく、長期的な視点での継続性を重視した検討が必要と考える。2点目としては、自治体クラウドで調達対象となる機器はサーバーや端末等ある程度限られており、機器側からの更新タイミング等の制限はそれほど大きくなかったが、水道事業の浄水施設等の設備・機器類も関連する業務システムの場合、システム構築よりも設備等が高額となることも考えられるため、施設等の更新タイミング等を考慮することが必要と考えられる。
以上のように、システムを共同で利用するための手順・ポイントとして、自治体クラウドの考え方を参考にしつつ、各自治体の水道事業の事情も考慮した上で、最も効果的な共同利用システムを検討することが有効であると考える。
4.おわりに
水道事業の広域連携とシステム共同利用についてPart1:水道事業の危機に対応する広域連携とシステムの現状、とPart2:広域連携後のシステム形態と検討の進め方において解説した。今後の水道事業を考えると、広域連携は避けては通れないテーマであり、事業の核となる共同利用システムの導入に向けて、一歩を踏み出すことを検討いただきたい。
(※1)特定のベンダーの製品やサービスに依存し、他のベンダーの製品への移行が困難となる状態。ベンダーロックインに陥ると、価格競争が生じないためシステム費用が高額となることや、システム改修等についてベンダー都合に従わざるを得ないという影響が出る可能性がある。
以 上
※記事は執筆者の個人的見解であり、日本総研の公式見解を示すものではありません。