札幌市では「なんちゃって共通基盤」を招く3つの要因が生じないように考慮したシステム基盤の導入を行っています。

この実現には、システム基盤を構成するさまざまなしくみが関連しています。
全てを紹介するのは困難ですので、今回はそのなかで特徴的なものについて紹介します。

特徴的にな3つのしくみは、
①MW固有の呼び出し記述を排除するソフトウェアFW
②制度ごとに異なる定義を統合する宛名管理
③種類と記述量の多さが特徴的な規約
です。

3.1　MW固有の呼び出し記述を排除するソフトウェアFW

これは、2.1で紹介した「MWと業務システムの境目に緩衝のしくみがない」という問題を解消します。
札幌市のシステム基盤では、業務システムからデータベースや帳票管理などのMW製品等へのアクセスの緩衝となるソフトウェアFWを用意しています。
業務システムからのアクセスはこのFWを介して行うように統制しています(図4)。

これは、AIST包括FWで提供される基礎FW（Javaで作られたFW）を充実させる形で構築しています。

ソフトウェアFWの提供によって、業務システムのプログラムはMW固有の呼び出し記述をしなくて済むようになります。
それにより、MWを同様の仕様を満たす他製品へ置き換えることや、製品のバージョンアップの際の業務システム側の修正を極力生じさせないようにすることが可能になっています。

例えば、リレーショナルデータベースに対するデータアクセスは、オープンソースFWであるHibernate(オンライン処理で利用）やMyBatis(バッチ処理で利用）をベースにしたソフトウェアFWを提供しています。
それによって、業務システムのプログラムのMWへの依存や属人化の原因となるSQL(特にPL/SQLやストアドプロシージャ)の記述を排除しています。

帳票出力についても、帳票種類、帳票レイアウトの項目（名称、日付など）、出力方式（両面印刷やマージン設定など）を業務プログラムから指示すると、帳票MW固有の出力方式に変換して帳票クライアントへ出力要求を行うソフトウェアFWを提供し、業務システムのプログラムから帳票MW固有の呼び出し記述を排除しています。

ソフトウェアFWは、緩衝のしくみとして有効に働きますが、導入にあたって気をつける点があります。
というのも実際に開発を進めていくと、このソフトウェアFWがボトルネックになるケースがあるからです。

その場合、大きくは3つのパターン、
①業務システムの実装品質が悪いパターン
②ソフトウェアFW側で考慮が足りていないパターン
③MW固有の機能の助けを借りなければ達成できないパターン
があります。

これらは、そもそもケースとして生じないように後述する規約での統制や事前ノウハウの提供を行うことが望ましいです。
しかし、実際に発生してしまった場合には、どのパターンに該当するか、誰がどのように対応していくかを開発プロジェクトでのマネジメントのなかで判断していくことが重要になります。

3.2　制度ごとに異なる定義を統合する宛名管理

2.2で紹介した「共通機能の分析が不足している」ことが原因で、使えない共通機能が提供されている典型例が宛名管理の機能です。

そこで、この機能についての札幌市の取組みを具体的に紹介し、共通機能提供において行うべき業務分析の重要性を示したいと思います。

宛名管理が不十分なものになりがちな理由は、宛名の利用は全業務に関わり、それぞれに扱いが異なるため、非常に複雑であるにもかかわらず十分な業務分析をしないままに機能を作っているためです。

札幌市では再構築にあたって、宛名管理について徹底的な業務分析を行うことで、システム基盤の一部としての「統合宛名管理」を実現しました。

「統合宛名管理の考え方」

統合宛名管理は、制度の違いや個人情報保護を担保しつつ、市民へサービスをワンストップで提供できるよう、それぞれの業務システムが扱う個人の情報を許容される範囲において同一人の情報として扱うことができるようにする機能です。

基幹系システムの再構築にあたり、システムを使って宛名を扱っている業務を分析したところ、「宛名」を対象者の氏名、住所といった宛先の情報として扱う業務がある一方で、送付先の情報や折衝の情報といったさまざまな情報も「宛名」として扱う業務もあることがわかりました。

そのため、「宛名」という言葉を明確にしないまま、システムの要件定義を進めると、混乱が起きることが懸念されました。

そこで、まず「宛名」を「行政サービスの対象者となる顧客を管理する台帳である」と定義しました。これによって、ひとりひとり人格を持つ市民自体を扱うのではなく、行政サービスの種類によって異なる扱いをするものであることが明確になるからです。

さらに、顧客台帳で扱う情報範囲を、「基本四情報に加えて、連絡手段、行政サービスに係る権利・義務、徴収先・給付先の銀行口座などの接点にあたる情報」としました。

これは、宛名という情報の単位で、各行政サービスに必要な情報を集約できるようにするのが望ましいと考えたからです。

「3階層での宛名統合」

札幌市のシステム基盤が提供する「統合宛名管理」は、最終的に「人格」、「宛名（顧客台帳）」、「行政サービス」の3階層で統合を行うことにしました。（図5）。

「人格」の階層は、住民を個人として特定するための階層で、複数の宛名として散在する個人を個人番号によって紐付ける役割だけを果たします。

「宛名」の階層は、制度の観点から住民と結び付ける必要のある同一世帯員の情報や、通知物の送付先住所とした情報などを合わせたものを宛名情報として管理します。

「行政サービス」の階層は、札幌市の行政サービスに必要な制度固有の情報を保持する役割を果たします。

宛名管理は業務サービス横断で使いたい機能を共通化するという側面で整理をしてもなかなかまとまりません。
むしろ共通に扱うべき概念の整理と情報の構造化を行うことでより本質的な整理ができたと感じています。

分析をしっかり行わずに機能だけ共通にしてしまうと、制度ごとの差異を吸収できず、共通にならなくなってしまう典型例だと思います。

苦労もありましたが、しっかり分析を行った上で構築したことにより、マイナンバー制度への対応もスムーズに進めることができています。

3.3 種類と記述量の多さが特徴的な規約

2.3で紹介した「業務システムのアーキテクチャ統制が機能していない」を解消するため、札幌市のシステム基盤では規約を提供しています。

規約の提供をシステム基盤の役割としていることを特徴的な点として紹介しましたが、規約自体にも特徴があります。

それは、種類が豊富で１つ１つの記述量が非常に多いということです（表1）。

これらは、開発を進めるなかで、AIST包括FWがもともと定めていたものに加えて、種類を拡充してきたものです。

規約を分類すると、大きく3つの種類があります。

1つ目はルールを定めた「規約」、2つ目は考え方を記した「ガイド」、3つ目は、過去の事例を踏まえた留意点などを記載した「ノウハウ」です。

開発当初はルールを定めた「規約」のみでしたが、実際の開発において規約の解釈に差が出るケースが生じたことから、考え方を記した「ガイド」も作成することにしました。

さらに、開発が進行し先行プロジェクトのノウハウがたまってきましたが、規約やガイドへの追記ではなくプロジェクトで融通が利くほうがよいものが出てきたので、それらを「ノウハウ」としてまとめて提供することにしました。

これらの規約類によって、各業務システムは作りが標準化され、どのシステムも作り方が類似しているため、低い学習コストで他のシステムの開発や保守が可能となっています。

「鶏が先か卵が先か」

規約は、しっかり統制をしていこうとすると種類も量も大量に必要です。

また、規約による統制は業務システムの使い勝手に影響を与えることも多く、しっかり統制したいという想いと、システム基盤が業務要件を制限しすぎてはいけないのではないか、というジレンマに悩むことになります。

特に業務システムの使い勝手に影響を与えるような統制をどこまで行うかについては、実際に業務システムの開発が進捗し業務要件が見えてこなければ判断がつかないケースが多くあります。

このことから、開発の早い段階ですべての規約を揃えることは難しい面がありますが、一方で規約の提示が遅くなることは業務システム開発の手戻りを誘発することにも繋がるため、可能な限り早い段階でそろえることが重要です。

実際に札幌市の開発では、再構築プロジェクトの開始時にすべての規約を揃えることはできていませんでした。特にガイドやノウハウはプロジェクトが進捗していく経験のなかで追加されたものが多くあり、開発の中盤でやっと今のラインナップになりました。

このことからも、規約は先行自治体の事例を共有するといった方法により、可能な限り早い段階で揃えておくことが重要になります。

また、規約が増えるにしたがって、開発のどの段階で何を参照するか探すのが大変になってしまうという状況が生じます。

私たちはこの解決のために、開発の作業段階でどのようなドキュメントを参照すべきかを俯瞰できる地図を作成し「開発イベントマップ」と呼んで提供しています。

おわりに

今回はシステム基盤の導入の際に気をつけるべき内容について紹介しました。

システム基盤は導入だけでなく、開発のなかでの統制や運用開始後にも継続して統制していくしくみ作りも重要になってきます。

これらは後のテーマであるプロジェクト管理や運用保守のなかで紹介していきます。

次回ですが、検討を繰り返し、なかなか着手にいたらないのが自治体のシステム再構築です。

他の自治体などから視察を受けた際に問い合わせの多い、検討開始から事業着手の意思決定やプロジェクトの立ち上げといった「システム企画」部分について札幌市での取組みを振り返り、そのポイントについて紹介する予定です。